Subject: Re: [DNSOP] Fracturing the protocol - was Re: Updated cheese-shop.

From: Ólafur Guðmundsson <[email-masked]>
Date: Tue, 1 Mar 2016 15:26:43 +0000

On Mon, Feb 29, 2016 at 4:03 PM, Warren Kumari <[email-masked]> wrote:

>
>
> On Mon, Feb 29, 2016 at 10:04 AM Shane Kerr <[email-masked]>
> wrote:
>
>> Ed,
>>
>> At 2016-02-29 14:34:39 +0000
>> Edward Lewis <[email-masked]> wrote:
>> > I don't think I was clear - this is only about the DNS protocol.  This
>> > document proposes that the DNS protocol behave differently depending on
>> > the data being carried (QNAME) in it's own messages.
>>
>> [...]
>>
>> > This isn't about processing different values differently, this is about
>> > changing the behavior of the protocol based on environmental factors.
>>
> Ah. So you don't like identifying magic zones (other than in-addr.arpa,
>> ip6.arpa, .example, .local, ...). Fair enough.
>>
>> But AIUI, the proposal is an observation that Fujiwara's
>> NXDOMAIN-from-NSEC proposal can be implemented safely today for the root
>> zone, so we may as well go ahead and do that while considering wider
>> usage.
>>
>
>
> Yup. I believe we should still pursue Fujiwara's document, but that is
> likely to take a significant time, and there are hurdles to overcome. This
> document limits things to a subset where we know things work correctly (and
> seem OK within 4035) - once we have demonstrated that things work OK here,
> it paves the way for more aggressive NSEC.
>
>
Warren,

Can you list the issues you think need addressing in Fujiwara's document
other than saying that zones signed with "Opt-out" there will be gaps where
the technique can be applied, but gaps with opt-out bit set can not be
protected.

Thus I consider your document a distraction, we should push the general
solution not a special case

Olafur

---

From: Ray Bellis <[email-masked]>
Date: Tue, 1 Mar 2016 15:41:36 +0000

> solution not a special case 

+1

Ray

---

From: Mark Andrews <[email-masked]>
Date: Wed, 02 Mar 2016 08:06:39 +1100

In message <[email-masked]>, Ray Bellis writes:
> 
> 
> On 01/03/2016 15:26, =D3lafur Gu=F0mundsson wrote:
> 

ANC can be both good and bad depending upon where it is used in the
DNS.  For the root zone and DLV there is no downside to using ANC
for those zones but the benefits of using ANC will decrease as the
root zone increases in size (the ANC hit ratio will drop).

ANC does not work for zones using OPTOUT.  This is just about all
TLDs and similar zones.

For in-addr.arpa and ip6.arpa it may actually have strong negative
consequences and you can't bring up a machine and have it be useful
for certain classes of work until the NSEC* records have cleared
the cache.  Think bring up a replacement SMTP server.

That then leaves leaf zones.  Here sites will not want ANC for their
own zones internally.  Externally there is only real benefit if you
are under a random prefix DoS attack.

I actually don't see much benefit in deploying this generally.

Mark

> _______________________________________________
> 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: Evan Hunt <[email-masked]>
Date: Wed, 2 Mar 2016 06:49:43 +0000

> ANC does not work for zones using OPTOUT.  This is just about all

To be pedantic, it doesn't work for optout ranges. I don't actually know
offhand of any zones that mix optout and non-optout, though, so it's a
fairly pointless quibble.

> are under a random prefix DoS attack.

Random prefix DoS attacks are prevalent enough nowadays to make
this seem like a rather significant exception.

The downsides should be manageable. We can implement ANC so that it's
separately enabled or disabled for different namespaces, and put a TTL
cap on NSEC/NSEC3 records in zones that have ANC enabled.

I agree with the suggestion upthread that we address the general case
instead of the root-only solution.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 2 Mar 2016 10:10:09 +0100

Evan,

At 2016-03-02 06:49:43 +0000
> instead of the root-only solution.

I can see that implementors such as yourself like won't bother with a
special-cased version, and that adding code to restrict this technique
to the root only is likely to be MORE WORK. (Although realistically
there will probably need to be domain whitelisting & blacklisting in the
resolvers in any case, because in DNS nothing works and everything
is horrible and how does this stuff work at all?)

I think that moving Fujiwara's fuller proposal forward will likely take
an extra year and don't see any conflict with the cheese shop approach
really. However since the cheese shop won't likely result in any
running code, I also agree with the suggestion to focus on the general
case.

Cheers,

--
Shane

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 2 Mar 2016 10:35:09 +0000

+1

> cap on NSEC/NSEC3 records in zones that have ANC enabled.

I personally think we should start up a conversation on good practices for
TTL's
based on the fact we have reliable, fast, dynamic Internet.

> We agree
Olafur

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 2 Mar 2016 10:47:56 +0000

> running code, I also agree with the suggestion to focus on the general
Why?
 Everything we need is in the current draft, if anything there is only
cutting of text to do.
I think the indicator Flag that I (and others) proposed is a bad idea and
should either removed or put in
the OPT record

If we keep it simple then the world will look like this:
  - resolver MAY apply ANC when it suits them, CD bit is ignored for
caching when ANC is in use
  - Auth operators MUST assume they have no control over if resolvers use
ANC and are limited to pleading for help when under attack.

In this world we are no worse off than today. Large Auth server operators
can only hope that the big resolver farms like Google, OpenDNS, Verisign,
Level3, and <mega ISP's> do ANC.
For the record the local-root-zone operation does exactly what the Cheese
shop wants to do just requires two processes in some cases.

Olafur

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 11 Mar 2016 21:45:42 +0100

On Wed, Mar 02, 2016 at 10:10:09AM +0100,
 Shane Kerr <[email-masked]> wrote 
 a message of 29 lines which said:

> I can see that implementors such as yourself like won't bother with
> a special-cased version, and that adding code to restrict this
> technique to the root only is likely to be MORE WORK.

I know at least one case of an implemented option which is to the root
only when it could be more general:

https://doc.powerdns.com/md/recursor/settings/#root-nx-trust

So, not all implementers think the same.