bind 9.7.2-P3 does not resolve www.microsoft.com

[Michael Sinatra]

On 12/28/10 00:26, Eivind Olsen wrote:

> So, to recap: at the risk of showing what a fool I am by doing something
> completely wrong here, I'm betting Microsoft has messed up their DNS - I
> would have expected queries over TCP to work, and I would not have
> expected EDNS to give a FORMERR (but ok, if a nameserver doesn't implement
> EDNS, giving a FORMERR is apparantly the right thing to do).

Yes, see section 5.3 of RFC 2671, which defines EDNS.  FORMERR is one of 
the expected responses for a server that doesn't support EDNS.

'dig any microsoft.com' likely results in an answer that exceeds 512 
bytes.  In such a situation, if either the server or the client do not 
support EDNS0, they must fall back to TCP.  Microsoft either has 
(incorrectly) not implemented TCP on their nameservers, or is 
(incorrectly) blocking it at some intermediate firewall.

Name servers are NOT allowed to NOT implement TCP.  This is a good 
counter-example to those folks who periodically post to this list asking 
why they shouldn't be blocking TCP/53 at some firewall in front of their 
nameserver.  As we can see, TCP can be necessary to properly resolve 
domain names.

In other words, you are correct (and you do not appear to be doing 
something wrong): Microsoft has messed up their DNS.  Moreover, the 
problem is not limited to resolvers running BIND.  I can replicate the 
issue on a server running unbound 1.4.6.  'dig any microsoft.com' will 
easily replicate the error.

The question remains as to why simply trying to resolve microsoft.com 
(i.e. the A record) caused truncation and fallback to TCP.  In all cases 
I have tried, this record resolves.  For the original poster, it's a 
good idea to double-check that YOUR server is capable of receiving 
answers longer that 512 bytes.  Later versions of BIND will set the DO 
bit on queries and this will result in longer answers (e.g. in order to 
resolve the ns[12345].msft.net servers so that they can be queried). 
'dig any berkeley.edu' is one way to test this out...:)

michael