Re: [dnsext] perhaps we should reintroduce "resimprove"

["Blacka, David" <[e-mail]>]

On Feb 13, 2012, at 12:18 PM, Olafur Gudmundsson wrote:

> <still no-hat>
>> 
>>> TTL stretching was a REAL BAD idea, and must be stamped out.
>> 
>> What do you mean by "TTL stretching"?  Are you inventing new DNS terms?
>> 
> Well I have been using this for a while, and I do recall where the definition originated. The issue this term is describing:

Did you mean "I don't recall"?

> When a resolver sees an RRset in an response, that it has in its cache,
> it compares the RRset's and if identical it updates the TTL to reflect the RRset in the response.

OK.  I agree this is a bad idea.  Although, in various implementation's defense, *why* it is a bad idea isn't necessarily obvious.  If you are thinking about improving the cache efficiency of your implementation, and not thinking about "cache pinning" problems, TTL stretching seems like a good idea.

>>>> But changing "replace" with "replace-with-min-ttl" means you're conservative on timeout in the case of disagreement between old and new.
>>> 
>>> I prefer that resolver perform Delete rather than this, that forces the resolver to reevaluate the delegation.
>> 
>> So, every time a zone operator modifies the apex NS RRset, resolvers around the world instantly (as they query the zone for positive answers) invalidate the cached NSs and go back to the parent.  That seems like suboptimal behavior to me.
> 
> I wish you would not use the word: optimal
> as that is setting a value judgment without explicitly saying what you are optimizing.
> In the past trying to do the optimal (packet count) thing vs the safest thing has got us in problems and I do not want to see that again.

In the past, doing overly aggressive things have caused serious problem, too.  My concern with the use of "Delete" it that is has the potential for creating packet storms when a busy zone changes its apex NS RRset.

> What happens depends both on the behavior of the resolver and the authoritative server that is asked.
> For example if the authoritative server is using Minimal-answer (i.e. no authority section on positive answers).
> Then the resolver does not see a new version of the NS set and is denied the opportunity to following ``optimizations''
> 	- discover that the NS set has changed
> 	- Stretch the TTL on the NS set

Sure, minimal-answer does solve a set of problems, but I don't understand the consequences of widespread use of that feature.

>>> In the case of resolver that does "Fetch NS" upon seeing the referral and adheres to RFC2181 credibility rules, it will always ignore NS set in authority section.
>> 
>> Fair enough, but why do I have to do that extra query in order to solve this problem?
> 
> Again here you are using value judgment as what is better:
> 	fewer queries vs safety

No, I'm suggesting that both are important.

> If all resolvers in 2007 had implemented "Fetch NS" and applied credibility rules Kaminsky attack would never have become an issue.
> 
> Similarly when authoritative severs use minimal answers the resolver only has the parent side NS set, what should the resolver do?
> keep the parent side NS or lookup the Childs NS set.

I don't know what they "should" do.  I suspect they keep the parent side NS, as that it what the resolution algorithm will naturally lead.

>>> If a zone wants changes to propagate quickly it should use a smaller TTL. Resolvers should implement a MAX TTL both to purge old data faster, and to adopt faster to changes.
>> 
>> Agreed.  However, I don't think there is any advice what a good max TTL value should be.  2 days? 7 days?
>> 
> 
> Personally I think 1 day if a fine upper bound.

What??? And disenfranchise the millions of 2 day TTLs??

>>> Do you want everyone that has a parent with 600-3600 TTL on parent side NS records to force that policy on all their children?
>> 
>> I don't, at least.  I'd like to preserve as much of the current DNS behavior here as we can (thus, I really don't like the bailiwick rule that the paper authors recommend, since it will force all zones to be parent-centric, which is a major change to current behavior.)
>> 
>> I would think that if the rule was:
>> 
>> Credibility>
>>    Replace, update TTL
>> Credibility ==
>>    Replace, keeping existing TTL
>> 
>> then you would get the desired behavior.  That is, the first NS RRset from the child would update the RRset as normal, allowing the child to have a different NS RRset and whatever TTL they choose.  And when the child changes their NS RRset, it propagates at the same speed it does today (faster than the TTL expiration).  But the resolver will always revaluate the parent delegation after at most 2 TTL intervals.
>> 
> 
> Of the two alternatives, I like "Fetch NS" much better than the logic above.

Why?  I'll admit to not really understanding exactly what "Fetch NS" entails.  When does the resolver decide to issue the NS queries?

> Having said that I also like "Minimal answers" for authoritative servers as that forces resolvers to act more predictably :-)

Clearly, you think that the current DNS behavior of returning the apex NS RRset in the authority section provides no value.  My position is that I don't know that it doesn't, and thus would not like to throw that protocol feature away unnecessarily.

--
David Blacka                          <[e-mail]> 
Principal               Verisign Infrastructure Engineering




_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext