Subject: Re: [DNSOP] Adoption of <draft-wkumari-dnsop-omniscient-as112-01.txt> as a WG work item?

From: Roy Arends <[email-masked]>
Date: Fri, 1 Mar 2013 14:12:46 +0000

On Feb 22, 2013, at 8:52 PM, P Vixie <[email-masked]> 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-masked]> wrote:
> 
> On 2013-02-22, at 07:57, Paul Vixie <[email-masked]> 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-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
> 
> -- 
> Sent from my Android phone with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: George Michaelson <[email-masked]>
Date: Thu, 14 Mar 2013 17:46:16 -0400

With apologies for lateness..

On 22/02/2013, at 12:47 AM, Mark Andrews <[email-masked]> wrote:

> 
> In message <[email-masked]>, George Michaels
> on writes:
>> 
>> 
>> btw, I continue to collect data on the volume of ULA, link-local, teredo 
>> traffic in reverse, and it continues to grow..
> 
> And the traffic stats are where?
> The analysis of the recursive servers that are sending this traffic is where?
> Vendor, version, isp.
> Is it worth adding the terado prefix to locally served zones registry?
> 
>> -George

as partial answer to this larger question, I include the following. It shows that Teredo continues to grow, and continues to scale beyond normal IPv6. Global Unicast overtook ULA sometime mid-2012, probably as a result of changes to the bind server localizing it (well done Mark) and 6to4 is a stub which will not go away but is of a far smaller consequence, and in case is validly delegated.

So yes. I believe Teredo is worth adding to locally served zones registry, but I also believe it should be delegated to the AS112 system.

I have data in the same period for all of the multicast subtypes, link-local and site-local, embedded V4 and other things which really shouldnt be seen in reverse DNS for IPv6. If that is of interest, I can post it.

-George