> From: Joe Abley <[EMAIL PROTECTED]> > Date: Tue, 7 Aug 2007 15:19:30 -0400 > Sender: [EMAIL PROTECTED] > > > > 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 research labs. 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: [EMAIL PROTECTED] Phone: +1 510 486-8634 Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751
pgpU18YPgK72t.pgp
Description: PGP signature
