Re: Event 5504 when using root hints on Server 2008 R2

> DNAME records aren't the issue. That's a complete red herring. So,
> also, is what characters are in the domain name. Ironically, the
> information for diagnosing the issue was in plain sight, in the event
> log message itself. Well done, therefore, for following the standard
> problem reporting litany and giving the error messages that you see.
> Here's the important part:
>
> AH> Data:
> AH> 0000: cb a6 80 11 00 00 00 00 Â* ˦€.....
> AH> 0008: 00 00 00 00 Â* Â* Â* Â* Â* Â* Â* ....
>
> What's happening here is a combination of the fact that Lloyds TSB
> uses content DNS servers that are not EDNS0 capable, and the fact that
> you are using resolving proxy DNS servers that are EDNS0 capable. A
> quick query to 193.34.230.74 reveals that if it receives an EDNS0
> query it responds with a "format error" response, which is what the
> above DNS/UDP datagram actually decodes to. So, first of all, if
> Lloyds TSB were using better content DNS servers you wouldn't be
> experiencing this problem. Exacerbating the problem is the fact that
> Lloyds TSB's response doesn't repeat the question in the query. It is
> this that is throwing off Microsoft's DNS server. It's expecting to
> have the question that it asked echoed back to it in the response.
> But as you can see from the final four words in the aforegiven data,
> there are no resource records *at all* in the response that Lloyds
> TSB's content DNS servers are returning. The question isn't being
> echoed. So when Microsoft's DNS server comes to decode the question
> section, to check that the question returned is the same as the
> question asked, it finds no question at all, and complains.
>
> The reasons that you don't see this with other resolving proxy DNS
> servers are twofold: First, older resolving proxy DNS servers won't
> be sending EDNS0 queries, so won't be triggering this response from
> Lloyds TSB's content DNS servers. Second, some other resolving proxy
> DNS server softwares are more liberal in their handling of the DNS
> protocol than Micorosoft's DNS server is being here in this instance.
> They won't even look at the question section of a "format error"
> response. (The downside of this liberty is that such resolving proxy
> DNS servers are slightly more vulnerable to spoof responses from blind
> attackers, albeit only if the attacker wants to spoof "format error"
> responses.)
>
> AH> The users trying to access that site get a DNS server failure
> AH> response from Squid (our proxy).
>
> If you wish to have Microsoft's DNS server perform query resolution,
> you really have a choice of three courses of action, probably none of
> which you will find appealing, here:
> * You could ask Lloyds TSB to get better content DNS servers, that
> support EDNS0.
> * You could ask Microsoft to make the resolving proxy part of its DNS
> server more liberal when it comes to "format error" responses.
> * You could tell your users that they aren't missing out on much by
> not being able to use Lloyds TSB's WWW site.
>
> The alternative is to have some other resolving proxy DNS server
> software perform query resolution for that domain name and its
> subdomains. This is where forwarding proxy DNS service, for
> "lloydstsb.co.uk." and its subdomains, comes into play, as you've
> already discussed. That's a local fix. But a service fix would be
> better.

Good find, Jonathan. What query command did you use with Dig to
determine this, or did you use nslookup?

Ace

