On 28/03/12 20:35, Don Stokes wrote:
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.
Absolutely. I was more making the point that the UI that permitted
you to do that, also permits others to do the same thing.
I was not aware (from your later comments) that this data is ignored
by the NZRS.
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.
You are absolutely right - this has become much clearer to me in
recent years (having moved NS between IP's several times now) but
Joe-domain-owner isn't necessarily going to know about this.
They're just going to fill in the information the form asks for.
A competent name server operator will refuse to accept a zone with
glue
they don't control.
... So how does this relate to the .nz root zone and glue records
for external DNS Server A records provided during registration,
then? [see below]
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.
This is excellent advice, I think I came to the same conclusion
myself many years ago but it's great to see it articulated somewhere
that it can become a reference to others.
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.
For domains registered by Xtra, even prior to Xtra becoming a
Registrar, alien/terminator were always used.
For domains registered by Customers, they were always told to use
Alien and Terminator, and not to create their own address records -
at least in my experience.
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.
Well I just modified one of my .nz domains (using Discount Domains)
... it previously only had NS address records for it's DNS servers.
I populated the IP of my first DNS server and their web management
tool automatically resolved the other two and has populated the
nameserver fields with both hostnames and IP addresses. The Address
records are indeed outside of the zone in question. (Bonus points,
the IP address field was indeed described as optional.)
As an exercise, I then modified my Primary DNS server for the domain
in question, to be the correct address record, but an incorrect Ip
address (8.8.8.8, ohai Google). It accepted this too, no error, so
there's obviously no checking that the A record matches the IP
involved...
I then attempted to clear the IP address fields entirely. I don't
appear to be able to... this caused the real IP (derived by DNS
lookup) to be put back into the IP address field.
Of course, I needn't worry about this in practice, because based on
your post the IP address is going to be ignored everywhere anyway,
as the A record is not from the same DNS zone?
Thanks for your helpful post Don, good learnings to be had.
Mark.