Personally, I would like an even finer control than what the allow-query option 
allows. I too run an authoritative server, and it too is being routinely used 
for DNS amplification attacks. Rather than returning a REFUSED error (which 
still uses bandwidth on my link and the poor victim's link), I would like to be 
able to configure my bind instance to not respond AT ALL to _any_ domain 
queries for which I am not authoritative or a "glue" server.

Yes, I realize this would be a violation of the current DNS protocol 
specification. IP address spoofing and DNS amplification attacks already are a 
much more egregious violation of the protocol spec, causing much more damage, 
and the attackers aren't going to quit using this attack technique just because 
the spec says not to do it. Such a attacker-ignoring capability (if spread 
widely) would make it much more difficult for attackers to use public DNS 
servers as attack drones; they would have to determine authoritative domains on 
a per-server basis to be able to use public DNS servers for attacking; such 
information would be very tedious to harvest and organize at the attacker's 
sites.

The last time I asked for this, 10+ years ago, I was told such a feature might 
be a problem for someone with an antique configuration still trying to use the 
server that was at my IP address before the IP address was reassigned to me 
(are they so dumb they can't time out and try the next server on their list?). 
Well, only my DNS server has been at this specific public numeric IPv4 address 
for 19 years now; if anyone is still trying to use that IP address for some 
other party using stale DNS data, they deserve all the pain they get for being 
that out of date. And their determined retries would still be less of a load on 
my server than the attackers are (especially since I've never actually seen an 
antique domain request, just guaranteed attacks).

Please consider "no answer" as a configurable option for non-authoritative 
queries on authoritative servers. Being configurable means that it could be 
turned off for a while if a given DNS server stops being authoritative (primary 
or secondary) for a given domain. Even better if the deprecated domain could be 
temporarily configured as REFUSED for a short period of time (cache expiration 
time) on a per-domain basis to allow "no answer" to still apply for any 
non-authoritative domain that didn't change its authoritative state on the 
server. However, the latter isn't necessary if the administrator of the former 
secondary simply doesn't delete its copy of the domain from its records until 
the expiration time after the primary stops using that secondary.

Andrew Pavlin
administrator of ka2ddo.org and ka2ddo.radio domains

________________________________________
From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Darren Ankney 
<darren.ank...@gmail.com>
Sent: Sunday, September 7, 2025 6:21 AM
To: bind-users@lists.isc.org
Subject: Re: Finer control over REFUSED, e.g. root referrals

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
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list.
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list.

Reply via email to