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

This is a discussion on The "fixes" for Verisign's behaviour are potentially far worse than the problem. - TCP-IP ; 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 ...

+ Reply to Thread
Results 1 to 3 of 3

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

  1. 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.

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

    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.)

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

    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.



+ Reply to Thread