Finer control over REFUSED, e.g. root referrals
Robert McDonald
bmcdonaldjr at gmail.com
Sun Sep 7 11:17:04 UTC 2025
I've used a similar approach to limiting the access to a recursive server
in the past. (Allow-query)
However, I would suggest using tsig keys on a rotating change schedule to
secure your server access. It's simply too easy to spoof an IP address.
YMMV,
Bob
Sent from my Google Pixel 9a phone.
On Sun, Sep 7, 2025, 06:22 <bind-users-request at lists.isc.org> wrote:
> Send bind-users mailing list submissions to
> bind-users at lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
> bind-users-request at lists.isc.org
>
> You can reach the person managing the list at
> bind-users-owner at lists.isc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
> 1. Finer control over REFUSED, e.g. root referrals (Fred Morris)
> 2. Re: Finer control over REFUSED, e.g. root referrals
> (Darren Ankney)
> 3. Re: Finer control over REFUSED, e.g. root referrals (Dan Mahoney)
> 4. Re: Finer control over REFUSED, e.g. root referrals
> (Darren Ankney)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 6 Sep 2025 11:27:13 -0700 (PDT)
> From: Fred Morris <m3047 at m3047.net>
> To: bind-users at lists.isc.org
> Subject: Finer control over REFUSED, e.g. root referrals
> Message-ID: <alpine.LSU.2.21.2509061039410.3786 at flame.m3047>
> Content-Type: text/plain; format=flowed; charset=US-ASCII
>
> So I have a BIND server which is publicly exposed, but which is not
> referenced from the canonical tree we call "The DNS". It serves as a
> firewall / DNS "WAF" for resources which it recurses to obtain.
>
> People (bad, misinformed people) issue queries to it, for things which it
> is not intended or capable of answering: it is not a general-purpose
> recursing resolver:
>
> # perl -ne 'm/query: (\S+) (\S+) (\S+)/ && printf "%s\n", join( "\t", $1,
> $2, $3);' bind-queries.log | sort | uniq -c | sort -rnk1 | grep -vE '^ +1
> '
> 1912 gsu.edu IN ANY
> 13 sl IN ANY
> 10 isc.org IN TXT
> 10 isc.org IN ANY
> 10 cloudflare.com IN DNSKEY
> 9 version.bind CH TXT
> 9 ripe.net IN DNSKEY
> 9 cloudflare.com IN ANY
> 8 ripe.net IN TXT
> 8 ripe.net IN ANY
> 8 isc.org IN DNSKEY
> 8 cloudflare.com IN TXT
> 6 vtb.com IN ANY
> 3 collectd.org IN ANY
> 2 VERSION.BIND CH TXT
> 2 hostname.bind CH TXT
> 2 hbtbank.com IN TXT
> 2 hbtbank.com IN ANY
> 2 direct.shodan.io IN A
>
> (That's a taste from the past 24 hours.)
>
> It can't answer any of those questions, and properly enough given that it
> recurses, answers NXDOMAIN. For completeness, you get essentially the
> same answer if you ask +norecurse. But the mote in my eye is the AUTHORITY
> section, which contains a referral to root (".") which references this
> server, not the canonical roots. Mockapetris can holster his sidearm,
> because this server is not part of The DNS.
>
> However if I ask one of ISC's nameservers (ns1.isc.org) running BIND
> 9.18.38 according to version.bind for something which it is not
> authoritative for it answers REFUSED, with no referral in AUTHORITY. I'd
> like to be able to do that.
>
> # dig @ns1.isc.org . TXT +norecurse
>
> ; <<>> DiG 9.12.3-P1 <<>> @ns1.isc.org . TXT +norecurse
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21168
> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: 8aef89922fc3d6b60100000068bc7b689f633c48a5f93945 (good)
> ;; QUESTION SECTION:
> ;. IN TXT
>
> ;; Query time: 35 msec
> ;; SERVER: 149.20.2.26#53(149.20.2.26)
> ;; WHEN: Sat Sep 06 11:20:24 PDT 2025
> ;; MSG SIZE rcvd: 56
>
> It would be nice if I could achieve this behavior, IN CASE someone else
> running a server for this purpose intentionally or inadvertently put it in
> The DNS (tree). Just so Mockapetris doesn't come gunning for them.
>
> It seems as though somehow that behavior is implicit in allowing /
> disallowing recursion by the server. I could modify the code and recompile
> so that it answered everything "AA"; in fact I'd be pleased if this server
> straight up lied and claimed to be authoritative for all of the domains it
> legitimately queries, just saying. I don't know if I'd have to do some
> additional work to get it to answer REFUSED.
>
> It occurred to me that RPZ would be an option; but the RPZ implementation
> has no option to return REFUSED.
>
> Am I missing something?
>
> --
>
> Fred Morris, internet plumber
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 6 Sep 2025 16:50:27 -0400
> From: Darren Ankney <darren.ankney at gmail.com>
> To: Fred Morris <m3047 at m3047.net>
> Cc: bind-users at lists.isc.org
> Subject: Re: Finer control over REFUSED, e.g. root referrals
> Message-ID:
> <CAKabWHhBx1KjQUwnom6PXFHMZm2HK8Vtvf4aSy=
> wGwckwixJYA at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi Fred,
>
> > It seems as though somehow that behavior is implicit in allowing /
> disallowing recursion by the server.
>
> I think this is right. I think isc.org ns servers return "REFUSED"
> because they have recursion disabled and are not authoritative for
> what you have asked for ('.' TXT) (and you used +norec in your dig
> query anyway). You implied that you have recursion enabled, I think.
>
> If I ask my own test resolver in the same manner I get no answer/no
> error and the '.' SOA in the authority section:
>
> % dig . TXT @192.168.40.42 +norec
>
> ; <<>> DiG 9.10.6 <<>> . TXT @192.168.40.42 +norec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15715
> ;; flags: qr ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;. IN TXT
>
> ;; AUTHORITY SECTION:
> . 86400 IN SOA a.root-servers.net.
> nstld.verisign-grs.com. 2025090601 1800 900 604800 86400
>
> ;; Query time: 14 msec
> ;; SERVER: 192.168.40.42#53(192.168.40.42)
> ;; WHEN: Sat Sep 06 16:40:47 EDT 2025
> ;; MSG SIZE rcvd: 103
>
> I have a vague memory that this is the correct behavior as described
> in RFC 1034 and 1035.
>
> As for if you are missing something else that would allow you to
> achieve your goal, I'll let others answer.
>
> Thank you,
> Darren Ankney
>
> On Sat, Sep 6, 2025 at 2:27?PM Fred Morris <m3047 at m3047.net> wrote:
> >
> > So I have a BIND server which is publicly exposed, but which is not
> > referenced from the canonical tree we call "The DNS". It serves as a
> > firewall / DNS "WAF" for resources which it recurses to obtain.
> >
> > People (bad, misinformed people) issue queries to it, for things which it
> > is not intended or capable of answering: it is not a general-purpose
> > recursing resolver:
> >
> > # perl -ne 'm/query: (\S+) (\S+) (\S+)/ && printf "%s\n", join( "\t", $1,
> > $2, $3);' bind-queries.log | sort | uniq -c | sort -rnk1 | grep -vE '^ +1
> > '
> > 1912 gsu.edu IN ANY
> > 13 sl IN ANY
> > 10 isc.org IN TXT
> > 10 isc.org IN ANY
> > 10 cloudflare.com IN DNSKEY
> > 9 version.bind CH TXT
> > 9 ripe.net IN DNSKEY
> > 9 cloudflare.com IN ANY
> > 8 ripe.net IN TXT
> > 8 ripe.net IN ANY
> > 8 isc.org IN DNSKEY
> > 8 cloudflare.com IN TXT
> > 6 vtb.com IN ANY
> > 3 collectd.org IN ANY
> > 2 VERSION.BIND CH TXT
> > 2 hostname.bind CH TXT
> > 2 hbtbank.com IN TXT
> > 2 hbtbank.com IN ANY
> > 2 direct.shodan.io IN A
> >
> > (That's a taste from the past 24 hours.)
> >
> > It can't answer any of those questions, and properly enough given that it
> > recurses, answers NXDOMAIN. For completeness, you get essentially the
> > same answer if you ask +norecurse. But the mote in my eye is the
> AUTHORITY
> > section, which contains a referral to root (".") which references this
> > server, not the canonical roots. Mockapetris can holster his sidearm,
> > because this server is not part of The DNS.
> >
> > However if I ask one of ISC's nameservers (ns1.isc.org) running BIND
> > 9.18.38 according to version.bind for something which it is not
> > authoritative for it answers REFUSED, with no referral in AUTHORITY. I'd
> > like to be able to do that.
> >
> > # dig @ns1.isc.org . TXT +norecurse
> >
> > ; <<>> DiG 9.12.3-P1 <<>> @ns1.isc.org . TXT +norecurse
> > ; (1 server found)
> > ;; global options: +cmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 21168
> > ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> >
> > ;; OPT PSEUDOSECTION:
> > ; EDNS: version: 0, flags:; udp: 1232
> > ; COOKIE: 8aef89922fc3d6b60100000068bc7b689f633c48a5f93945 (good)
> > ;; QUESTION SECTION:
> > ;. IN TXT
> >
> > ;; Query time: 35 msec
> > ;; SERVER: 149.20.2.26#53(149.20.2.26)
> > ;; WHEN: Sat Sep 06 11:20:24 PDT 2025
> > ;; MSG SIZE rcvd: 56
> >
> > It would be nice if I could achieve this behavior, IN CASE someone else
> > running a server for this purpose intentionally or inadvertently put it
> in
> > The DNS (tree). Just so Mockapetris doesn't come gunning for them.
> >
> > It seems as though somehow that behavior is implicit in allowing /
> > disallowing recursion by the server. I could modify the code and
> recompile
> > so that it answered everything "AA"; in fact I'd be pleased if this
> server
> > straight up lied and claimed to be authoritative for all of the domains
> it
> > legitimately queries, just saying. I don't know if I'd have to do some
> > additional work to get it to answer REFUSED.
> >
> > It occurred to me that RPZ would be an option; but the RPZ implementation
> > has no option to return REFUSED.
> >
> > Am I missing something?
> >
> > --
> >
> > Fred Morris, internet plumber
> >
> > --
> > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list.
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 6 Sep 2025 14:08:58 -0700
> From: Dan Mahoney <danm at prime.gushi.org>
> To: Fred Morris <m3047 at m3047.net>
> Cc: bind-users at lists.isc.org
> Subject: Re: Finer control over REFUSED, e.g. root referrals
> Message-ID: <08CE304B-E647-4C31-8FE3-D9CD4DAEF2FF at prime.gushi.org>
> Content-Type: text/plain; charset=utf-8
>
>
>
> > On Sep 6, 2025, at 11:27, Fred Morris <m3047 at m3047.net> wrote:
> >
> > So I have a BIND server which is publicly exposed, but which is not
> referenced from the canonical tree we call "The DNS". It serves as a
> firewall / DNS "WAF" for resources which it recurses to obtain.
>
> Hey Fred,
>
> If you have a service on port 53, people will find it and will throw
> queries againt it, and they do not care if it does recursion or not. They
> might not even care if there?s a service there or not.
>
> Many times, these will be from spoofed IPs where they do not care about
> the query, they just want to send more traffic to a place. This is
> especially common with ANY queries.
>
> isc.org is a popular zone for redirection attacks because the response to
> an ANY query are pretty big, so make a nice payload to abuse someone else
> with.
>
> You have not told us the actual outputs of these queries (do you know if
> you?re returning refused or not?), nor have you said if your server is
> somewhere inside gsu.edu, which might account for the large number of
> queries there, if you have clients that exist under that bailiwick.
>
> -Dan
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 7 Sep 2025 06:21:28 -0400
> From: Darren Ankney <darren.ankney at gmail.com>
> To: bind-users at lists.isc.org
> Subject: Re: Finer control over REFUSED, e.g. root referrals
> Message-ID:
> <
> CAKabWHiaHVkgj_Wx-ZbnRVbFKuu-Ygc4sVc-bsWG3WiFHDGSow at mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi again Fred,
>
> > As for if you are missing something else that would allow you to
> > achieve your goal, I'll let others answer.
>
> This was bugging me this morning so I ran a quick second test. It
> turns out that allow-query { }; limited to just those IP(s) that
> should be able to query the server will return refused to all others.
> I set on my test server:
>
> allow-query {
> none;
> };
>
>
> And that produced REFUSED on a client:
>
> % dig . TXT @192.168.40.82 +norec
>
> ; <<>> DiG 9.10.6 <<>> . TXT @192.168.40.82 +norec
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 53007
> ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; OPT=15: 00 12 ("..")
> ;; QUESTION SECTION:
> ;. IN TXT
>
> ;; Query time: 11 msec
> ;; SERVER: 192.168.40.82#53(192.168.40.82)
> ;; WHEN: Sun Sep 07 06:20:31 EDT 2025
> ;; MSG SIZE rcvd: 34
>
> Thank you,
> Darren Ankney
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> --
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list.
>
>
> ------------------------------
>
> End of bind-users Digest, Vol 4797, Issue 1
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20250907/1d6070ed/attachment-0001.htm>
More information about the bind-users
mailing list