Re: Re: DNS load research

Frank Ellermann wrote:
> Ralf Doeblitz wrote:
>
>  [mx check] 
>
> > Of course you do - unless you are willing to accept mail
> > from senders that you may not be able to send an DSN to.
>
> Then Andy's idea with a weight 1 for any mx mechanism was
> correct.  And my idea to add the number of MXs per q=mx for
> some kind of "overall DNS query count" was probably wrong.
Let's call it unchallenged, not correct. It's completely up to the DNS 
server implementation whether it sends information it wasn't asked for, 
but suspects would be useful. bind9 does send out as much info as 
possible, but apparently aol's NS servers do not send the additional 
info (do nslookup -debug -type=mx aol.com dns-01.ns.aol.com).
Besides, if an MX contains a list of A records of many 
long-host-names-as-MTA-servers.com, there may not be enough room in one 
UDP packet the IP addreses of those hosts, and maybe not even enough 
room for all the names.
The DNS server truncates the name list, and then round-robin rotates 
them, to give the truncated out ones an equal opportunity to serve mail 
requests. In this case, there would be no additional records, and each 
subsequent A query will generate traffic.
When the DNS server has to truncate the answer list, it also sends a 
complete reply by TCP, unless TCP mode is disabled.
Well, that would cause some SPF checks to fail if the DNS server doesn't 
have room to include all the server names.
For small MX lists, it certainly seems to be customary to include as 
much useful information as is available in the response UDP packet.
So it's not all wrong to assume that the MX costs 1 query, but it's not 
a correct general assumption either.
And thus, I restate my preference to retire mx as it is unreliable in 
this SPF application. But I won't put up a fight, as an equally good 
alternative would be to point this corner-case in the spec, and make it 
the publisher's burden to make sure that if he uses MX as a mechanism, 
the list is not so long that it has to be truncated and round-robined.
Also, I believe there's no requirement for a server to return the full 
list even if it would fit in the UDP packet. A smarter DNS server may 
respond with the first 3 or 4 servers, and leave it at that. In the 
application that the MX was inteded for, this works very well. It saves 
DNS bandwidth, and whoever is trying to send email doesn't need to know 
more that 1 or 2 backup MX's. If it works out that none of the given 
MX's are reachable, the sending MTA will just try later, when maybe one 
of the listed servers comes back online, or the MX record expires and a 
new one is fetched that gives different list of hosts.
The same technique is applied for load balancing on A records. 
www.yahoo.com does it:
[root(_at_)sun zones]# host www.yahoo.com
www.yahoo.com is an alias for www.yahoo.akadns.net.
www.yahoo.akadns.net has address 68.142.226.44
www.yahoo.akadns.net has address 68.142.226.45
www.yahoo.akadns.net has address 68.142.226.47
www.yahoo.akadns.net has address 68.142.226.48
www.yahoo.akadns.net has address 68.142.226.50
www.yahoo.akadns.net has address 68.142.226.51
www.yahoo.akadns.net has address 68.142.226.32
www.yahoo.akadns.net has address 68.142.226.39
[root(_at_)sun zones]# /usr/sbin/rndc flush
[root(_at_)sun zones]# host www.yahoo.com
www.yahoo.com is an alias for www.yahoo.akadns.net.
www.yahoo.akadns.net has address 68.142.226.37
www.yahoo.akadns.net has address 68.142.226.39
www.yahoo.akadns.net has address 68.142.226.40
www.yahoo.akadns.net has address 68.142.226.42
www.yahoo.akadns.net has address 68.142.226.44
www.yahoo.akadns.net has address 68.142.226.49
www.yahoo.akadns.net has address 68.142.226.52
www.yahoo.akadns.net has address 68.142.226.53

And it's the master server doesn't do load balancing, there's nothing to 
stop a caching server to do load balancing, and for a list of 8 IPs 
returned by the master server, to respond to queries with only 2-3 at a 
time.
So it would seem that that A mechanism is also not as reliable as we 
believe it to be, in the SPF application. The way it works is perfectly 
fine, and even very smart for the rest of the internet.
Maybe these are some of the reasons why the DNS guys didn't like SPF ?

Like Kitterman said... There's more DNS work that needs to be done here.

I'm happy to lend a hand and a piece of my brain. :)

Regards,
Radu.