
ICANN urges adopting DNSSEC now - okket
https://www.networkworld.com/article/3343185/icann-urges-adopting-dnssec-now.html
======
Tepix
DNSSEC is an awful standard that doesn't even solve half the problems that DNS
has.

Edit: To offer more constructive criticism: I'd rather see DNSCurve
[http://dnscurve.org/](http://dnscurve.org/) see wide adoption.

~~~
phicoh
It's a pity that you link to a page that compares DNSCurve to plain DNS.

DNSSEC has the feature that it works even in the presence of caching
(recursive) resolvers.

DNSSEC only solves half of the problems. That's why you use DNS-over-TLS (or
DNS-over-HTTPS) for the other half.

~~~
the8472
DNS-over-TLS is only intended for stub resolver - recursive resolver traffic
(check the introduction sections of the relevant RFCs). We're still lacking a
protocol to provide confidentiality between the recursive resolver and
authoritative servers. DNSCurve would offer that.

~~~
phicoh
Which makes sense, because there is (in general) not much point in protecting
traffic between recursive and auth. servers if you don't protect the stub
resolver.

At the same time traffic between stub resolver and recursive resolver is much
more privacy sensitive.

So it makes sense to first get TLS between stub and recursive up and running.
And that proves already hard enough.

~~~
zzzcpan
Technically stub resolvers and recursive resolvers are the same thing (one is
an inherent part of the other). So all is needed is recursive resolvers to
communicate securely with authoritative servers. Tunnels to third party
recursive resolvers do nothing but leak private data to them.

