[RFCI-Discuss] wirralnews.com

[Derek J. Balling]

On Sep 8, 2007, at 10:57 AM, Alex van den Bogaerdt wrote:
> My point is: no, you don't.  All you need is one server which
> gives the wrong answer.  You aren't interested, at all, in the
> rest of the set of servers (if any).

But you need to know "all" of them, so you can find one.

> I believe this will significantly reduce the load in many cases.
> What you describe is the worst case scenario, where you happen to
> visit all possible permutations until you end up by the one wrong
> record on one of many servers.  This won't happen often. Especially
> in the case where DNS is maliciously crippled, all servers will have
> the same or at least a similar "problem".

Oh, it happens *way* more often than you would like to think. It's why  
we re-wrote the CheckMX package to do the full-tree traversal in the  
first place.

Yes, we bail "as soon as we find an error", so we don't keep  
needlessly/mindlessly reading the entire decision tree if we find one  
that's bad. But we do need to know a "starting point" of "who should  
we be asking questions of", and that's what's fundamentally in  
question...

> I think I understand what you say about libresolv.  I also think
> you are right in saying that this is their bug to fix. Nevertheless,
> if DNS points to a server saying "ask this one", and if that server
> does answer, and if that server returns "*.mx.*.", then it's a
> listable offence IMHO.  You walked the tree, and you got the wrong
> answer you were looking for.

But how do I know that person was *actually* in the NS set? If they're  
not actually in the NS set, then they're answering authoritatively  
"out of turn" as it were.

> In the case at hand, the server does not provide NS or SOA records.
> However, it does claim there aren't any servers because it does
> return, authoritatively, an empty set of NSes.  This will also
> reduce the workload.  There's no need to try the other NS, as
> the first one, to which is authority _*is*_ delegated, tells you
> that you don't need to continue.

It tells me specifically "nobody can give you a good answer". There's  
nobody to ask questions about MXes to.

> Remember: you don't need to prove that there are servers out there
> which do it right, all you need to prove is that there is one server
> doing wrong.

Right, and to start doing that, I need to find a list of all the  
servers. And that's the crux of the problem.

To recap:

- Near as I can tell, the checker is behaving properly. That "bogus"  
MX record is more a factor of DNS bogosity than anything else. Nobody  
should be listening to it, because it's coming from a host that's not  
in the NS set. Just as nobody should be listening to my servers if I  
tell them where "www.yahoo.com" is located, even if I do so  
authoritatively, because I'm not in the NS set.  That the "bogus" MX  
gets seen and accepted as "truth" by a resolver library is a bug in  
your (and my, admittedly) UNIX's libresolv, and is for the vendor to  
fix. Good luck with that, I can't picture them accepting the  
performance decrease just for really really edge cases like that.

- Even if I were inclined to think the checker is broken in some  
fashion, the methodology that would need to be implemented to do what  
you're describing would make the code heinously more complex than it  
is now. Again, you're welcome to hack the heck out of it if you want  
to give it a shot. Let me know, and I'll send you a copy of the  
existing perl code. :-)

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/7d6d5cee/attachment.bin