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

On 13/02/2012 13:59, Blacka, David wrote:
>
> 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"?
>

Yes I meant "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 I wrote originally was the resolver could do one of two things: 
Ignore or Delete.

If it does ignore the NS RRset will time out and at some point after 
that the resolver will find out about the change.

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

The main consequence is that large set of resolvers will use the Parent 
side NS record.

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

Number is up for discussion and should be configurable, but for the 
record this is what the current version of Unbound does.
I suspect that most TTL decisions consist of pulling numbers out of a 
hat or looking at what someone else is doing because they know better :-)

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

The only time Resolver is required to do  "Fetch NS" is when it 
discovers the existence of the delegations by getting a referral from 
the parent.

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

I would phrase it differently "Currently having the apex NS RRset 
included in authority section of positive answers provides ability for 
badly written resolvers to misbehave to the determent of the Internet"

Background: I have been researching how to do Domain Name Transfers when 
DNSSEC is enabled on the domain. In doing that I realized that not all 
resolvers are following the protocol. The first thing I needed to 
educate myself was that using the word "Transfer" was a bad idea.
So I now call it "changing the DNS operator".
One of the questions to answer was when can the old operator turn off 
service ?
everyone's first guess is "NS TTL"
To that the followup question: which NS ?
second guess is "max of the two NS's TTL"
but that fails for the resolvers that stretch the TTL and have strong 
affinity for the domain going through the operator change, except when 
the old operator is doing "minimal answers" and the resolvers can not 
cheat.

	Olafur
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext