DNSSEC resolving problem with .pl domains

s.beimer · December 14, 2022, 6:49pm

I run a pi-hole on rasperry pi. Path is: client -> pi-hole -> openwrt dnsmasq -> openwrt unbound -> ...

I expierence that midov.pl give SERVFAIL/BOGUS on the pi-hole. If I resove directly on the openwrt dnsmasq or openwrt unbound, everything works as expected.

Expected Behaviour:

[resolving midov.pl shall work without error]

Actual Behaviour:

[midov.pl resolves as BOGUS]

pi-hole is 192.168.40.2

sb@pcsb:~$ dig +dnssec midov.pl @192.168.41.1

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> +dnssec midov.pl @192.168.41.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25857
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;midov.pl.			IN	A

;; ANSWER SECTION:
midov.pl.		70171	IN	A	37.247.57.95

;; Query time: 0 msec
;; SERVER: 192.168.41.1#53(192.168.41.1) (UDP)
;; WHEN: Wed Dec 14 19:43:39 CET 2022
;; MSG SIZE  rcvd: 53

sb@pcsb:~$ dig +dnssec midov.pl @192.168.40.2

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> +dnssec midov.pl @192.168.40.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 52109
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;midov.pl.			IN	A

;; Query time: 8 msec
;; SERVER: 192.168.40.2#53(192.168.40.2) (UDP)
;; WHEN: Wed Dec 14 19:43:47 CET 2022
;; MSG SIZE  rcvd: 37

sb@pcsb:~$ dig +dnssec www.heise.de @192.168.40.2

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> +dnssec www.heise.de @192.168.40.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35111
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.heise.de.			IN	A

;; ANSWER SECTION:
www.heise.de.		1536	IN	A	193.99.144.85

;; Query time: 4 msec
;; SERVER: 192.168.40.2#53(192.168.40.2) (UDP)
;; WHEN: Wed Dec 14 19:51:15 CET 2022
;; MSG SIZE  rcvd: 57

Looking in my 7 days querey log, it seems as if all .pl domains have a problem.

Bucking_Horn · December 14, 2022, 9:07pm

Your dig is forcing DNSSEC validation.
Is your Pi-hole configured for DNS validation?
Does that domain resolve correctly when not validating/with DNSSEC disabled?

I have no issues resolving and validating midov.pl via unbound directly from my Pi-hole, regardless whether DNSSEC support is enabled or disabled.

Your issue may be related to DNSSEC support on your openwrt/dnsmasq.

You could try to rule that out by pointing your Pi-hole to use your openwrt/unbound, but you may have to adopt your unbound's configuration to accept your Pi-hole's requests for that to work.

s.beimer · December 15, 2022, 8:28am

Hi
thanks for the answer.
Yes, the unbound and the pi-hole having dnssec validation enabled.

As said, my dns resolvers are in line -> pi-hole (192.168.40.2) -> OpenWrt dnsmasq (192.168.4x.1) -> OpenWrt unbound (127.0.0.1:5053, qname minimization) -> ...

dnssec validation works well, except for midov.pl and onet.pl. Other in .pl are correct and listed as either insecure or secure, but not bogus. Only midov.pl and onet.pl are listed bogus by pi-hole. But both are resolved correctly by Openwrt unbound.

I don't have a clue what is causing this. Restarting (clearing cache) didn't help either.

DL6ER · December 15, 2022, 8:39am

Just as @Bucking_Horn, I've been able to resolve both domains just fine using my Pi-hole + local unbouond running at localhost#5335

Could you please provide the relevant lines from /var/log/pihole/pihole.log?

s.beimer · December 15, 2022, 8:53am

[✓] Your debug token is: https://tricorder.pi-hole.net/5DAGXLIh/
But query log is disabled. Will enable it.

