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

"Andrew Hodgson" <> wrote in message
news:db86cda2-3300-4c7e-809d-...
> Hi all,
>
> Since we moved our domain controllers onto Windows Server 2008 R2 last
> week I tried to use the DNS servers to resolve external names using
> root hints instead of relying on an old Linux server to do this.
>
> The first problem I ran into was EDNS0 blocking on the firewall, which
> I got resolved by speaking nicely to the firewall team, and asking
> them to allow DNS packets larger than 512 bytes (they currently set
> this to 1280 bytes, as per the default settings in the MS DNS server).
>
> All seems to work well, but we then had issues resolving a specific
> DNS name - www.lloydstsb.co.uk. This resolves fine when resolving
> through the Linux DNS forwarder, but when doing this using the root
> hints, we get the following in the event log:
>
> Event Type: Information
> Event Source: DNS
> Event Category: None
> Event ID: 5504
> Date: 09/12/2009
> Time: 13:29:07
> User: N/A
> Computer: [...]
> Description:
> The DNS server encountered an invalid domain name in a packet from
> 193.34.230.74. The packet will be rejected. The event data contains
> the DNS packet.
>
> For more information, see Help and Support Center at
> http://go.microsoft.com/fwlink/events.asp.
> Data:
> 0000: cb a6 80 11 00 00 00 00 ˦€.....
> 0008: 00 00 00 00 ....
>
> The users trying to access that site get a DNS server failure response
> from Squid (our proxy).
>
> I did a dig +trace on the Linux machine and found out that the server
> that was causing the problem was at ns3.lloydstsb.co.uk, and I also
> got events fired for ns2.lloydstsb.co.uk. However, all the DNS
> responses were under the 512 bytes.
>
> Anyone seen this before? Is the Windows Server DNS service no good
> for this type of usage? (the Server 2008 standard one had issues as
> well!)
>
> Thanks.
> Andrew.

This may be relevant to the discussion. If an EDNS query fails R2 doesn't
fall back to DNS. I believe BIND does.

http://weblogs.asp.net/owscott/archi...ns-issues.aspx

Hopefully at some point an update will fix this.

--
Kerry Brown
MS-MVP - Windows Desktop Experience: Systems Administration
http://www.vistahelp.ca/phpBB2/

"Andrew Hodgson" <> wrote in message
news: ews.com...
> On Fri, 11 Dec 2009 06:36:24 -0800, "Kerry Brown"
> <*a*m> wrote:
>
>>This may be relevant to the discussion. If an EDNS query fails R2 doesn't
>>fall back to DNS. I believe BIND does.
>
> Yes, enabling all the logging on our Bind box shows that we are
> falling back to using non EDNS0 requests for that domain. I can see
> the format error response when I do the lookup. The local fix I did
> was to use forwarders on the DNS servers, until MS can fix this issue,
> as it doesn't involve modifying the defaults, so we can just implement
> it without too much documentation .
>>
>>http://weblogs.asp.net/owscott/archi...ns-issues.aspx
>>
>>Hopefully at some point an update will fix this.
>
> Well, in 2008 we had this issue:
>
> http://support.microsoft.com/kb/968372
>
> That held us from using root hints as well. They never fixed that;
> not even with Service Pack 2. Although, it does seem to fall back
> from using EDNS0 when resolving www.lloydstsb.co.uk, unlike its R2
> counterpart.
>
> Windows Server 2003 R2 was the most reliable DNS server I used with
> root hints, it did use EDNS0, but seemed to fall back ok, and was not
> affected by the 2008 issue.
>
> Thanks.
> Andrew.


I haven't seen this issue yet, with 2008. I am aware of the MaxCacheTTL.
Adding the entry and a value (articles suggests 2 days), keeps items in the
cache for the time you set and ignores the TTL on the record. Normally DNS
deletes the items in cache when TTL expires. However, I don't see forcing
this entry to help resolve some TLDs, unless there's something else this
key does with EDNS0 that's not stated in the following article.

MaxCacheTtl
http://technet.microsoft.com/en-us/l.../cc959926.aspx

Also funny thing - What happens if DNS can't resolve a record? Then there
will be no record to be placed in cache.

Ace

> AH> http://support.microsoft.com/kb/968372
>
> AF> I haven't seen this issue yet, with 2008. [...] I don't see
> forcing
> AF> this entry to help resolve some TLDs, *unless there's something
> AF> else this key does with EDNS0 that's not stated in the following
> AF> article.
>
> It's a bodge. It has all of the hallmarks of one. Stopping things
> from being cached for more than 2 days prevents something as a side-
> effect. It's not obvious what, though. My educated guess would be a
> problem with caching the "glue" of the affected delegation points, but
> a very quick review of "br." doesn't turn up anything that would
> obviously cause a problem.

Interesting. Problems with caching the glue may help with overriding
the TTL, but then again, that indicates it would need to be able to
resolve the glue, and perhaps if Lloyd's TTBS server won't respond to
that, then the chicken/egg theory comes into play.

>
> That's really a quite poor KB article when it comes to explaining what
> the problem being bodged around is.

I agree it is a bodge - hastily put together to address an issue
without explaining why it works or why it was suggested as a
workaround, and in this case, not necessarily a 'fix,' otherwise we
would have seen a 'dns.exe' hotfix.

>
> AF> Also funny thing - What happens if DNS can't resolve a record?
> AF> Then there will be no record to be placed in cache.
>
> Define "can't resolve". There's a different between the resolution
> algorithm having to be aborted and the receipt of a negative answer.
> The latter is most definitely cacheable.

