chiark / gitweb /
New section on gluelessness.
authorianmdlvl <ianmdlvl>
Sat, 12 Jan 2002 00:09:18 +0000 (00:09 +0000)
committerianmdlvl <ianmdlvl>
Sat, 12 Jan 2002 00:09:18 +0000 (00:09 +0000)
scripts/named-conf.8

index ef7dcb6..40e5955 100644 (file)
@@ -71,23 +71,8 @@ increase the debugging level.  (Maximum is
 .BR -DD .)
 .TP
 .BR \-g | \-\-glueless
-Do not warn about glueless referrals.  Not recommended.  Note that
-glueless referrals usually cause extra delays looking up names, and
-can make lookups fail even if in theory they could succeed.  There is
-no generally agreed convention or standard for avoiding circular
-glueless situations such as
-.br
-.B example.com NS ns0.example.net.uk
-.br
-.B example.com NS ns1.example.net.uk
-.br
-.B example.net.uk NS ns0.example.com
-.br
-.B example.net.uk NS ns1.example.com
-.br
-where gluelessness would completely prevent lookups inside
-example.net.uk and example.com.  The best way to be sure to avoid this
-is to avoid gluelessness.
+Do not warn about glueless referrals.  Not recommended - see
+the section GLUELESSNESS, below.
 .TP
 .BR \-l | \-\-local
 Only checks for mistakes which are the responsibility of the local
@@ -156,7 +141,7 @@ To avoid indefinitely long or even circularly glueless referrals
 effectively implement similar conventions; currently the author
 believes that only the reverse lookup namespaces are conventionally
 devoid of nameservers, and therefore fine to provide glueless
-referrals for.
+referrals for.  See GLUELESSNESS below.
 .TP
 \fBoutput\fP \fIformat\fP \fIfilename\fP [\fIformat\fP \fIfilename ...\fP]
 Arranges that each
@@ -306,6 +291,77 @@ one of the names specified with
 For published zones, the address should be that of the SOA origin.
 For stealth zones, the address should be that of the SOA origin or one
 of the published nameservers.
+.SH GLUELESSNESS
+Glue is the name given for the addresses of nameservers which are
+often supplied in a referral.  In fact, it turns out that it is
+important for the reliability and performance of the DNS that
+referrals, in general, always come with glue.
+
+Firstly, glueless referrals usually cause extra delays looking up
+names.  BIND 8, when it receives a completely glueless referral and
+does not have the nameservers' addresses in its cache, will start
+queries for the nameserver addresses; but it will throw the original
+client's question away, so that when these queries arrive, it won't
+restart the query from where it left off.  This means that the client
+won't get its answer until it retries, typically at least 1 second
+later - longer if you have more than one nameserver listed.  Worse, if
+the nameserver to which the glueless referral points is itself under
+another glueless referral, another retry will be required.
+
+Even for better resolvers than BIND 8, long chains of glueless
+referrals can cause performance and reliability problems, turning a
+simple two or three query exchange into something needing more than a
+dozen queries.
+
+Even worse, one might accidentally create a set of circularly glueless
+referrals such as
+.br
+.B example.com NS ns0.example.net.uk
+.br
+.B example.com NS ns1.example.net.uk
+.br
+.B example.net.uk NS ns0.example.com
+.br
+.B example.net.uk NS ns1.example.com
+.br
+Here it is impossible to look up anything in either example.com or
+example.net.uk.
+
+There are, as far as the author is aware, no generally agreed
+conventions or standards for avoiding unreasonably long glueless
+chains, or even circular glueless situations.  The only way to
+guarantee that things will work properly is therefore to always supply
+glue.
+
+However, the situation is further complicated by the fact that many
+implementations (including BIND 8.2.3, and many registry systems),
+will refuse to accept glue RRs for delegations in a parent zonefile
+unless they are under the parent's zone apex.  In these cases it can
+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.
+
+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.
+
+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
+in-addr.arpa zones (ie, no NS RRs seem to point into in-addr.arpa,
+even those for in-addr.arpa zones).  Current practice seems to be to
+always use nameservers for in-addr.arpa which are in the normal,
+forward, address space.  If everyone sticks to the rule of always
+publishing nameservers names in the `main' part of the namespace, and
+publishing glue for them, there is no chance of anything longer than a
+1-step glueless chain might occur for a in-addr.arpa zone.  It is
+probably best to maintain this as the status quo, despite the
+performance problem this implies for BIND 8 caches.  This is what the
+serverless\-glueless directive is for.
 .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,