Dec 15 09:58:37 dnsmasq[31344]: query[A] midov.pl from 192.168.41.108
Dec 15 09:58:37 dnsmasq[31344]: forwarded midov.pl to 192.168.40.1
Dec 15 09:58:37 dnsmasq[31344]: dnssec-query[DS] pl to 192.168.40.1
Dec 15 09:58:37 dnsmasq[31344]: reply pl is DS keytag 38491, algo 8, digest 2
Dec 15 09:58:37 dnsmasq[31344]: reply pl is DS keytag 59899, algo 8, digest 2
Dec 15 09:58:37 dnsmasq[31344]: dnssec-query[DS] midov.pl to 192.168.40.1
Dec 15 09:58:37 dnsmasq[31344]: dnssec-query[DNSKEY] pl to 192.168.40.1
Dec 15 09:58:37 dnsmasq[31344]: validation midov.pl is BOGUS
Dec 15 09:58:37 dnsmasq[31344]: reply midov.pl is 37.247.57.95

sb@pcsb:~$ dig +dnssec midov.pl DS @192.168.40.2

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> +dnssec midov.pl DS @192.168.40.2
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4935
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;midov.pl.			IN	DS

;; Query time: 24 msec
;; SERVER: 192.168.40.2#53(192.168.40.2) (UDP)
;; WHEN: Thu Dec 15 10:01:07 CET 2022
;; MSG SIZE  rcvd: 37

Dec 15 10:01:06 dnsmasq[31344]: query[DS] midov.pl from 192.168.41.108
Dec 15 10:01:07 dnsmasq[31344]: forwarded midov.pl to 192.168.40.1
Dec 15 10:01:07 dnsmasq[31344]: dnssec-query[DNSKEY] pl to 192.168.40.1
Dec 15 10:01:07 dnsmasq[31344]: validation midov.pl is BOGUS
Dec 15 10:01:07 dnsmasq[31344]: reply midov.pl is NODATA

DL6ER · December 15, 2022, 2:22pm

Hmm, interesting, compare this to the logs on my Pi-hole:

Normal query

Dec 15 15:18:29 dnsmasq[2279871]: query[A] midov.pl from 127.0.0.1
Dec 15 15:18:29 dnsmasq[2279871]: forwarded midov.pl to 127.0.0.1#5335
Dec 15 15:18:29 dnsmasq[2279871]: dnssec-query[DS] pl to 127.0.0.1#5335
Dec 15 15:18:29 dnsmasq[2279871]: reply pl is DS keytag 38491, algo 8, digest 2
Dec 15 15:18:29 dnsmasq[2279871]: reply pl is DS keytag 59899, algo 8, digest 2
Dec 15 15:18:29 dnsmasq[2279871]: dnssec-query[DS] midov.pl to 127.0.0.1#5335
Dec 15 15:18:30 dnsmasq[2279871]: dnssec-query[DNSKEY] pl to 127.0.0.1#5335
Dec 15 15:18:30 dnsmasq[2279871]: reply pl is DNSKEY keytag 22188, algo 8
Dec 15 15:18:30 dnsmasq[2279871]: reply pl is DNSKEY keytag 31164, algo 8
Dec 15 15:18:30 dnsmasq[2279871]: reply pl is DNSKEY keytag 59899, algo 8
Dec 15 15:18:30 dnsmasq[2279871]: reply pl is DNSKEY keytag 38491, algo 8
Dec 15 15:18:30 dnsmasq[2279871]: reply midov.pl is no DS
Dec 15 15:18:30 dnsmasq[2279871]: validation result is INSECURE
Dec 15 15:18:30 dnsmasq[2279871]: reply midov.pl is 37.247.57.95

cleared cache

And now explicitly asking for DS:

$ dig +dnssec midov.pl DS @127.0.0.1

; <<>> DiG 9.18.1-1ubuntu1.2-Ubuntu <<>> +dnssec midov.pl DS @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17216
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;midov.pl.			IN	DS

