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

> AH> Yes, we could add a "conditional forwarder" for that domain,
> AH> and still use the root hints. *I would be happy to do this, but
> AH> would face questions about whether this would happen in the
> AH> future.
>
> It's my preference of local fix.
>
> AH> Could an alternative to be to switch off EDNS0 support in
> AH> the DNS server itself?
>
> That's another local fix, but one that I view as less preferable, for
> the simple reason that large DNS/UDP datagram support *is* beneficial,
> in my experience. So I'm, personally, reluctant to disable it.
>
> But, as I said before, a service fix is better than any local fix,
> here. Really, Microsoft's DNS server should cope better with content
> DNS servers like Lloyds TSB's content DNS servers. Doing so *does*
> trade off some small measure of security for interoperability.
> There's no argument about that. But when it comes to the security of
> the DNS protocol as a whole, it's somewhat of a drop in the ocean.
> The DNS protocol is massively insecure, and badly designed. *This*
> particular insecurity simply permits blind attackers to easily forge
> negative, "format error", responses. Blind attackers are more
> interested in forging *positive* responses. So this insecurity is on
> the level of handing so-called "script kiddies" a mechanism for
> preventing a victim from finding "whitehouse.gov." and its subdomains,
> rather than on the level of actually being able to impersonate the
> U.S. government, as other flaws in the DNS protocol do.
>
> The service fix would address the issue that you touch upon. Lloyds
> TSB is not the only organization with poor content DNS servers. (It's
> more embarrassing for Lloyds TSB than you paint it to be, Ace, by the
> way. RFC 2671 is dated August 1999. So it's over 10 years that
> Lloyds TSB has had to get its content DNS servers capable of at least
> *parsing* EDNS0 queries, even if they simply ignore the extensions.)
> But the positive side is that it's one of a *few* such organizations
> that has poor content DNS service. If they were many, the trouble
> that you experience would be more widely reported over the past
> decade.
>
> 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.

Jonathan,

I would welcome seeing such a list. It would provide Internet community
awareness. Also, I didn't look it up, but thank you for the RFC EDNS0
note. I thought it was longer than 8 years. :-)

Ace

"J de Boyne Pollard" <> wrote in message
news:f8c7c2eb-b91b-4b20-9cb6-...
> AF> I would welcome seeing such a list.
>
> I'll give it some further consideration. For what it's worth, I had
> this particular issue with content DNS servers that respond in this
> particular way to EDNS0 documented some five years ago, in another,
> related but not quite the same, Hall of Shame.
>
> <URL:http://homepage.ntlworld.com./jonath...llard/FGA/dns-
> superdomain-owner-hall-of-shame.html#Irony>
>
> The situation isn't quite as bad now as it was when I wrote that.
> Witness the aforegiven log excerpt. The "uk." content DNS server at
> 199.7.66.44 responded quite happily to an EDNS0 query, without the
> need for any fallback.


I guess as time has passed, many DNS owners have upgraded to support EDNS0
functionality, albeit the few that are left out there that haven't such as
Lloyd's.

If you put the list together, I will definitely reference it in future,
related posts.

Thank you,
Ace