Domain Name Server Operations (dnsop)

Warren Kumari | 12 Jun 2012 16:40

A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

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

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.

(Continue reading)

headers

Nicholas Weaver | 12 Jun 2012 16:58

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

On Jun 12, 2012, at 7:40 AM, Warren Kumari wrote:

> 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):

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

(Continue reading)

headers

Joe Abley | 12 Jun 2012 17:17

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

Hi Nicholas,

On 2012-06-12, at 10:58, Nicholas Weaver wrote:

> On Jun 12, 2012, at 7:40 AM, Warren Kumari wrote:
> 
>> 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):
> 
> 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 change.

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.

(Continue reading)

headers

Nicholas Weaver | 12 Jun 2012 17:33

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

On Jun 12, 2012, at 8:17 AM, Joe Abley wrote:

>> 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?
> 
> 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.

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.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

headers

Tony Finch | 12 Jun 2012 18:10

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

Joe Abley <joe.abley <at> icann.org> 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  <dot <at> dotat.at>  http://dotat.at/
Forties: Northwest 5 or 6, occasionally 4 later. Moderate or rough. Showers.
Good.
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

headers

Chris Thompson | 12 Jun 2012 19:59

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

On Jun 12 2012, Tony Finch wrote:

>Joe Abley <joe.abley <at> icann.org> 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.

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: cet1 <at> ucs.cam.ac.uk    New Museums Site, Cambridge CB2 3QH,
Phone: +44 1223 334715       United Kingdom.

(Continue reading)

headers

Joe Abley | 27 Jun 2012 20:15

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

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

(Continue reading)

headers

Paul Vixie | 27 Jun 2012 20:24

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

On 6/27/2012 6:15 PM, Joe Abley wrote:
> ...
> Adopt this doc?

yes please.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

headers

Nicholas Weaver | 27 Jun 2012 20:37

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00


On Jun 27, 2012, at 11:15 AM, Joe Abley wrote:

> 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.)

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.

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

headers

William F. Maton Sotomayor | 27 Jun 2012 20:46

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

On Wed, 27 Jun 2012, Joe Abley wrote:

> 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.)

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
_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

(Continue reading)

headers

SM | 27 Jun 2012 20:41

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

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 
> has, we don't need more

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 

_______________________________________________
DNSOP mailing list
DNSOP <at> ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

headers

Mark Andrews | 28 Jun 2012 02:01

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00


In message <6FE949C2-18F3-432D-AB75-F66E71570CDF <at> hopcount.ca>, 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:
> 
>  - 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>

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.

(Continue reading)

headers

Joe Abley | 29 Jun 2012 21:51

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

Hi Mark,

On 2012-06-27, at 20:01, Mark Andrews wrote:

> 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.

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.

>> - 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?

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
> 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.

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.

(Continue reading)

headers

William F. Maton Sotomayor | 10 Jul 2012 15:45

Re: A good chance to get all riled up - draft-wkumari-dnsop-omniscient-as112-00

On Fri, 29 Jun 2012, Joe Abley wrote:

>>> - 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?
>
> 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.

AFAIK, data points to this effect were presented by George Michaelson at 
the DNSOP IETF meeting in Prague when he introducted his draft to the 
group for their consideration.  Not sure if George is on this list to 
verify my memory as being correct.

>> 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.
>
> 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.

+1, good for BIND to do this, provided people run the latest version of 
BIND.  An interesting test would be to see how many and what versions of 
vendor implementations would self-sink AS112-bound queries.

(Continue reading)