expedia.msn.com does not resolve

[Brad Knowles]

At 12:48 AM +0000 8/16/01, Barry Margolin wrote:

>  I don't think you're supposed to set the truncated flag if the overflow is
>  due to records in the Additional Records section.

	That is not my understanding, nor is that the way that BIND has 
ever worked (to the best of my knowledge).  The key is whether or not 
the truncation occurs in the "Additional" section or the "Authority" 
section.  If the former, then it is the *option* of the resolver to 
simply accept what it got and to go on, but in the case of the 
latter, the resolver is *required* to re-query with TCP.

>                                                     And since all the
>  servers are in the msft.net domain, DNS's compression mechanism allows
>  most answers to fit in a UDP packet.

	Only if you do a type "NS" query.  If you do a type "ANY" query, 
you'll get truncation.

>  It also looks like the msft.net servers don't fill in the Authority section
>  of their responses, which keeps these responses from being truncated.  I
>  suspect that the OP's problem is that his internal nameserver is configured
>  to forward to a BIND nameserver outside the firewall.  That nameserver
>  fills in the Authority section, which causes overflow and truncation, and
>  then the firewall blocks the TCP retry.

	I was getting truncation when I queried them directly for type 
"ANY" queries for the microsoft.com zone.  I'm sure that they have 
similar problems with other queries.

-- 
Brad Knowles, <brad.knowles at skynet.be>

H4sICIFgXzsCA2RtYS1zaWcAPVHLbsMwDDvXX0H0kkvbfxiwVw8FCmzAzqqj1F4dy7CdBfn7
Kc6wmyGRFEnvvxiWQoCvqI7RSWTcfGXQNqCUAnfIU+AT8OZ/GCNjRVlH0bKpguJkxiITZqes
MxwpSucyDJzXxQEUe/ihgXqJXUXwD9ajB6NHonLmNrUSK9nacHQnH097szO74xFXqtlbT3il
wMsBz5cnfCR5cEmci0Rj9u/jqBbPeES1I4PeFBXPUIT1XDSOuutFXylzrQvGyboWstCoQZyP
dxX4dLx0eauFe1x9puhoi0Ao1omEJo+BZ6XLVNaVpWiKekxN0VK2VMpmAy+Bk7ZV4SO+p1L/
uErNRS/qH2iFU+iNOtbcmVt9N16lfF7tLv9FXNj8AiyNcOi1AQAA