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