J
Jonathan de Boyne Pollard
TL> Looks like a normal cache-poisoning attack. Windows 2K DNS
TL> uses predictable query IDs [...]
Cache poisoning is not necessarily the result of an attack, nor is it
necessarily (or indeed often, as far as reports in this forum go) the result
of response forgery. In this particular case, the evidence (of two simple
tests) strongly indicates that it is not an attack and that response forgery
was not involved at all.
SD> If I check ARIN, they tell me that address is owned by
SD> Vicajo Consultants
TL> The attacker had their site pulled by Onefusion.com, so
TL> it's probably a wide-scale thing, not just you.
As I said, the evidence is that there was - and is - no attacker. I suspect
that all that there actually was, was a delegation without prior agreement
(the all-too-frequent error of someone thinking that they can just delegate
their domain's content DNS service to their ISP's content DNS servers without
actually asking their ISP beforehand) since that is all that is actually
needed to poison the caches of insecure resolving proxy DNS servers in exactly
the way that was described.
TL> It's ultimately a flaw in the design of DNS, but Microsoft
TL> made it worse by making their query IDs too predictable.
Actually, the relevant error that Microsoft made was having security against
cache pollution turned off by default. It took roughly two years of pointing
it out, but this error has now (as of 2003-03-02) been fixed. Now all that
remains is to persuade all of the existing users of Microsoft's DNS server to
either (a) upgrade to the relevant versions of the software or (b) manually
turn the security on. (-:
TL> uses predictable query IDs [...]
Cache poisoning is not necessarily the result of an attack, nor is it
necessarily (or indeed often, as far as reports in this forum go) the result
of response forgery. In this particular case, the evidence (of two simple
tests) strongly indicates that it is not an attack and that response forgery
was not involved at all.
SD> If I check ARIN, they tell me that address is owned by
SD> Vicajo Consultants
TL> The attacker had their site pulled by Onefusion.com, so
TL> it's probably a wide-scale thing, not just you.
As I said, the evidence is that there was - and is - no attacker. I suspect
that all that there actually was, was a delegation without prior agreement
(the all-too-frequent error of someone thinking that they can just delegate
their domain's content DNS service to their ISP's content DNS servers without
actually asking their ISP beforehand) since that is all that is actually
needed to poison the caches of insecure resolving proxy DNS servers in exactly
the way that was described.
TL> It's ultimately a flaw in the design of DNS, but Microsoft
TL> made it worse by making their query IDs too predictable.
Actually, the relevant error that Microsoft made was having security against
cache pollution turned off by default. It took roughly two years of pointing
it out, but this error has now (as of 2003-03-02) been fixed. Now all that
remains is to persuade all of the existing users of Microsoft's DNS server to
either (a) upgrade to the relevant versions of the software or (b) manually
turn the security on. (-: