DNSSEC problem with our zone

Mirsad Goran Todorovac mirsad.todorovac at alu.unizg.hr
Wed May 18 21:10:59 UTC 2022


Dear All,

In the past three days I have just made our domain DNSSEC signed. 
However, I seem to be missing something.

When I query other DNS servers, like CloudFlare 1.0.0.1, I get the "ad" 
flag.

But in my own domain, and my own domain servers, the "ad" flag is still 
missing:

root at domac:/var/cache/bind# dig -u @161.53.235.3 domac.alu.hr a +dnssec 
+multiline

; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> -u @161.53.235.3 
domac.alu.hr a +dnssec +multiline
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5934
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 172503ebbe7de24201000000628512077e46d89b4369e3dd (good)
;; QUESTION SECTION:
;domac.alu.hr.          IN A

;; ANSWER SECTION:
domac.alu.hr.           86400 IN A 161.53.235.3
domac.alu.hr.           86400 IN RRSIG A 8 3 86400 (
                                 20220615102400 20220516102400 46119 alu.hr.
tHS58DiuHm0BTCbpyR7k9G9YRtl0iG03Sl5YBK55tBQF
MqR5Bdk9t0Gz8HTFvqYd2kO7jHVRP5hBsMpETXo1PTWa
FYq5WAd4NW+qNJg2giVp04ZC0agS+rPaCQZgeUXuneUk
5wle1qc5GF+R3E8rheTioWPJLw+L2V/n39LYOlQ= )

;; Query time: 189 usec
;; SERVER: 161.53.235.3#53(161.53.235.3)
;; WHEN: Wed May 18 17:34:31 CEST 2022
;; MSG SIZE  rcvd: 251

root at domac:/var/cache/bind#

Can you please help?

Thank you very much.

Kind regards,
Mirsad

On 5/18/2022 4:14 PM, Mirsad Goran Todorovac wrote:
>
> Dear Sir or Madam,
>
> According to this article: 
> https://www.cloudflare.com/dns/dnssec/how-dnssec-works/ ,
> I did everything right by following the APNIC article for manual 
> signing procedure. And uploaded
> DS record made of zone KSK hash to the parent domain's 
> registrar.carnet.hr :
>
> root at domac:/etc/bind/keys# dig @localhost dnskey alu.hr | 
> dnssec-dsfromkey -f - alu.hr
> alu.hr. IN DS 34042 8 2 
> FD6D9A51ABB63FFDF8B2205AA8529D32CB1121D8342D5929481567D5885BBF08
> root at domac:/etc/bind/keys# host -t ds alu.hr
> alu.hr has DS record 34042 8 2 
> FD6D9A51ABB63FFDF8B2205AA8529D32CB1121D8342D5929481567D5 885BBF08
> root at domac:/etc/bind/keys#
>
> The BIND version we use is 9.16.27, latest backport on Debian buster:
>
> root at domac:/etc/bind/keys# dpkg -l | grep bind9 | grep 9.16
> ii  bind9 1:9.16.27-1~deb11u1~bpo10+1 amd64        Internet Domain 
> Name Server
> ii  bind9-libs:amd64 1:9.16.27-1~deb11u1~bpo10+1 amd64        Shared 
> Libraries used by BIND 9
> ii  bind9-utils 1:9.16.27-1~deb11u1~bpo10+1 amd64        Utilities for 
> BIND 9
> ii  bind9utils 1:9.16.27-1~deb11u1~bpo10+1 all          Transitional 
> package for bind9-utils
>
> However, for some reason the validation doesn't give me the "ad" 
> authenticated data flag in dig queries.
>
> There must be something I'm missing.
>
> I would be grateful for any help.
>
> P.S.
>
> I withdraw my question. Now it automagically started working (the "ad" 
> flag appeared):
>
> root at magrf:~# dig @127.0.0.1 domac.alu.hr +dnssec +multiline
>
> ; <<>> DiG 9.16.27-Debian <<>> @127.0.0.1 domac.alu.hr +dnssec +multiline
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55024
> ;; flags: qr rd ra *ad*; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags: do; udp: 1232
> ; COOKIE: ac834aa33f88f006010000006284fdf6c5738a0b6f9bde2b (good)
> ;; QUESTION SECTION:
> ;domac.alu.hr.          IN A
>
> ;; ANSWER SECTION:
> domac.alu.hr.           86400 IN A 161.53.235.3
> domac.alu.hr.           86400 IN RRSIG A 8 3 86400 (
>                                 20220615102400 20220516102400 46119 
> alu.hr.
> tHS58DiuHm0BTCbpyR7k9G9YRtl0iG03Sl5YBK55tBQF
> MqR5Bdk9t0Gz8HTFvqYd2kO7jHVRP5hBsMpETXo1PTWa
> FYq5WAd4NW+qNJg2giVp04ZC0agS+rPaCQZgeUXuneUk
> 5wle1qc5GF+R3E8rheTioWPJLw+L2V/n39LYOlQ= )
>
> ;; Query time: 39 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed May 18 16:08:54 CEST 2022
> ;; MSG SIZE  rcvd: 251
>
> root at magrf:~#
>
> Thank you for any help. At least I was motivated to do more homework.
> I believe there is a future for DNSSEC, much like nowadays we do not 
> have too many
> legacy sites that request password without HTTPS. I guess now our 
> domain won't be
> easily spoofed :-)
>
> The next step is to make the subzone delegation and automatic DS 
> record upload to
> the main zone, for maintaining half a dozen of DS delegations might 
> become infeasible
> if the KSK expires every couple of months :-/
>
> Thank you for your time reading this. You are patient if you came this 
> far.
>
> Kind regards,
> Mirsad Todorovac
>
> On 5/18/2022 11:52 AM, Mirsad Goran Todorovac wrote:
>>
>> Dear Sir or Madam,
>>
>> I have tried to implement an instance of DNSSEC signed DNS zone at 
>> our Academy's server.
>>
>> Though we apparently got away without anything catastrophic, the 
>> DNSSEC apparently doesn't
>> work, despite doing everything like in the tutorial:
>>
>> https://blog.apnic.net/2019/05/23/how-to-deploying-dnssec-with-bind-and-ubuntu-server/
>>
>> I recall getting help here with dynamic ISC DHCP-updated reverse zone 
>> lookup for sub/24 rev zone.
>> And it is a gift that keeps on giving :)
>>
>> Now, to provide as much info as possible, the output of
>> # dig @efk.alu.hr alu.hr. AXFR +multiline +onesoa
>> is attached.
>>
>> root at domac:~# host -t ds alu.hr
>> alu.hr has DS record 34042 8 2 
>> FD6D9A51ABB63FFDF8B2205AA8529D32CB1121D8342D5929481567D5 885BBF08
>> root at domac:~#
>>
>> DS record came as the result of the command from the tutorial:
>>
>> # dig @localhost dnskey alu.hr | dnssec-dsfromkey -f - alu.hr
>> alu.hr. IN DS 34042 8 2 
>> FD6D9A51ABB63FFDF8B2205AA8529D32CB1121D8342D5929481567D5885BBF08
>>
>> I am doing the reading of the documentation on kb.isc.org and 
>> elsewhere, but it would be good to have some
>> immediate result as well, at least to make the static zones running 
>> signed.
>>
>> Step two would be the dynamically updated zone.
>>
>> I am otherwise thrilled how much better BIND9 is when compared to the 
>> Windows Server 2016 DNS server.
>>
>> Though, so many features look as well a bit scary, for it is trivial 
>> to shoot oneself in his own leg ...
>>
>> Please, any help would be welcome.
>>
>> Apparently, the record in DS iz the KSK key 34042, while in other 
>> records like domac.alu.hr, they are referenced
>> with the ZSK key 46119. Is that normal?
>>
>> From RFC 3658, https://datatracker.ietf.org/doc/html/rfc3658#section-2.1
>>
>>     Even though DS identifies two roles for KEYs, Key Signing Key (KSK)
>>     and Zone Signing Key (ZSK), there is no requirement that zone uses
>>     two different keys for these roles.  It is expected that many small
>>     zones will only use one key, while larger zones will be more likely
>>     to use multiple keys.
>>
>> It is not quite clear to me what went wrong. I am completely new to DNSSEC, despite it being
>> around since about 1999 or 2006.
>>
>> The output of dig command doesn't show the "ad" (authenticated data) flag:
>>
>> root at domac:/etc/bind/keys# dig @127.0.0.1 domac.alu.hr +dnssec +multiline
>>
>> ; <<>> DiG 9.11.5-P4-5.1+deb10u7-Debian <<>> @127.0.0.1 domac.alu.hr +dnssec +multiline
>> ; (1 server found)
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 239
>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags: do; udp: 1232
>> ; COOKIE: c4a4792d65d3fbb7010000006284c0b0bd75890e0cf18dca (good)
>> ;; QUESTION SECTION:
>> ;domac.alu.hr.          IN A
>>
>> ;; ANSWER SECTION:
>> domac.alu.hr.           86400 IN A 161.53.235.3
>> domac.alu.hr.           86400 IN RRSIG A 8 3 86400 (
>>                                  20220615102400 20220516102400 46119 alu.hr.
>>                                  tHS58DiuHm0BTCbpyR7k9G9YRtl0iG03Sl5YBK55tBQF
>>                                  MqR5Bdk9t0Gz8HTFvqYd2kO7jHVRP5hBsMpETXo1PTWa
>>                                  FYq5WAd4NW+qNJg2giVp04ZC0agS+rPaCQZgeUXuneUk
>>                                  5wle1qc5GF+R3E8rheTioWPJLw+L2V/n39LYOlQ= )
>>
>> ;; Query time: 0 msec
>> ;; SERVER: 127.0.0.1#53(127.0.0.1)
>> ;; WHEN: Wed May 18 11:47:28 CEST 2022
>> ;; MSG SIZE  rcvd: 251
>>
>> root at domac:/etc/bind/keys#
>>
>> Thank you very much for your help.
>> I have now received the confirmation that it wasn't DNSSEC that caused yesterday's outage
>> and that it only only on a couple of blocked accounts, so I am enthusiastic to make this
>> work.
>>
>> Eventually, I would migrate to BIND9.16 automatically signed zones and rollout of keys,
>> once the basic stuff starts to work.
>>
>> Best regards,
>> Mirsad Todorovac
>> -- 
>> Mirsad Goran Todorovac
>> CARNet sistem inženjer
>> Grafički fakultet | Akademija likovnih umjetnosti
>> Sveučilište u Zagrebu
>> --
>> CARNet system engineer
>> Faculty of Graphic Arts | Academy of Fine Arts
>> University of Zagreb, Republic of Croatia
>> tel. +385 (0)1 3711 451
>> mob. +385 91 57 88 355
> -- 
> Mirsad Goran Todorovac
> CARNet sistem inženjer
> Grafički fakultet | Akademija likovnih umjetnosti
> Sveučilište u Zagrebu
> --
> CARNet system engineer
> Faculty of Graphic Arts | Academy of Fine Arts
> University of Zagreb, Republic of Croatia
> tel. +385 (0)1 3711 451
> mob. +385 91 57 88 355

-- 
Mirsad Goran Todorovac
CARNet sistem inženjer
Grafički fakultet | Akademija likovnih umjetnosti
Sveučilište u Zagrebu
--
CARNet system engineer
Faculty of Graphic Arts | Academy of Fine Arts
University of Zagreb, Republic of Croatia
tel. +385 (0)1 3711 451
mob. +385 91 57 88 355
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20220518/80cfdc43/attachment-0001.htm>


More information about the bind-users mailing list