To solve the chicken-or-egg problem for DNSSEC from the other side, let’s use an authoritative DNS server (BIND) for signing DNS zones. This tutorial describes how to generate the keys and configure the “Berkeley Internet Name Domain” (BIND) server in order to automatically sign zones. I am not explaining many details of DNSSEC at all, but only the configuration and verification steps for a concrete BIND server.
It is really easy to tell BIND to do the inline signing. With this option enabled, the admin can still configure the static database for his zone files without any relation to DNSSEC. Everything with signing and maintaining is fully done by BIND without any user interaction. Great.
Prerequisites
I am assuming that there is a working BIND server in place which is the authoritative name server for at least one zone. The BIND server must at least run with version 9.9! I am using an Ubuntu Server 14.04.4 LTS with BIND version 9.9.5-3ubuntu0.8-Ubuntu. A few days age I published a blog post covering the secure installation of BIND. Refer to it to see how. Note that ALL of the following configuration steps are done only on the primary server since the secondary servers will only mirror the completely signed zone file. There is no need to adjust something at the secondaries at all. For this tutorial, I am using my test domain weberdns.de.
Furthermore, please read some general DNSSEC information on other sites, or simply google it and read the Wikipedia, DNSSEC.net, or RFC (4033, 4034, 4035) articles. I am assuming that you are already familiar with KSK & ZSK, RRSIG, DNSKEY, DS, NSEC & NSEC3. If not, come back again in two hours. ;) Ok, in any case, here it is: DNSSEC signes zones with a private key (ZSK and KSK), while the public key is used to verify the signature. The signature for all resource records are stored in additional records, called RRSIG. The “Next SECure record” (NSEC) is used to prove that no entry exists between two other entries (NXDOMAIN).
Design and Keys
One thing to think about is the placement of the keys. The private keys (for both, the KSK as well as for the ZSKs) should NOT be accessible from the Internet. In the best way, a hardware security module (HSM) would be used for them. However, since this is not that trivial, the concept of a hidden primary can be used. With this way, the private keys are only stored on a not-accessible server, while only the secondaries (which must not store the private keys) are queried from the Internet:
Another consideration is the usage of NSEC or NSEC3. For small zones that only store a few well-known names such as ns, www, and mail, NSEC can be used. (Remember the zone walking.) For complex zones with many hidden domain names, the usage of NSEC3 should be considered. However, note that “security through obscurity” is not a good design at all. ;)
BIND Configuration
We will first generate the keys followed by the configuration of BIND. A great (hence: small) tutorial is also available at ISC: Inline Signing in ISC BIND 9.9.0 — Examples. Note that I am using /dev/urandom for my key generation. If you are interested in more details, read this or that. And again, note that you must have at least BIND 9.9 for these features to work.
dnssec-keygen
First, create a new directory for the keys:
1 |
sudo mkdir /etc/bind/keys |
And generate both, the KSK and the ZSK, within that newly created directory. I am using the RSASHA256 algorithm and 2048 bit for the KSK, while 1024 bit for the ZSK:
1 2 |
sudo dnssec-keygen -r /dev/urandom -a RSASHA256 -b 2048 -K /etc/bind/keys/ -f KSK -n ZONE weberdns.de sudo dnssec-keygen -r /dev/urandom -a RSASHA256 -b 1024 -K /etc/bind/keys/ -n ZONE weberdns.de |
Since BIND must be able to read the private key, change the permissions for the group (bind) to read the *.private files: “sudo chmod g+r *.private” the ownership of the files to “bind:bind”:
1 |
sudo chown bind:bind * |
Now, the /keys directory should look like that:
1 2 3 4 5 |
weberjoh@jw-vm16-ns0:/etc/bind/keys$ ls -ahl Kweberdns* -rw-r--r-- 1 bind bind 431 May 20 09:46 Kweberdns.de.+008+57909.key -rw------- 1 bind bind 1012 May 20 09:46 Kweberdns.de.+008+57909.private -rw-r--r-- 1 bind bind 605 May 20 09:46 Kweberdns.de.+008+63202.key -rw------- 1 bind bind 1.8K May 20 09:46 Kweberdns.de.+008+63202.private |
For example, my public KSK for weberdns.de looks like that:
1 2 3 4 5 6 |
weberjoh@jw-vm16-ns0:/etc/bind/keys$ cat Kweberdns.de.+008+63202.key ; This is a key-signing key, keyid 63202, for weberdns.de. ; Created: 20160205194002 (Fri Feb 5 20:40:02 2016) ; Publish: 20160205194002 (Fri Feb 5 20:40:02 2016) ; Activate: 20160205194002 (Fri Feb 5 20:40:02 2016) weberdns.de. IN DNSKEY 257 3 8 AwEAAdQXI+UfqnGbHdwJtBBStf0CM8Q8nXcriaOysrpGEDNkM//amUBD 2YMWQ3g+htca6tmzfDJMM5D0gOk5d4IdEmdywkcH+0rGLjNiNEPFnZUp wb6XsYD+ZI/WEuSlp+KCEV8vwELq7VltABrFT+9Rz5CEvokTxonzQrvn fclVHaGwO7cglgALsFqJCqBpvDZvEr2Z6dSepjDnFC9BPS6V8PGSNwAY EtzDp/lrQojkCj28xHj2OCjpr0dIQjdjGFJTHIlc9cYTAHjdPDsC8Eqf s5HcL3ruU6cbqjTn+5Lm4RdXpOWVgemVvIGDnUN+v+Tma/WgtQk7U3sa izNJ3epCv3s= |
[Note that I had some problems on Ubuntu with the keys for BIND. This post helped me to solve it. But I am not fully sure whether this is the best way:
1 |
sudo nano /etc/apparmor.d/usr.sbin.named |
and changing the following line to this:
1 |
/etc/bind/** rw, |
and a restart of apparmor: sudo service apparmor restart .]
named.conf.options & named.conf.local
It is really simple to tell BIND that it should sign its zones for the proper usage of DNSSEC. The first step is to set the key-directory and to enable dnssec. (Note that dnssec-enable is “yes” per default. However, I am adding the lines anyway.) Open the named.conf.options file: sudo nano named.conf.options and add the following two lines within the options { } section:
1 2 |
dnssec-enable yes; key-directory "/etc/bind/keys"; |
The second step is to configure the concrete zone to be signed and maintained. That is: BIND will 1) use the existing zone file and sign it in the background and 2) maintains the signed file in order to update any signatures once they expire.
Open the named.conf.local file in which the zones are declared: sudo nano named.conf.local and add the following two lines to the zone which should be signed:
1 2 |
auto-dnssec maintain; inline-signing yes; |
That’s it!!
Reload the server in order to let BIND sign the zone: sudo service bind9 reload. The following command checks the correct signing, e.g.:
1 2 3 |
weberjoh@jw-vm16:/etc/bind$ sudo rndc signing -list weberdns.de Done signing with key 57909/RSASHA256 Done signing with key 63202/RSASHA256 |
Note that you now have two more files within the /etc/bind/ directory, namely the *.signed and *.signed.jnl files. These are the real zone files that are presented to the world, while the original zone file is the file which is still edited by the admin:
1 2 3 4 5 |
weberjoh@jw-vm16-ns0:/etc/bind$ ls -ahl db.weberdns* -rw-r--r-- 1 root bind 8.0K Aug 23 12:41 db.weberdns.de -rw-r--r-- 1 bind bind 34K Aug 23 12:41 db.weberdns.de.jnl -rw-r--r-- 1 bind bind 26K Aug 23 12:53 db.weberdns.de.signed -rw-r--r-- 1 bind bind 387K Aug 23 12:41 db.weberdns.de.signed.jnl |
KSK/DS to Parent Zone
In order to have the full DNS tree secured by DNSSEC, you must transfer your KSK or DS record to your registrar. They will sign it with their private key. This is the main part of DNSSEC because afterwards anyone in the world will be able to validate that you really own the private key for your zone.
If the registrar wants the DS record, obtain it from the KSK keys with the tool dnssec-dsfromkey, such as:
1 2 3 |
weberjoh@jw-vm16-ns0:/etc/bind/keys$ dnssec-dsfromkey Kweberdns.de.+008+63202. weberdns.de. IN DS 63202 8 1 45B896D0F5735832203F18A600A605072596D368 weberdns.de. IN DS 63202 8 2 2F9112FF344BCDF9C6F9A7548F04184AAE73458C7150DE8FFFA3B7D9893C5EEE |
If they want the whole public KSK, simply “cat” it from the keyfile, as already shown above (cat Kweberdns.de.+008+63202.key).
After the registrar has received and signed the KSK, it can be queried within the DNS. For the German DENIC, the KSK is also present in the whois query:
1 2 3 4 5 6 7 8 |
whois weberdns.de Domain: weberdns.de Nserver: ns1.weberdns.de 2003:51:6012:110:0:0:a07:53 80.154.108.230 Nserver: ns2.weberdns.de 213.61.29.182 Dnskey: 257 3 8 AwEAAdQXI+UfqnGbHdwJtBBStf0CM8Q8nXcriaOysrpGEDNkM//amUBD2YMWQ3g+htca6tmzfDJMM5D0gOk5d4IdEmdywkcH+0rGLjNiNEPFnZUpwb6XsYD+ZI/WEuSlp+KCEV8vwELq7VltABrFT+9Rz5CEvokTxonzQrvnfclVHaGwO7cglgALsFqJCqBpvDZvEr2Z6dSepjDnFC9BPS6V8PGSNwAYEtzDp/lrQojkCj28xHj2OCjpr0dIQjdjGFJTHIlc9cYTAHjdPDsC8Eqfs5HcL3ruU6cbqjTn+5Lm4RdXpOWVgemVvIGDnUN+v+Tma/WgtQk7U3saizNJ3epCv3s= Status: connect Changed: 2016-05-17T17:01:42+02:00 |
The DS record can be queried with a normal DNS request. In the following example, I am using the +trace and +dnssec options in order to see the DS returning from the parent zone (in my case .de) and to see some RRSIG signatures for all answers:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 |
weberjoh@jw-nb12-lx:~$ dig weberdns.de ds +multi +dnssec +trace ; <<>> DiG 9.10.3-P4-Ubuntu <<>> weberdns.de ds +multi +dnssec +trace ;; global options: +cmd . 451618 IN NS i.root-servers.net. . 451618 IN NS d.root-servers.net. . 451618 IN NS l.root-servers.net. . 451618 IN NS g.root-servers.net. . 451618 IN NS h.root-servers.net. . 451618 IN NS j.root-servers.net. . 451618 IN NS b.root-servers.net. . 451618 IN NS e.root-servers.net. . 451618 IN NS c.root-servers.net. . 451618 IN NS a.root-servers.net. . 451618 IN NS m.root-servers.net. . 451618 IN NS f.root-servers.net. . 451618 IN NS k.root-servers.net. . 518356 IN RRSIG NS 8 0 518400 ( 20160902050000 20160823040000 46551 . C2NM1S7/NzZQDbx9H1tWLl1VotgaC0+YG0LtkW6Gfy5l 91WCLoK7RZJfl2joYyU4KnB/4/jRJhV4tbfvB4+GA7pp c0V/v00KLipbCB+i39RFP5WVy9nlBgyXbqy8AqzJKnPH BePme3m4q36RESbBxl3fENeoPPUWtO4/iSbxgsg= ) ;; Received 397 bytes from 192.168.120.22#53(192.168.120.22) in 1 ms de. 172800 IN NS a.nic.de. de. 172800 IN NS f.nic.de. de. 172800 IN NS l.de.net. de. 172800 IN NS n.de.net. de. 172800 IN NS s.de.net. de. 172800 IN NS z.nic.de. de. 86400 IN DS 24220 8 2 ( FFE926ACA67ED94089390250F1F294AC84A6D84F9121 DF73A79E439F42E820C2 ) de. 86400 IN DS 39227 8 2 ( AAB73083B9EF70E4A5E94769A418AC12E887FC3C0875 EF206C3451DC40B6C4FA ) de. 86400 IN RRSIG DS 8 1 86400 ( 20160901170000 20160822160000 46551 . YNFLS/92zyUl+kiulpePRyyqc33LqbAO2PSCQvzBup+Q 5HfhS4KpoXPf7nuLB4BuVMGyjg0pmeFhqpk+yY7Ny8b1 UYoy3jTZ82z0Kx8pxTdkU/25cLBn7HHxGIakOupcd0cF LpalPqLFzmvmWATy6G2CBRKj73mfCBFK4JEr9b0= ) ;; Received 609 bytes from 2001:503:c27::2:30#53(j.root-servers.net) in 165 ms weberdns.de. 86400 IN DS 63202 8 2 ( 2F9112FF344BCDF9C6F9A7548F04184AAE73458C7150 DE8FFFA3B7D9893C5EEE ) weberdns.de. 86400 IN RRSIG DS 8 2 86400 ( 20160830060000 20160823060000 56953 de. pwtHpsI4NLVHDPP43PvQNJqZ0idkAMt0PACex8+d3et7 f2laUbWydCkQwlFymWl+UGelXBk249vENMPUdyb5p0Je 9juE0n+ruvf83YNXNjFoNjMloOwc7qDA0VB/tJr0o/kX 56dkBHzPM4Vba4fvOBXdp4IbM16u7PWXYeMxW50= ) ;; Received 250 bytes from 194.246.96.1#53(z.nic.de) in 9 ms |
In the same way, the dnskeys (KSK and ZSK) can be queried:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 |
weberjoh@jw-nb12-lx:~$ dig weberdns.de dnskey +multi ; <<>> DiG 9.10.3-P4-Ubuntu <<>> weberdns.de dnskey +multi ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44554 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;weberdns.de. IN DNSKEY ;; ANSWER SECTION: weberdns.de. 448 IN DNSKEY 256 3 8 ( AwEAAc1G9dfFSBL+/NxRd7//80J8Hx8hjUyaQ7oaJV0t OErEc1+To0BGp3FOB7fQFQ6dJIHzfRD4YO0KoJjaH4P7 fWO6Qs+05U6dnf2BGPy91m/4LHqM+6jzFMMf566GHxuZ YB/8OkKcyRU7IS+vubtYL8jT7hqzqg+XXpQbDRlbtNgP ) ; ZSK; alg = RSASHA256; key id = 57909 weberdns.de. 448 IN DNSKEY 257 3 8 ( AwEAAdQXI+UfqnGbHdwJtBBStf0CM8Q8nXcriaOysrpG EDNkM//amUBD2YMWQ3g+htca6tmzfDJMM5D0gOk5d4Id EmdywkcH+0rGLjNiNEPFnZUpwb6XsYD+ZI/WEuSlp+KC EV8vwELq7VltABrFT+9Rz5CEvokTxonzQrvnfclVHaGw O7cglgALsFqJCqBpvDZvEr2Z6dSepjDnFC9BPS6V8PGS NwAYEtzDp/lrQojkCj28xHj2OCjpr0dIQjdjGFJTHIlc 9cYTAHjdPDsC8Eqfs5HcL3ruU6cbqjTn+5Lm4RdXpOWV gemVvIGDnUN+v+Tma/WgtQk7U3saizNJ3epCv3s= ) ; KSK; alg = RSASHA256; key id = 63202 ;; Query time: 1 msec ;; SERVER: 192.168.120.22#53(192.168.120.22) ;; WHEN: Tue Aug 23 10:27:18 CEST 2016 ;; MSG SIZE rcvd: 464 |
Tests (AD & RRSIG)
Now, lets check the correct signing of the DNSSEC secured zone. You must use a DNSSEC validating name server, such as BIND or Unbound, as I showed in the past two blog posts. If you do not have a validating server yourself, you can use the Google public DNS server at 2001:4860:4860::8888 or 8.8.8.8 because it already does validating DNSSEC answers. (Note that your authoritative server won’t ever reply with the “ad” flag, but only with the “aa” flag. This is by design. The authoritative server must not prove his own records, because he has direct access to the source and trusts it.)
The main part when using dig is the “ad” flag within the DNS answer. This indicates the “Authentic Data” being transferred. (Ref: IANA, DNS Header Flags.)
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
weberjoh@jw-nb12-lx:~$ dig mail.weberdns.de ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.weberdns.de ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48243 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;mail.weberdns.de. IN A ;; ANSWER SECTION: mail.weberdns.de. 3529 IN A 80.154.108.237 ;; Query time: 1 msec ;; SERVER: 192.168.120.22#53(192.168.120.22) ;; WHEN: Tue Aug 23 10:43:33 CEST 2016 ;; MSG SIZE rcvd: 61 |
In order to see the signatures (RRSIG), use dig with the +dnssec and +multi options. Now, the DNSSEC related information are displayed, as well as listed within multiple lines with some explanatory notes. Note that my domain name “mail.weberdns.de” has an A and an AAAA record. Therefore this example shows two answers along with two signatures:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
weberjoh@jw-nb12-lx:~$ dig mail.weberdns.de any +dnssec +multi ; <<>> DiG 9.10.3-P4-Ubuntu <<>> mail.weberdns.de any +dnssec +multi ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53578 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;mail.weberdns.de. IN ANY ;; ANSWER SECTION: mail.weberdns.de. 3505 IN RRSIG AAAA 8 3 3600 ( 20160915070035 20160816062828 57909 weberdns.de. UQCnmReXJ0jqU7u0frFR9Nj+vTPxlXB/k2h2yc9pNZht GvhNYbRzvslI9P/XH1cBXphqs1YNSntMGcl/GDpR5ZK6 Mn0PN5LGJ+Q/SI/mVgZSSRrnFRaZn1/w0muAcintv8kq Mkhh47WT2QJ2JAiaUcB8P3P/w2X57oeTr1hrawg= ) mail.weberdns.de. 3505 IN AAAA 2003:51:6012:110::15 mail.weberdns.de. 3451 IN RRSIG A 8 3 3600 ( 20160915070035 20160816062828 57909 weberdns.de. aOublailZ4XyYZEO5Wq1ucexwYrIs6LDjiwbav2wBRq1 ALNT4+0w6BqZ+so5xvYpH0bW9bHcXH+oJx7yUZEZi0Ka IlrU96PvMKJGluqpZiuzS8jGhVQgKAfwLqKJOQzBB+4M s21YkDAOu/oDiso42yP9GuFakK1JzZPhE5Z5t6Y= ) mail.weberdns.de. 3451 IN A 80.154.108.237 ;; Query time: 1 msec ;; SERVER: 192.168.120.22#53(192.168.120.22) ;; WHEN: Tue Aug 23 10:44:51 CEST 2016 ;; MSG SIZE rcvd: 431 |
In both cases, note the AD flag.
Congratulations. You’re done. You have correctly secured your DNS zone!
In case of failures such as “no servers could be reached” when checking from the outside you might have a look at intermediary firewalls. For example, blocking IP fragments (such as I did ;)) is a bad idea:
Just solved a #DNS problem on my @PaloAltoNtwks firewall settings: Using DNSSEC while dropping IP fragments is a bad idea. ;) Loving the "show counter global filter …" command on the Palo. Helps extremely! pic.twitter.com/NlGbI08w76
— Johannes Weber 🎸 (@webernetz) April 5, 2019
What about the Secondaries?
Good news: You do not have to do anything with the secondary name servers. They only mirror the signed zone files in the same way they mirrored the unsigned ones. So nothing to do here. ;)
Tools
There are some great online tools to verify the DNSSEC signatures. Have a look at DNSViz. It reveals and visualizes any DNS name, for example for mail.weberdns.de. Another tool is the DNSSEC Analyzer for iPhone. Here are two screenshots of these tools:
Further Reading
One key word that was not mentioned until now is: key rollover. I have only generated a single ZSK without any further expiration dates or following keys. In an upcoming blogpost I will show how to rollover the ZSK.
Furthermore, there are some cool things to come with DNSSEC: DANE and SSHFP, which I will cover in upcoming posts, too.
And keep in mind that you MUST have accurate date and time settings on your DNSSEC servers. If you’re drifting too much, all signatures will become invalid. Consider the usage of an own NTP server with different sources.
Some more links:
- DNSSEC.net
- [de] heise Netze: DNSSEC-Day 2015
- How To Setup DNSSEC on an Authoritative BIND DNS Server
- OpenDNSSEC
- DNSSEC Deployment
Featured image “vertrag-130407_014.jpg” by Eleleleven is licensed under CC BY-SA 2.0.
I have a silly question, but maybe you might update your awesome tutorial to answer it. All tutorials (including yours) just deal with one domain name. That means generating two keys, the KSK and the ZSK. If I have many (dozens, thousands…) of domain names, each will have its own ZSK (obviously) but will they have their own KSK as well? If so, what’s the point of signing the zones twice? On the other hand, I see the advantage of having all zones signed with the same KSK, so that you can invalidate everything by changing just the KSK manually, and let BIND regenerate everything. Cool, of course. However, I can also see that it wouldn’t be that hard to change all ZSKs with a simple script… uh… so I don’t see the point of using a KSK altogether. Ok, I know — I ought to spend the two hours reading manuals :-P I will do so, and hopefully get some light shed into this mysterious issue…
BTW, for the sake of completeness, you ought also to write a paragraph explaining how to properly configure the secondary nameserver. I know it’s trivial, but it’s always nice to have everything on a single page (most tutorials also ‘forget’ the secondary nameservers, so you’re definitely not alone on this).
Gwyneth! Thanks for your feedback and sorry for the delay in responding.
1) The differences between the KSK and the ZSK are that the KSK must be brought to the parent zone (which involves a third party). You won’t rollover the KSK that often but only after a breach or every few years. The ZSK is completely under your control and you can simply rollover it every few month. Of course, with some scripts. ;) Please refer to my blog post about the ZSK rollover. That is, it is absolutely recommended to use new and fresh KSKs (and of course ZSKs) for each and every zone. (Note that you must specify the name of the zone while generating the KSK so you don’t have the choice anyway.)
2) Thanks for the hint. I just added a small paragraph stating that you must not do anything on the slaves. (Assumed that you already have a working primary-slave setup.) The slaves will just mirror the complete (signed) zone file. I did not have any problems with them so far.
Thank you for your detailed explanation. Can we implement the same for a private hierarchial DNS structure without being registered with Domain registery. When I tried to do DNSEC on a private root zone including top level domain and child nodes.My signed zone does not contain signed RR of DS, How can I bring signed RR of DS into my signed zone?
Hey Jeyakumar,
you can sign whatever you want. ;) But you must put your own trust-anchor at the DNSSEC validating resolver.
Concerning your DS records: You must place them into your parent zone by yourself. BIND won’t do it in an automatic way. Please have a look at this blogpost: https://weberblog.net/signing-a-delegated-subdomain/
Those DS records will be signed with RRSIGs by the parent zone. Of course only if you’re signing your parent zone at all. ;)
Ciao,
Johannes
Hi Johannes, I am implementing Bind9 with DNSSEC in a local environment with an authoritative server on the “lan” domain.
The Bind version is 9.11, I can’t get the “lan” zone to be validated. which is my local area. I have tried to add trsted-keys but it does not validate (bit ad).
I don’t find anything clear how to do the validation locally, this is the output of delv
; fetch: dns01.lan/A
;; validating dns01.lan/A: starting
;; validating dns01.lan/A: attempting positive response validation
;; fetch:lan/DNSKEY
;; validating lan/DNSKEY: starting
;; validating lan/DNSKEY: attempting positive response validation
;; fetch: lan/DS
;; chase DS servers resolving ‘lan/DS/IN’: 192.168.33.100#53
;; fetch: ./NS
;; REFUSED unexpected RCODE resolving ‘./NS/IN’: 192.168.33.100#53
;; validating lan/DNSKEY: in dsfetched
;; validating lan/DNSKEY: falling back to insecurity proof (SERVFAIL)
;; validating lan/DNSKEY: checking existence of DS at ‘lan’
;; fetch: lan/DS
;; chase DS servers resolving ‘lan/DS/IN’: 192.168.33.100#53
;; fetch: ./NS
;; REFUSED unexpected RCODE resolving ‘./NS/IN’: 192.168.33.100#53
;; validating lan/DNSKEY: in dsfetched2: SERVFAIL
;; no valid DS resolving ‘lan/DNSKEY/IN’: 192.168.33.100#53
;; validating dns01.lan/A: in fetch_callback_validator
;; validating dns01.lan/A: fetch_callback_validator: got SERVFAIL
;; broken trust chain resolving ‘dns01.lan/A/IN’: 192.168.33.100#53
;; resolution failed: broken trust chain
Hey Eduardo,
one question, just to be sure: You’re NOT asking the authoritative server directly, don’t you?
If you’re querying the authoritative directly, you’ll get the “aa” flag but NEVER the “ad” flag. You’ll only see that “ad” flag if you’re querying a recursive DNS server that does the DNSSEC validation.
Cheers
Johannes