[dns-operations] resimprove and Re: DNS Flush Protocol

[Edward Lewis]

On 3/27/15, 16:00, "Paul Vixie" <paul at redbarn.org> wrote:

>Warren Kumari wrote:
>> ...
>>
>> I was saying is that we don't really need to reach *every* recursive,
>> whatever we do manage to do will be better than the current position.
>
>i disagree. a solution for the big resolvers will decimate incentive for
>any other solution for all resolvers. we need the weight of the big
>resolvers behind any standard we push in this area.

I agree with the former and disagree with the latter.

If the one continues to assume the commercial world adheres to RFCs and
refuses to entertain measurements of activity, irrelevance is the eventual
result.

Concentration of the recursive service market matters, if it is true.
(Mindful that all statistics are subject to bias and error.)

>> Sure, a fully awesome, all shining, all dancing cache flush solution
>> that can securely flush all caches everywhere would be best, but until
>> this comes along, something, anything really, is better than posting
>> on DNS-Operations.... W
>
>warren, have you read
><http://datatracker.ietf.org/doc/draft-vixie-dnsext-resimprove/> and do
>you have comments?

Speaking for myself and not Warren - I read it back in time.  I distinctly
remember responding but no longer recall on what mailing list or when.  In
essence, and why I recall the draft, is that I didn't support it's ideas.

I get the idea of using the cutpoint TTL to determine when to refresh apex
data.  I get that if a zone is hijacked, this would lower recovery time.
But I think that it is unwise to optimize for "rainy days" when "sunny
days" are more frequent.

I more cling to the sanctity of a delegation.  When a parent delegates to
a child, the child is the master over it's contents, not the parent.
Outside of permitting the delegation (holding an NS set) and indicating
its security entry parameters, all else is property of the child.

A resolver does have free-will to do what it needs to find answers to
queries.  It could choose to over amp queries if it wants up to date
information at all times (whether for rainy days or just because).  Most
do judging from work I've done in the past.  (E.g., very, very few
queriers honored a multi-day TTL I had for a particular record set.)  (Had
I known this, it would have made  difference in how I set TTL values.)

Overall, I wouldn't make the recommendations in -resimprove.  Probably
said it then (can't substantiate my claim) and I still not moved.  I get
the point, ... but unless you can show me statistics that say hijacked
zones matter enough, I'm not going to optimize that direction.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4604 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20150327/980e1c93/attachment.bin>