[dns-operations] [dDoS] Good discussion on the Rackspace attack and DNS resiliency

[Paul Vixie]

> David C Lawrence <mailto:tale at akamai.com>
> Tuesday, December 30, 2014 9:17 AM
> Colm MacCarthaigh wrote:
>> Yes, that clearly violates the TTL of the rrset, but wouldn't be
>> over-all better for the health of the internet?
>
> Paul Vixie wrote:
>> no. sometimes the old value is dangerous (private; load; loss) to the
>> person who changed it.
>
> On the other hand, since implementing it in our own local resolvers I
> can tell you that the feature has absolutely averted customer
> incidents, and never once caused one by using stale data.

i think you mean "we have heard no reports of incidents caused by stale
data"?
> Thus personally I would say that the answer to Colm's question is a
> qualified yes.  I don't disagree with you about there being
> problematic cases, but if we had let the perfect be the enemy of the
> good we wouldn't even have the practical Internet and the World Wide
> Web today.  On balance to me the feature is "over-all better" for DNS
> resilience.
>
> I've been considering writing up an I-D and/or presenting to SSAC
> about our experiences with it and recommendations for how to handle it
> operationally.  Should make for a lively discussion.

i think it's worth debating and/or standardizing, but ought not be done
without case by case permission otherwise. if the real problem is "ttl's
are too short" or "rdns servers should save and restore their cache
across restarts" then i'd rather we solve the real problem. violating
other people's reasonable assumptions meanwhile shouldn't be an option.

see also: <http://queue.acm.org/detail.cfm?id=1242499>.

-- 
Paul Vixie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141230/83ef9a09/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141230/83ef9a09/attachment.jpg>