"J de Boyne Pollard" <> wrote in message
news:4810a244-11b2-43ae-ad13-...
> AF> Good find, Jonathan.
>
> Merci.
>
> AF> What query command did you use with Dig to
> AF> determine this, or did you use nslookup?
>
> Neither. I used my own tool. I just sent an "A" query for
> "www.lloydstsb.co.uk." to 193.34.230.74 with EDNS0 large datagram
> support enabled. I don't remember, off the top of my head, what the
> option for enabling that in "dig" is, but that's all that one needs to
> do. With my own tool, it's the /LARGEUDP option, which yielded the
> following:
>
> [c:\]dnsqry /serverip:193.34.230.74 /largeudp a www.lloydstsb.co.uk.
> [0.0.0.0:0000] -> [193.34.230.74:0035] 48
> Header: 0000 1+0+0+1, Q, , query, no_error
> Question: www.lloydstsb.co.uk. IN A
> Additional: . 0x7fff OPT 0
>
> [193.34.230.74:0035] -> [0.0.0.0:0000] 12
> Header: 0000 0+0+0+0, R, , query, bad_format
>
> [c:\]
>
> That's the same 12-octet response (except for message ID and some
> reserved flag bits) as is given in the reported event log data. As
> you can see, there's no question section in the response. The first
> thing that I actually did, that I then double-checked with the above
> manual query, was simply ask a non-Microsoft resolving proxy DNS
> server to look up the "A" resource record set for
> "www.lloydstsb.co.uk.", and read its log of back-end queries sent and
> responses received. Here's the relevant portion of that log (which
> Google Groups will probably mangle a bit -- every @ timestamp is a new
> line):
>
> @4b20580e 15d9 rx 7f000009 07e1 query: www.lloydstsb.co.uk. IN A
> @4b20580e ed99 tx c707422c 0035 (uk.) 1+0+0+1 48 www.lloydstsb.co.uk.
> IN A
> @4b20580e ed99 rx c707422c 0035 (uk.) 1+0+2+3 116 www.lloydstsb.co.uk.
> IN A
> @4b20580e ed99 rx c707422c 0035 cached: lloydstsb.co.uk. IN NS 172800
> ns3.lloydstsb.co.uk.
> @4b20580e ed99 rx c707422c 0035 cached: lloydstsb.co.uk. IN NS 172800
> ns2.lloydstsb.co.uk.
> @4b20580e ed99 rx c707422c 0035 cached: ns3.lloydstsb.co.uk. IN A
> 172800 193.34.230.74
> @4b20580e ed99 rx c707422c 0035 cached: ns2.lloydstsb.co.uk. IN A
> 172800 193.34.230.73
> @4b20580e ed99 tx c122e649 0035 (lloydstsb.co.uk.) 1+0+0+1 48
> www.lloydstsb.co.uk. IN A
> @4b20580f ed99 rx c122e649 0035 server indicated a bad format (1/2
> lame or failed)
> @4b20580f ed99 tx c122e649 0035 (lloydstsb.co.uk.) 1+0+0+0 37
> www.lloydstsb.co.uk. IN A
> @4b20580f ed99 rx c122e649 0035 (lloydstsb.co.uk.) 1+1+2+2 136
> www.lloydstsb.co.uk. IN A
> @4b20580f ed99 rx c122e649 0035 cached: www.lloydstsb.co.uk. IN A 900
> 141.92.130.226
> @4b20580f ed99 rx c122e649 0035 cached: lloydstsb.co.uk. IN NS 900
> ns2.lloydstsb.co.uk.
> @4b20580f ed99 rx c122e649 0035 cached: lloydstsb.co.uk. IN NS 900
> ns3.lloydstsb.co.uk.
> @4b20580f ed99 rx c122e649 0035 cached: ns2.lloydstsb.co.uk. IN A
> 86400 193.34.230.73
> @4b20580f ed99 rx c122e649 0035 cached: ns3.lloydstsb.co.uk. IN A
> 86400 193.34.230.74
> @4b20580f 15d9 tx 7f000009 07e1 1+1+0+0 53 ok: www.lloydstsb.co.uk.
> 900
>
> The "bad format" response to the initial EDNS0 query is, as you can
> see, received at 4b20580f. This is the point where Microsoft's DNS
> server fails to find an echoed question in the response and aborts,
> logging the event that you see. The non-Microsoft resolving proxy DNS
> server doesn't mind empty question sections in "format error"
> responses to EDNS0 queries, and so just proceeds to switch off EDNS0
> and re-try the query.


Thank you for the explanation. Yes, I see exactly what you mean where
Microsoft DNS drops the query request.

I am archiving this for if an when it may arise again in the future.

Thank you, once again!

Ace

