Subject: Re: [dnsext] draft-vixie-dnsext-resimprove-00: Improvements to DNS Resolvers for Resiliency, Robustness, and Responsiveness

From: "Zheng Wang" <[email-masked]>
Date: Fri, 25 Jun 2010 13:16:45 +0800

>On 2.6 - I not sure that randomly reducing the TTL as suggested is a
>good idea. Instead it may be better to randomise when the record is
>revalidated (or prefetched). The difference is that I think that the
>resolver should advertise the "honest" decrementing TTL to any
>queries. That way if you have a hierarchy of resolvers they aren't
>simply making the effective TTL shorter and shorter still.
>

In my view, they are separate concepts. The advertised TTL adheres to the original
definition, while the TTL used for delegation validation is randomly reduced. 

>On 3.4 - I see the security note at 5.1, but still - an attacker might
>poison with a long-ttl NXDOMAIN response for "com" or "." and it will
>cause a lot of problems for the resolver. As written, it may even
>cause the cache to have to purge potentially a large volume of data.
>I'm not sure I see the benefit, insulating upstream servers from
>slightly more queries seems less important. Are NXDOMAIN subtrees
>really a big problem?
>

No, the purpose of delegation validation is likewise right here to maintain the
coherency. 

>On 4.4 - what happens when no nameservers are returned? Sometimes the
>nameservers to which a domain have been delegated have incoherent
>opinions about where the apex even is. E.g.
>
>   example.com delegates www.example.com to   ns-1.foo.com
>
>   ns-1.foo.com considers itself authoritative for "example.com" and
>has a record configured for www.example.com
>
>   A query for www.example.com's NS records would return 0 answers, but NOERROR.
>
>This works right now, and while it's incoherent, it's a relatively
>common misconfiguration.
>

This still works, but the delegated nameservers have no chance to be replaced by
the true authoritative ones and thus have to be relied on.

Regards,

------------------------------
Zheng Wang

CNNIC Labs

_________________________________________________________

China Internet Network Information Center

Phone:    (8610)-58813212

Fax:      (8610)-58812666-123

Email:    [email-masked]

Address:  4, South 4th Street, Zhongguancun

          Haidian District, Beijing

          P.R.China  100190

________________________________________

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 28 Jun 2010 09:14:06 -0700

> definition, while the TTL used for delegation validation is randomly reduced.

That's my view too, but it's not what the I-D says. The I-D says to
reduce it before storing it in the cache :)

> No, the purpose of delegation validation is likewise right here to maintain the

I don't see NXDOMAIN for an entire subtree as that closely tied to
delegation validation - as the I-D itself says the current state of
things is ambiguous.

> the true authoritative ones and thus have to be relied on.

That should be clarified - one reading is that it implies "this domain
has no nameservers".

-- 
Colm

---

From: Paul Vixie <[email-masked]>
Date: Mon, 28 Jun 2010 16:52:12 +0000

> Date: Mon, 28 Jun 2010 09:14:06 -0700
> From: Colm MacCárthaigh <[email-masked]>
> 
> > In my view, they are separate concepts. The advertised TTL adheres to
> > the original definition, while the TTL used for delegation validation
> > is randomly reduced.
> 

here's the text:

   2.6. To make the timing of a revalidation event unpredictable from
   the point of view of a potential cache-spoof attacker, the parent's
   delegating NS RRset TTL should be reduced by a random fraction of its
   value before being stored for use in revalidation activities.

the intent was what you guys are saying here. i'll clarify the text. i
really thought "stored for use in revalidation activities" was clear.

> > > On 3.4 - I see the security note at 5.1, but still - an attacker
> > > might poison with a long-ttl NXDOMAIN response for "com" or "." and
> > > it will cause a lot of problems for the resolver. As written, it may
> > > even cause the cache to have to purge potentially a large volume of
> > > data.  I'm not sure I see the benefit, insulating upstream servers
> > > from slightly more queries seems less important. Are NXDOMAIN
> > > subtrees really a big problem?
> >
> > No, the purpose of delegation validation is likewise right here to
> > maintain the coherency.
> 
> delegation validation

it's not. but it is intended to maintain coherency.

> - as the I-D itself says the current state of things is ambiguous.

the -00 text says it was ambiguous before DNSSEC clarified it.

if we believe that a poisoned response can overwrite . or COM in the
cache, then we should worry about false NS RRsets as much as we'd worry
about false NXDOMAIN. i assert that those are equivilent risks (same
possibility of it occurring, same danger to a victim when it occurs.)

i'm not talking about "slightly more queries" either. this is a DDoS
vector the leaving open of which supports a protocol ambiguity that's
long since been decided. the more i think about this, it should be STD
nor FYI.

> > This still works, but the delegated nameservers have no chance to be
> > replaced by the true authoritative ones and thus have to be relied on.
> 

will do.