Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Terry Manderson]

On 25/06/2014 12:12 am, "Tim Wicinski"  wrote:

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

Doing my own leap frog as well.

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

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.

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

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

Cheers
Terry


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Paul Vixie]

Tim Wicinski wrote:
> ...
>
> On 6/24/14 3:57 AM, Paul Hoffman 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.
>
> 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Jiankang Yao]

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

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

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

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

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Tim Wicinski]

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


On 6/24/14 3:57 AM, Paul Hoffman wrote:

On Jun 24, 2014, at 8:08 AM, Terry Manderson  wrote:


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


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


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?


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.



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.


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.



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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Warren Kumari]

On Tue, Jun 24, 2014 at 3:57 AM, Paul Hoffman  wrote:
> On Jun 24, 2014, at 8:08 AM, Terry Manderson  
> wrote:
>
>> Yes, I noted the hand waving as well as a few hand-passes of problems to
>> $elsewhere.
>
> 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.

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


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



>
> --Paul Hoffman
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Warren Kumari]

On Mon, Jun 23, 2014 at 5:32 PM, Paul Hoffman  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).


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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Paul Hoffman]

On Jun 24, 2014, at 8:08 AM, Terry Manderson  wrote:

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

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

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

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

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Terry Manderson]

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


smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Paul Hoffman]

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

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[David Conrad]

Paul,

On Jun 23, 2014, at 5:02 AM, Paul Vixie  wrote:
> in this case, warren kumari is usually pretty smart and sane, but this
> 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
> found in the ICANN ITI report
> 
> section 9.4.

Are you intending to submit that as an ID?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Jiankang Yao]

The draft says
" Once the resolver has transferred and validated the zone, it MUST act as 
though it is a
   copy of the root zone."

 If the idea in this document is implemented, does it mean that the "root 
servers" will be everywhere in the internet?


Jiankang Yao ___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Paul Vixie]

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
.

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

section 9.4.

vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Ralf Weber]

On 22 Jun 2014, at 18:41, Joe Abley  wrote:

> 
> On 22 Jun 2014, at 11:54, John Levine  wrote:
> 
 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.  
>>> 
>>> 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.
> 
> 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Mark Andrews]

In message , "John R Levine" 
writes:
> >> 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.
> >
> > 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?

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.

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

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.

> Regards,
> John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
> Please consider the environment before reading this e-mail.
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[John R Levine]

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.


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, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Joe Abley]

On 22 Jun 2014, at 11:54, John Levine  wrote:

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

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

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[John Levine]

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

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

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

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

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

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[Paul Hoffman]

On Jun 22, 2014, at 2:14 AM, John Levine  wrote:

>> Reactions have been, um, mixed. Some folk say it;s a no-brainer,
>> 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.  

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

Yes.

> 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 latter. That's a benefit of DNSSEC.

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

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

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

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
> company could profitably cache foo.com, particularly if it's less
> administrative and technical hassle than setting up a local shadow
> master.

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.

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

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

Re: [DNSOP] feedback on draft-wkumari-dnsop-dist-root-00

[John Levine]

>Reactions have been, um, mixed. Some folk say it;s a no-brainer,
>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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop