Subject: [DNSOP] Would love some feedback on 2 drafts (.alt and distributing the root).

From: Warren Kumari <[email-masked]>
Date: Sat, 21 Jun 2014 16:32:56 -0400

Hi there all.

So, I have 2 drafts that I'd really appreciate feedback on - one of
the is the .alt TLD document (which many of y'all have already read):
http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-01

The other one is somewhat more controversial - I have already
presented the general idea at the DNS-OARC meeting, the DNS track at
RIPE, and the DNS track at NANOG.
Reactions have been, um, mixed. Some folk say it;s a no-brainer,
others seriously dislike the idea.

Oh, I'm getting on a plane in a few minutes, so lack of response
doesn't mean that I'm not interested, just that I haven't seen your
response.

Draft: http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-00

Putting on the nomex underwear...

W

---

From: "John Levine" <[email-masked]>
Date: 22 Jun 2014 00:21:38 -0000

>http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-01

This brings the delightful semi-anarchy of Usenet to the DNS, which is
not necessarily a bad thing.  (Usenet still works pretty well if you
ignore the alt.* groups.)

I get the impression that the plan is that .alt is for things like
.onion that are implemented completely outside the DNS in application
specific ways, and would have to be intercepted at a layer no lower
than a stub resolver and probably higher.  Would it also be
appropriate for the sort of link-local names people typically do with
.home that often resolve A or AAAA records with addresses only locally
visible?

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 22 Jun 2014 01:14:33 -0000

>others seriously dislike the idea.

As I understand it, this changes DNS caches so that for the root zone
its behavior is somewhere between a cache and a secondary master.  It
slurps up a copy of the root zone by AXFR or rsync or something,
checks that all the DNSSEC is valid, and then directly answers queries
about that zone. All the info about the zone comes from the real master
with TTL or other limits to avoid staleness, but once it has the info,
it is in practice authoritative for the zone. (Although I realize that
its answers to queries still say it's a cache, no AA bits on the
answers.)

Since it has the whole zone, it can immediately return NXDOMAIN for
names in the zone that don't exist, which is not something that caches
currently do.  Is the plan that it will infer by looking at the NSEC
or NSEC3 records that nonexistent names don't exist, or is it just
part of the design, it validated the zone, so it knows it has the
whole thing?  The reason I ask is that I have suggested in the past
that for DNSBLs or DNSWLs, which tend to have a lot of queries to
names that don't exist, a DNSSEC-aware cache could synthesize the
answers to reduce the load on the authoritative servers.  The response
from the dnsop crowd could politely be described as dismissive.
Personally, I think it's fine to do it either way, if you don't want
stale answers, you know how to set TTLs.

Another question is why one would limit this to the root, since it is
hardly the only zone that has a lot of traffic, much of which is
bogus.  If you could cache in-addr.arpa, that would automagically do a
lot of what's in RFC 6303.  Or the servers at various parts of the Foo
company could profitably cache foo.com, particularly if it's less
administrative and technical hassle than setting up a local shadow
master.

I also observe that it is very common to do basically this trick at
busy mail sites for DNSBLs.  The site copies the DNSBL zones using
rsync or the like, serves it from a server on the LAN, and the caches
are configured to find those zones from the local server rather than
the normal place.  These zones typically aren't DNSSEC signed for
various reasons, but it occurs to me that the issues are different
from the root, and allowing unsigned non-root zones could be OK.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Jun 2014 09:17:24 +0100

On Jun 22, 2014, at 2:14 AM, John Levine <[email-masked]> wrote:

> its behavior is somewhere between a cache and a secondary master.  

The cache remains precisely a cache. The proposal is simply a way to (a) fill the cache with TLDs immediately on starting, (b) keep it filled when the TTL kicks in, and (c) let the cache know which TLDs do not exist so that the cache can send back NXDOMAIN without asking the root.

> It

Yes.

> whole thing?  

The latter. That's a benefit of DNSSEC.

> The reason I ask is that I have suggested in the past

Synthesizing positive answers in a signed zone is completely different than sending NXDOMAIN.

> bogus.  

One step at a time.

> If you could cache in-addr.arpa, that would automagically do a
> lot of what's in RFC 6303.  

The number of bogus queries for in-addr.arpa has not been seen as a big issue.

> Or the servers at various parts of the Foo

Verisign could do this if they wanted. There is no reason to have this document, which is about the root, suggest what Verisign, Nominet, or any other TLD operator should do.

> from the root, and allowing unsigned non-root zones could be OK.

Could be OK, could also be an attack vector. For this document, which is about the root, we want as much safety as we can muster.

--Paul Hoffman

---

From: "John Levine" <[email-masked]>
Date: 22 Jun 2014 15:54:08 -0000

>The cache remains precisely a cache.

I understand that it's still a cache in the DNS hierarchy, but in
operation, it's much more like a secondary master.  Like a secondary,
it bulk fetches the zone, answers all queries about that zone from its
own copy, and uses the SOA times to decide when to fetch again.
Unlike a secondary master, its answers don't have AA set, and if a
refetch fails, it falls back to being an ordinary cache rather than
continuing to serve what it has.  It also doesn't have anything like
notify or ixfr.

>Synthesizing positive answers in a signed zone is completely different than sending NXDOMAIN.

No, I'm talking about synthesizing NXDOMAIN.  If a cache has A and C
with DNSSSEC info, then gets a request for B and it sees the NSEC link
A->C, it doesn't have to ask whether there is a B.  Like I said, the
reactions were at best dismissive.  When the cache verifies the zone I
presume it checks that it has the full chain of NSEC or NSEC3, so it's
doing the same thing, just as a batch check up front.

>The number of bogus queries for in-addr.arpa has not been seen as a big issue.

It must have been at some point, since we have advice for caches to
locally intercept 10.in-addr.arpa and such.

>Verisign could do this if they wanted.

No, not .com, foo.com, the organization's own 2LD zone.  An
organization's own 2LD is likely to be small, and to be heavily used
within its own organization.

>Could be OK, could also be an attack vector. For this document, which is about the root, we want as much safety as we can muster.

I understand the security issues about the root, but wouldn't the
mechanism be exactly the same for any other zone?

R's,
John

---

From: Joe Abley <[email-masked]>
Date: Sun, 22 Jun 2014 12:41:52 -0400

> own copy, and uses the SOA times to decide when to fetch again.

There are some potentially surprising protocol implications for clients when recursive servers answer authoritatively for particular queries. Specifically, AA and AD bit processing is different.

If the suggestion is that a resolver with an AXFR- (or whatever-) sourced root zone should behave identically to a resolver that operates conventionally, then there are protocol changes and corresponding implementation changes needed. This draft proposes significant implementation changes for resolvers anyway, but I'm not convinced anybody has enthusiasm for revisiting the DNSSEC and DNS spec just to support this proposal (but perhaps I'm wrong, and I'm certainly biased in my mental risk/benefit analysis since I think this is a bad idea with very marginal benefit to anybody).

If the suggestion is that the different behaviour is commonly observed in the wild and so therefore it's a public service to document it, then I have no problem with that. This document goes further than that, though.

Joe

---

From: "John R Levine" <[email-masked]>
Date: 22 Jun 2014 15:05:15 -0400

> There are some potentially surprising protocol implications for clients 
> when recursive servers answer authoritatively for particular queries. 
> Specifically, AA and AD bit processing is different.

I don't get it.  The recursive server is still using data that it got from 
an authoritative server.  Why wouldn't it set the bits the same way it 
would as if it had fetched the records one name at a time?

The only thing I can see that's a little funky is that it makes its own 
NXDOMAIN responses, but I'd think those would be AD if they're created 
from signed RRSETs.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 23 Jun 2014 09:14:41 +1000

> would as if it had fetched the records one name at a time?

Because authoritative servers don't normally validate the answers
they are returning.  You have to answer things like what to do when
you can't establish a chain of trust to the zone you are serving
or prove that there isn't a chain of trust.  For a cache you SERVFAIL.
An authoritative server's job is to serve the data it has regardless
of whether it validates or not.

That said it is possible to validate answers from a local copy of
a zone and I do just that on my caching servers by having the
recursive view query a seperate view which has local copies of the
zones in it.

> NXDOMAIN responses, but I'd think those would be AD if they're created 

Synthesizing NXDOMAIN / NODATA responses is different to having a
local copy of the zone.

DLV requires caches synthesize negative responses internally so it
is not like doing this is impossible.  The fun part becomes limiting
it to just some zones.  For DLV this is easy as the entire namespace
is supposed to be involved.  There is no bottom of zone to detect
and worry about.

You also need to do things like maintain seperate NSEC / NSEC3 trees
or finding the previous NSEC / NSEC3 record becomes expensive in
the general case.  In the NSEC3 case you also have to workout where
to anchor the search for the NSEC3 record.  You also have to worry
about things like OPTOUT.  For NSEC you can just walk the normal
cache tree, provided it is in DNSSEC order, which is why DLV only
uses NSEC signed zones.  I didn't want to have to solve those other
issues involved with NSEC3.

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ralf Weber <[email-masked]>
Date: Mon, 23 Jun 2014 05:39:18 +0200

> There are some potentially surprising protocol implications for clients when recursive servers answer authoritatively for particular queries. Specifically, AA and AD bit processing is different.
I don't think that anybody is suggesting this. I think it is more appropriate to think of the solution as the resolver having a tiny authoritative server inside serving the root. If it has a copy of the root zone transferred it answers, if not it doesn't and the recursion goes the normal way. That is similar to what people did when there was fear of an attack on the root servers, just inside the server and not with two servers.

So long
-Ralf

---

From: Paul Vixie <[email-masked]>
Date: Sun, 22 Jun 2014 21:02:41 -0700

i'm worried that silence will seem like assent. (for example, someone
who noted that i hadn't complained out loud about the dns-over-tcp preso
at the recent dns-oarc meeting in warsaw to assume that i was in favour
of it -- whereas the truth is at
<http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/>.

in this case, warren kumari is usually pretty smart and sane, but this
time he's come up with a really bad idea. my own related proposal can be
found in the ICANN ITI report
<https://www.icann.org/en/system/files/files/report-21feb14-en.pdf>
section 9.4.

vixie

---

From: David Conrad <[email-masked]>
Date: Mon, 23 Jun 2014 10:48:13 +0100

Paul,

On Jun 23, 2014, at 5:02 AM, Paul Vixie <[email-masked]> wrote:
> time he's come up with a really bad idea.

Your message seemed to have been oddly truncated such that the "because ..." part of this sentence was lost.

> my own related proposal can be

Are you intending to submit that as an ID?

Regards,
-drc

---

From: Tony Finch <[email-masked]>
Date: Mon, 23 Jun 2014 18:07:57 +0100

> Draft: http://tools.ietf.org/html/draft-wkumari-dnsop-dist-root-00

What I do on my toy server at the moment is similar but different, based
on a suggestion from Mark Andrews:
https://lists.dns-oarc.net/pipermail/dns-operations/2013-November/011158.html

The idea is to have an authoritative view with a local copy of the root
zone, and a recursive view which validates as normal but queries the auth
view instead of the usual servers.

The downside compared to your proposal is the lack of any way (other than
operator intervention) to recover from a bogus zone transfer.

view rec {
	match-recursive-only yes;
        zone "." {
		type static-stub;
		server-addresses { ::1; };
	};
};

view auth {
	recursion no;
	allow-recursion { none; };
	zone "." {
		type slave;
		masters { 2001:500:2f::f; 192.5.5.241; };
	};
};

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Plymouth, Northwest Biscay: Northeasterly 4 or 5. Slight or moderate. Fair.
Good.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Jun 2014 22:32:27 +0100

Just to be clear: Warren asked for feedback with an open mind. If you read the draft, you'll see Warren and I explicitly handwave. Also, note that at the moment, he and I disagree about some of the suggestions, just like it seems that some people here so far do. FWIW, I currently prefer the result to be a more robust cache (something that acts just like a cache but also knows how to synthesize NXDOMAIN for things not in the root), and Warren prefers the result to be a less robust slave (something that does not have as close of a relationship with the master as what we normally think, but gives authoritative answers).

That's fine: it is supposed to be a consensus document and we aren't there yet. My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on.

--Paul Hoffman

---

From: Terry Manderson <[email-masked]>
Date: Tue, 24 Jun 2014 00:08:52 -0700

Hi,

Yes, I noted the hand waving as well as a few hand-passes of problems to
$elsewhere.

I personally think this needs (much) more thinking, before coming to the
front of the room in DNSOP - are you considering a bar session somewhere
in Toronto to chat through this?

Cheers
Terry

On 24/06/2014 7:32 am, "Paul Hoffman" <[email-masked]> wrote:

>Just to be clear: Warren asked for feedback with an open mind. If you
>read the draft, you'll see Warren and I explicitly handwave. Also, note
>that at the moment, he and I disagree about some of the suggestions, just
>like it seems that some people here so far do. FWIW, I currently prefer
>the result to be a more robust cache (something that acts just like a
>cache but also knows how to synthesize NXDOMAIN for things not in the
>root), and Warren prefers the result to be a less robust slave (something
>that does not have as close of a relationship with the master as what we
>normally think, but gives authoritative answers).
>
>That's fine: it is supposed to be a consensus document and we aren't
>there yet. My hope is that DNSOP doesn't become too DNSEXT-like where if
>the -00 for a proposal isn't universally loved, it is destroyed instead
>of worked on.
>
>--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jun 2014 08:57:52 +0100

> Yes, I noted the hand waving as well as a few hand-passes of problems to

The latter is unintentional. That is, the goal is to have a spec that does everything it says it will.

> in Toronto to chat through this?

That's one option, but we thought that the WG chairs wanted the consensus discussions happening in the WG on the list. If that's not the case, we can certainly churn the draft in private a bit and then bring it to the WG.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 24 Jun 2014 07:21:44 -0400

> Just to be clear: Warren asked for feedback with an open mind. If you read the draft, you'll see Warren and I explicitly handwave. Also, note that at the moment, he and I disagree about some of the…

I suspect I may have worded things poorly, this isn't quite what I
think. Just FYI, Paul and I had a chat last night in a really quite
nice pub. I was saying that I think both of the above are merely
different ways of looking at the same thing (a less strict slave, or a
more knowledgeable cache). I also spent some time playing devil's
advocate on returning AA vs not AA (it's entirely possible I was
pontificating...)

Anyway, I think that this solution shouldn't return AA bits -- this is
more easily thought of as a cache pre-population system, with the
added benefit of knowing the entire zone (so you already know what
*doesn't* exist.

>
> That's fine: it is supposed to be a consensus document and we aren't there yet.

Yup. The draft has an entire Open Questions section -- we specifically
want to develop this with folk in DNSOP. We could have come along with
a finished document, saying "This is how you should do this - there,
we fixed it for you...", and then fight over all the bits y;all thing
we got wrong. Instead we'd much rather design this *with* everyone so
we end up with a better solution (and with less tears too!)

> My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on.
>
> --Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 24 Jun 2014 07:30:54 -0400

> The latter is unintentional. That is, the goal is to have a spec that does everything it says it will.

Yup. Please point at bits where we've done this / ask what exactly we
were trying to say, or, even better, provide text that answers the
hand-wave.

> That's one option, but we thought that the WG chairs wanted the consensus discussions happening in the WG on the list. If that's not the case, we can certainly churn the draft in private a bit and…

Yup. We did already churn this some in private -- this general idea
has been around for a *long* time, but DNSSEC now makes it much more
feasible. There were (unsurprisingly!) a number of emails and
discussions with a number of people (many of whom are listed in the
contributors section. The rough idea was also presented at DNS-OARC,
RIPE and the DNS track at NANOG) before we posted this version. We
specifically want to get feedback / more input, which is why we
published it as a draft (listing things we know need more discussion
as open questions), and then asked folk to poke at it.

W

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 24 Jun 2014 10:12:59 -0400

(I am merging two of Paul Hoffman's messages into one reply. I hope I am 
not muddling the message)

> That's one option, but we thought that the WG chairs wanted the consensus discussions happening in the WG on the list. If that's not the case, we can certainly churn the draft in private a bit and…

Speaking as co-chair, Mr. Hoffman is absolutely correct on this point - 
we are more than OK with half-baked ideas being hand-waved and a solid 
discussion happening on the list.

> My hope is that DNSOP doesn't become too DNSEXT-like where if the -00 for a proposal isn't universally loved, it is destroyed instead of worked on.

We as chairs do not have that mind set.  My personal feeling is to 
figure out what parts do seem to be useful and have some interest, and 
guide discussions along those lines.   We may be also completely 
delusional, but I'd like to keep believing otherwise for a little while 
longer.

tim

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 25 Jun 2014 11:19:17 +0800

From: Tim Wicinski
Date: 2014-06-24 22:12
To: dnsop
Subject: Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

>the -00 for a proposal isn't universally loved, it is destroyed instead 

+1

Even it looks to be not a good idea at the first stage, it may become a good idea after a detailed discussion and some adjustment.

Jiankang Yao

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Jun 2014 20:30:18 -0700

Tim Wicinski wrote:
> ...
>> My hope is that DNSOP doesn't become too DNSEXT-like where if the -00
>> for a proposal isn't universally loved, it is destroyed instead of
>> worked on.
>
> delusional, but I'd like to keep believing otherwise for a little
> while longer.

i don't think universal love should be the standard for surviving one's
-00 or not -- so that would be a straw man argument if anyone is
actually making it. however, the standard for consensus should remain
good engineering in view of the overall system. i've authored any number
of silly -00's over the years, which were killed before there could be a
-01, because discussion in the forum pointed in that direction. e.g.,
dns-0x20 remains a bad idea, and will remain a bad idea, no matter how
much work the group does on it.

let's not learn the wrong lesson from dnsext's disgrace -- some -00
ideas do deserve to die. warren introduced dist-root to me in warsaw
during dns-oarc as possibly one such stupid idea, and i agreed with him
and told him why. per drc, i owe this forum a copy of those reasons. the
chairs, and the co-authors, should be open to the possibility that no
amount of work will yield consensus that the idea is sound and that the
resulting overall system would be stronger than either the system we
have now or other more easily reached alternatives.

vixie

---

From: Terry Manderson <[email-masked]>
Date: Tue, 24 Jun 2014 23:59:27 -0700

>not muddling the message)

Doing my own leap frog as well.

>the -00 for a proposal isn't universally loved, it is destroyed instead

To be clear, I'm not immediately reaching for a hatchet (a pint perhaps
;). That said rumour mill preceded the draft and I felt somewhat
disappointed by the -00.

