Last week I noticed, that Kabel Deutschland, a cable provider in germany, returns for any non existing hosts “204.9.89.60″. It seems, thats it is rolled out since last fall. Even for DNSSEC enabled infrastructure it breaks it totally:
; <<>> DiG 9.3.4 <<>> +dnssec web.pixaco.se @83.169.184.161
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
web.pixaco.se. 0 IN A 204.9.89.60
Beside that, this behavour breaks the whole DNS, since many mechanism rely on a negative answer. The most visible effect for the users is, that when having a typo on surfing, he will forwarded to http://suche.kabeldeutschland.de/de.kde.assist/?domain=<domainyoutypedinyourprompt>. Since 204.9.88.0/21 is located at our transatlantic friends from US, there might be some problem with leaking privacy informations. I don’t feel happy, if I had a typo in my URL and getting listed for it on any terror list or providing the newest porno links to my american friends inside the organisations with the tree capitals.
All that for getting some extra money, but racing pricedumping for connectivity, this sucks a lot.
If you are a customer and feel pissed, you can send a friendly note to them:
Kabel Deutschland Vertrieb und Service GmbH & Co. KG
Beschwerdestelle
99116 Erfurt
kundenservice@kabeldeutschland.de
Fax: 01805299925
A quick and dirty workaround for dnsmasq maybe to add “bogus-nxdomain=204.9.89.60″ to your config file. This doesn’t fix the DNSSEC problem.
The problem also pops up at dns-operations and there are traces at google too.
After shutdown of the old L.ROOT-SERVERS.NET the IP address formerly associated with it, the IP continued to answere requests. More informations can be found at the ICANN Blog
UPDATE: Before bothering around, if you read the ICANN Blog, you realize that the issue was fixed very shortly. The whole problem is, that the file of the root DNS servers have to be keeped up to date. This issue should be fixed by operator of resolving nameservers (usually your ISP). A goody will be, to have this fixed by the next point release of debian, but it is NOT security critical.
Thanks Thijs for make me sensible that my article may misslead people who are not reading the referenced document.
UPDATE 2: A more technical description can also be found at Renesys Blog and a disussion how it is related to debian.
Today I was reconfiguring a Cisco 7513 with a RSP 16 and a FastEthernet module inside.
So I did a “erase nvram” and a “reload”. After booting I was surprised to see the following in my Terminal:
Would you like to enter the initial configuration dialog? [yes/no]:
Loading pxelinux.0 from 10.42.10.50 (via FastEthernet4/0/0): !!!
[OK - 13156 bytes]
So the box took an IP via DHCP and tried to netboot. (Un)fortunately it only breaks my terminal, so no worries! ;)
Today the RIPE DNS for LIRs Training Course did take place. (some not up to date course material can be found here)
Managing some thousands of zones inclusive nameserver infrastructure behind since several years, I thought it would be neat to provide a secure dns chain to our costumers.
After going deeper into the material within the course, I recognized the following impacts:
- only bind9 (>= 9.3) and NSD privides support (yet)
- bandwidth will be increased 2-3 times with max. key size
- increased memory usage depending on your server software
- operational costs will increasing dramaticaly due significant higher amount of regular work
- more computing power (hardware) needed to generate dnssec ready zones and signing
- unknown influence on resolving nameservers (load/memory/bandwidth)
- chain of trust ends at resolving nameserver and is not provided to enduser
Since the last issue isn’t solved (yet), it doesn’t make any sence for me to invest resources into setting up DNSSec infrastructur, cause the end user would not recognize if the communication with the resolving nameserver or the resolving nameserver itself is taken over.
Any complaints and/or hint? Did I missed something?
