Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

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?

share|improve this question

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: 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 and would then look up 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.

share|improve this answer
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 – acidzombie24 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. – acidzombie24 Apr 12 '14 at 21:38
@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

You are confusing DNSSEC with TLS for HTTP (HTTPS).

DNSSEC is just a measure to try and make sure that all your users get authoritative DNS records and they don't get spoofed, one way or another. DNSSEC does not encrypt connections or help you to secure your traffic.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.