On Jun 24, 2013, at 10:15 AM, Joe Abley <[email protected]> wrote: > > On 2013-06-24, at 12:56, Paul Hoffman <[email protected]> wrote: > >> In looking at the diffs, I still have the question I had earlier about NSID. >> I give the following command three times quickly: >> dig -4 @L.ROOT-SERVERS.NET . SOA +nsid +norec +noall +comments >> I get three different answers (lax16..., lax09..., lax13...). >> >> This is similar to the variance I see when doing >> dig -4 @L.ROOT-SERVERS.NET HOSTNAME.BIND CH TXT +short >> and >> dig -4 @L.ROOT-SERVERS.NET ID.SERVER CH TXT +short >> However: >> dig IDENTITY.L.ROOT-SERVERS.ORG TXT +short >> gives me the same answer each time I give it. >> >> So, I'm still confused about the paragraph just before section 4.1. > > That paragraph addresses the case of: > > (a) send query, get problematic response > (b) do HOSTNAME.BIND (or similar) query to identify what node I'm talking to > > It's entirely possible that the responding node for (a) will be different > from the responding name for (b), in which case the node identity wouldn't > correspond with the node that seemed to be giving a problematic response. > > If instead you do: > > (a) send query with NSID, get problematic response > > then the identity of the node exposed by the use of NSID corresponds exactly > to the node that supplied the problematic response, in all cases, guaranteed.
Ah, got it. I missed the linkage of "add NSID to the troublesome query". Proposal: Current: Use of the NSID option can obviate this possibility Proposed: Adding the NSID option to the query that causes the problematic response can obviate this possibility _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
