> From: Stephane Bortzmeyer <bortzme...@nic.fr> > > Why would there be extra support calls? Wrong keys are no worse > > than wrong delegations > > Of course, they are worse. In the vast majority of cases, lame > delegations (or other mistakes) do not prevent resolution (as long as > one name server works). A wrong key can completely prevent resolution, > leading to a loss of service. The DNS is extremely robust, you have to > try very hard to break it. With DNSSEC, it's the opposite, you have to > be very careful for it to work.
Let's agree to somewhat disagree about that. I've found giving one's registrar the wrong IP address or glue a lot worse than a stupid delegation in my own zone files. DNSSEC needs a more effort than plain DNS, but that almost none of extra effort has anything to with registrars. Registrars/registries must sign your DNSSEC RRs, but they must now also sign your other RRs, so that's no extra work for them. > > Why would registrars get support calls about validation problems? > > Do they get calls now (that they answer) from DNS resolver operators > > (other than big resolvers like Comcast) for lame delegations? > > See above. "I cannot visit http://www.онлайн/ while it works from > $OTHERISP so it's your fault". I don't understand that. Of course DNSSEC causes more support calls, but the calls are to ISPs and IT groups and not to the registrars trying to sabotage or delay DNSSEC for as long as possible supposedly because of DNSSEC support calls. And again, whether they do suffer more support calls *not*, let them charge extra for adding DNSSEC records! If they can profit from simple DNS for US$10/year, then they could profit with DNSSEC for US$30/year. A rational reason for the registrar DNSSEC sabotage is that the margins on the PKI certs they flog to the punters are at lot more than US$30/year (proof: free certs), and DNSSEC+DANE will eventually kill that cash cow. Yes, no doubt some registrars are too dumb to see that. ... } From: Stephane Bortzmeyer <bortzme...@nic.fr> } > This is not an attack on DNS, but an attack on IP reassembly } > technology. } } Frankly, I do not share this way of seeing things. Since the DNS is, } by far, the biggest user of UDP and since TCP is already protected by } PMTUD, I do not think we can say it's not our problem. How dos PMTUD protect TCP? When since perhaps 1995 has PMTUD been seen as protection instead of vulnerability, thanks to goobers with firewalls? Why can't similar attacks using TCP segment assembly be mounted against DNS/TCP? I've heard of more segment assembly attacks than IP fragment assembly attacks, albeit against TCP applications other than DNS. } > This might happen even due to malfunctioning network adapter or } > other network device, not necessarily an "attack". } } A random modification by a malfunctioning device or an errant cosmic } ray has a very small probability of being accepted (UDP checksum, DNS } checks, etc). We are talking here about a deliberate attack, by a } blind attacker. (I thought these latest attacks are not blind, but never mind that.) I've seen more vastly more bit rot undetected by UDP and TCP checksums (esp. due to my own software and firmware bugs and bugs in green hardware) than human attacks. And the number of bad TCP and UDP checksums reported by `netstat -s` on any even slightly busy host should be worrisome. Why does it matter whether the bad bits are natural or man made? Why not turn on DNSSEC, declare victory, and go home? Why continually rehash the falling DNS sky? Aren't there enough other security issues? Some that I've heard about are incomparably worse in consequenes as well as ease of attack (e.g. no hours of 100 Mbit/sec flooding or per-target packet tuning to forge one measly DNS response). Vernon Schryver v...@rhyolite.com
_______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs