[EMAIL PROTECTED] wrote:
On Tue, Nov 27, 2007 at 02:05:55PM -0500, Edward Lewis wrote:
At 6:25 PM +0000 11/27/07, [EMAIL PROTECTED] wrote:
then we have a small issue... you as zone admin, can't
dictate which IP's i must use on my machines, since you don't
control my connectivity. as zone admin, your job is to
provide accurate mapping betwn lable and address ... the
extent of your influence is over the lables used, not their
IP addresses.
It is the prerogative of you to do what it takes to get your machine
to function correctly. It's the prerogative of the zone admin to
include (or not) your machine in the NS set.
A zone admin ought to be aware of what the state of the slave servers
are. (That's my main point.) There are minor tweaks, like IP
addresses, and then there are major tweaks, like letting the domain
lapse. A responsible zone admin would be up to date on what the
slave server admins are up to. So, in this case, when the slave
server changes IP addresses, this goes to the zone admin, who would
then have to update the IP addresses registered.
a concrete example:
i have a zone, example.org and chose the following
nameservers:
moe.rice.edu
ns.isi.edu
PDC.example.org
as the admin of PDC.example.org, I know what IP addresses
are assigned and can change them on whim. However, It is
the Height of Arrogance to presume I can tell the rice.edu
or isi.edu people what IP addresses to use on their machines.
Kind of, and maybe.
Basically, glue is necessary only because NS records are allowed to be
FQDNs instead of just IP addresses. (This is so that fewer NS records
need to be updated when a nameserver changes IP address(es).)
And that glue is needed only, strictly speaking, when the NS FQDN is a
subordinate of the (parent) zone.
(Any NS whose FQDN isn't subordinate, is "out of zone data", and
shouldn't be kept as glue in the zone.)
Sometimes the glue isn't really necessary, if the FQDN of the NS is
served by zone whose own NS records don't need glue, e.g. are served by
entirely out-of-zone name servers.
(But that leads potentially to a name-server race condition, which
operators should know to avoid. Having example.net use ns.example.org as
its NS, and having example.org use ns.example.net as *its* NS, is bad form.)
In the example above, moe.rice.edu and ns.isi.edu are outside of the
'.org' zone, and their IP should neither be accepted nor kept.
If, on the other hand, the nameservers were PDC.example.org, and
FOO.other-example.org, then:
- the IP for FOO may already exist, if it is a nameserver for
other-example.org
- even if FOO is not a nameserver for other-example.org, it might be in
future.
So, capturing its IP *might* make sense. But, even if it exists, it
isn't authoritative, so likely won't (or shouldn't) be used.
Which means, unless it comes to pass that other-example.org uses
FOO.other-example.org as their nameserver, the presence or absence of
quote-glue-unquote for FOO is irrelevant and annoying.
And if/when other-example.org adds FOO as their nameserver, they really
do need to provide the IP, at which time the registrar should require
the IP, and the registry operator should accept it as authoritative.
(Whether the things pointed to by the NS records are serving the zone is
a whole other kettle of fish. Lame fish at that.)
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
