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

<still no-hat>
On 10/02/2012 10:58, Nicholas Weaver wrote:
>
> On Feb 10, 2012, at 7:23 AM, Olafur Gudmundsson wrote:
>> For Credibility Greater ">"  the following options make sense
>> 	Store, Replace
>>
>> For Credibility Equal "="   the following options make sense
>> 	Ignore, Delete
>>
>> For Credibility Less "<"
>> 	Ignore
>>
>> If you do Replace on NS on "=" you get ghost domains, because
>> NS set and Glue are the only data that resolver will see in an answer that it potentially has in cache.
>> If you insist on allowing "Replace" on equal then you MUST implement "Fetch NS from child" and "Fetch all glue" to combat the ghost domains and still have Kaminsky defense.
>
> One other option:
> replace-with-min-TTL:  A replacement cache entry's new TTL is min(current TTL on the entry, new TTL).
>
>
> 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.

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

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.

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

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