Finer control over REFUSED, e.g. root referrals

[Dan Mahoney]

Fred,

I think I’ve rendered all the help I’m capable of.  Best of luck.

-Dan

> On Sep 7, 2025, at 14:58, Fred Morris <m3047 at m3047.net> wrote:
> 
> I thought I gave enough context, but let me give some more. The instance of BIND which is publicly exposed is sitting in front of a fleet of these: https://github.com/m3047/rkvdns which are delegated subdomains of the one and only zone which the BIND instance knows about (not counting administrative zones, i.e. RPZ).
> It needs to recurse to gather the data which it is intended to deliver. It also runs RPZ configured as a WAF ("web application firewall". I know, this is DNS. deal with the cognitive dissonance, starting with the fact that RPZ is referred to as a "DNS firewall" pretty much everywhere) so that only specific, pre-determined queries are allowed. I don't run RRL, I have other measures.
> I'm not going to quibble about whether in-bailiwick REFUSED would be better than NXDOMAIN. But out of bailiwick REFUSED is the proper response for a server which is for all intents and purposes authoritative for the intended audience (and any random miscreants who might be passing by).
> Here's lulz: I have other "slip" mitigations in place. In the past week I have blocked 142,000 out of 145,000 SYN and UDP packets in general (not just to this service) from dynamically flagged ranges with 133,000 from one particular /16. What's to write home about? Should I be excited?
> Here, run an out-of-bailiwick query yourself:
> dig @athena.m3047.net gsu.edu IN ANY
> Just don't run it too many times, or you will get blocked and end up a statistic in the telemetry which the server is intended to publish. Oh. Although I have made announcements about it semi-publicly, I think posting on bind-users@ would be tempting fate. So if you are interested in exactly what telemetry, and would like to taste it, reach out with bona fides and within reason (you give me, you know, actual bona fides and agree to keep it to yourself and not post it publicly... TLP:orange) I'll give you the clue.
> The most (only) productive suggestion was sent to me off-list (thank you, CJC) and was to set allow-query { ! any;  } in options, and then set allow-query { any; } in the (parent) zone stanza. Attempt one, with glue, was not successful (returned refused for the subdomains, disabled recursion). For attempt two I removed the glue and declared the subdomains as static-stub zones so that I could set allow-query { any; } on them explicitly. Same thing, returned refused for the subdomains (but worked when I changed the options stanza to allow any, so yes the zone declarations are accurate).
> The more I think about it, RPZ is the best option; I don't know why it's incapable of returning REFUSED. Seems like an oversight to me. But if I have to hack the server, I might as well make it so that it returns AA in bailiwick, as well as REFUSED out of bailiwick. I don't need to do that yet. The server is not in The DNS, so it is technically correct declaring itself as root. I'm trying to be proactive here because other people are starting to run this, and you know how things happen.
> 
> I'm not sure what squirrel everyone is chasing, but it says more about you and your circumstances than it does about me and my issue.
> 
> Darren Ankney wrote:
> 
>> 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.
>> 
> 
> and then later:
> 
>> 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: [...]
>> 
> 1) "Right" or "wrong", to the world my server should (does) look (more) like an authoritative server.
> 
> 2) Why would I want or need to limit the access to this server to specific addresses (or partners) known in advance? No no no, no hypotheticals, my situation: I have other measures in place. Even if I ran RRL, I still wouldn't do this; at least, not right now. This server exists so that people can taste the data, without registering. There is no evidence in the field that I need to rethink this policy at the present time. Could that change in the future? Sure! The web is under attack right now, with e.g. Cloudflare circling the wagons to poison purported AI bots (can't say I blame them, although the business model is odious). Want my advice? Prepare for Balkanization!
> 
> Bob McDonald wrote:
>> 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.
>> 
> 
> Full squirrel. On behalf of the other respondents, I apologize for the misdirection you were caused to suffer. By the way, most of the telemetry the server provides is large enough to require TCP; but none of the miscreants asking for things which are out-of-bailiwick are even swinging for the fence.
> 
> 
> Dan Mahoney writes:
> 
>> 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.
>> 
> 
> Thank you for that. I'm fine, thanks for asking. Glad to know you are, too. 
> 
>> 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.
> 
> Yes, yes. Isn't the weather something? 
> 
>> 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.
> 
> I own several of their t-shirts. I think they provide a valuable service. I try to help out when I can. I'm a fan of BIND, and utilize RPZ extensively. You should check out my GitHub account!
> 
>> You have not told us the actual outputs of these queries (do you know if you’re returning refused or not?),
> 
> Dan, I think I did:
> 
>> > It can't answer any of those questions, and properly enough given that it
>> > recurses, answers NXDOMAIN.
>> 
> 
> but ok
> 
>> nor have you said if your server is somewhere inside gsu.edu,
> 
> Now I'm not sure what you mean but I said:
> 
>> > So I have a BIND server which is publicly exposed, but which is not
>> > referenced from the canonical tree we call "The DNS".
> 
> Did you mean some address space they control? You mean in Brazil maybe? By the way, the data you seek is in the telemetry the server publishes. Although maybe I should publish an additional product with the domains being queried for. Interested?
> 
>> which might account for the large number of queries there, if you have clients that exist under that bailiwick.
>> 
> 
> This is just irrelevant as well as confounding. DNS clients do not declare what "bailiwick" they're in; I'm not even sure that makes sense. Do you mean search lists? That doesn't even make sense, since the actual queries are for the FQDN gsu.edu (and isc.org) as I showed with the Perl one-liner.
> 
> 
> I know people mean well, so thank you, but you're adding smoke and not light...
> --
> Fred Morris, internet plumber
> 
> -- 
> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list.