kyle-qmail at memoryhole
Jul 16, 2009, 7:49 AM
Post #16 of 16
(3903 views)
Permalink
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
On Wednesday, July 15 at 07:22 PM, quoth Andy Bradford:
> Right, and even qmail.org mentions that it is only a mitigating
> option to use dnscache, however, in 10 years of practical use, I
> don't recall ever having had an issue with it (I've never used the
> patch). Are there any legitimate domains (I would agree with you
> that this domain probably doesn't deserve mail) that have problems
> with qmail+dnscache?
I'm not aware of any *currently*, but that doesn't mean that they
don't exist.
>> The 512-byte limit that qmail assumes is a UDP limit, not a DNS
>> limit (in fact, the DNS RFC explicitly points out that the TCP
>> length is a two-byte field for extra large packets). Since DNS can
>> be transmitted over TCP to avoid that packet size limit, large
>> responses are perfectly legal (if somewhat absurd and annoying).
>
> Actually, /usr/include/arpa/nameser.h defines the packet size as 512:
>
> /*
> * Define constants based on rfc883
> */
> #define PACKETSZ 512 /* maximum packet size */
I recognize that, but nameser.h is being misinterpreted. I can read
the RFC, and RFC 883 *does* indicate that packets can be bigger. The
number 512 shows up in only a few places in the RFC. Page 11 ("Query
and response transport") is talking about DNS "datagram service",
which is by definition a connectionless communication protocol (in
other words, UDP). There it says:
Hence datagram messages are limited to 512 octets.
But nowhere does it say that "virtual circuit" (i.e. a TCP connection)
communication has such a limit.
And when you think about it, what is the point of the TC bit
(TrunCation, page 26) if not to indicate that sometimes DNS responses
need to be larger than 512 bytes?
> Granted, RFC883 is outdated, but modern *nix do still include this file.
RFC 883 may be outdated, but it's still CORRECT. PACKETSZ only applies
when you are considering *packets*, which the client almost never
should. PACKETSZ does not apply to general DNS responses.
> What would be the implications of simply changing the arrays to use a
> larger buffer:
>
> #define MYPACKETSZ 65536
>
> static union { HEADER hdr; unsigned char buf[MYPACKETSZ]; } response;
>
> Would this be sufficient?
In qmail's dns.c? Yes, that'd be sufficient. But it would also be
wasteful. MOST of the time you don't need that much buffer space for
DNS operations. That's why the much-discussed patch resizes that
buffer as necessary.
> Yet, presumably, if arpa/nameser.h were for some reason updated with
> a new PACKETSZ definition, would it still be a problem? I imagine
> that qmail is not the only program that depends on PACKETSZ so this
> could have far reaching effects...
The problem is not that PACKETSZ is the wrong size, but more
accurately that PACKETSZ is being misused. Qmail (and maybe even most
programs that use PACKETSZ) is assuming that PACKETSZ has some sort of
impact on the output of the res_query function. In other words,
they're assuming that all DNS responses fit into a single (UDP)
packet. That's an invalid assumption. PACKETSZ is still the correct
size of a single (datagram) packet, which is all it ever claimed to
be. The problem is the assumption that DNS responses are never any
bigger than a single packet. (I know I'm repeating myself there, but I
haven't had my coffee yet this morning.)
~Kyle
- --
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
-- Brian Kernighan
-----BEGIN PGP SIGNATURE-----
Comment: Thank you for using encryption!
iQIcBAEBCAAGBQJKXz3oAAoJECuveozR/AWeHsQQAKXv4ogKkWvi63Hcdysb0YuK
Gyfhrwea7djX3AcTBfE/3BTBp0HZ0PE+7aoeJXjvR0lEMKj+GRupbHGX31e7woD5
PDXronCLtgjrkIi0/WgI9AYEIhqkMkeycSRuqIayLbQhw0ShHI19X/Uu+31Y3+lL
UNeUG2tDiECzp4VGsH7QGnIz64g0AGoe5HzmXPU+WAQ44Or/HzZ8XiS3HAhIlzha
E+KO8WPmOybBojQlu0YCqomtEwhj060HPIXU27e9iNG0sLicYddniQfNSWSxZpef
QmAewrzwYYSlWc3XiJ0zHix9BB2nQeojKGLk3fI2bsR1jdLp/0qcaeM9Og88P2qW
sS4sz84+m5y0jq9LrFEr2YpvzDDmZBoLrCLizKW0Rw5A/4X6RZQ+TFsT4PUJXMMG
5jnGcZlKKSBXdca6ucFnEVu9FnIOLOrT3x3iEkZUITJMC7ct3We1t4A2IU8wimrr
Mz02erEjB1g9wc4VGBMqxpjXUlo5CgMxWjPqdZREIZ0xuinAc6RkTXlgA9kn4lDF
6K04j6yx0bjQGAujYSq3QykKO5gOQA5TKTGOoFv+0Jze/ntwfN1NRaY+Hkp+jgQz
eI34d7TPZc5wHca/FWJ+auk0wWRkiqDZ/8qp4EIICnEiqcx1x2vFPrdb4xZxtHSe
7KjV2XhZsNwdLfRwQ9ON
=bj10
-----END PGP SIGNATURE-----
|
