[RFCI-Discuss] wirralnews.com

[Derek J. Balling]

It's funny to watch you and Jeff talk about this like it's some simple  
"solved many times" problem. Believe me, it's not as easy as you think  
(and, I've repeatedly said "if you think you can make the bogusmx  
check perform better, let me know and you can see the code").

To Jeff, briefly, the libresolv stuff which "has no problem" doesn't  
have any problem because it's willing to cheat the solution..  it  
jumps to the end of the problem first "I've been told by others you  
can give me an MX record, can you?" without first asking that site if  
it considers itself to be part of the list of hosts that should be  
answering that question. I think for most cases, this is a perfectly  
reasonable "performance" decision to make, but sacrifices accuracy in  
edge cases. They're fine with the edge-case inaccuracy, because they  
will point to the heinous misconfiguration of both answering  
authoritatively and not having yourself in the NS set and say "Well,  
that's boned..."

There is a complete separation in code logic between "find the people  
whom I should be asking questions of" (determine the NS set) and then  
"go ask them questions".

The code does the first step of saying "Who are the authoritative NSs  
for DOMAIN?" ... it starts at the root-servers. They say, "go ask the  
gtld-servers.net NS set". The code then adds those NSes to the  
"possibly they're the authoritative NS set" list. It then queries each  
one of them see if they're authoritative, or if, rather, they redirect  
to someone else (like, say to a domain-holder). It then asks THOSE  
NSes the same question. And does that recursively downward further and  
further until one of two things happens:
	1.) It finds the actual authoritative NS set
	2.) It gets told that there is no authoritative NS set
It then returns either a list of NSes or an empty list back to the  
main thread saying "here's who you should ask any and all questions  
about DOMAIN of"

Why does it have to do it this way?  Ponder the case where you're  
looking for say "foo.somedomain.com", and somedomain.com's DNS records  
aren't in sync between "server1" and "server2".... so you have to  
traverse all possible DNS decision paths to get a full and complete  
list of all "possibilities" of places you might end up querying

	root ->
		gtld -->
			server1 -->
				ns1.somedomain.com
				ns2.somedomain.com
			server2 -->
				nsA.badplace.com
				nsB.badplace.com

so in this case, the authoritative list is (ns1.somedomain.com,  
ns2.somedomain.com, nsA.badplace.com, nsB.badplace.com)

So then you say "ok, I need to know the MX set for DOMAIN", so you  
query every one of those hosts you got before, asking them for the MX  
set.

Now you've got a list of hostnames that are potential MXes. Maybe you  
scan them real quick for easy things (e.g., if one of the hostnames is  
"."), but essentially you are then chasing down each MX to find out  
where it resolves to.  So you have to play the authoritative NS game  
again for the domain which the MX hostname is in (to find all the  
possible resolution decision-tree paths for, say, mx.mydomain.org),  
and then go ask each one of those for an A record (and check your  
results, report CNAME returns as errors, etc., etc.)

So, again, this problem is a lot more complicated than it sounds and  
-- frankly -- I think the code is behaving "properly" as it is.
Do I think it sucks that it can miss people who have misconfigured  
their DNS, by intent or accident? Yes.
Do I think libresolv should be "finding" the answer from those people  
with misconfigurations? No.
Do I understand why it does? Yes.
Am I comfortable with the fact that libresolv will still "find" some  
bogus MXes that a meticulous traversal will miss? Meh, I can live with  
it. It's their bug to fix, not mine.

Cheers,
D



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2419 bytes
Desc: not available
Url : http://lists.megacity.org/pipermail/rfci-discuss/attachments/20070908/8662dafe/attachment.bin