On Wed, 27 Jul 2005, Jim Fenton wrote:
That is because your DNS server is configured to send ip addresses of all
your mx servers in additional section. Whilte this is helpful to a degree,
this is not a typical response to mx by dns servers (you don't really need
to know EVERY MX ip when doing query, just one is enough).
I haven't yet found a domain that works as you describe. I did a single "dig
elan.net mx" and my DNS cache got populated with 4 NS, 4 MX, and 8 A records.
As I kind of mentioned I was testing things out on my own for a project.
I'll try to find my patched code to return just one mx and get it running
if you're interested. For general community, point of all that turned out
that sending just one (lowest) mx 'A' from nameserver can reduce amount
of data from dns queries and cache on remote end with only few extra
dns lookups being done (to keep number of those extra lookups to almost
0 'A' of last highiest mx in your list could also be sent - I'll let you
guess yourself who were the goons trying to use last max). I should
probably mention this on appropriate mail list and possibly write a draft
about it (although I should really do more testing with couple larger
domains first).
It seems like the difference isn't orders of magnitude.
Difference in what?
Difference in the size of the response. It's not like we're making a
factor-of-10 difference in the amount of data returned from a typical
query.
What did you compare? If its comparison of DKS public key vs fingerprint
in DNS, that is factor of 5 difference there for 1024bit keys and factor
of 10 for 2048bit keys.
I agree that if you just compare dns query response size, the difference
is probably about 2x (because of typical dns packet overhead). But for
the amount stored in cache difference in the size of RDATA is going to
be quite a bit larger.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net