Omnia cannot resolve auth.app.wiz.io with DNSSEC

Software SW bugs discussion
, ,
1

Hi,
it seems my omnia cannot resolve the domain auth.app.wiz.io with DNSSEC enabled. It doesn’t matter which forwarder I use (I regularly use the cz.nic forwarder but I have tried the others too). Online dnssec validators/resolvers are fine (except it is a cname pointing to an unsecured domain) with it so I suspect it is some kind of kresd issue.

This happens when I try to resolve it from omnia:

root@omnia:~# dig auth.app.wiz.io

; <<>> DiG 9.18.24 <<>> auth.app.wiz.io
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 59239
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; EDE: 0 (Other): (OGHD: exceeded iteration count limit)
;; QUESTION SECTION:
;auth.app.wiz.io.		IN	A

;; Query time: 80 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Tue Feb 18 14:53:02 CET 2025
;; MSG SIZE  rcvd: 86

The dns debug log from omnia is here: gist:d431ad4acc189710e2b3c2849ea7ed5d · GitHub

Any idea what could be wrong?

2

@vcunat Could you take a look?

3

They are serving inconsistent DNSSEC records. Snippets from your log:

Feb 18 13:14:26 omnia kresd[10300]: app.wiz.io.         	300	DS	62788 13 2 49617F9A01B6DC10155BEEBFAEF6B83AF5A21B64A90111F713F44ED5C2396015
Feb 18 13:14:26 omnia kresd[10300]: app.wiz.io.         	300	RRSIG	DS 13 3 300 20250218141926 20250218121426 60330 wiz.io. YcfGY+6EuyQjInyqIM4OYtZIBA+3mqFdl1fKJkWpyk8/eC46fZ5Azs7XR/ZBsWGeoGq0yhl83AHmy7oEpQQKpQ==

so a DS record gets presented on the name but apparently they do not want a zone cut in there, so the validator is unable to extend the DNSSEC trust chain below that point:

Feb 18 13:14:26 omnia kresd[10300]: app.wiz.io.         	86400	NSEC	\000.app.wiz.io. A PTR HINFO MX TXT RP AAAA SRV NAPTR SSHFP RRSIG NSEC TLSA SVCB HTTPS SPF CAA
Feb 18 13:14:26 omnia kresd[10300]: app.wiz.io.         	86400	RRSIG	NSEC 13 3 86400 20250219141426 20250218121426 60330 wiz.io. 0ILVf+TZ+mqdg4Oc7qwHKPvoMRRWTCHFz21/Aa8UdIFljQ77u7+b0sPH5ny5JZuJ1heBqN0rrzNkGKqMd5u+Hw==

(BTW, this record denies existence of the previously sent record, too.)

While in my testing the validator did not get into this “loop” and it just resolved, honestly I don’t really care if it fails after getting sent this kind of mess. I’m sorry. I’d spend most of my time working around similar nonsense.

I expect this particular situation would be also avoided if you configured without any forwarding.

1 Like
4

Alright, thank you for checking! I will try to get in touch with them.

1 Like