NSD incorrectly logging DNAME as refused?

NSD
1

I just noticed this with NSD 4.10.0 (and earlier versions - it's not a
new regression))

I have nsd set to log refused requests to syslog.

After adding a DNAME type into my dns for one sub-zone that is being moved,
I noticed that legitimate requests for hosts under that subdomain are working
as expected, howerver they are being logged as refused.

As a quick replicable test, I just did this to demostrate the issue.

Firatlt, add edthis to my dyslexicfish.net domain:

nsdtest IN DNAME hello.example.com.

Then, update serial, reload, watch it propagate to secondaries etc., then
from a machine with no specific acls (i.e. not from one of the primaries
or secondaries:

> # dig sjsjqju2qu.nsdtest.dyslexicfish.net.
>
> ; <<>> DiG 9.18.27 <<>> sjsjqju2qu.nsdtest.dyslexicfish.net.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 53148
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: eef66b9e45770f3e010000006684ada8ca27d2ccb2d7c25f (good)
> ;; QUESTION SECTION:
> ;sjsjqju2qu.nsdtest.dyslexicfish.net. IN A
>
> ;; ANSWER SECTION:
> nsdtest.dyslexicfish.net. 86363 IN DNAME hello.example.com.
> sjsjqju2qu.nsdtest.dyslexicfish.net. 86363 IN CNAME sjsjqju2qu.hello.example.com.
>
> ;; AUTHORITY SECTION:
> example.com. 3600 IN SOA ns.icann.org. noc.dns.icann.org. 2024041842 7200 3600 1209600 3600
>
> ;; Query time: 30 msec
> ;; SERVER: 205.166.94.24#53(205.166.94.24) (UDP)
> ;; WHEN: Wed Jul 03 01:47:17 UTC 2024
> ;; MSG SIZE rcvd: 213

This produces this via syslog on the nsd serversx:

> Jul 3 02:46:43 <daemon.info> catnip nsd[3620]: query sjsjqju2qu.nsdtest.dyslexicfish.net. from 205.166.94.24 refused, no acl matches .

As can be seen from "dig", the result is valid, and everything works as
suspected, I'm just getting rather a lot of those "refused" messages, as
the domain gets a lot of traffic!

I know I can disable the logging of such messages, but I do want to log
then when they are legitimate!

(Obviously I first noticed this on a valid DNAME target zone of mine
I just used 'hello.example.com' in the above demonstration to show that
it's nothing weird going on with my setup - delegating to any domain that
the nsd server itself doesn't serve causes the issue)

Any ideas? And apologies for any late-night incoherencies in this message!

Cheers, Jamie

2

Hi Jamie,

I can reproduce, but only if the target zone of the DNAME (or CNAME which behaves the same) matches a zone with an allow-query option that doesn't match the querier.

For example with the following config in nsd.conf:

zone:
name: "."
allow-query: 0::/128 NOKEY

zone:
name: "example"
zonefile: "example"

and an example zone that contains `nsdtest.example. CNAME hello.example.com.`, then indeed a query for `nsdtest.example.` gives the correct CNAME answer, but a "info: query nsdtest.example. from 127.0.0.1 refused, no acl matches" message is logged. NSD logs the error trying to add more records while following the CNAME, but the checked target CNAME domain has an acl forbidding this for the querier.

Do you have a similar situation?

Should an error be logged when CNAME targets match a zone with an allow-query list that doesn't match?

-- Willem

3

B.t.w. I've created a PR for it that resolves it (see https://github.com/NLnetLabs/nsd/pull/346 ), but we may need to discuss if and how to resolve it first. First I'd like to know if your configuration is similar in that the CNAME or DNAME target does contain an allow-query list.

4

B.t.w. I've created a PR for it that resolves it (see
https://github.com/NLnetLabs/nsd/pull/346 ), but we may need to discuss
if and how to resolve it first. First I'd like to know if your
configuration is similar in that the CNAME or DNAME target does contain
an allow-query list.

Willem, thanks for the quick reply, and apologies for the delay in getting
back to you.

Apologies if I misunderstand you, but what i noticed, in my case I was setting
a DNAME to a point to a different domain that is not on my dns-server set at all.
(a third party provider)
and it appeared to happen regardless of the acl status of the remote server.
(Granted, it's probably the synthasised CNAME that triggers the log message
rather than the DNAME itself)

I first did it with a remote server that did respond, and responded (correctly)
wit nxdomain.

The example I quoted in my email were literal enties - ie. it the dname was
pointing to a remote server that didn't even exist.

Apologies for not being clear. Does this help? - II've modified my tests to these:

In my primary (and obviously, secondaries) DNS, I now have literally the
following entries. (Apologies to these guys for doing a quick test off
their nameservers!):

noexist-test.dyslexicfish.net. IN DNAME hello.example.com.
nx-test.dyslexicfish.net. IN DNAME empty.as112.arpa.
cname-test.dyslexicfish.net. IN DNAME sourceforge.net.

As the names suggest:

hello.example.com doesn't exist.
empty.as112.arpa accepts queries, but always responds with NXDOMAIN
sourceforge.net accepts queries, and always responds with a "catchall" cname.

So, with the above setup, I then log into a third-party unix account I have,
that is unrelated to my network / ip range / dns servers, and get this:

> > host a1.cname-test.dyslexicfish.net.
> cname-test.dyslexicfish.net has DNAME record sourceforge.net.
> a1.cname-test.dyslexicfish.net is an alias for a1.sourceforge.net.
> a1.sourceforge.net is an alias for projects.sourceforge.net.cdn.cloudflare.net.
> projects.sourceforge.net.cdn.cloudflare.net has address 172.64.150.145
> projects.sourceforge.net.cdn.cloudflare.net has address 104.18.37.111
> projects.sourceforge.net.cdn.cloudflare.net has IPv6 address 2606:4700:4400::6812:256f
> projects.sourceforge.net.cdn.cloudflare.net has IPv6 address 2606:4700:4400::ac40:9691
> >
> > host a1.nx-test.dyslexicfish.net.
> Host a1.nx-test.dyslexicfish.net. not found: 3(NXDOMAIN)
> >
> > host a2.noexist-test.dyslexicfish.net.
> Host a2.noexist-test.dyslexicfish.net. not found: 3(NXDOMAIN)
> >

These results are as expected. However, on my own dns servers, which
are authorative for dyslexicfish.net,. i get logged on 2 of them:
[amnesia.dns.dyslexicfish.net. (catnip)
and esparadis.dns.dyslexicfish.net (catwalk)

4 Jul 9 02:39:07 <daemon.info> catnip nsd[99594]: query a1.cname-test.dyslexicfish.net. from 205.166.94.24 refused, no acl matches .
4 Jul 9 02:39:31 <daemon.info> catwalk nsd[14669]: query a1.nx-test.dyslexicfish.net. from 205.166.94.24 refused, no acl matches .
4 Jul 9 02:39:41 <daemon.info> catwalk nsd[14669]: query a1.noexist-test.dyslexicfish.net. from 205.166.94.24 refused, no acl matches .

So, the log message is getting logged despite whether the remote
nameserver exists or allows it.

I wouldn't have expected a log message for any of those cases -
indeed, as an authorative nameserver, I wouldn't have expected
nsd to try to contact the remote servers at all - isn't its job
to just return the DNAME record (and, sure, the corresponding
synthasised CNAME for compatibility purposes) without knowing
or caring what those themselves resolved to? Isn't that the
responsibility of the calling recursive nameserver?

Incidentally, it not just that the recursive dns client may be
trying to coax nsd into doing some recursitivity, even the
following non-resursive lookup direct to the authorative server:

> > dig -4 +norecurse foo.cname-test.dyslexicfish.net @amnesia.dns.dyslexicfish.net.
>
> ; <<>> DiG 9.18.27 <<>> -4 +norecurse foo.cname-test.dyslexicfish.net @amnesia.dns.dyslexicfish.net.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54018
> ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;foo.cname-test.dyslexicfish.net. IN A
>
> ;; ANSWER SECTION:
> cname-test.dyslexicfish.net. 86400 IN DNAME sourceforge.net.
> foo.cname-test.dyslexicfish.net. 86400 IN CNAME foo.sourceforge.net.
>
> ;; Query time: 137 msec
> ;; SERVER: 104.238.172.250#53(amnesia.dns.dyslexicfish.net.) (UDP)
> ;; WHEN: Tue Jul 09 02:07:59 UTC 2024
> ;; MSG SIZE rcvd: 119

... gives the correct response, but produces the log entry:

Jul 9 03:07:28 <daemon.info> catnip nsd[99683]: query foo.cname-test.dyslexicfish.net. from 205.166.94.9 refused, no acl matches .

I hope this makes sense. Please let me know if I've misunderstood what you
were saying.

Thanks, Jamie

5

As an interesting aside, within 30 seconds of my reply, my nameservers
got flooded for about 2 minutes with requests from all over the place
for those very test domains I mentioned - approx 100 uniq addresses. (shout
out to noc.net. jpberlin.de. lemarit.net. moybella.net. schlyter.se.
tednet.nl. transip.nl. vantosh.com. wildnet.pl. .etc....)

Presumably some mailservers are scanning the inbound email, and attempting
to resolve potential links? I'm sure there's some privacy / tracking
issues there!

6

You were right about the CNAME. I've reproduced this prolem with
a much simpler CNAME only example:

For zone dyslexicfish.net, I've added:

bbc IN CNAME www.bbc.co.uk.

Then, on a third party host, I get this:

> $ dig -4 bbc.dyslexicfish.net. @amnesia.dns.dyslexicfish.net.
>
> ; <<>> DiG 9.18.27 <<>> -4 bbc.dyslexicfish.net. @amnesia.dns.dyslexicfish.net.
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29321
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;bbc.dyslexicfish.net. IN A
>
> ;; ANSWER SECTION:
> bbc.dyslexicfish.net. 86400 IN CNAME www.bbc.co.uk.
>
> ;; Query time: 136 msec
> ;; SERVER: 104.238.172.250#53(amnesia.dns.dyslexicfish.net.) (UDP)
> ;; WHEN: Fri Jul 19 21:15:38 UTC 2024
> ;; MSG SIZE rcvd: 76

So, the answer is correct, and works fine, however, on the dns server, this is logged:

Jul 19 22:15:41 <daemon.info> amnesia nsd[26483]: query bbc.dyslexicfish.net. from 205.166.94.4 refused, no acl matches .

A tcpdump on the server shows no spurious requests from this host, simply:

> % tcpdump -n host 205.166.94.4
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
> 22:15:41.161045 IP 205.166.94.4.52640 > 104.238.172.250.53: 29321+ [1au] A? bbc.dyslexicfish.net. (61)
> 22:15:41.161536 IP 104.238.172.250.53 > 205.166.94.4.52640: 29321*- 1/0/1 CNAME www.bbc.co.uk. (76)
> ^C

Cheers, Jamie