Subject: [DNSOP] A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

From: Warren Kumari <[email-masked]>
Date: Tue, 12 Jun 2012 10:40:11 -0400

Hi there all,

So, back in (AFAIR) Taipei I proposed making AS112 instances simply be authoritative for *everything*, and then simply delegating and undelegating things to it as appropriate (this would make things much simpler as there would be very little coordination needed). At the time I realized that this would require synthesizing answers (always a bit of a controversial topic), but it turns out that there are a number of other things that may be equally contentious, such as (thanks to Joe for this partial list):

- assignment of new address space to separate omniscient and existing AS112 nodes
- v6 transport for omniscient AS112 servers
- naming the omniscient servers under as112.net
- reduced focus on the reverse tree (we could delegate anything we liked to the omniscient servers)
- unusual NXDOMAIN responses (the included SOA will be for a fake root zone, not the enclosing zone)
There are probably a bunch of other "interesting" implications...

So, do any of these things sound like topics that might interest you? A good chance to get annoyed / irritated?

If so, here is the draft: http://tools.ietf.org/html/draft-wkumari-dnsop-omniscient-as112-00
If not, well, feel free to say that too :-P

W

P.S: This is already being (slightly) discussed on the AS112 ops list, but having all of the discussions (hint hint) in one place would be good. Oh, I'll be asking for consideration as a WG doc soon...

--
Consider orang-utans.
In all the worlds graced by their presence, it is suspected that they can talk but choose not to do so in case humans put them to work, possibly in the television industry. In fact they can talk. It's just that they talk in Orang-utan. Humans are only capable of listening in Bewilderment.
-- Terry Practhett

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 12 Jun 2012 07:58:30 -0700

