+Our zone configuration: For primary zones, the SOA origin should be
+one of the names specified with
+.BR self\-soa " (or " self ).
+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.
~ian / chiark-utils.git / blobdiff