The "fixes" for Verisign's behaviour are potentially far worse than the problem.

t> a patch for BIND was available in 1 day. Let's compare
t> how long it takes for a solution from MS.

Before you get too smug, notice that the first patch for ISC's BIND (the one
that you are referring to) handed Verisign a massive denial-of-service weapon
that Verisign can direct at any domain name in the entire namespace, should it
choose to wield it; and that the second "delegation-only" patch _also_ hands
Verisign a denial-of-service weapon, albeit a subtler one (but, on the other
hand, also one that Verisign can wield _specifically_ against those who are
trying to disregard its wildcards using "delegation-only").

Yes, these things appeared quickly. They are also wrong.

I hope that Microsoft is sitting back, watching, and learning from these
mistakes that other DNS server software writers are making. Although - alas!
- I suspect that right now someone somewhere in Microsoft is working on
copying these same flawed schemes into Microsoft's DNS server. However, if
Microsoft _is_ watching and learning, the thing that it will be learning is
that the problem that Verisign has caused is an administrative problem with a
talking-to-human-beings fix, and _not_ a problem that can be fixed by
modifying DNS server softwares.

Right now, probably the best thing for Microsoft to be doing is to be talking
to Verisign and to the root server organisations, threatening to ship a
different set of root hints with its DNS server if Verisign doesn't revert to
toeing the line, sharpish.

Jonathan de Boyne Pollard wrote in
news:3F690976.DF347522@Tesco.NET:

> the second "delegation-only" patch _also_ hands
> Verisign a denial-of-service weapon, albeit a subtler one (but, on the
> other hand, also one that Verisign can wield _specifically_ against
> those who are trying to disregard its wildcards using
> "delegation-only").

Please elaborate. What's the danger here?

One solution I saw proposed (I think on the SpamAssassin list) was to query
a zone's wildcard record explicitly and return NXDOMAIN for any other query
that returned the same value. What goes wrong if you do that?

(I love hearing about the subtle things that bite one when going for the
obvious solutions.)

JdeBP> [...] the second "delegation-only" patch _also_ hands Verisign
JdeBP> a denial-of-service weapon, albeit a subtler one (but, on the
JdeBP> other hand, also one that Verisign can wield _specifically_
JdeBP> against those who are trying to disregard its wildcards
JdeBP> using "delegation-only").

KP> Please elaborate. What's the danger here?

An explanation was in my post on the subject to "comp.protocols.dns.bind".
I've also updated the web page with both a longer explanation of the
denial-of-service mechanism and a way that Verisign can in fact entirely
defeat the "delegation-only" mechanism, should it choose to.

http://homepages.tesco.net./~J.deBoy...tml#Resistance

KP> One solution I saw proposed (I think on the SpamAssassin list) was to
KP> query a zone's wildcard record explicitly and return NXDOMAIN for any
KP> other query that returned the same value. What goes wrong if you do
KP> that?

This has come up several times in several fora. Its flaws are also
now explained in detail on the web page. Verisign's Judo defence
against it is quite simple, and completely defeats the mechanism.

The "fixes" for Verisign's behaviour are potentially far worse than the problem. - TCP-IP

Thread: The "fixes" for Verisign's behaviour are potentially far worse than the problem.

LinkBack

Tools

The "fixes" for Verisign's behaviour are potentially far worse than the problem.

Re: The "fixes" for Verisign's behaviour are potentially far worse than the problem.

Re: The "fixes" for Verisign's behaviour are potentially far worse than the problem.