To:
Derek Atkins <warlord@MIT.EDU>
cc:
Paul Hoffman / IMC <phoffman@imc.org>, keydist@cafax.se
From:
Michael Richardson <mcr@sandelman.ottawa.on.ca>
Date:
Tue, 08 Jan 2002 15:32:37 -0500
In-reply-to:
Your message of "08 Jan 2002 13:59:57 EST." <sjmsn9gis7m.fsf@cutter-john.mit.edu>
Sender:
owner-keydist@cafax.se
Subject:
Re: From whence we came...
-----BEGIN PGP SIGNED MESSAGE-----
>>>>> "Derek" == Derek Atkins <warlord@MIT.EDU> writes:
Derek> Paul Hoffman / IMC <phoffman@imc.org> writes:
>> At 9:43 PM -0500 1/7/02, Derek Atkins wrote:
>> >I think we're already assuming EDNS0 and DNSSEC, which already requires
>> >support for >512 bytes (and provides a way of negotiating support).
>> >So, no, size is not (really) an issue.
>>
>> OK, I admit that I am a bit naive about DNS politics. I thought that
>> the objection to >512 octets was regardless of EDNS0. That is, even
>> though the end systems are supposed to support longer packets, the
>> UDP fragmentation happens in the middle of the net, and the end
>> systems fall back to TCP. The EDNS0 document is far from clear (even
>> after many readings, which I have done wearing my IDN hat).
>>
>> So, are 2K-4K DNS responses OK now as long as they come in EDNS0?
Derek> 2K-4K? Where do you get that size? When I query, for example,
Derek> "tislabs.com. IN ANY" I get a response of 2223 bytes (according to
Derek> dig). This response includes the SOA, 3 NS records, 2 MX records, 4
Derek> KEY records, 1 NXT record, and 8 SIG records. So, where is your
Derek> 4K coming from?
There are no application keys in that response :-)
] ON HUMILITY: to err is human. To moo, bovine. | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[
] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1
Comment: Finger me for keys
iQCVAwUBPDtXY4qHRg3pndX9AQE9CwP+MSlqXFlV00ersLn7PrlFigHubfE6zPzT
4eO3Bu5B66qV0JGTnDHXWjYj5udODiGkaiABkx2EI3UFTgOsM/P/Daf8UQAUggWY
1wHPQt+rzsFLojJ9FA/LBfb72cFqPgkdGH7sLhzNYLqiHsgyIvpsxHACZ4l5piSS
XcdxhAeNudo=
=9qFR
-----END PGP SIGNATURE-----