<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>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: <a class="moz-txt-link-freetext" href="https://github.com/m3047/rkvdns">https://github.com/m3047/rkvdns</a> which are
delegated subdomains of the one and only zone which the BIND
instance knows about (not counting administrative zones, i.e.
RPZ).<br>
</p>
<p>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.</p>
<p>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).</p>
<p>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?</p>
<p>Here, run an out-of-bailiwick query yourself:</p>
<blockquote>
<p><tt>dig @athena.m3047.net gsu.edu IN ANY</tt><br>
</p>
</blockquote>
<p>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.<br>
</p>
<p>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).</p>
<p>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.<br>
</p>
<p><br>
</p>
<p>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.</p>
<p><br>
</p>
<p>Darren Ankney wrote:</p>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
</p>
<p>and then later:</p>
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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: [...]
</pre>
</blockquote>
1) "Right" or "wrong", to the world my server should (does) look
(more) like an authoritative server.</p>
<p>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!<br>
</p>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Bob McDonald wrote:</div>
<div class="moz-cite-prefix">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Dan Mahoney writes:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<br>
</div>
<div class="moz-cite-prefix">Thank you for that. I'm fine, thanks
for asking. Glad to know you are, too. <br>
</div>
<div class="moz-cite-prefix"><br>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
</div>
<div class="moz-cite-prefix">Yes, yes. Isn't the weather something?
<br>
</div>
<div class="moz-cite-prefix"><br>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
</div>
<div class="moz-cite-prefix">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!<br>
</div>
<div class="moz-cite-prefix"><br>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">You have not told us the actual outputs of these queries (do you know if you’re returning refused or not?),</pre>
</blockquote>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Dan, I think I did:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">> It can't answer any of those questions, and properly enough given that it
> recurses, answers NXDOMAIN.
</pre>
</blockquote>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">but ok<br>
</div>
<div class="moz-cite-prefix"><br>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">nor have you said if your server is somewhere inside gsu.edu,</pre>
</blockquote>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Now I'm not sure what you mean but I
said:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">> So I have a BIND server which is publicly exposed, but which is not
> referenced from the canonical tree we call "The DNS".</pre>
</blockquote>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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?<br>
</div>
<div class="moz-cite-prefix"><br>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">which might account for the large number of queries there, if you have clients that exist under that bailiwick.
</pre>
</blockquote>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<p><br>
</p>
<p>I know people mean well, so thank you, but you're adding smoke
and not light...</p>
<p>--</p>
<p>Fred Morris, internet plumber</p>
<p><br>
</p>
</body>
</html>