;; AUTHORITY SECTION:
pl.			3527	IN	SOA	a-dns.pl. dnsmaster.nask.pl. 1671105630 900 300 2592000 3600
pl.			3527	IN	RRSIG	SOA 8 1 86400 20230114141003 20221215131003 22188 pl. Kz6fXFgo2agOXrldmQvZS5wpkm6UPFPQPXcuLCIB34dwLuIWD13hYIge /N02vdMh/p8Sgz1LDX7EWloUsXRtFcXfvjoZFdsjZl27spHZS3oGOuLZ 1FbgijC0XUx41zpFgLMkeXNHAhhSmTf5lWoagYozGCKj7XetKGWYBdSq gDxzZoUXL+nWRaubFWTr2K/W/BCpxv57Rf+FKZh4Vq38kJa+xw8L4Sfg /iyTAZGvceRG6spAdyw/h+P4A9dKS7LTSobUwEt9Um3fqB5S5oWmVL8u BmTGC2BPOZg6V+G9y1Pg4e67Eqtok0CpbtNnJ4kLBOMcqsSSWkfy6sP+ Baq0Kw==
HJH3QODF72BCSOSF30PAIV5CFNE30109.pl. 3527 IN NSEC3 1 1 12 072E695EC656851B HJHATK9QD0Q281BOKJ6H4UQN8M301A2H NS SOA TXT RRSIG DNSKEY NSEC3PARAM
HJH3QODF72BCSOSF30PAIV5CFNE30109.pl. 3527 IN RRSIG NSEC3 8 2 3600 20230110120000 20221211120000 22188 pl. Gyb91LIcM8g/CkvwBmF8tiunu5PS/jLlfgX1ibV5w2rBlZq5MXNDPsOr fQM4hR+65EMPow5ukfNUQn6h1hrT1hIW9akMeD/2wo9dvUdyORban5jf oxOD8D+7h8hhd+sq0PjecxetVqOAsr9cBO5UvJ29K7GmJnNcyyofxERo 90OrDl4CB+NOdNloniLvwfop7SGlGVK+VDck20sOZjlHQfSGj0HAhWE5 pCOTOMnuQCloCyQ89WWEyx/rVxc8Wgf+aV8y56zigSq22jFNxH4cdIk0 XB7XwsBleniM7dkD+tbt1XZGGr3VVAylXsh302C6xnpTNvcACleOvuHo dbdouA==
EJSSG2FFSIRDL0F0I65I0POD2MQ1TBHM.pl. 3527 IN NSEC3 1 1 12 072E695EC656851B EJT0N52KGBQCEH93D7B6GCLB7288F4DT NS DS RRSIG
EJSSG2FFSIRDL0F0I65I0POD2MQ1TBHM.pl. 3527 IN RRSIG NSEC3 8 2 3600 20230110120000 20221211120000 22188 pl. GSDZ97ckltARNZkBzfLJsy6vJtWncvuo4oa/2ys/mIWRsT1kESnnpiml 4oumpO73ECzzlFocnLao2abvnBrd/LnnNyB0ghYRTw8jdHdlcGEWXQFa oVfPFqnh8wdmhU8yUzQErqnQRSFZ0zLVagoSyH83DS3wUVHGsva7XvUs 4kYljKTX+3dLkFbm7lh7lSRqVq4JZpjXXoonAXXFQc9RcsbNjJMzmYE8 3wThZ9DuMXMzdVsMZn7VTzkSvYtU7zOlngpN6AZy04h87KWd5Cn4h78R OQcOvx6BB2nbHKb1l7oGRs0qcdh3/5CkgIPBSOpHmPFG9ZTm3RBXScFm eTMCGQ==

;; Query time: 4 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Dec 15 15:19:43 CET 2022
;; MSG SIZE  rcvd: 1139

Related log lines:

Dec 15 15:20:39 dnsmasq[2280085]: query[DS] midov.pl from 127.0.0.1
Dec 15 15:20:39 dnsmasq[2280085]: forwarded midov.pl to 127.0.0.1#5335
Dec 15 15:20:39 dnsmasq[2280085]: dnssec-query[DS] pl to 127.0.0.1#5335
Dec 15 15:20:39 dnsmasq[2280085]: reply pl is DS keytag 38491, algo 8, digest 2
Dec 15 15:20:39 dnsmasq[2280085]: reply pl is DS keytag 59899, algo 8, digest 2
Dec 15 15:20:39 dnsmasq[2280085]: dnssec-query[DNSKEY] pl to 127.0.0.1#5335
Dec 15 15:20:39 dnsmasq[2280085]: reply pl is DNSKEY keytag 38491, algo 8
Dec 15 15:20:39 dnsmasq[2280085]: reply pl is DNSKEY keytag 22188, algo 8
Dec 15 15:20:39 dnsmasq[2280085]: reply pl is DNSKEY keytag 31164, algo 8
Dec 15 15:20:39 dnsmasq[2280085]: reply pl is DNSKEY keytag 59899, algo 8
Dec 15 15:20:39 dnsmasq[2280085]: validation result is SECURE
Dec 15 15:20:39 dnsmasq[2280085]: reply midov.pl is NODATA

As your are getting the BOGUS reply apparently as a result of whatever the reply to the dnssec-query[DNSKEY] pl returned is, I'd like to ask you trying to point your Pi-hole directly to your unbound for testing purposes (so skip the detour over the openwrt dnsmasq for now).

The next step would be to create a network packet recording for an in-depth analysis. As this is always considerable amounts of work, it'd be good it we find the answer using other means.

s.beimer · December 15, 2022, 3:16pm

This is indeed interessting.

Setting the pi-hole to directly query the unbound, bypassing the dnsmasq on OpenWrt, gives the correct result:

Dec 15 16:13:20 dnsmasq[3106]: query[A] midov.pl from 192.168.41.108
Dec 15 16:13:20 dnsmasq[3106]: forwarded midov.pl to 192.168.40.1#5053
Dec 15 16:13:20 dnsmasq[3106]: dnssec-query[DS] pl to 192.168.40.1#5053
Dec 15 16:13:20 dnsmasq[3106]: reply pl is DS keytag 38491, algo 8, digest 2
Dec 15 16:13:20 dnsmasq[3106]: reply pl is DS keytag 59899, algo 8, digest 2
Dec 15 16:13:20 dnsmasq[3106]: dnssec-query[DS] midov.pl to 192.168.40.1#5053
Dec 15 16:13:20 dnsmasq[3106]: dnssec-query[DNSKEY] pl to 192.168.40.1#5053
Dec 15 16:13:20 dnsmasq[3106]: reply pl is DNSKEY keytag 38491, algo 8
Dec 15 16:13:20 dnsmasq[3106]: reply pl is DNSKEY keytag 22188, algo 8
Dec 15 16:13:20 dnsmasq[3106]: reply pl is DNSKEY keytag 31164, algo 8
Dec 15 16:13:20 dnsmasq[3106]: reply pl is DNSKEY keytag 59899, algo 8
Dec 15 16:13:20 dnsmasq[3106]: reply midov.pl is no DS
Dec 15 16:13:20 dnsmasq[3106]: validation result is INSECURE
Dec 15 16:13:20 dnsmasq[3106]: reply midov.pl is 37.247.57.95

I don't find any suspicious setting in Openwrt's dnsmasq config.

This is logging on Openwrt for querying midov.pl directly:

Thu Dec 15 16:27:05 2022 daemon.info dnsmasq[1]: 101 192.168.41.108/43667 query[A] midov.pl from 192.168.41.108
Thu Dec 15 16:27:05 2022 daemon.info dnsmasq[1]: 101 192.168.41.108/43667 forwarded midov.pl to 127.0.0.1
Thu Dec 15 16:27:05 2022 daemon.info dnsmasq[1]: 101 192.168.41.108/43667 forwarded midov.pl to ::1
Thu Dec 15 16:27:05 2022 daemon.info dnsmasq[1]: 101 192.168.41.108/43667 reply midov.pl is 37.247.57.95