> So, back in (AFAIR) Taipei I proposed making AS112 instances simply be authoritative for *everything*, and then simply delegating and undelegating things to it as appropriate (this would make thing…

To be honest, it seems like almost a no-brainer good idea to me.  And whats wrong about synthesizing answers?

The only question I have is DNSSEC.  I take it since the model is this is all bogus traffic, just have an NSEC above it saying "No DNSSEC information", but I just want to be sure that doesn't change.

Stupid question on the SOA record however: why not dynamically generate an exact match SOA?  

So if the query is, say

121.14.34.10.in-addr.arpa.     IN      PTR

Instead of returning

10.in-addr.arpa.        300     IN      SOA     prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800
(current)

or

.        		300     IN      SOA     a.root-servers.net. nstld.verisign-grs.com. 2012061200 1800 900 604800 86400
(omniscient)

Why not return

121.14.34.10.in-addr.arpa.	300     IN      SOA     prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800

as the SOA?

---

From: Joe Abley <[email-masked]>
Date: Tue, 12 Jun 2012 11:17:47 -0400

Hi Nicholas,

> To be honest, it seems like almost a no-brainer good idea to me.  And whats wrong about synthesizing answers?

Actually, from the perspective of the omniscient AS112 server there's no real answer synthesis; the AS112 servers just serve an empty, unsigned namespace in which nothing exists apart from required zone scaffolding.

> The only question I have is DNSSEC.  I take it since the model is this is all bogus traffic, just have an NSEC above it saying "No DNSSEC information", but I just want to be sure that doesn't chang…

The only reason a resolver would normally send a query to an AS112 server (current, or omniscient) is if they followed a delegation there.

Since these are all junk domains of no global significance, it's hard to see how they could be signed. The expectation is (as currently) that they would not be.

A resolver would hence be receiving an unsigned name error (no NSEC RRs in the response) for a name that is verifiably insecure (due to the lack of a corresponding RRSet in the parent zone). The only potential wrinkle is the SOA record returned with the name error.

I can't think of a reason why a resolver would be upset to receive a name error from an AS112 server where the included (enclosing, root) SOA record attached is unsigned, but perhaps there are corner cases.

> 121.14.34.10.in-addr.arpa.	300     IN      SOA     prisoner.iana.org. hostmaster.root-servers.org. 2002040800 1800 900 604800 604800

That would involve custom software. At present, anybody can run an AS112 server using whatever choice of platform and DNS code they feel like. Requiring custom code for an AS112 server and expecting it to be maintained on multiple platforms seems unlikely, but no doubt it could be done.

Joe

---

From: Nicholas Weaver <[email-masked]>
Date: Tue, 12 Jun 2012 08:33:26 -0700

> That would involve custom software. At present, anybody can run an AS112 server using whatever choice of platform and DNS code they feel like. Requiring custom code for an AS112 server and expectin…

OTOH, it eliminates all worries about the SOA being misinterpreted, and really, this would be be remarkably small:

EG, I know I can code this up in prototype form in my (hackish) Python DNS library in about an hour, and the total codebase would be on the order of 600 total LOC, including the DNS library.

So synthesizing an exact-match SOA should at least be considered, since it addresses the only interoperability concern I see with that of an overly-broad SOA record.

---

From: Tony Finch <[email-masked]>
Date: Tue, 12 Jun 2012 17:10:57 +0100

Joe Abley <[email-masked]> wrote:
>
> Since these are all junk domains of no global significance, it's hard to
> see how they could be signed. The expectation is (as currently) that
> they would not be.

And rightly so.

Since it is normal (especially for the RFC1918 zones) for sites to have
local versions of the zones, it is much easier operationally if the zones
are not signed. If they are signed then any site that overrides them would
have to distribute trust anchors to all validators, so that they are able
to resolve the local names without rejecting them as bogus. If the AS112
zones are not signed then distributing trust anchors for local versions is
optional, depending on whether the site wants to bother validating them.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties: Northwest 5 or 6, occasionally 4 later. Moderate or rough. Showers.
Good.

---

From: Chris Thompson <[email-masked]>
Date: 12 Jun 2012 18:59:22 +0100

>optional, depending on whether the site wants to bother validating them.

See also RFC 6303, section 7, paragraph 2:

* As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA
* namespaces, the zones listed above will need to be delegated as
* insecure delegations, or be within insecure zones.  This will allow
* DNSSEC validation to succeed for queries in these spaces despite not
* being answered from the delegated servers.

-- 
Chris Thompson               University of Cambridge Computing Service,
Email: [email-masked]    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

---

From: Joe Abley <[email-masked]>
Date: Wed, 27 Jun 2012 14:15:50 -0400

Hi all,

The only suggestion I have heard relating to this draft is that if we supplied custom software to synthesise answers we could avoid the overly-broad SOA RR returned with the NXDOMAIN.

(My personal opinion is that this leads us down a path of needing to develop, publish and support particular software for AS112 servers, presumably on every platform that anybody might imagine using to run an AS112 server, and that this is a non-starter if for no better reason that there is no clear "we", here.)

Apart from that nothing much, which means one or more of (a) I missed some comments, (b) nobody cares, or (c) the draft is perfect as-is, in decreasing order of probability.

Another specific question, then: should the working group adopt this document? Possible fodder for answers, PROVIDED AS-IS WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES:

 - everybody should just follow RFC 6303, if they did the AS112 project would be superfluous
 - apparently not everybody follows RFC 6303, e.g. <http://dns.icann.org/cgi-bin/dsc-grapher.pl?plot=bynode&server=as112>
 - we do need some mechanism to delegate (e.g.) zones under IP6.ARPA corresponding to the various v6 analogues of 1918
 - AS112 servers were previously specified in a document which was a product of this wg, so subsequent guidance should properly do likewise
 - this idea should properly be reviewed by this working group if it is to proceed at all
 - it would be just as good for this document to proceed as an individual submission, since it will see dns directorate review anyway and hence all bases will be covered
 - this wg already has enough trouble processing the documents it has, we don't need more
 - this is a bad idea, we should just let it die

Adopt this doc?

Joe

On 2012-06-12, at 10:40, Warren Kumari wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 27 Jun 2012 18:24:52 +0000

On 6/27/2012 6:15 PM, Joe Abley wrote:
> ...

yes please.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 27 Jun 2012 11:37:32 -0700

> (My personal opinion is that this leads us down a path of needing to develop, publish and support particular software for AS112 servers, presumably on every platform that anybody might imagine usin…

Especially since the indication is that the overly broad SOA isn't likely to be a problem.  So as thats the only suggestion I had....

> Adopt this doc?

Yes.

---

From: "William F. Maton Sotomayor" <[email-masked]>
Date: Wed, 27 Jun 2012 14:46:01 -0400 (EDT)

> (My personal opinion is that this leads us down a path of needing to develop, publish and support particular software for AS112 servers, presumably on every platform that anybody might imagine usin…

Nor do I want to comteplate custom-built software if it can be helped.

[]
> Adopt this doc?

Yes, but biased yes.

Or, I can resubmit the IPv6 counterpart to my draft as a prelude to a 
stream of such docs to fill-up DNSOP's agenda (or IETF's in general) for 
the forseeable future (years) and enumerate countless junk.

Maybe our draft is better after all.

wfms

---

From: SM <[email-masked]>
Date: Wed, 27 Jun 2012 11:41:27 -0700

Hi Joe,
At 11:15 27-06-2012, Joe Abley wrote:
>  - it would be just as good for this document to proceed as an 
> individual submission, since it will see dns directorate review 
> anyway and hence all bases will be covered

That's not a good idea.

>  - this wg already has enough trouble processing the documents it 

Adopt the draft if people commit to review it.

There is nothing the WG chairs can do if a working group is 
lazy.  The authors can always encourage non-regular participants to 
review the draft.  I don't see any reason why you cannot turn this 
draft into a RFC number.

Regards,
-sm

---

From: Mark Andrews <[email-masked]>
Date: Thu, 28 Jun 2012 10:01:50 +1000

In message <[email-masked]>, Joe Abley writes
:
> Hi all,
> 
> The only suggestion I have heard relating to this draft is that if we supplie
> d custom software to synthesise answers we could avoid the overly-broad SOA R
> R returned with the NXDOMAIN.
> 
> (My personal opinion is that this leads us down a path of needing to develop,
>  publish and support particular software for AS112 servers, presumably on eve
> ry platform that anybody might imagine using to run an AS112 server, and that
>  this is a non-starter if for no better reason that there is no clear "we", h
> ere.)
> 
> Apart from that nothing much, which means one or more of (a) I missed some co
> mments, (b) nobody cares, or (c) the draft is perfect as-is, in decreasing or
> der of probability.
> 
> Another specific question, then: should the working group adopt this document
> ? Possible fodder for answers, PROVIDED AS-IS WITHOUT ANY EXPRESS OR IMPLIED 
> WARRANTIES:
> 
>  - apparently not everybody follows RFC 6303, e.g. <http://dns.icann.org/cgi-
> bin/dsc-grapher.pl?plot=bynode&server=as112>

RFC 6303 was published less than a year ago.  There really hasn't
been time to see much RFC 6303 deployment yet to measure its impact.
Now if we had data going back several years available to look at
we might even see if the load is going up, down or staying steady.

If you look at the classification graph[1] just talking to a single
organisation will kill a lot of the traffic.  8.0.0.0 is a single
organisation yet it is the third largest /8.

[1] http://dns.icann.org/cgi-bin/dsc-grapher.pl?binsize=60&window=2592000&plot=client_subnet2_accum&server=as112

I personally think a vendor education campain would be more productive.
We can't do much about already deployed servers but we can make
sure the next major release supports RFC 6303 by default.

>  - we do need some mechanism to delegate (e.g.) zones under IP6.ARPA correspo
> nding to the various v6 analogues of 1918

Do we have data that says we need to?  Remember RFC 6303 style
support for ULA was permitted a long time ago.  ISC added it to
named in 9.4.0.  Full RFC 6303 support, to cover the RFC 1918
reverses, was only added in 9.9.0 the first major release after RFC
6303 was published.

>  - AS112 servers were previously specified in a document which was a product 
> of this wg, so subsequent guidance should properly do likewise
>  - it would be just as good for this document to proceed as an individual sub
> mission, since it will see dns directorate review anyway and hence all bases 
> will be covered
> > So, back in (AFAIR) Taipei I proposed making AS112 instances simply be auth
> oritative for *everything*, and then simply delegating and undelegating thing
> s to it as appropriate (this would make things much simpler as there would be
>  very little coordination needed). At the time I realized that this would req
> uire synthesizing answers (always a bit of a controversial topic), but it tur
> ns out that there are a number of other things that may be equally contentiou
> s, such as (thanks to Joe for this partial list):
> > 
> > P.S: This is already being (slightly) discussed on the AS112 ops list, but 
> having all of the discussions (hint hint) in one place would be good. Oh, I'l
> l be asking for consideration as a WG doc soon...
> > 
> > --
> > Consider orang-utans.
> > In all the worlds graced by their presence, it is suspected that they can t
> alk but choose not to do so in case humans put them to work, possibly in the 
> television industry. In fact they can talk. It's just that they talk in Orang
> -utan. Humans are only capable of listening in Bewilderment.
> > -- Terry Practhett
> > 
> > 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Joe Abley <[email-masked]>
Date: Fri, 29 Jun 2012 15:51:07 -0400

Hi Mark,

> sure the next major release supports RFC 6303 by default.

I'm not sure we can influence the next major release of anything with any certainty. I would put money on (a) AS112 traffic not dropping to zero any time soon, and (b) if there is v4-related AS112 traffic, that there will also be v6-related AS112 traffic once we have an opportunity to sink it.

> Do we have data that says we need to?

I don't think we get that data until we look for it, and I think we look for it by delegating some zones and counting queries. We just need somewhere to delegate the zones to. This document is a proposal which would facilitate such a query sink.

> Remember RFC 6303 style

I think I interpret your note as "ISC is taking steps to reduce traffic on the AS112 servers through the knobs and switches available in BIND" which I think is commendable and great, but not entirely an answer to the question.

Joe