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