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

<still no-hat>

On 10/02/2012 17:58, Blacka, David wrote:
>
> On Feb 10, 2012, at 3:08 PM, Olafur Gudmundsson wrote:
>>>
>>>
>>> The problem with ghosted domains is not changing the NS RRSET, its that changing the NS RRSET is also resetting the TTL.  Yet given "Newer vs older data of the same credibility", isn't newer more meaningful (apart from the stickyness problem)?
>>>
>> 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:

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.

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

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

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

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

>>> And overall, I think replace-with-min-TTL should be standardized. Because even "Credibility>   replace" can have a problem:  The parent wants a deliberate shorter TTL for the NS set, but the child can override it.
>>>
>>> For example, .com wants a 2 day TTL, but the child overrides it with a 7 day TTL, which still gives a 7-day 'no-revocation' window for any preseeded domains.  This could be even worse for various dynamic DNS services which allow delegation.
>>>
>>>
>> well in the case of TLD's the TTL on referrals ranges from 600 (10min) to 345600 (4 days)  with 1 day as the median value and most common one.
>> Based on a sample of 180 google.<TLD>  domains out of 310 TLD's.
>>
>> 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.
Having said that I also like "Minimal answers" for authoritative servers 
as that forces resolvers to act more predictably :-)

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