large organization nameservers sending icmp packets to dns servers.
oberman at es.net
Tue Aug 7 19:56:34 UTC 2007
> From: Joe Abley <jabley at ca.afilias.info>
> Date: Tue, 7 Aug 2007 15:19:30 -0400
> Sender: owner-nanog at merit.edu
> On 7-Aug-2007, at 14:38, Patrick W. Gilmore wrote:
> > On Aug 7, 2007, at 2:14 PM, Donald Stahl wrote:
> >>> All things being equal (which they're usually not) you could use
> >>> the ACK
> >>> response time of the TCP handshake if they've got TCP DNS resolution
> >>> available. Though again most don't for security reasons...
> >> Then most are incredibly stupid.
> > Those are impressively harsh words.
> But they are hard to argue with.
> >> In addition, any UDP truncated response needs to be retried via
> >> TCP- blocking it would cause a variety of problems.
> > Since we are talking about authorities here, one can control the
> > size of ones responses.
> "Never reply with anything big and hence never set TC" seems like a
> reasonable, expedient way to circumvent the problem of wholesale 53/
> tcp-blocking stupidity. It doesn't make the behaviour any less
> stupid, though.
> The "security" argument looks even more bizarre when you consider
> what the DO bit in a request will do in general to the size of a
> response, in the case of an authority server which has signed zone data.
This has been a pain for me for years. I have tried to reason with
security people about this and, while they don't dispute my reasoning,
they always end up saying that it is the "standard" practice and that,
lacking any evidence of what it might be breaking, it will continue to
be blocked. And I don't mean small companies, either. One of the biggest
issues I have is with one of the countries largest government funded
Wonder how often DNSSEC might make non-transfer queries tickle this and
really break things? (Assuming we ever get wide use of DNSSEC.)
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 224 bytes
Desc: not available
More information about the NANOG