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:
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
ns2.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
ns2.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