Kresd resolver bug?

Hi,

I’m having trouble resolving the divelog.blue domain. When I try to query the default Turris Omnia DNS resolver (kresd), I get a SERVFAIL error:

# dig @localhost divelog.blue

; <<>> DiG 9.9.8-P4 <<>> @localhost divelog.blue
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49036
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;divelog.blue.			IN	A

;; Query time: 1398 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 31 21:50:29 CEST 2017
;; MSG SIZE  rcvd: 41

If I query dnsmasq (running on the Turris Omnia on port 5353), the domain is resolved correctly:

# dig -p 5353 @localhost divelog.blue

; <<>> DiG 9.9.8-P4 <<>> -p 5353 @localhost divelog.blue
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64056
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1280
;; QUESTION SECTION:
;divelog.blue.			IN	A

;; ANSWER SECTION:
divelog.blue.		26785	IN	A	81.209.182.12

;; Query time: 0 msec
;; SERVER: 127.0.0.1#5353(127.0.0.1)
;; WHEN: Fri Mar 31 21:50:51 CEST 2017
;; MSG SIZE  rcvd: 57

Same when querying the root servers directly:

# dig +trace @localhost divelog.blue

; <<>> DiG 9.9.8-P4 <<>> +trace @localhost divelog.blue
; (1 server found)
;; global options: +cmd
.			298965	IN	NS	a.root-servers.net.
.			298965	IN	NS	b.root-servers.net.
.			298965	IN	NS	c.root-servers.net.
.			298965	IN	NS	d.root-servers.net.
.			298965	IN	NS	e.root-servers.net.
.			298965	IN	NS	f.root-servers.net.
.			298965	IN	NS	g.root-servers.net.
.			298965	IN	NS	h.root-servers.net.
.			298965	IN	NS	i.root-servers.net.
.			298965	IN	NS	j.root-servers.net.
.			298965	IN	NS	k.root-servers.net.
.			298965	IN	NS	l.root-servers.net.
.			298965	IN	NS	m.root-servers.net.
.			298965	IN	RRSIG	NS 8 0 518400 20170410170000 20170328160000 61045 . NC8yCFd4ktfkPbKIlYraJgt8prPZT8bPY3SRfLkVM/ukX9yAuzr+l2TW NwRkQDnKVzA4sumxd2bFGGzxq5Lu37vFnGL+N1SmueY8cYXkaz3r+1U4 x5tpzKWpZZXiyaab8qGsUCAzMkKLT49iA9kyNglfrDLs0OLt/1EwiN16 yNWRyjIE+zvvdDVMCMMdCtG+Yx/v81rq/xojwLRgW9/a18ZXAQMVhTgW vjCcSGvCpOSDjRtZFvew3fmJE10nUtOzJERscVfuKGkvz2Um8RiJTTs/ kFm34SAqtMP5WEhV2OUXzPIfd3HVq7tRmr1yilfF6u8V9Z/Y4swEsbMc +/upbA==
;; Received 525 bytes from 127.0.0.1#53(localhost) in 0 ms

blue.			172800	IN	NS	a0.nic.blue.
blue.			172800	IN	NS	a2.nic.blue.
blue.			172800	IN	NS	b0.nic.blue.
blue.			172800	IN	NS	c0.nic.blue.
blue.			86400	IN	DS	26950 7 1 A6DE389755ABBAF7B58547B03F0D46E3C210687B
blue.			86400	IN	DS	26950 7 2 AECA57D8557C1F9F486AD18216FAE2DA2E8539E6F157DBF876BA6DF1 FEE1604D
blue.			86400	IN	RRSIG	DS 8 1 86400 20170413170000 20170331160000 61045 . bhoF0R3dKzbdfzLJIZt8gEpp2muQVKFYcwOtX6Hux5d6NLoseJAvWPId UkXyjDP2wW1Xva7fFtOqAQ6hTylBV6ZhHFpOklQES1yz64fdDsksMn9y TfPN0DUK9XyTVOGxFGucGkaPcFCI8zIH8dDITQcU9OWRg1WJPwvx6v9d ezF80PKdjU+/z/BlybGKI9sxTI9JAd4rkkHlIAcv2XfXnHsWPawlI9gO GoZxCxK1jZ8wjutdHMKhEig1wZzi1I9akcMIGIh65n9MN1CHUT3t906m HHXsO/Arq7TDL3142lT6/EOe2F3qpIIJPY/mcAtYNkacxcHCM+5KV1As wAocIw==
;; Received 660 bytes from 192.203.230.10#53(e.root-servers.net) in 14 ms

divelog.blue.		3600	IN	NS	a.ns.bsws.de.
divelog.blue.		3600	IN	NS	c.ns.bsws.de.
divelog.blue.		3600	IN	NS	b.ns.bsws.de.
divelog.blue.		3600	IN	DS	30454 8 2 74E8C1B65F9DDD96A333BCD71E283EF1928106957C3AE414AD29C275 4E1EC1D0
divelog.blue.		3600	IN	RRSIG	DS 7 2 3600 20170420131815 20170330121815 30740 blue. U6D5nTPFEG2bMa/2vlspvJmoJmfZu9KkS3d8iksg/EuRNmG+Tc/UUaQ3 zt1nVVSAUE61jzGy08tbQtsVk5y8GoXJBfr6IsyGv1yrinkqZceG0E5R AmjFJRziooDFNCK+qHhG7u+LbncMfUk6YEudmMZ3DIe82WsUhQ87LqPM Hs8=
;; Received 311 bytes from 65.22.29.9#53(b0.nic.blue) in 175 ms

divelog.blue.		86400	IN	RRSIG	A 8 2 86400 20170404205444 20170330195444 28116 divelog.blue. F3cXXjgC74xNKWNtwy0MY8scrT+c5XhvrNeGIjv+X8XCQzHR062j2h+4 gz3DlRKobm7Hf7vs62sAaS4gjiRRB56qiN4c1v4owHv58m0F/s9Umd+A oXZc5csz3uzHr4CQ/WqySoy/HqAZv8U20Nd57RmGI5Pf+P4/WEw6ysfz jUU=
divelog.blue.		86400	IN	A	81.209.182.12
divelog.blue.		259200	IN	NS	a.ns.bsws.de.
divelog.blue.		259200	IN	NS	b.ns.bsws.de.
divelog.blue.		259200	IN	NS	c.ns.bsws.de.
divelog.blue.		259200	IN	RRSIG	NS 8 2 259200 20170404205444 20170330195444 28116 divelog.blue. fNTcAYbXAl6CSggmTWbkDcRHRFoz6ONi35WE6OGi4TL6hDDJbZEACj81 JZqBgSTPjKM2raiDjpxjet/14aC6Dt7Lhf/m52r5qkM3MMgccA0Bv2Dn G2Pq9jGtgxFlgA4ViA9D8OZn+CDiqalrELK1YYs0WBeG65avURmYYapU OD4=
;; Received 963 bytes from 80.86.183.57#53(b.ns.bsws.de) in 27 ms

If I enable the “Use forwarding” setting in the Forris configuration, then it works too. So this looks like a bug in kresd.

Jef

1 Like

When you disabling forwarding, you use kresd, when you enable forwarding, you use ISPs DNS. Isnt it that way?

You’re right. I made a typo in my explanation. What I meant to say is: Resolving works if I enable the “Use forwarding” setting in Forris. I updated the original post now.

For reference: upstream ticket.

It now works on upstream master. I personally think that the authoritative server isn’t strictly correct when it’s mixing data from multiple zones, but I don’t see a good reason not to accept this particular case.

Thanks for reporting my bug upstream!