
The Journey to Hijacking a Country’s TLD – The Hidden Risks of Domain Extensions - 0x0
https://thehackerblog.com/the-journey-to-hijacking-a-countrys-tld-the-hidden-risks-of-domain-extensions/index.html
======
hdhzy
And that, ladies and gentlemen, is why DNSSEC is a really terrible idea...
That's what tptacek would've said, I guess.

But seriously, having such a weak security for something so fundamental as
name server scares me out.

~~~
toast0
I'm not sure this is an indictment for DNSSEC; if DNSSEC were widely deployed,
it would actually address one aspect of this: you wouldn't be able to takeover
a latent glue record, because you couldn't provide properly signed answers.

If you takeover email domains, and ask IANA to change the signing keys, or
take over the servers and recover the signing secrets; DNSSEC wouldn't help,
and might provide some air of legitimacy though. And, of course, then you
could provide false keys for whatever subdomains you hijacked. On the other
hand, if you control DNS, it's not hard to get a domain validated certificate,
although some CAs will run your domain through a list of high value names
before they will issue a fully automated cert.

In a world with domain validated certificates being very common, it doesn't
seem like we gain much by declaring that TLD operators are untrustworthy, so
we can't explicitly trust them to provide DNSSEC signatures and enable DANE,
when we are implicitly trusting them to provide correct information when CAs
do domain validation.

There's certainly an argument that we don't gain very much by knowing an
untrustworthy entity has certified something, though.

~~~
hdhzy
Yep, this discussion about DNSSEC happens here from time to time usually with
the same arguments.

Once Chrome even supported DANE certs for domains but deprecated it for I
think performance reasons:

> Some years ago now, Chrome did an ex­per­i­ment where we would lookup a TXT
> record that we knew ex­isted when we knew the In­ter­net con­nec­tion was
> work­ing. At the time, some 4–5% of users couldn't lookup that record; we
> as­sume be­cause the net­work wasn't trans­par­ent to non-stan­dard DNS
> re­source types. DANE records are going to be even more non-stan­dard, are
> going to be larger and browsers would have to fetch lots of them be­cause
> they'll need the DNSKEY/RRSIG chain up from the root. Even if DNSSEC record
> lookup worked flaw­lessly for every­one, we prob­a­bly still wouldn't
> im­ple­ment this as­pect of DANE be­cause each extra lookup is more la­tency
> and an­other chance for packet loss to cause an ex­pen­sive time­out and
> re­trans­mit.

Source:
[https://www.imperialviolet.org/2015/01/17/notdane.html](https://www.imperialviolet.org/2015/01/17/notdane.html)

Is DANE currently used for anything? XMPP certs?

~~~
toast0
I don't think DANE is really in use; although there's some hints it may be
usable with SMTP (postfix has support).

I'm not sure DANE is realistically usable anyway -- unless it was for a
protocol which specified DANE only, you'd need to have a CA signed cert for
interoperability with clients that didn't support it; in which case, you may
as well just use that. I guess it makes sense for SMTP -- generally
certificates are not validated when delivering mail, under the theory that
encryption with an invalid cert is better than plaintext, and there's not a
usable UI to let the sender pick what to do. In that case, DANE can work, but
I kind of doubt there's much adoption still.

------
dylz
One huge question is: why are entire countries' TLDs being hosted on free DNS
services?

~~~
nobodyorother
Budget cuts? :)