And this is logging of midov.pl queried through my pi-hole:

Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 139 192.168.40.2/50190 query[A] midov.pl from 192.168.40.2
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 139 192.168.40.2/50190 forwarded midov.pl to 127.0.0.1
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 139 192.168.40.2/50190 reply midov.pl is 37.247.57.95
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 140 192.168.40.2/50358 query[DS] pl from 192.168.40.2
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 140 192.168.40.2/50358 forwarded pl to 127.0.0.1
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 140 192.168.40.2/50358 reply pl is <DS>
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 140 192.168.40.2/50358 reply pl is <DS>
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 140 192.168.40.2/50358 reply pl is <RRSIG>
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 141 192.168.40.2/60094 query[DS] midov.pl from 192.168.40.2
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 141 192.168.40.2/60094 forwarded midov.pl to 127.0.0.1
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 141 192.168.40.2/60094 reply midov.pl is NODATA
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 142 192.168.40.2/59449 query[DNSKEY] pl from 192.168.40.2
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 142 192.168.40.2/59449 forwarded pl to 127.0.0.1
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 142 192.168.40.2/59449 reply pl is <DNSKEY>
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 142 192.168.40.2/59449 reply pl is <DNSKEY>
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 142 192.168.40.2/59449 reply pl is <DNSKEY>
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 142 192.168.40.2/59449 reply pl is <DNSKEY>
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 142 192.168.40.2/59449 reply pl is <RRSIG>
Thu Dec 15 16:29:27 2022 daemon.info dnsmasq[1]: 142 192.168.40.2/59449 reply pl is <RRSIG>

with this the logging on the pi-hole itself:

Dec 15 16:29:26 dnsmasq[742]: query[A] midov.pl from 192.168.41.108
Dec 15 16:29:27 dnsmasq[742]: forwarded midov.pl to 192.168.40.1
Dec 15 16:29:27 dnsmasq[742]: dnssec-query[DS] midov.pl to 192.168.40.1
Dec 15 16:29:27 dnsmasq[742]: validation midov.pl is BOGUS
Dec 15 16:29:27 dnsmasq[742]: reply midov.pl is 37.247.57.95

s.beimer · December 15, 2022, 3:40pm

Looking on dnsviz for midov.pl I see that there are two setups side by side. It's also showing in the log that I get two RRSIG. May there be any problem by maybe fetching the wrong RRSIG under what? circumstances?

DL6ER · December 15, 2022, 4:21pm

Can you quote the config you have? Also, can you tell us what version is used by openwrt? At (the very) least, we know now that this is not a Pi-hole bug but something else. Everything seems to point towards that the openwrt's dnsmasq is providing incorrect/incomplete answers.

You should simply always get both. DNSSEC is a delicate thing by construction. If anything breaks, this could also be someone doing something malicious so it's correct to reject the entire query.

The next steps seems to be

so please follow what is already described here

and provide the pcap file afterwards. If openwrt's dnsmasq is recent enough, you can do the same on the router which would make it a lot easier to compare. The recordings will then contain

What is sent FROM your client to your Pi-hole
What is sent FROM your Pi-hole to your openwrt dnsmasq
(optionally) what is sent FROM your openwrt dnsmasq to your openwrt unbound
(optionally) what is received BY your openwrt dnsmasq from your openwrt unbound
What is received BY your Pi-hole from your openwrt dnsmasq
What is received BY your client from your Pi-hole

We expect something broken in step 5 above so I'd be quite helpful to also have no. 4

s.beimer · December 15, 2022, 4:31pm

I see if I can get this done tomorrow.

