On 03/28/2012 05:30 PM, Mark Foster wrote:
I note Don that your own domain name has IP's published into the registry (viewed via whois), not just DNS hostnames.
Yep, I certainly do. But that's because I control the name servers that serve up my names, so I ought to know if they're going to change... It's marginally preferable to do it that way, as it means that the addresses of the name servers don't need an extra query to obtain them. I recall a long while ago, a major ISP had its email hosted in domain A, domain A had its NS records in domain B, which in turn had its NS records in domain C, which finally had some actual A records. Note that B was in a different TLD to A & C. Since BIND 8's forwarding strategy goes like this: On receipt of query from client * If query can be answered from known data (authoritative or cached), answer the query * Else, send query to best next hop (again from known data) * Stop. On receipt of query answer: * Cache it. * Stop. It took several retries /by the client/ before it would get through that loop with enough cached answers to get a response. Enough that the client resolver would give up and claim the name couldn't be resolved. A few manual queries could prime the cache enough to get answers, but of course the next time you wanted to send them mail the cache entries had expired and it was off around that loop again... BIND 9 is better at this, actually continuing the recursion on receipt of query answers, so it will eventually give a positive answer (or a SERVFAIL) to a client. But the fact remains that if you have the NS records in the same zone, with glue, no other name servers need to be queried between the registry NSes and the zone's NSes. However, it is a very bad idea to enshrine IP addresses of servers that you don't control into glue records held in registry records the name server operator can't change, as the name server may at some point need to change its IP address. If the NS is in a domain the operator controls, they can just change it (and possibly upstream glue for the NS's name) and the domains carried on it keep working as if nothing happened. A competent name server operator will refuse to accept a zone with glue they don't control. The second best approach, and the best when the registrant and name server operator aren't the same entity, is to use the /same name servers/ as the name server operator's domain, that is: /isp-domain. /NS ns1./isp-domain. / NS ns2./isp-domain. /ns1/.isp-domain/ A /ns1-ip-address/ ns/2.isp/-domain A /ns2-ip-address/ /customer-domain/. NS ns1./isp-domain./ NS ns2./isp-domain./ and not: /isp-domain. /NS ns1./isp-domain. / NS ns2./isp-domain. /ns1/.isp-domain/ A /ns1-ip-address/ ns/2.isp/-domain A /ns2-ip-address/ /customer-domain/. NS cust-ns1./isp-domain./ NS cust-ns2./isp-domain./ as in the latter config, cust-ns1./isp-domain/ won't have a glue record, and ns1./isp-domain/ will need to be consulted to get it before /customer-domain/ can be resolved. I believe Xtra always used alien/terminator as the name servers back in the day; they didn't accept in-domain NS records referring to those IP addresses ... or at least if they ever did, they were a very small minority.
Back in the days when I provided technical support for domain name registrations at Xtra, i'm pretty sure we specified both IP's and Hostnames for everything we registered[1], as it was considered normal, good practise, at the time - it's only in recent years that i've started leaving the IP's out and relying on DNS. But only where the DNS zone i'm relying on is one that I have some faith in, and/or one where I can take responsibility for any muckups that may occur (eg one I manage myself).
NZ has always (since the Waikato University days) only pushed glue records for name servers that are within the domain they are NS for. It's a strategy that has worked extremely well. (Various gTLD registries have had some fairly bad ideas about insisting on glue IP addresses when they don't actually need them.) The "addresses" submitted to the NZ registry for alien/terminator (and other NSes) were often crap (wrong, syntactically incorrect, names instead of numbers, stories about what the registrant did in their holidays et c.); it didn't matter since the data was discarded long before they ever got anywhere near a name server. The only place where the glue for alien/terminator.xtra.co.nz has ever been published in the DNS at any time was alongside the xtra.co.nz delegation. It actually threw me when working on the DRS implementation in early 2000 that the glue data in the Waikato records was such complete garbage. It turned out that they had been capturing it unconditionally, but if the NSes weren't within the domain being registered, it wasn't checked for any kind of validity since it would never be published. A major (and slightly controversial!) part of the DRS deployment was to clean up all the Waikato data before importing it, and in that process the unnecessary glue was removed. The NZRS SRS used to discard unnecessary glue; I believe it now actually rejects it. Other TLD name servers similarly won't publish a glue record for an NS that isn't in the TLD zone. Doing so is disallowed by the DNS RFCs. They may push extraneous glue that's within the same TLD ... they used to, but I'm not sure what current practice is. -- don