4

From my understanding DNSSEC allows me to create a public key and sign my DNS records. There appears to be multiple ways to have a certificate record (such as DANE see https://wiki.mozilla.org/Security/DNSSEC-TLS-details#Embedding_Certificate_Information_in_DNS)

I'm not exactly sure how this works. I'm guessing these steps. Is this correct?

  • Create a public/private key pair
  • Put the public key into a DNS record (DS I believe)
  • Sign my dns records
  • Create a public/private key for my server
  • Create a certificate
  • Sign the certificate using the DNS private key
  • Put the certificate in the DNS!?!?!
  • Put the certificate on my server and use it the typical way?

I feel like I got something wrong and that Mozilla link mentions not all records would be supported so which is currently well supported (lets say firefox, chrome, IOS and android) and what record am I using for what I describe? DANE? CAA?

1 Answers1

6

DNSSEC and DANE are separate things but DNSSEC is a prerequisite to using DANE.

DNSSEC specifically allows for validation that the received DNS data is authentic, nothing more.

Making use of DNSSEC would mean to generate DNSSEC keys, signing your zone (which would result in publishing the public keys as DNSKEY records, adding RRSIG/NSEC/NSEC3 records based on your actual zone data, etc), making the delegation signed by having the registrar add a DS record (which identifies the valid key that you have published in the delegated zone) along with normal NS / glue records.

Making use of DANE essentially comes down to adding a TLSA record like the following in the DNSSEC-signed zone:

_443._tcp.example.com. IN TLSA tlsa-parameters-identifying-the-valid-certificate

(You may want to use tlsa(1) from hash-slinger to generate this record)

The DANE-aware HTTPS client (in this example) would then know that they are connecting to port 443/tcp on example.com and would then look up _443._tcp.example.com. IN TLSA, validate the authenticity of the DNS data and then, in turn, use that data to validate the certificate presented in the TLS connection.

Community
  • 1
Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
  • Good answer. I'm confused, what is the DS record? It seems like its my name registrar sign my (DNSKEY) key? RRSIG seems like its for zones that exist and NSEC3 for a catchall/zones that doesn't exist? I guess NS i'm confused about. It seems to control which name server are authoritative (my DNS knowledge isn't good). But why does it need it when I'm signing all the zones?? I don't believe it can fake any of my subdomains? hash-slinger seems like a good tool thanks for mentioning it –  Apr 12 '14 at 21:34
  • It looks like hash-slinger/tlsa util doesn't need my private key? and I sign the cert using the key I signed my DNS? and that DANE record is just a hash of my cert? this makes sense. –  Apr 12 '14 at 21:38
  • 1
    @acidzombie24 The purpose of the `DS` record is to have the parent zone identify which key is valid for the child zone. It's essentially a hash of your public key. The reason why this is needed is that the party validating dnssec data would have no means of knowing which key to trust for a given zone otherwise. – Håkan Lindqvist Apr 12 '14 at 21:38
  • @acidzombie24 The `DS` and `TLSA` records are similar in that sense, they both identify which key(/cert) to trust (but in entirely different contexts). – Håkan Lindqvist Apr 12 '14 at 21:40