But I'm still wondering what the cause might be. I have a Friendica, a Synapse and a postfix server running all using the pi-hole in this setup for long time without any problems. There are a lot of queries. Now this problem occured with so far only two pl domains, everything else is working fine.
Thinking about it it started roughly the same time I updated the unbound on the Openwrt router. (22.03.2) I'll give it a try to reinstall the image without the updates and see if this helps.

s.beimer · December 16, 2022, 2:54pm

It's getting weird now ... since this morning the resolving has no errors. Nothing has changed in the meantime, no reboots, no updates ... only snowfall during the night.
I'll keep an eye on it (but I believe as long as it works properly we'll likely won't find any explanation).

chrislph · December 16, 2022, 3:25pm

Domains Needed Some Snow Enabled Communication

s.beimer · December 17, 2022, 7:01pm

OK, it is now happening again.
I also found a few mysterious entries in pi-hole where querying an AAAA record is listed multiple times with always NODATA as result, but every second line either INSECURE or SECURE.
I would argue that there is some cache problem. I need to find screenshots and log output tomorrow.

s.beimer · December 18, 2022, 8:22am

I will now blame .pl for all of this ... even though it might also be a problem in the chain of my dns resolvers but as

it is only .pl domains and
everything else (and for other domains) works fine

having a look on dnsviz.net for midov.pl I see a number of changes starting 2022-12-08.

This is 2022-08-28:

This is a picture on onet.pl from 2022-12-08

and now

I assume the changes together with caching is causing my troubles.

s.beimer · December 18, 2022, 7:12pm

I still believe it is a problem at pl. look at this:

$ drill -k root.key -S pl @192.168.40.1
;; Number of trusted keys: 1
;; Chasing: pl. A


DNSSEC Trust tree:
pl. (A)
|---Existence is denied by:
|---HJH3QODF72BCSOSF30PAIV5CFNE30109.pl. (NSEC3)
No trusted keys found in tree: first error was: No DNSSEC public key(s)
;; Chase failed.

compared to this

drill -k root.key -S de @192.168.40.1
;; Number of trusted keys: 1
;; Chasing: de. A


DNSSEC Trust tree:
de. (A)
|---Existence is denied by:
|---tjlb7qbojvmlf1s6gdriru7vsms1lg16.de. (NSEC3)
    |---de. (DNSKEY keytag: 44298 alg: 8 flags: 256)
        |---de. (DNSKEY keytag: 26755 alg: 8 flags: 257)
        |---de. (DS keytag: 26755 digest type: 2)
            |---. (DNSKEY keytag: 18733 alg: 8 flags: 256)
                |---. (DNSKEY keytag: 20326 alg: 8 flags: 257)
;; Chase successful

drill -k root.key -D midov.pl A @192.168.40.1 -p 5053
;; Number of trusted keys: 1
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 39557
;; flags: qr rd ra ; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 
;; QUESTION SECTION:
;; midov.pl.	IN	A

;; ANSWER SECTION:
midov.pl.	28865	IN	A	37.247.57.95

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 0 msec
;; EDNS: version 0; flags: do ; udp: 1232
;; SERVER: 192.168.40.1
;; WHEN: Sun Dec 18 21:27:59 2022
;; MSG SIZE  rcvd: 53
; midov.pl.	28865	IN	A	37.247.57.95
Bad data; RR for name and type not found or failed to verify, and denial of existence failed.

s.beimer · December 21, 2022, 11:11am

It's absolutely interessting to see what is going on in pl.

DanSchaper · December 21, 2022, 6:37pm

It is incredibly easy to completely hose yourself and your domains with DNSSEC. I'd say that is the major blocking point that keeps it from being used generally.

s.beimer · December 24, 2022, 5:13pm

Seems as if this is now set up correctly in pl. No more bogus checks within the last days and no changes in dnssec setup in pl.

system · January 14, 2023, 5:14pm

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.