[dns-operations] Concerns regarding the ICANN/IANA DNS vulnerability checker
Florian Weimer
fweimer at bfk.de
Fri Aug 8 08:52:38 UTC 2008
Here's an excerpt of <http://recursive.iana.org/?query=cert.uni-stuttgart.de>:
| Assessment of CERT.UNI-STUTTGART.DE
|
| Vulnerable.
|
| The authoritative name servers for “CERT.UNI-STUTTGART.DE” are vulnerable to
| cache poisoning. However, those providing recursive name servers have
| unpredictable source ports so the risk is lowered, but not eliminated.
|
| Name server IP Address Result
| ARTEMIS.RUS.UNI-STUTTGART.DE 129.69.1.28 Is recursive, with source port
| randomisation
| DNS.CERT.UNI-STUTTGART.DE 141.58.89.50 Not recursive
| DNS1.BELWUE.DE 129.143.2.10 Not recursive
| DNS3.BELWUE.DE 131.246.119.18 Not recursive
| SKYLLA.RUS.UNI-STUTTGART.DE 141.58.231.9 Not recursive
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.
The whole test is bogus anyway because publicly available recursive
service is neither necessary nor sufficient for the presence of cache
poisoning potential. For instance, it reports FR as "safe", even
though A.NIC.FR apparently serves the glue for A.NIC.FR from cache.
(Note that I don't want to pick on AFNIC here; this is very common
among zone operators.) The example only shows that the ICANN testing
methodology is deeply flawed: There are both false positives and false
negatives.
Apart from that, it saddens me that ICANN joins the popular game of
pushing random agendas using mostly unrelated security
vulnerabilities. The apparent lack of understanding of DNS protocol
issues worries me, too.
--
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
More information about the dns-operations
mailing list