It was more of a general statement such as if the Lloyd's A record is
not resolvable due to Lloyd's TTBS servers, e.g. not able to get a
response, then there would be no "A" record to cache, however, good
point that the negative response is cached.

> Remember: The database
> schema that content and proxy DNS servers use isn't the schema used in
> the DNS protocol. In the *true* DNS database schema, the one that DNS
> server (and indeed DNS client) software writers actually have to
> employ, resource records aren't considered individually, and empty
> resource record sets and "no such name" indicators are concrete
> things, with TTLs of their own.

Understood. As stated, I was making more of a general statement.

Ace

> AH>http://support.microsoft.com/kb/968372
>
> AF> I haven't seen this issue yet, with 2008. [...] I don't see
> forcing
> AF> this entry to help resolve some TLDs, unless there's something
> AF> else this key does with EDNS0 that's not stated in the following
> AF> article.
>
> JdeBP> [...] *It's not obvious what, though. *My educated guess
> JdeBP> would be a problem with caching the "glue" of the affected
> JdeBP> delegation points, but a very quick review of "br." doesn't
> JdeBP> turn up anything that would obviously cause a problem.
>
> AF> Interesting. Problems with caching the glue may help with
> AF> overriding the TTL, but then again, that indicates it would
> AF> need to be able to resolve the glue, and perhaps if Lloyd's
> AF> TSB's server won't respond to that, then the chicken/egg
> AF> theory comes into play.
>
> M. Hodgson said that he had the KB968372 problem last year. He didn't
> say what domain names were affected, but the article gives "br." as
> one example. It's not related to the Lloyds TSB problem, as far as I
> can see. Some further research after I wrote the above indicates that
> the cache not handling "glue" properly is indeed the KB968372
> problem. (That one Microsoft employee suggested tweaking a
> "LameDelegationTtl" property as a local fix was one clue. It's still
> not clear what the actual problem is, though.) It's not a response
> parsing issue, as the current Lloyds TSB problem is.
>
> M. Hodgson's point, I believe, was that since we haven't yet seen a
> service fix (or even a temporary fix) for the KB968372 problem,
> whatever it is, we probably won't see a service fix for *this* problem
> in the near future.

I agree that I don't think we will ever see a service fix for this
assuming that the engineers believe the problem is on the out of date
DNS servers, and should have been updated long ago. Maybe someone
should email Lloyds' to let them know.

Thanks for the info on the LameDelegationTtl explanation. It makes
sense that it's truly a glue problem.

Ace

"J de Boyne Pollard" <> wrote in message
news:ce9ac157-a192-4c77-8382-...
> AF> Thanks for the info on the LameDelegationTtl explanation.
>
> If you enjoyed that, you'll like these:
>
> <URL:http://msdn.microsoft.com/en-us/library/cc422472(PROT.10).aspx>
> <URL:http://msdn.microsoft.com/en-us/library/cc422509(PROT.10).aspx>


Interesting, thank you. I'll have to take a few moments to read them,
especially the Product Behavior link.

Ace

Here is another very well known ISP that has the same issue: Earthlink.net.
When we attempt to send mail to one of their hosted customers,
bronsoncos.com which uses Earthlink.net as it's ISP, you get the 5504 event
ID on Windows 2008 R2.

Perhaps you can add them to your list of companies that don't comply!

"Jonathan de Boyne Pollard" <J.deBoynePollard-> wrote
in message news:. localhost...
> I've been tempted, in recent months, to start a content DNS service
> "Hall of Shame", listing content DNS services that don't get the DNS
> protocol right, or that are woefully inadequate in their handling of the
> DNS protocol, to the extent of causing interoperability problems with
> widespread secure resolving proxy DNS servers that necessitate variances
> from the protocol. Lloyds TSB not including a question section in its
> responses to EDNS0 queries would be the third on such a list, after Google
> (whose content DNS servers erroneously stop halfway through constructing
> responses) and Amazon (whose content DNS servers in combination put CNAME
> resource records on a delegation point). I haven't done so, yet. But
> perhaps it would raise awareness of exactly how much bad protocol
> softwares like Microsoft's DNS server have to be coded to cope with, and
> the security tradeoffs that are forced as a result; and how flawed the DNS
> protocol itself really is.
>
>
> Here is another very well known ISP that has the same issue:
> Earthlink.net. When we attempt to send mail to one of their hosted
> customers, bronsoncos.com which uses Earthlink.net as it's ISP, you get
> the 5504 event ID on Windows 2008 R2.
>
> The resolving proxy DNS server that I used to test this before actually
> logs this problem thrice for the DNS lookups involved in sending mail.Â
> This is because of the intermediate domain names:
>
>
> [C:\]dnsqry mx bronsoncos.com.|grep /b/u Answer:
> Answer: bronsoncos.com. IN MX 86066 10 store-forward.mspring.net.
> Answer: bronsoncos.com. IN MX 86066 5 mail.bronsoncos.com.
> Looking up both of the intermediate domain names mail.bronsoncos.com. and
> store-forward.mspring.net. results in A queries to the self-same content
> DNS servers that received the MX query. All three queries will receive
> "bad format" responses with zero question section resource records.
>
>
> Perhaps you can add them to your list of companies that don't comply!
>
>
> You, too, want me to start that list, eh? (-:
>



I thought you already did?

Ace