DNS hardening, was Re: Dan Kaminsky
morrowc.lists at gmail.com
Thu Aug 6 10:44:43 CDT 2009
On Thu, Aug 6, 2009 at 11:16 AM, Paul Vixie<vixie at isc.org> wrote:
> note, i went off-topic in my previous note, and i'll be answering florian
> on [email protected] since it's not operational. chris's note was operational:
>> Date: Thu, 6 Aug 2009 10:18:11 -0400
>> From: Christopher Morrow <morrowc.lists at gmail.com>
>> awesome, how does that work with devices in the f-root-anycast design?
>> (both local hosts in the rack and if I flip from rack to rack) If I send
>> along a request to a host which I do not have an association created do I
>> get a failure and then re-setup? (inducing further latency)
> yes. so, association setup cost will occur once per route-change event.
> note that the f-root-anycast design already hashes by flow within a rack
pulling something I didn't previously understand from an ongoing
discussion on the LISP/v6ops mailing lists... most routers today only
hash on tcp/udp so.. sctp isn't going to hash in the same
'deterministic' manner, or someone should probably test that that is
> to keep TCP from failing, so the only route-change events of interest to
> this point are in wide area BGP.
right, and the (I think K-root) K-root folks had a study showing <1%
of sessions seemed to be failing in this manner? (nanog in Toronto I
>> ...: "Do loadbalancers, or loadbalanced deployments, deal with this
>> properly?" (loadbalancers like F5, citrix, radware, cisco, etc...)
> as far as i know, no loadbalancer understands SCTP today. if they can be
> made to pass SCTP through unmodified and only do their enhanced L4 on UDP
> and TCP as they do now, all will be well. if not then a loadbalancer
> upgrade or removal will be nec'y for anyone who wants to deploy SCTP.
> it's interesting to me that existing deployments of L4-aware packet level
> devices can form a barrier to new kinds of L4. it's as if the internet is
> really just the web, and our networks are TCP/UDP networks not IP networks.
sadly, people have (and continue) to make simplifying assumptions
while designing/deploying equipment.
More information about the NANOG