[dns-operations] The strange case of fox.com

[Daniel Kalchev]

This issue comes up from time to time… 

> On 1.03.2016 г., at 3:41, Mark Andrews <marka at isc.org> wrote:
> 
> 
> In message <56D4E7A8.7060005 at redbarn.org <mailto:56D4E7A8.7060005 at redbarn.org>>, Paul Vixie writes:
>> 
>> 
>> Mark Andrews wrote:
>>> In message<56D47005.20206 at redbarn.org>, Paul Vixie writes:
>>>> it's never been practical for a registry to check the NS RR's of its
>>>> delegated child apexes. i think that both registrars and registrants
>>>> should do so, and would do so if there were better tooling available.
>>> 
>>> For each NS registered in whois / parent zone
>>> 	dig NS +norec zone +short @NS | tr '[A-Z]' '[a-z]' | sort
>>> 	if (NS set does not match)
>>> 		flag for followup where followup involved re-testing
>>> 			after X hours then sending email to contacts
>>> 			for zone.
>>> 
>>> This is not rocket science.  The tools have existed to do this for
>>> decades now.
>> 
>> mark, we aren't working in the same company now, so let me say something 
>> that's been on my mind for quite a few years now.
>> 
>> you are smarter than almost everybody, and almost everything is easy for 
>> you. please stop pretending that it isn't so, or that you don't know it.
>> 
>> it god damned is god damned rocket god damned science. stop pretending 
>> that these tools are adequate for any significant percentage of 
>> registrars or registrants, because it's not, and i think you know it.
> 
> This boils down to checking two list of names to see if they are
> the same.  We have tools that will give you the lists.  I could ask
> a 12 year old if two list of names are the same and get the correct
> answer.

Paul is correct here. A significant percentage of those who are Registrants or Registrars in this ecosystem have no idea how to do these checks. What is worse, most of those also do not know why they need to care about this — even if the Registry finds out there are differences and passes down this information to Registrar/Registrant. Anything that slows the cash flow is bad for the business… this is the model.

> 
>>> As for whether the Registry / Registrar performs the actual looks
>>> I don't care.  The Registry is clearly responsible for ensuring
>>> that they get performed as they are responsible for the overall
>>> operations of the parent zone.
>> 
>> no, in two ways.
>> 
>> if you're .DE and you have 50M delegations you're not going to be 
>> checking them. for .COM at 100M delegations it's worse.
> 
> These are all checkable.  It doesn't take massive resources to make
> the checks.

This is true. Eventually, you end up with millions of records “something is messed up with this domain”. Then what is an Registry supposed to do?

> 
>> also, ICANN does not allow the registry to take action if it knows that 
>> a delegation is bad. no action, including not notifying registrars or 
>> registrants, and especially not including changing or suspending the 
>> delegation.
> 
> Which just means ICANN stuffed up.

There is no doubt about this. ICANN started this when they introduced Registrars in the sake of competition. They made things worse, when Registrars were made the focal point (of power) and Registries were left as appendixes that are responsible for the database. While according to RFC1951 Registrars don’t even exist and Registries are solely responsible for the proper delegation. And so it was… years ago, at lest with some ccTLDs. (one can argue this was because they were subject to less pressure to be “more like .COM” back then)

Even if the Registrant and Registrar can make their own checks, the ultimate place for consistency checks like this is at the Registry.

The WHOIS mess is again because of ICANN/Registrars — creating “inventions” such as “privacy guard”. 

You can’t put the cart before the horse and expect it will run just as before. DNS has great resiliency and still works, even after all the abuse. I guess we just need to wait until things break - DNSSEC wasn’t good enough for the task  :-)

Daniel


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160301/299dab69/attachment.html>