Re: [dnsext] WG opinion on draft : Improvements to DNS Resolvers, for Resiliency, Robustness, and Responsiveness

[Paul Vixie <[e-mail]>]

there are replies to three messages here.

---

> From: David Blacka <[e-mail]>
> Date: Mon, 21 Feb 2011 13:58:27 -0500
> ...
> I was not aware of this draft's existence until now, but I just read it.

i figured as much from the silence.  hopefully this thread will stimulate
other readers.

> ... I'm unsure, although I'm leaning toward thinking that they are not
> good ideas. 

you've misunderstood the text, indicating that the writing quality is
too low.  i won't go point by point on your misgivings and concerns,
since...

---

> Date: Mon, 21 Feb 2011 15:51:20 -0400
> From: Brian Dickson <[e-mail]>
> 
> I have read the draft, and also David's comments, and have comments of
> my own in-line below.

...since brian dickson's point by point followup is accurate and on target.

> Briefly, however, I'd say:
> - the things in the draft are all good ideas
> - the draft is good, should be adopted, requires only a small amount
> of work, and once that is done, is probably fine for WGLC.
> - s few clarifications will go a long way to addressing both David's
> issues, and making the document useful
> - all of the above are "IMIHO"

this echos my own view.  we were not expecting to go to WGLC on -00, and
in fact there is a -01 in the wings (sweeping in a fourth topic that was
flying solo out of CNNIC) and we should see that posted before the cutoff
for prague.  what the authors were hoping for from -00 is exactly the kind
of review and feedback that is occurring right now.  so, let's pull back
from WGLC and fix the editorial problems noted by dave blacka and put this
on the prague agenda?

---

> From: Tony Finch <[e-mail]>
> Date: Mon, 21 Feb 2011 21:28:53 +0000
> 
> There are a couple of other things that worry me about this section of
> the draft.
> 
> Firstly, it suggests that there can be multiple different TTLs on the
> delegation NS RR set - it talks about the minimum TTL. It needs fixing
> to understand that the whole RR set has the same TTL.

well, so, the protocol gives each RR a TTL and the original specification
does not say what to do if the TTLs in an RR set differ.  in BIND4 4.9, i
decided to discard the whole RR set if any of its TTLs reached zero since
otherwise we'd be modifying RR sets during TTL expiration.  in RFC 2136 i
enshrined this behaviour into the protocol by declaring "RR set atomicity".
but editorially speaking i still think it's wise to say "discard when the
minimum TTL in the RR set is reached" since the wire protocol allows TTLs
to be different across an RR set and sending them out that way is not an
error or a protocol violation.

> Secondly, it is basically suggesting that the TTL of the
> non-authoritative spoofable delegation NS RR set should override the
> TTL of the authoritative signed apex NS RR set. This seems to me to be
> contrary to DNS and DNSSEC authority semantics.

again, the quality of the writing is evidently low, and i wrote this
section of the resimprove draft so i'll take the hit for that.  it is
NOT an override.  it's a freshness guaranty.  if upon parent (non-auth)
expiry the refresh (from the parent) shows that the delegation still
exists then no change is made to the child (auth) data then in cache.
however, if the delegation has disappeared in the parent, then we want
the child GONE.  e-criminals periodically use million-second TTLs on
their zone data and by the time they're done with a spam run using that
name it's ineffective to delete the delegation since by that time child
data is widely held in caches.  using the parent TTL as a freshness
guaranty just means the registrar and registry operators can put shorter
TTLs on the delegation than the child has at their apex, and cause
periodic refreshes of this, for the purpose of having domains disappear
from cache if their delegation disappears.  it has no dnssec or other
semantic effects.