In message <56e64398.7010...@redbarn.org>, Paul Vixie writes:
>
>
> Mark Andrews wrote:
> > ... please explain how RFC 1034 Section 4.3.2. Algorithm can return
> > a Name Error for a empty non-terminal. I don't see it unless there
> > is a missing delegation and that is a configuration error. I have
> > zero problems with a cache returning Name Error if there is a
> > configuration error.
>
> i see no ambiguity in RFC 1034 4.3.2.
>
> however, the wording of RFC 1035 4.1.1 could be clearer:
Lots of STD 13 could be clearer. :-)
> > 3 Name Error - Meaningful only for
> > responses from an authoritative name
> > server, this code signifies that the
> > domain name referenced in the query does
> > not exist.
Which defines the code point and says it applies to non-existing
names. RFC 1035 also references RFC 1034 thusly:
This RFC describes the details of the domain system and protocol, and
assumes that the reader is familiar with the concepts discussed in a
companion RFC, "Domain Names - Concepts and Facilities" [RFC-1034].
So given that, how can you get to Name Error for a empty non terminal
from this description of the code point?
> of course, name error is also meaningful for responses from a caching
> recursive name server, so perhaps this text should be treated suspiciously.
>
> see also this text from [ibid] 6.2.2:
>
> > All of these data structures can be implemented an identical tree
> > structure format, with different data chained off the nodes in different
> > parts: in the catalog the data is pointers to zones, while in the zone
> > and cache data structures, the data will be RRs. In designing the tree
> > framework the designer should recognize that query processing will need
> > to traverse the tree using case-insensitive label comparisons; and that
> > in real data, a few nodes have a very high branching factor (100-1000 or
> > more), but the vast majority have a very low branching factor (0-1).
>
> 100-1000, eh?
100-100000000 would be a better description.
> --
> P Vixie
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
