[dns-operations] summary of recent vulnerabilities in DNS security.

[Vernon Schryver]

> From: Stephane Bortzmeyer <bortzmeyer at 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 <bortzmeyer at 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    vjs at rhyolite.com