Hi All
Just a quick question. We are using DeDyn for a couple of applications running in the Azure cloud and recently noticed, that we cannot add IP Addresses from Azure ranges. We always get “IP address x.x.x.x not allowed.”.
Is this a restriction of the DeDyn service and therefore something intentional? If so, would the managed DNS service have the same restriction?
Cheers and thanks a lot for your hard work!
Marc
Hi Marc,
Thank you for your message, and welcome to deSEC 
I’m going to give you a bit of a longish response, so this post will be useful for other people who may have a similar question.
Background
Over the last 8 months, we have seen a lot (several thousand) of abusive registrations under dedyn.io (phishing, malware, …). The amount of work that went into processing abuse reports was very significant, and at the same time we noticed that IP addresses used for these domain names almost never were residential IP addresses.
As a result, we implemented a new policy a few weeks ago: any time we block a domain, we note down the associated IP subnet range(s), and use this list as a blocklist for new IP address records under the suffix dedyn.io. The blocklist almost entirely contains datacenter IP address ranges which are not the primary use case for dedyn.io domains. (They are intended for users who have a dynamically changing IP address, and who need a name mapping.)
Impact
The mechanism has proven very effective: we currently have 55 IPv4 ranges blocked, covering 0.36% of the address space (… that’s more than 1/300!). The number of abuse reports has gone down by a very large factor (I have no measurements, but the factor is perhaps 50)
I’m sorry we had to take this step, but we did not see any other way out. Existing DNS records using these IP addresses, even under dedyn.io, are not touched by the new policy. The policy only affects the creation of new records. As nothing stopped working, we didn’t make a fuss about it (= we did not send you an email). Perhaps that was suboptimal – sorry about that!
Alternative approaches / Workaround
dedyn.io is very susceptible to abuse, because registration is free, and we currently have no KYC procedures: a valid email address at registration time suffices. Other ways to reduce abuse is insisting the customer to be identified at some point, which is complex for us to do. It seems that indirect approaches are most practical, such as requiring a (very small) credit card payment, thereby outsourcing customer ID to the issuing bank. So far, we have not taken that route.
However, for domains where registration comes with a cost, the registrar and/or payment provider will usually identify their customers. We think that it is due to this circumstance that we see very little abuse for other domain names, which our users have to register elsewhere (usually for a fee) and then delegate to deSEC. Therefore, we currently have no restrictions on IP addresses used with non-dedyn.io domain names.
For your specific use case, I suggest delegating a subdomain from your organization to deSEC. You will then be able to use any IP addresses you like.
Stay secure,
Peter
Hi Peter,
Thanks a lot for your detailed answer and background info! Your move makes a lot of sense and your suggestion to use a subdomain delegation sounds perfect.
Best wishes,
Marc