We want the absence of (qname, qtype) to be cached by resolvers who follow a delegation to an omniscient as112 server for all (qname, qtype).
Given that requirement the thought was that NOERROR/no data and NXDOMAIN were equally plausible. However, I see now that the lack of "no children" signalling has the potential to cause increased query load, since resolvers will re-query for children despite an earlier query for a parent. My feeling is that this is not a big deal and the ability to add/drop with no coordination with server operators represents a greater win, but I have no science behind my words. The current scheme (witness Warren's code) seems to do this (modulo extra queries for children) for all (qname, qtype) where qtype != SOA. Which is not perfect, but, I think pretty good. We could servfail on qtype == SOA I guess, which is crazy nasty but which I think for all practical purposes would work. I like your other message's "minimal response" notion, though. When I'm not sitting on a plane headed for a beach, I will play with that. Joe Aue Te Ariki! He toki ki roto taku mahuna! On 2013-02-22, at 16:53, 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. No data/noerror says there are either other types or children or both. 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 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 (blackhole-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