------
jlgaddis
I don't have the DHS "emergency directive" (referenced in the article) handy
at the moment (and it's been a couple months since I read it) but I don't
recall _ANY_ recommendation (or "directive") by DHS for the government
agencies to implement DNSSEC.

In fact, if memory serves, DNSSEC was not mentioned _AT ALL_ in the DHS
document.

That's somewhat telling, IMO.

I'm not sure what ICANN's motivations are in pushing DNSSEC so hard -- all of
these "hijackings" were due to compromised accounts (at DNS providers,
registrars, etc.).

Instead of requiring government agencies to implement DNSSEEC, DHS instead
directed them to rotate/secure their accounts/passwords at the DNS providers,
registrars, etc.

That makes much more sense to me.

~~~
tssva
OMB memorandum M-08-23 released in 2008 already requires US federal government
agencies to use DNSSEC.

~~~
tptacek
Since repealed, right?

 _Later_

Yep. It was rescinded in 2018. There is no longer a mandate for DNSSEC in
federal government IT that I'm aware of.

------
xeeeeeeeeeeenu
I don't understand what's the point of DNSSEC. Literally the only attack
scenario that DNSSEC protects from is when someone is MITMing your ISP, which,
I believe, is something that practically never happens.

It doesn't do anything about the most common attack scenarios, such as MITM
between the client and the last mile DNS server or hackers stealing your
domain registrar credentials.

To be honest, it seems to me that the _real_ purpose of this protocol is to
make people/enterprises feel safer without actually doing anything useful.

~~~
wtallis
> Literally the only attack scenario that DNSSEC protects from is when someone
> is MITMing your ISP, which, I believe, is something that practically never
> happens.

It also helps when your ISP is MITMing your attempts to get accurate DNS
information. That happens _all the time_ , though most of it is just sending
you to advertisements when you're supposed to get NXDOMAIN.

~~~
xeeeeeeeeeeenu
No, it does not protect from that. Stub resolvers (i.e. DNS clients) fully
trust recursive resolvers by design and don't validate DNSSEC signatures.

In theory the client _can_ validate them but, for various reasons, pretty much
none of the implementations do that.

------
tyingq
I don't expect a lot of movement, given things like:

 _" If you want to configure DNSSEC for a domain that is registered with Route
53, you must use another DNS service provider"_

~~~
colde
Yeah. It's extremely disappointing that AWS hasn't implemented DNSSEC in Route
53. Even more so, since they have actually been a target of an attack on Route
53, that would have been ineffective if DNSSEC had been enabled.

~~~
tombrossman
If you are buying a domain through Route 53, there is a good chance the
purchase is actually being handled by Gandi[0]. Gandi supports DNSSEC[1] (it's
literally a check box in the options, very simple) so you may as well skip
buying the domain through Route 53 and get it directly from Gandi.

No affiliation with either company, just a happy customer of both.

    
    
      [0]https://aws.amazon.com/route53/domain-registration-agreement/
      [1]https://docs.gandi.net/en/domain_names/advanced_users/dnssec.html

------
throwaway031519
Waiting for tptacek...

~~~
tptacek
I feel like HN is getting to the point where, if I'm 24 hours late to a DNSSEC
story, other people will have gotten the main points I'd have made first, and
those points will be voted high on the page. You're all grown up, now, HN.

------
jcranmer
> “Some of the attacks target the DNS, in which unauthorized changes to the
> delegation structure of domain names are made, replacing the addresses of
> intended servers with addresses of machines controlled by the attackers.
> This particular type of attack, which targets the DNS, only works when
> DNSSEC is not in use,” ICANN stated.

Isn't that a bald-faced lie? The attacks in question are "someone stole my
credentials and told my DNS provider to change the records to point
elsewhere", as I understand them. DNSSEC merely protects against DNS spoofing
on the internet backbone (not everywhere, because you're not supposed to turn
out in when querying your ISP's DNS server, so the last mile isn't protected).

~~~
phicoh
The argument seems to be that if your attacker is stupid enough to only change
your NS records and doesn't know about DS records, then DNSSEC will provide
some protection.

It is not clear with ICANN mentions this, because somebody hacking your
registry account (or somebody hacking your registry or the registrar) are
attacks DNSSEC cannot protect against.

~~~
quicksilver03
A threat model where the attacker is assumed to be stupid is a very weak
threat model. Better to assume that the attacker is at least as knowledgeable
as you are.

------
bluejekyll
> “However, most implementations are incompatible with modern DNS
> requirements, including redundant DNS setups or dynamic responses from DNS-
> based traffic-management features,” Beevers said. “Legacy DNSSEC
> implementations break even basic functions, such as geo-routing, and is hard
> to implement across multiple vendors, which means poor performance and
> reduced availability for end users.”

Does anyone have more information related to the above quote? I’d like to
understand better what they’re referring to.

~~~
toast0
I can field this one. DNSSEC was conceived with support for a traditional zone
transfer process. When you edit the zone, you sign it once (potentially
offline) and send it via zone transfer to all your authoritative servers. In
that context, the authoritative servers can't do things like serve the best A
or whatever record given the recursive resolver contacting them and global
state. Instead, you generally end up with your keys online on all the
authoritative servers. Which means if your DNS account is hacked, chances are,
the hackers are in a position to change your records. If your registrar
account is hacked, the hackers are certainly able to remove or replace the DS
records at the registry, so DNSSEC doesn't help there either (good auth at the
registry and registrar and maybe registry lock help there).

DNSSEC might help with MITM, if you only communicate with recursive resolvers
you trust to properly implement it and not sneak in any garbage, but it
doesn't help against account compromise.

~~~
marcosdumay
> serve the best A

Well, you have to serve them all and let the client decide what to use, like
with MX or SRV. Too bad HTTP is stuck in time and can't get any proper
functionality.

And yes, I mean it is literally too bad. Why can HTTP hold 3 current standards
at the same time, but still fail to work with basic internet infrastructure?

~~~
tptacek
Are we at the point of desperation in the death gasps of DNSSEC where its
advocates are now blaming other protocols for not rearchitecting the way they
use the DNS to make it DNSSEC more viable? Because: nobody was ever going to
do that.

