nanog mailing list archives

Re: large organization nameservers sending icmp packets to dns servers.


From: "Kevin Oberman" <oberman () es net>
Date: Tue, 07 Aug 2007 12:56:34 -0700

From: Joe Abley <jabley () ca afilias info>
Date: Tue, 7 Aug 2007 15:19:30 -0400
Sender: owner-nanog () 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
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: oberman () es net                       Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751

Attachment: _bin
Description:


Current thread: