3 ms·

> where the DNS simply becomes another CA that has to be trusted alongside all the others Isn't DNS already implicitly trusted?

tptacek 6y ago
Not in the same way. Again: you can't revoke the DNS.
- magila 6y ago
  Any CA that issues domain validated certs can be duped by a fraudulent DNS record. All it takes is one CA failing to promptly revoke and blacklist the offending domain and the attacker is off to the races.
1vuio0pswjnm7 6y ago
As a user, one can bypass root servers and TLD servers, and caches, and go straight to the designated authoritative server(s) to get RR data. That is the most secure way to obtain DNS data, IMO. No recursion. Ideally the authoritative servers should support encryption of DNS data in transit, e.g., per packet encryption via DNSCurve. Control over RR data belongs to the person publishing it and she is free to distribute it however she likes, e.g., using ICANN DNS to list the IP address of her authoritative DNS server(s). If she chooses ICANN DNS, the ICANN-approved TLD registry and the entity that controls ICANN DNS root servers have no control over the content of the RR data (cf. the domainname), e.g., they cannot declare a RR as "false", "invalid", "revoked", etc. DNSSEC gives them this control. DNSSEC as used in practice requires that the RR data must be signed ("approved") by a third party, e.g., a TLD registry, whose own RR data must in turn must be signed ("approved") by another third party, e.g., ICANN. DNSSEC was designed for people who get their DNS data second hand, e.g., from a remote cache run by an ISP or some other third party, including "open resolvers" such as Google. That method carries some additional risk, e.g., RR data in the cache may be manipulated, as compared with retrieving the RR data directly, with no third party ISP/Google middleman, from its source: the authoritative server(s) listed by the person publishing her RR data. There are existing solutions for encrypting individual DNS packets (i.e., not streams, not TLS) travelling from the authoritative server to the user, such as DNSCurve. Alas, few authoritative servers are encrypting DNS packets. The DNS data travelling between authoritative servers and third party DNS providers running caches is, generally, not secured. I never see any discussion of this online.
- Denvercoder9 6y ago
  > As a user, one can bypass root servers and TLD servers, and caches, and go straight to the designated authoritative server(s) to get RR data. In practice everyone finds the designated authoritative servers through the root servers and TLD servers. They're trusted already.
  - 1vuio0pswjnm7 6y ago
    The addresses for those rarely change, some are unlikely to change in a lifetime. They have the same addresses year after year. You are free to keep looking them up every day, but, with very few exceptions, they will still be the same. Don't take my word for it, try storing these addresses for the major TLDs. With very few exceptions, they will work for decades. I know the addresses for a root and a .com server from memory. They do not change.

tptacek 6y ago

Not in the same way. Again: you can't revoke the DNS.

magila 6y ago
Any CA that issues domain validated certs can be duped by a fraudulent DNS record. All it takes is one CA failing to promptly revoke and blacklist the offending domain and the attacker is off to the races.

1vuio0pswjnm7 6y ago

As a user, one can bypass root servers and TLD servers, and caches, and go straight to the designated authoritative server(s) to get RR data. That is the most secure way to obtain DNS data, IMO. No recursion. Ideally the authoritative servers should support encryption of DNS data in transit, e.g., per packet encryption via DNSCurve. Control over RR data belongs to the person publishing it and she is free to distribute it however she likes, e.g., using ICANN DNS to list the IP address of her authoritative DNS server(s). If she chooses ICANN DNS, the ICANN-approved TLD registry and the entity that controls ICANN DNS root servers have no control over the content of the RR data (cf. the domainname), e.g., they cannot declare a RR as "false", "invalid", "revoked", etc. DNSSEC gives them this control. DNSSEC as used in practice requires that the RR data must be signed ("approved") by a third party, e.g., a TLD registry, whose own RR data must in turn must be signed ("approved") by another third party, e.g., ICANN. DNSSEC was designed for people who get their DNS data second hand, e.g., from a remote cache run by an ISP or some other third party, including "open resolvers" such as Google. That method carries some additional risk, e.g., RR data in the cache may be manipulated, as compared with retrieving the RR data directly, with no third party ISP/Google middleman, from its source: the authoritative server(s) listed by the person publishing her RR data. There are existing solutions for encrypting individual DNS packets (i.e., not streams, not TLS) travelling from the authoritative server to the user, such as DNSCurve. Alas, few authoritative servers are encrypting DNS packets. The DNS data travelling between authoritative servers and third party DNS providers running caches is, generally, not secured. I never see any discussion of this online.

Denvercoder9 6y ago
> As a user, one can bypass root servers and TLD servers, and caches, and go straight to the designated authoritative server(s) to get RR data. In practice everyone finds the designated authoritative servers through the root servers and TLD servers. They're trusted already.
- 1vuio0pswjnm7 6y ago
  The addresses for those rarely change, some are unlikely to change in a lifetime. They have the same addresses year after year. You are free to keep looking them up every day, but, with very few exceptions, they will still be the same. Don't take my word for it, try storing these addresses for the major TLDs. With very few exceptions, they will work for decades. I know the addresses for a root and a .com server from memory. They do not change.