new draft

doc/draft/draft-ietf-dnsop-serverid-01.txt

@@ -5,8 +5,8 @@
 
 
 INTERNET-DRAFT                                            David Conrad
-draft-ietf-dnsop-serverid-00.txt                         Nominum, Inc.
+draft-ietf-dnsop-serverid-01.txt                         Nominum, Inc.
-                                                             May, 2002
+                                                        November, 2002
 
                 Identifying an Authoritative Name Server
 
@@ -55,9 +55,9 @@ Abstract
 
 
 
-Expires November, 2002                                          [Page 1]
+Expires May, 2003                                               [Page 1]
 
-draft-ietf-dnsops-serverid-00.txt                              May, 2002
+draft-ietf-dnsop-serverid-01.txt                               May, 2002
 
 
    the covention's existence and proposes a slight redefinition of the
@@ -111,12 +111,12 @@ draft-ietf-dnsops-serverid-00.txt                              May, 2002
 
 
 
-Expires November, 2002                                          [Page 2]
+Expires May, 2003                                               [Page 2]
 
-draft-ietf-dnsops-serverid-00.txt                              May, 2002
+draft-ietf-dnsop-serverid-01.txt                               May, 2002
 
 
-   rightly been viewed by many implementors as not being standardized
+   (rightly) been viewed by many implementors as not being standardized
    nor being implementation neutral.  As such, a standard mechanism to
    identify a particular machine among a shared unicast set of machines
    serving the same DNS data does not currently exist.
@@ -141,12 +141,37 @@ draft-ietf-dnsops-serverid-00.txt                              May, 2002
    can be used to differentiate among multiple servers.
 
    To make this convention useful, DNS operators wishing to identify
-   their servers MUST put a unique string for the RDATA of the TXT
+   their servers uniquely MUST, for EACH server, put a unique string for
-   record associated with the "ID.SERVER." domain in class CHAOS.
+   the RDATA of the TXT record associated with the "ID.SERVER." domain
-   Implementors MUST provide a way to disable returning identifying
+   in class CHAOS.  For example, given two machines "a.example.com" and
+   "b.example.com" that receive DNS queries at the same IP address, the
+   name server administrator could include
+
+        $ORIGIN SERVER.
+        ID   CH   TXT  "a"
+
+   in the appropriate zone file on machine "a.example.com" and
+
+        $ORIGIN SERVER.
+        ID   CH   TXT  "b"
+
+   in the appropriate zone file on machine "b.example.com".
+
+   Queries for TXT RRs of "id.server" in class CHAOS to the IP address
+   serving both "a.example.com" and "b.example.com" should return "a" or
+   "b" depending on which machine the query was routed.
+
+   Implementors MUST provide a way to disable returning this identifying
    information.  Implementors SHOULD provide a way to limit who can
    query for the identifying information.
 
+
+
+Expires May, 2003                                               [Page 3]
+
+draft-ietf-dnsop-serverid-01.txt                               May, 2002
+
+
    The use of other names in the CHAOS class "SERVER." domain are beyond
    the scope of this document.
 
@@ -161,16 +186,9 @@ Security Considerations
 
    Providing identifying information as to which server is responding
    can be seen as information leakage and thus a security risk.  It may
-   be appropriate to restrict who can query for the "ID.SERVER."
+   be appropriate to restrict who can query for the "ID.SERVER." domain.
-   domain.  Filtering on source address would be one way in which
+   Filtering on source address would be one way in which restrictions
-   restrictions can be applied.
+   can be applied.
-
-
-
-Expires November, 2002                                          [Page 3]
-
-draft-ietf-dnsops-serverid-00.txt                              May, 2002
-
 
    The identifer returned via an "ID.SERVER." query SHOULD NOT contain
    the hostname or other information that could be considered sensitive.
@@ -182,7 +200,9 @@ Acknowledgements
    Consortium in the Berkeley Internet Name Domain package.  Useful
    comments on earlier drafts were provided by Bob Halley, Brian
    Wellington, Andreas Gustafsson, Ted Hardie, Chris Yarnell, and
-   members of the ICANN Root Server System Advisory Council.
+   members of the ICANN Root Server System Advisory Council.  Additional
+   explanatory information provided due to questions received from Randy
+   Bush.
 
 References
 
@@ -200,6 +220,14 @@ References
 
 Author's Address
 
+
+
+
+Expires May, 2003                                               [Page 4]
+
+draft-ietf-dnsop-serverid-01.txt                               May, 2002
+
+
    David Conrad
    Nominum, Inc.
    2385 Bay Road
@@ -220,14 +248,6 @@ Full Copyright Statement
    distributed, in whole or in part, without restriction of any kind,
    provided that the above copyright notice and this paragraph are
    included on all such copies and derivative works.  However, this
-
-
-
-Expires November, 2002                                          [Page 4]
-
-draft-ietf-dnsops-serverid-00.txt                              May, 2002
-
-
    document itself may not be modified in any way, such as by removing
    the copyright notice or references to the Internet Society or other
    Internet organizations, except as needed for the purpose of
@@ -259,25 +279,5 @@ draft-ietf-dnsops-serverid-00.txt                              May, 2002
 
 
 
-
+Expires May, 2003                                               [Page 5]
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Expires November, 2002                                          [Page 5]