"Ace Fekay [MCT]" <> wrote in message
news:...
> "J de Boyne Pollard" <> wrote in message
> news:4810a244-11b2-43ae-ad13-...
>> AF> Good find, Jonathan.
>>
>> Merci.
>>
>> AF> What query command did you use with Dig to
>> AF> determine this, or did you use nslookup?
>>
>> Neither. I used my own tool. I just sent an "A" query for
>> "www.lloydstsb.co.uk." to 193.34.230.74 with EDNS0 large datagram
>> support enabled. I don't remember, off the top of my head, what the
>> option for enabling that in "dig" is, but that's all that one needs to
>> do. With my own tool, it's the /LARGEUDP option, which yielded the
>> following:
>>
>> [c:\]dnsqry /serverip:193.34.230.74 /largeudp a www.lloydstsb.co.uk.
>> [0.0.0.0:0000] -> [193.34.230.74:0035] 48
>> Header: 0000 1+0+0+1, Q, , query, no_error
>> Question: www.lloydstsb.co.uk. IN A
>> Additional: . 0x7fff OPT 0
>>
>> [193.34.230.74:0035] -> [0.0.0.0:0000] 12
>> Header: 0000 0+0+0+0, R, , query, bad_format
>>
>> [c:\]
>>
>> That's the same 12-octet response (except for message ID and some
>> reserved flag bits) as is given in the reported event log data. As
>> you can see, there's no question section in the response. The first
>> thing that I actually did, that I then double-checked with the above
>> manual query, was simply ask a non-Microsoft resolving proxy DNS
>> server to look up the "A" resource record set for
>> "www.lloydstsb.co.uk.", and read its log of back-end queries sent and
>> responses received. Here's the relevant portion of that log (which
>> Google Groups will probably mangle a bit -- every @ timestamp is a new
>> line):
>>
>> @4b20580e 15d9 rx 7f000009 07e1 query: www.lloydstsb.co.uk. IN A
>> @4b20580e ed99 tx c707422c 0035 (uk.) 1+0+0+1 48 www.lloydstsb.co.uk.
>> IN A
>> @4b20580e ed99 rx c707422c 0035 (uk.) 1+0+2+3 116 www.lloydstsb.co.uk.
>> IN A
>> @4b20580e ed99 rx c707422c 0035 cached: lloydstsb.co.uk. IN NS 172800
>> ns3.lloydstsb.co.uk.
>> @4b20580e ed99 rx c707422c 0035 cached: lloydstsb.co.uk. IN NS 172800
>> ns2.lloydstsb.co.uk.
>> @4b20580e ed99 rx c707422c 0035 cached: ns3.lloydstsb.co.uk. IN A
>> 172800 193.34.230.74
>> @4b20580e ed99 rx c707422c 0035 cached: ns2.lloydstsb.co.uk. IN A
>> 172800 193.34.230.73
>> @4b20580e ed99 tx c122e649 0035 (lloydstsb.co.uk.) 1+0+0+1 48
>> www.lloydstsb.co.uk. IN A
>> @4b20580f ed99 rx c122e649 0035 server indicated a bad format (1/2
>> lame or failed)
>> @4b20580f ed99 tx c122e649 0035 (lloydstsb.co.uk.) 1+0+0+0 37
>> www.lloydstsb.co.uk. IN A
>> @4b20580f ed99 rx c122e649 0035 (lloydstsb.co.uk.) 1+1+2+2 136
>> www.lloydstsb.co.uk. IN A
>> @4b20580f ed99 rx c122e649 0035 cached: www.lloydstsb.co.uk. IN A 900
>> 141.92.130.226
>> @4b20580f ed99 rx c122e649 0035 cached: lloydstsb.co.uk. IN NS 900
>> ns2.lloydstsb.co.uk.
>> @4b20580f ed99 rx c122e649 0035 cached: lloydstsb.co.uk. IN NS 900
>> ns3.lloydstsb.co.uk.
>> @4b20580f ed99 rx c122e649 0035 cached: ns2.lloydstsb.co.uk. IN A
>> 86400 193.34.230.73
>> @4b20580f ed99 rx c122e649 0035 cached: ns3.lloydstsb.co.uk. IN A
>> 86400 193.34.230.74
>> @4b20580f 15d9 tx 7f000009 07e1 1+1+0+0 53 ok: www.lloydstsb.co.uk.
>> 900
>>
>> The "bad format" response to the initial EDNS0 query is, as you can
>> see, received at 4b20580f. This is the point where Microsoft's DNS
>> server fails to find an echoed question in the response and aborts,
>> logging the event that you see. The non-Microsoft resolving proxy DNS
>> server doesn't mind empty question sections in "format error"
>> responses to EDNS0 queries, and so just proceeds to switch off EDNS0
>> and re-try the query.
>
>
> Thank you for the explanation. Yes, I see exactly what you mean where
> Microsoft DNS drops the query request.
>
> I am archiving this for if an when it may arise again in the future.
>
> Thank you, once again!
>
> Ace
>


Oh, just to add, when trying to determine if a server responds with EDNS0 or
not, I usually use nslookup with the "set vc" switch. I was curious how you
determined that, and it was interesting. Once again, I thank you.

Ace