Confirmed users
299
edits
Security/DNSSEC-TLS: Difference between revisions
no edit summary
No edit summary |
|||
| Line 42: | Line 42: | ||
(Aside: CNAME records do not work well with this porposal. For instance, the A record for addons.mozilla.org is actually a CNAME for amo.glb.mozilla.net. The first problem is that amo.glb.mozilla.net has no RRSIG record, and thus cannot actually be verified through DNSSEC. The second problem is even if it did, we would have to send twice as much (more? can CNAMES point to CNAMES?) data.) | (Aside: CNAME records do not work well with this porposal. For instance, the A record for addons.mozilla.org is actually a CNAME for amo.glb.mozilla.net. The first problem is that amo.glb.mozilla.net has no RRSIG record, and thus cannot actually be verified through DNSSEC. The second problem is even if it did, we would have to send twice as much (more? can CNAMES point to CNAMES?) data.) | ||
= | =Google Chrome= | ||
According to [http://www.imperialviolet.org/2011/06/16/dnssecchrome.html Adam Langley's Weblog], DNSSEC validation of TLS (specifically HTTPS) sessions is enabled by default in the canary and dev channels of Chrome. It is achieved through the server sending a self-signed certificate that contains as an X509 extension a blob of data corresponding to the DNSSEC chain. The leaf of the chain is a CAA record. The root of the chain is implicitly the root zone key signing key (the key itself is not included). | |||