note, i have removed the leading tab character from this author's paragraphs, since i find it very distracting. (a cautionary note to marka and bmanning.)
[EMAIL PROTECTED] (Phil Regnauld) writes: > 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 ? i'm afraid that this will just result in a lot of QTYPE A messages sent to the authority servers for . asking about ., and a lot of new useless RCODE 3 responses therefrom. > 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. during the preparation of RFC 2136 we knew that SOA.MNAME was often meaningless, and so the rule is, "if it's the same as an NS.NSDNAME, then it's the best target for an update." the purpose of this was to avoid having to forward updates from secondaries toward the master. but as it happened, noone read RFC 2136 carefully. every second of every day, the SOA.MNAME for 10.in-addr.arpa receives update requests from all over the world, even though it is not also an NS.NSDNAME. those update requests are all coming from a single vendor's implementation. > 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 ? i think it will not be correctly implemented, just as RFC 2136 was not correctly implemented, and if people start putting SOA.MNAME="." then it will just lead to a lot more QTYPE A queries for ".". -- Paul Vixie _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
