Yesterday, I noticed that a client (who has just enough knowledge of networking to be dangerous) had messed up one of his nameserver records. We'd recently relocated to a different colocation provider, and ns2.his-domain.com was pointing back to the network in the recently vacated cabinet. I instructed him, "go to your registrar, and change the IP this name server points to, because until then you have only one working nameserver for all your clients' domains".
Due to time zone differences - he lives in Europe, and I'm in the US - we couldn't talk live.
This morning, I discovered that he'd used a shotgun to solve this problem. Not only did he change ns2.his-domain.com to point to the correct IP, he then proceeded to create more host records - at the registrar level, using their web tools for creating name servers - for every host name he'd ever used in the past, and some that he thought he might want in the future, all of them pointing to the same IP.
ns3.his-domain.com, ns4.his-domain.com, www.his-domain.com, ftp.his-domain.com, kirk.his-domain.com, spock.his-domain.com, scotty.his-domain.com, etc. - all of these may now be looked up with Whois, bypassing our local name server, cluttering up the root name space. He created about twenty host records in the domain registry, all of them pointing to the exact same IP.
My gut feeling is that this is very, very bad. It defeats the fundamental design of DNS, which is supposed to be hierarchical!
What are the consequences of this? Is there anything in the standards - in RFCs or elsewhere - that prohibits this, and describes what might happen as a result?
Example (name changed to protect the guilty:)
$ whois spock.his-domain.com
Whois Server Version 2.0
Server Name: SPOCK.HIS-DOMAIN.COM
IP Address: 22.33.44.55
Registrar: COMPUTER SERVICES LANGENBACH GMBH DBA JOKER.COM
Whois Server: whois.joker.com
Referral URL: http://www.joker.com
-
A couple of things:
I don't think this is very, very bad from the standpoint that nothing is going to happen other than the fact that his namespace is not going to be resolved correctly and consistently until this gets fixed.
As far as hierarchy goes, that hasn't changed. His namespace and DNS records are still at the same level in the hierarchy. Creating multiple name servers doesn't change where his namespace sits in the hierarchy.
The gTLD servers don't care how many name servers he has. They're going to look for the NS for his namespace and refer DNS requests for his namespace to whichever name servers are listed. Because the gTLD servers do not perform recursion, this puts no additional load on them. A DNS client (DNS server on behalf of a client) will ask the gTLD server that's responsible for the relevant gTLD domain (.com, .edu, etc.) where to find his namespace and the gTLD server will refer them to the name servers listed. The DNS client will then query one of the name servers listed.
Other than having some flaky name resolution and failures, I don't see this as an earth shattering problem. The fix is simply to log back in to his registrar's web site and remove the errant records.
Matt Hucke : That's what I've asked him to do (delete the records); he's just going to want to know why, as he'd likely consider it a convenience that all his machines are registered at the registrar, where he can edit them with a web form, and not in some icky complicated name server he has to ask me for help with!joeqwerty : I would explain to him the difference between an NS record and an A record and why he only wants NS records that actually point to real name servers for his namespace. After that, he can create any number of A records, to his heart's content. Good luck with this one. ;)voretaq7 : The best (short) reason to remove these records is "They don't belong at the registrar/tld level because they're not records for a nameserver."From joeqwerty -
As far as I'm aware nothing in the standards prohibits doing what he did, but it's definitely not "correct" -- the records created at your registrar are only supposed to be used for NS glue, and including other records can put an excessive load on the root servers.
In this case I believe the top-level (.com) servers will return the A record they have rather than referring the query to your client's nameserver -- this is certainly not what they want, so the errant records should be removed.
If someone can point to a specific RFC/STD document that prohibits or deprecates this behavior it would be nice to be able to quote that too :-)
From voretaq7
0 comments:
Post a Comment