On Feb 22, 2013, at 8:52 PM, P Vixie <[email protected]> wrote: > Sorry to be late on this, missed it earlier. > > Nxd says there is no such name, no matter what the type was, and there are no > children.
RCODE=3 states that the name does not exist. "no children" might be implied from that, but that is just it, an implication. A resolver assuming that no children exist is a resolver trying to be cute, and might be over-optimising. BIND9 (before 9.2.3) used to emit RCODE3 on empty non-terminals, and there are other implementations that currently still show this behaviour. Also see this message: http://www.ietf.org/mail-archive/web/dnsext/current/msg11084.html > No data/noerror says there are either other types or children or both. No, it really does not. Again this is implicit. What Nodata/noerror says is that the type requested for a name does not exist. NOERROR-NODATA is perfectly valid. There is no data to return for that QNAME, as the QTYPE does not exist. This is a negative response that, according to RFC2308 (NO DATA RESPONSE TYPE3) is a valid response. This is not 'lying' or 'not true', as the type for that QNAME really does not exist. > We know what the truth must be and we know which implications we want the > requestor to follow. Right? Is there any doubt at all or any ambiguity in > what we want said? … Paul There is no ambiguity. You're trying to optimise query load, with the assumption that NXDOMAIN implies absence of children, while resolvers implementations should actually not use this assumption at all. Roy > > Joe Abley <[email protected]> wrote: > > On 2013-02-22, at 07:57, Paul Vixie <[email protected]> wrote: > > if we can't return nxdomain, then i'm opposed to the omniscient spec, > and we should continue as before, enumerating on the responding servers > every zone to which we wish to delegate. > > noerror/nodata is the wrong answer. > > It does smell a bit wrong, but I'm interested in more details of why you > think that if it's more than just the smell. > > I'll note that the proposal is to assign new nameservers to be omniscient, > and not to convert the existing ones. We are then in a position to delegate > other local-zoneish zones to the new servers and review the impact. > > So, the suggestion is not to replace the existing AS112 servers (blackho > le-1, > blackhole-2 and prisoner) out of the gate. Any such replacement would happen > later, once there was some degree of comfort that it was safe to do that. > > > > Joe > > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity. > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
