[dns-operations] Concerns regarding the ICANN/IANA DNS vulnerability checker

[Florian Weimer]

* Simon Waters:

>> The problem is that it's flat out wrong.  Admittedly, 129.69.1.28 runs
>> an open resolver for historical reasons.  But this has no direct
>> effect on the CERT.UNI-STUTTGART.DE zone because all glue is
>> authoritatively known to 129.69.1.28, so there is no cache pollution
>> issue.
>
> Except the glue for badguy645654.cert.uni-stuttgart.de which it
> doesn't know yet. I don't know if it can be persuaded to cache it.

129.69.1.28 is authoritative for CERT.UNI-STUTTGART.DE, so there is no
upstream response to spoof.

> Are you sure it can't be persuaded to cache bad data for zones
> underneath CERT.UNI-STUTTGART.DE?

No, I'm not completely sure.  But if this were possible, BIND would
suffer from a catastrophic bug.  So it's "potentially vulnerable", but
not "vulnerable"--and almost anything useful is "potentially
vulnerable".

> The statement is true, the authoritative servers for that domain are
> vulnerable to cache poisoning. They didn't state that the poisoning
> would affect the zone they are authoritative for.

If it's about servers, why do I have to enter a zone name?

This also means that I can probe random strangers, which makes this
test so very different from the rest.

>> The whole test is bogus anyway because publicly available recursive
>> service is neither necessary nor sufficient for the presence of cache
>> poisoning potential. 
>
> I believe it is a necessary condition of poisoning an authoritative
> server.

You need to get the data into the server somehow, true.  Publicly
available recursive service is just one option.  Others are restricted
recursive service or customer zone edits.  Restricted recursive
service is fairly common, I would say, and there is no general
consensus that it's a terribly bad thing.

I already pointed fingers into one particular direction (and I
shouldn't have done that, sorry), but with a bit digging around
ccTLDs, you should be able to find several other examples.

> Either way the university is at best negligent in the running of its
> DNS operations.

*shrug* It's like OpenDNS, but without the ads.

> False positive - perhaps if your only threat model for DNS is Dan
> Kaminsky powered script kiddie might make them look daft.

Maybe.  But if it's a real problem, why doesn't ICANN make sure that
at least the gTLDs under its influence are protected before going
public?

On the other hand, if it's not that important, it's rather
questionable to associate it with the other DNS issues we're dealing
with right now.

-- 
Florian Weimer                <fweimer at bfk.de>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99