[dns-operations] CERT VU#800113 Multiple DNS implementations vulnerable to cache poisoning
Peter Dambier
peter at peter-dambier.de
Fri Jul 11 19:50:22 UTC 2008
For Bind and djbdns (tinydns/axfrdns) no change is needed. DNS over tcp is
enabled by default, but the fools programming the firewall dont read
the RFCs who say port 53 udp and tcp.
I have seen when testing dnssec Findland first dropped their IPv6
records because the packets got to big for udp and many clients
switched to tcp because edns did not work for them. Next they dropped
dnssec too.
Just for curiousity (IPv6 is back in):
; <<>> DiG 9.4.0 <<>> -t any fi @77.72.229.253
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53569
;; flags: qr aa rd; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 8
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;fi. IN ANY
;; ANSWER SECTION:
fi. 86400 IN SOA a.fi. fi-domain-tech.ficora.fi. 2008071145 3600 1800 2419200 86400
fi. 86400 IN NS d.fi.
fi. 86400 IN NS e.fi.
fi. 86400 IN NS a.fi.
fi. 86400 IN NS b.fi.
fi. 86400 IN NS c.fi.
fi. 86400 IN TXT "https://domain.ficora.fi/"
fi. 86400 IN TXT "whois.ficora.fi"
;; ADDITIONAL SECTION:
a.fi. 86400 IN A 193.166.4.1
a.fi. 86400 IN AAAA 2001:708:10:53::53
b.fi. 86400 IN A 194.146.106.26
c.fi. 86400 IN A 128.214.4.29
d.fi. 86400 IN A 77.72.229.253
d.fi. 86400 IN AAAA 2a01:3f0:0:302::53
e.fi. 86400 IN A 194.0.1.14
e.fi. 86400 IN AAAA 2001:678:4::e
;; Query time: 83 msec
;; SERVER: 77.72.229.253#53(77.72.229.253)
;; WHEN: Fri Jul 11 21:38:41 2008
;; MSG SIZE rcvd: 388
That is only 388 bytes, short enough to add dnssec data.
But a bleeding resolver might return
; <<>> DiG 9.4.0 <<>> -t any fi
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19854
;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 5, ADDITIONAL: 8
;; QUESTION SECTION:
;fi. IN ANY
;; ANSWER SECTION:
fi. 86400 IN TXT "whois.ficora.fi"
fi. 86400 IN TXT "https://domain.ficora.fi/"
fi. 86400 IN NS e.fi.
fi. 86400 IN NS a.fi.
fi. 86400 IN NS d.fi.
fi. 86400 IN NS b.fi.
fi. 86400 IN NS c.fi.
fi. 86400 IN SOA a.fi. fi-domain-tech.ficora.fi. 2008071145 3600 1800 2419200 86400
;; AUTHORITY SECTION:
fi. 86400 IN NS d.fi.
fi. 86400 IN NS b.fi.
fi. 86400 IN NS e.fi.
fi. 86400 IN NS c.fi.
fi. 86400 IN NS a.fi.
;; ADDITIONAL SECTION:
c.fi. 86400 IN A 128.214.4.29
d.fi. 86400 IN A 77.72.229.253
d.fi. 86400 IN AAAA 2a01:3f0:0:302::53
e.fi. 86400 IN A 194.0.1.14
e.fi. 86400 IN AAAA 2001:678:4::e
a.fi. 86400 IN A 193.166.4.1
a.fi. 86400 IN AAAA 2001:708:10:53::53
b.fi. 86400 IN A 194.146.106.26
;; Query time: 101 msec
;; SERVER: 7.19.30.36#53(7.19.30.36)
;; WHEN: Fri Jul 11 21:37:54 2008
;; MSG SIZE rcvd: 458
Now it is 458 because of the added authority section. add dnssec and your
clients will get the error "packet truncated - pleasy retry with tcp".
Kind regards
Peter
Paul Vixie wrote:
>>> any form of always-use-tcp is undeployable for reasons of both scale
>>> and reach. there would be too much state and through-delay in such a
>>> system, and, there are too many unreachable name servers seen by
>>> tcp/53.
>> I'm not sure if this is actually true. However, I'm convinced that
>> switching to TCP would require significant software changes on the
>> authoritative server side. And once such changes are needed on both
>> recursors and authoriative servers, a protocol change and a UDP-based
>> solution is preferable (and DNSSEC is that's already out there, at least
>> to some extent).
>>
>> IOW, I agree with your conclusion, but for different reasons.
>
> when you say "switching to TCP would require significant software changes
> on the authoritative server side" you're restating my "reasons of scale"
> constraint. similarly with "a UDP-based solution is preferrable". also,
> in the part of what i wrote that you didn't quote, are the words
> "... Secure DNS, ... still the right solution to the general class of
> problem being noted here" which is equivilent to your "DNSSEC is ...
> already out there ..." statement. so, i think that we have non-differing
> reasons.
>
> but let me add that DNSSEC also protects against non-spoofing non-poisoning
> attacks, including corrupted authority servers, man in the middle, ARP and
> ICMP level attacks. Secure DNS is strong enough to compete against X.509
> for PKI and e-commerce data exchanges, whereas "forgery resilience" is not.
>
> so we could consider a 100% installed base overhaul to add extended QID, or
> we could consider a 100% installed base overhaul to add Secure DNS. and in
> the second case, nobody has to either answer every query via TCP or answer
> every query twice during the long years of the complete installed base
> overhaul.
>
> there just is no responsible way forward using extended QID.
>
--
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: peter at peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
More information about the dns-operations
mailing list