@@ -1,8 +1,9 @@

 chiark-utils (3.0.3) unstable; urgency=low

   * chiark-backup: compatibility with md5sum from dpkg 1.10.4.
+  * chiark-named-conf: manpage gluelessness section improved.

- --
+ -- Ian Jackson <ian@davenant.greenend.org.uk>  Sun, 20 Oct 2002 17:42:53 +0100

 chiark-utils (3.0.2) unstable; urgency=low

diff --git a/debian/changelog b/debian/changelog
index 8ac63dfb21fba3aa6f3dfcdb1578b8f51bee388c..16ff7a07344c427ae8b9888a5bcb4c503514203d 100644 (file)
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,8 +1,9 @@
 chiark-utils (3.0.3) unstable; urgency=low
 
   * chiark-backup: compatibility with md5sum from dpkg 1.10.4.
 chiark-utils (3.0.3) unstable; urgency=low
 
   * chiark-backup: compatibility with md5sum from dpkg 1.10.4.

+  * chiark-named-conf: manpage gluelessness section improved.

 
 

- --
+ -- Ian Jackson <ian@davenant.greenend.org.uk>  Sun, 20 Oct 2002 17:42:53 +0100

 
 chiark-utils (3.0.2) unstable; urgency=low
 
 
 chiark-utils (3.0.2) unstable; urgency=low
 

diff --git a/scripts/named-conf.8 b/scripts/named-conf.8
index c586118e4364d31f01214d7663374e621b4b01e7..b1547fe93e2c440e5f7e011271243227009b3ef2 100644 (file)
--- a/scripts/named-conf.8
+++ b/scripts/named-conf.8
@@ -448,14 +448,13 @@ be necessary to create names for the child's nameservers which are
 underneath the child's apex, so that the glue records are both in the
 parent's bailiwick and obviously necessary.
 
 underneath the child's apex, so that the glue records are both in the
 parent's bailiwick and obviously necessary.
 

-Even worse, the horrid `shared registry system' managing .com, .net
-and .org does not allow a single IPv4 address to be used for more than
-one nameserver name!  It does, however, give out glue for any
-nameserver properly registered in the system.  I therefore recommend
-that you create a single name for your nameserver somewhere
-in .com, .net or .org, and use that for all the delegations
-from .com, .net and .org.  At the time of writing (January 2002) this
-seems to produce correct and glueful referrals.
+In the past, the `shared registry system' managing .com, .net and .org
+did not allow a single IPv4 address to be used for more than one
+nameserver name.  However, at the time of writing (October 2002) this
+problem seems to have been fixed, and the workaround I previously
+recommended (creating a single name for your nameserver somewhere
+in .com, .net or .org, and using that for all the delegations
+from .com, .net and .org) should now be avoided.

 
 Finally, a note about `reverse' zones, such as those in in-addr.arpa:
 It does not seem at all common practice to create nameservers in
 
 Finally, a note about `reverse' zones, such as those in in-addr.arpa:
 It does not seem at all common practice to create nameservers in


@@ -475,6 +474,22 @@ Dan Bernstein has some information and examples about this at
 http://cr.yp.to/djbdns/notes.html#gluelessness
 .UE
 but be warned that it is rather opinionated.
 http://cr.yp.to/djbdns/notes.html#gluelessness
 .UE
 but be warned that it is rather opinionated.

+.SS GLUELESSNESS SUMMARY
+
+I recommend that every nameserver should have its own name in every
+forward zone that it serves.  For example:
+.br
+.B zone.example.com NS servus.ns.example.com
+.br
+.B servus.ns.example.com A 127.0.0.2
+.br
+.B 2.0.0.127.in-addr.arpa PTR servus.example.net
+.br
+.B servus.example.net A 127.0.0.2
+.LP
+Domain names in
+.B in-addr.arpa
+should not be used in the right hand side of NS records.

 .SH SECURITY
 chiark\-named\-conf is supposed to be resistant to malicious data in
 the DNS.  It is not resistant to malicious data in its own options,
 .SH SECURITY
 chiark\-named\-conf is supposed to be resistant to malicious data in
 the DNS.  It is not resistant to malicious data in its own options,