However I am driven by stability, robustness, and 'accuracy' of the
system, thus any 'improvements' must be that with zero detractors compared
to the current system. I will invest some time sooner rather than later to
dive deeper into the document and highlight places that seem sketchy to
me, or even just a little bit nuts. (ie For me, the second "con" is a
rather large bump to the system - but could well be implementation
specific)

I don't see this so much as a question of being universally loved, but
more in the realms of it being technically appropriate for the aspects of
protocol function and DNS efficiencies given what we suggest here does
have a strong bearing on the (big "G") global internet operations.

So my first, and biggest, criticism of the draft would be the lack of a
clear and specific problem statement that this document addresses, or aims
to address.

I appreciate that this is half-baked as an answer and thats why its worth
bring here, however if the problem definition itself is half baked then we
really do have issues.

Case in point: the second paragraph of the Intro suggests that the target
is the 'somewhat inefficient' cache construction. Can we get some metrics
to truly define these inefficiencies? You can also read into the "Pro's"
that latency, DoS, centralised monitoring, junk/negative caching, and lack
of DNSSEC validation are all "issues". Are these the problems that _this_
draft is specifically addressing? and can we use those as metrics? Or are
there other problems that the authors have in mind but haven't documented
here for fear of being called a heretic? There are no porcelain angels
here - if there is a problem you see (even a political one that makes
technical life a pain) please call it out.

>delusional, but I'd like to keep believing otherwise for a little while

I'm fine for the discussion and will happily participate.

Cheers
Terry