This commit was generated by cvs2svn to compensate for changes in r99179,

which included commits to RCS files with non-trunk default branches.

4 files changed, 126 insertions, 4 deletions

diff --git a/contrib/bind/doc/html/server.html b/contrib/bind/doc/html/server.html
index b7fea33..5dea794 100644
--- a/contrib/bind/doc/html/server.html
+++ b/contrib/bind/doc/html/server.html
@@ -13,6 +13,7 @@
 
 <PRE>
 server <VAR><A HREF="docdef.html">ip_addr</A></VAR> {
+  [ edns <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
   [ bogus <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
   [ support-ixfr <VAR><A HREF="docdef.html">yes_or_no</A></VAR>; ]
   [ transfers <VAR><A HREF="docdef.html">number</A></VAR>; ]
@@ -28,6 +29,10 @@ server <VAR><A HREF="docdef.html">ip_addr</A></VAR> {
 <P>The server statement defines the characteristics to be
 associated with a remote name server.</P>
 
+<P>If you discover that a server does not support EDNS you can prevent
+named making EDNS queries to it by specifying <CODE>edns no;</CODE>.
+The default value of <CODE>edns</CODE> is <CODE>yes</CODE>.
+
 <P>If you discover that a server is giving out bad data, marking it as
 <CODE>bogus</CODE> will prevent further queries to it.  The default value of
 <CODE>bogus</CODE> is <CODE>no</CODE>.  Marking a server as <CODE>bogus</CODE>
@@ -69,7 +74,7 @@ required to be signed by this key.
 
 <HR>
 <ADDRESS>
-Last Updated: $Id: server.html,v 1.12 2001/08/10 05:12:29 marka Exp $
+Last Updated: $Id: server.html,v 1.13 2002/05/24 03:04:51 marka Exp $
 </ADDRESS>
 </BODY>
 </HTML>
diff --git a/contrib/bind/doc/man/dnsquery.1 b/contrib/bind/doc/man/dnsquery.1
index bc0307f..b6588c6 100644
--- a/contrib/bind/doc/man/dnsquery.1
+++ b/contrib/bind/doc/man/dnsquery.1
@@ -1,4 +1,4 @@
-.\" $Id: dnsquery.1,v 8.4 2001/08/08 07:49:58 marka Exp $
+.\" $Id: dnsquery.1,v 8.5 2002/06/18 02:04:54 marka Exp $
 .\"
 .\"Copyright (c) 1995,1996,1999 by Internet Software Consortium
 .\"
@@ -49,8 +49,10 @@ are treated without case-sensitivity.
 .Bl -tag -width Fl
 .It Fl n Ar nameserver
 The nameserver to be used in the query.  Nameservers can appear as either 
-Internet addresses of the form 
-.Ar w.x.y.z 
+Internet addresses of the form
+.Ar ( w.x.y.z
+or
+.Ar xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx )
 or can appear as domain names.
 (Default: as specified in 
 .Pa /etc/resolv.conf . ) 
diff --git a/contrib/bind/doc/man/named.conf.5 b/contrib/bind/doc/man/named.conf.5
index df07b1a..532af69 100644
--- a/contrib/bind/doc/man/named.conf.5
+++ b/contrib/bind/doc/man/named.conf.5
@@ -1895,6 +1895,7 @@ Any number of trusted keys can be specified.
 .Ss Syntax
 .Bd -literal
 server \fIip_addr\fR {
+  [ edns \fIyes_or_no\fR; ]
   [ bogus \fIyes_or_no\fR; ]
   [ support-ixfr \fIyes_or_no\fR; ]
   [ transfers \fInumber\fR; ]
@@ -1906,6 +1907,15 @@ server \fIip_addr\fR {
 The server statement defines the characteristics to be
 associated with a remote name server.
 .Pp
+If you discover that a server does not support EDNS you can prevent
+named making EDNS queries to it by specifying
+.Ic edns
+.Ic no; .       
+The default value of 
+.Ic edns
+is 
+.Ic yes .
+.Pp
 If you discover that a server is giving out bad data, marking it as
 .Ic bogus
 will prevent further queries to it.  The default value of
diff --git a/contrib/bind/doc/misc/rfc2317-notes.txt b/contrib/bind/doc/misc/rfc2317-notes.txt
new file mode 100644
index 0000000..0b62d2a
--- /dev/null
+++ b/contrib/bind/doc/misc/rfc2317-notes.txt
@@ -0,0 +1,105 @@
+Message-Id: <200005230246.WAA03750@hrothgar.gw.com>
+To: ...
+Subject: Notes on RFC-2317
+Date: Mon, 22 May 2000 22:46:55 -0400
+From: Kimmo Suominen <kim@tac.nyc.ny.us>
+
+Hi!
+
+I wrote down some notes on RFC-2317.  I've had discussions with all of
+you regarding classless IN-ADDR.ARPA delegations, and I would very much
+appreciate any comments you may have.  Please feel free to forward this
+to other parties as you see necessary or appropriate.
+
+The goal of these notes is to try and clarify the reasoning behind the
+recommendations I've been making on implementing RFC-2317 delegations.
+In particular the following issues keep coming up with again and again
+with each vendor:
+
+    - why use "-" instead of "/"
+    - why use particular NS records
+    - why delegate within IN-ADDR.ARPA
+
+I am hoping that the these notes could eventually be used to convince
+ISPs to provide an efficient and smooth implementation of RFC-2317 with
+the least amount of headache for the end-user.
+
+Regards,
++ Kim
+
+
+
+NOTES ON IMPLEMENTING CLASSLESS IN-ADDR.ARPA DELEGATION PER RFC-2317
+
+1.  Selecting the CNAME target zone
+
+    RFC-2317 shows an example case where the target zone is a delegated
+    sub-zone of the IN-ADDR.ARPA zone for the natural class C network.
+    This will allow for the NS records for the zone can be independently
+    selected (see benefits described below).  An example of such a zone
+    would be 0-28.150.80.204.IN-ADDR.ARPA.
+
+    Now pay careful attention to the last paragraph of RFC-2317.  There
+    are broken resolver implementations that apply the "valid host name"
+    restrictions on the CNAME target (it should only be applied to the
+    PTR target name).  To avoid problems with such implementations it
+    is best to use a character that is allowed in a hostname.  I prefer
+    using a hyphen, as I did in the example above.
+
+    Some ISPs may at first refuse to delegate these zones (without any
+    explanation).  Approach such ISPs with the reasoning in here first,
+    but if that fails consider using your "forward" zone as a fallback.
+
+    There is nothing magic about the IN-ADDR.ARPA zone for RFC-2317
+    delegations.  You will have to sacrifice the optimization provided
+    by a correct IN-ADDR.ARPA delegation, but you will still retain
+    the ease of local administration for all name changes.
+
+    I recommend using a dedicated subdomain for the PTR records, e.g. if
+    your "forward" domain is "HOME.GW.COM" use "REV.HOME.GW.COM" for the
+    PTR records.
+
+2.  Selecting the NS records
+
+    The NS records for the delegated zone should include all the NS
+    records of the parent zone, in addition to any NS records pointing
+    to the public name servers the delegate may want to use.  Having the
+    name servers of the parent zone secondary the delegated zone allows
+    them to have the necessary authoritative data to return the CNAME
+    target in the additional records of a response to a PTR record query
+    (minimizing the number of queries needed to resolve an address).
+
+    This can be achieved using any zone (i.e. even a subdomain of your
+    "forward" domain), of course.  However, having the ISP delegate an
+    IN-ADDR.ARPA zone for your PTR records rather than you delegating a
+    zone to your ISP maintains the logical "owner" and "delegate" roles.
+
+    If the primary server for the delegated zone is not permanently on
+    the Internet (e.g. a dial-on-demand connection) then you would not
+    want to advertise it in the NS records.  It would just be a stealth
+    server which the advertised secondaries poll for updates.
+
+3.  Example delegation
+
+    To delegate our example zone 0-28.150.80.204.IN-ADDR.ARPA first look
+    at the NS records of the parent zone 150.80.204.IN-ADDR.ARPA.  Let's
+    say they are the following:
+
+        $ORIGIN 150.80.204.IN-ADDR.ARPA.
+        @    IN NS GRENDEL.GW.COM.
+             IN NS PYRY.GW.COM.
+
+    To delegate 204.80.150.0/28 to SRV.HOME.GW.COM you would then insert
+    these records in the parent zone data:
+
+        $ORIGIN 150.80.204.IN-ADDR.ARPA.
+        0-28 IN NS SRV.HOME.GW.COM.
+             IN NS GRENDEL.GW.COM.
+             IN NS PYRY.GW.COM.
+        $GENERATE 0-15 $ IN CNAME $.0-28.150.80.204.IN-ADDR.ARPA.
+
+    The necessary modifications to /etc/named.conf will be left as an
+    exercise to the reader.
+
+Kimmo Suominen
+Global Wire Oy