Joe Abley (jabley) writes:
> Hi all,
>
> Comments on this document in this list would be most welcome.
> the MNAME field of an SOA record has no benefit, and in fact may well
> cause unwanted traffic (DNS UPDATE messages) to be received by the
> named server.
... if the named server is at all reachable/exists. Think stealth
servers or other zone population and provisioning mechanisms that do
not use AXFR/IXFR as their method of distribution (i.e. where each
nameserver for the delegation could arguably be itself a master).
I won't even get into MNAMEs pointing to RFC1918 addresses (see
http://www.ripe.net/ripe/maillists/archives/dns-wg/2005/msg00264.html)
> This document specifies a convention by which a zone operator may
> include an empty MNAME field in order to deliberately specify that
> there is no appropriate place for Dynamic Updates to be sent.
Question: How do existing implementations react to the presence of a
single, terminal dot ? What if an A record is published for '.' ?
I know it probably won't happen. but I'm also curious to know, and
I think the document should specify this: what is the impact of
this on existing implementations ?
> For zones whose SOA record contains an MNAME field which corresponds
> to a server listed in the apex NS set, making the MNAME field empty
> might well cause additional NOTIFY traffic. If this is a concern,
> the operators of the authority-only servers for the zone might choose
> to specify an explicit notify list.
... which excludes the "master".
Question:
In some cases it can be useful to be able to identify the real
master anyway. But MNAME was never a reliable way of ascertaining which
server in an NS set was the source of data, if such a source existed
at all.
Do people on this list think that we are losing any valuable
information by using the convention suggested by Joe, or was it already
too uncertain, and that no usefull debugging/troubleshooting
information is being lost by implementing the suggested approach ?
Otherwise a good idea.
Phil
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
