[98403] in North American Network Operators' Group
Re: large organization nameservers sending icmp packets to dns servers.
daemon@ATHENA.MIT.EDU (Douglas Otis)
Tue Aug 7 18:26:47 2007
In-Reply-To: <20070807212331.GF15413@dba3>
Cc: nanog@nanog.org
From: Douglas Otis <dotis@mail-abuse.org>
Date: Tue, 7 Aug 2007 15:21:32 -0700
To: Andrew Sullivan <andrew@ca.afilias.info>
Errors-To: owner-nanog@merit.edu
On Aug 7, 2007, at 2:23 PM, Andrew Sullivan wrote:
> On Tue, Aug 07, 2007 at 01:50:33PM -0700, Kevin Oberman wrote:
>
>> that security types (I mean those with a police/physical security
>> background) don't must care for these arguments. It usually comes
>> down to "lock and bar every door unless you can prove to them that
>> there is a need to have the door unlocked".
>
> ...
>
> The "need to have the door unlocked" is because that's the way the
> building is designed to fail its fireproofing. And the need to
> have the TCP port open is because that's the way the network
> protocol is designed to fail from UDP.
Ensuring an authoritative domain name server responds via UDP is a
critical security requirement. TCP will not create the same risk of
a resolver being poisoned, but a TCP connection will consume a
significant amount of a name server's resources.
ACLs restricting TCP fall-back is fairly common. For example, too
many bytes might be placed into a domain's SPF records. While TCP
offers a fallback mode of operation for this fairly common error,
this fallback does not ensure oversize records are fixed promptly.
TCP fallback on such records leaves open an opportunity to stage DDoS
attacks when bad actors wishes to take down authoritative name
servers while also attempting to poison resolvers. Here again, SPF
might offer access to remote resolvers query for the records to be
poisoned, isolate query ports, and time poison records. : (
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-forgery-
resilience-01.txt
-Doug
