Technical Summary
In order to be able to identify certain nameservers in a DNS
anycast cloud clients querying nameservers in that cloud can add an
EDNS OPT pseudo RR that signals the answering nameservers to
include identifying information in an OPT RR that is attached to
the answer.
This technique improves the existing ad-hoc methods to identify
nameservers.
Working Group Summary
Working group consensus is solid. During the working group
discussions the question came up to also allow for client to server
identification. This was argued to be out of scope.
Protocol Quality
This document was reviewed by Peter Koch, David Conrad, Sam Weiler,
Paul Vixie, Mark Andrews, Francis Dupont, Olaf Kolkman, Thomas Narten
and Mark Townsley.
This feature will be implemented in at least two independent
open-source products used on anycasted root-servers. And will be
available in at least one resolver implementation and become
available in two libraries.
Note to RFC Editor
Please add the following new text. The first chunk is in the discussion
of NSID payload, the second is in the Security Considerations section. The
diff is taken from the xml source.
@@ -310,6 +310,25 @@
constellation identify themselves as "My Name Server" would
not be particularly useful.
</t>
+ <t>
+ A signed blob is not particularly useful as NSID payload
+ unless the signed data is dynamic and includes some kind
+ of replay protection such as a timestamp or some kind of
+ data identifying the requestor. Signed blobs that meet
+ these criteria could conceivably be useful in some
+ situations but would require detailed security analysis
+ beyond the scope of this document.
+ </t>
+ <t>
+ A static encrypted blob would not be particularly
+ useful, as it would be subject to replay attacks and
+ would, in effect, just be a random number to any party
+ that does not posess the decryption key. Dynamic
+ encrypted blobs could conceivably be useful in some
+ situations but, as with signed blobs, dynamic encrypted
+ blobs would require detailed security analysis beyond
+ the scope of this document.
+ </t>
</list>
</t>
<t>
@@ -467,6 +486,18 @@
the NSID option content up to the implementation and the name
server operator.
</t>
+ <t>
+ Two of the possible kinds of payload data discussed in <xref
+ target="nsid-payload"/> involve digital signature and
+ encryption, respectively. While this specification discusses
+ some of the pitfalls that might lurk for careless users of
+ these kinds of payload data, full analysis of the issues that
+ would be involved in these kinds of payload data would require
+ knowledge of the content to be signed or encrypted, algorithms
+ to be used, and so forth, which is beyond the scope of this
+ document. Implementors should seek competent advice before
+ attempting to use these kinds of NSID payloads.
+ </t>
</section>