<div dir="ltr"><div>Yes, RPZ looks up first, and only replaces it if the lookup returns a value.  There is an option to skip that, but then an attacker can more easily detect that you are using RPZ to block them.</div><div>Search for descriptions online.</div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><br>-- <br>Bob Harold</div><div>DNS and DHCP Hostmaster - UMNet<br>Information and Technology Services (ITS)<br><a href="mailto:rharolde@umich.edu" target="_blank">rharolde@umich.edu</a>   734-647-6524<br></div></div></div></div></div></div><br></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Jan 3, 2025 at 3:04 PM Adam Augustine <<a href="mailto:augustineas@gmail.com">augustineas@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I have an intermittent RPZ problem that I am troubleshooting.<br>
<br>
I do a lookup for "<a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a>" which<br>
has a corresponding RPZ entry that looks like:<br>
<a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a>      A       10.254.254.254<br>
<br>
A little after midnight, we started getting timeouts when looking up<br>
the name, as well as SERVFAILs:<br>
$ dig <a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a> @ns02<br>
;; communications error to ns02#53: timed out<br>
<br>
; <<>> DiG 9.18.28-S1 <<>> <a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a> @ns02<br>
;; global options: +cmd<br>
;; Got answer:<br>
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13401<br>
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1<br>
<br>
;; OPT PSEUDOSECTION:<br>
; EDNS: version: 0, flags:; udp: 1232<br>
; COOKIE: a960c89ec8cb08b10100000067781f4693fa76a27ba9bf46 (good)<br>
;; QUESTION SECTION:<br>
;<a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a>. IN A<br>
<br>
;; Query time: 4992 msec<br>
;; SERVER: ns02#53(10.53.247.71) (UDP)<br>
;; WHEN: Fri Jan 03 10:32:54 MST 2025<br>
;; MSG SIZE  rcvd: 101<br>
<br>
Turning up the logging for query-errors on one of the secondaries (I<br>
thought it was a zone transfer issue at the time) I saw these:<br>
03-Jan-2025 10:46:48.863 query-errors: debug 3: client @0x7f67c0469168<br>
ns02#49282 (<a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a>): view<br>
Internal: rpz QNAME rewrite<br>
<a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a> stop on qresult in<br>
rpz_rewrite(): timed out<br>
03-Jan-2025 10:46:48.863 query-errors: debug 3: client @0x7f67b7aad168<br>
ns02#41110 (<a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a>): view<br>
Internal: rpz QNAME rewrite<br>
<a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a> stop on qresult in<br>
rpz_rewrite(): timed out<br>
03-Jan-2025 10:46:48.863 query-errors: debug 1: client @0x7f67c0469168<br>
ns02#49282 (<a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a>): view<br>
Internal: query failed (timed out) for<br>
<a href="http://dnshealthcheck.privatelink.azurewebsites.net/IN/A" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net/IN/A</a> at query.c:8113<br>
03-Jan-2025 10:46:48.863 query-errors: debug 1: client @0x7f67b7aad168<br>
ns02#41110 (<a href="http://dnshealthcheck.privatelink.azurewebsites.net" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net</a>): view<br>
Internal: query failed (timed out) for<br>
<a href="http://dnshealthcheck.privatelink.azurewebsites.net/IN/A" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net/IN/A</a> at query.c:8113<br>
03-Jan-2025 10:46:48.863 query-errors: debug 4: fetch completed at<br>
resolver.c:4519 for <a href="http://dnshealthcheck.privatelink.azurewebsites.net/A" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net/A</a> in<br>
10.000024: timed out/success<br>
[domain:<a href="http://azurewebsites.net" rel="noreferrer" target="_blank">azurewebsites.net</a>,referral:0,restart:2,qrysent:0,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]<br>
<br>
It seems queries for similar "A" records in the RPZ zone are also<br>
failing. I don't think all of them are, but maybe. They do all seem to<br>
be associated with <a href="http://azurewebsites.net" rel="noreferrer" target="_blank">azurewebsites.net</a> from what I can see so far.<br>
<br>
I looked at the source for "query.c" at line 8113 and it looks like a<br>
logging function, and so doesn't seem to give me more information<br>
about what was going on when the timeout happened, though I am<br>
certainly not a programmer.<br>
<br>
And at one point on one of the servers, I stumbled across this:<br>
<br>
Jan  3 12:03:14 ns0 named[10233]: network unreachable resolving<br>
'<a href="http://dnshealthcheck.privatelink.azurewebsites.net/A/IN" rel="noreferrer" target="_blank">dnshealthcheck.privatelink.azurewebsites.net/A/IN</a>':<br>
2a01:111:4000:700::e0#53<br>
<br>
Which surprised me. I figured if there was an "A" record for a name in<br>
an RPZ zone that bind would never do a lookup for it, since it would<br>
be overridden anyway.<br>
<br>
That said, it seems to correlate with at least one of the nameservers<br>
for <a href="http://azurewebsites.net" rel="noreferrer" target="_blank">azurewebsites.net</a> being unreachable (<a href="http://ns1-224.azure-dns.com" rel="noreferrer" target="_blank">ns1-224.azure-dns.com</a>.<br>
13.107.236.224). But that shouldn't matter since the resolver should<br>
switch to another.<br>
<br>
The issue ran for several hours, then resolved itself, then broke<br>
again for a few hours, then resolved itself again and things seem to<br>
be fine now. All without me doing anything (as far as I know, lots of<br>
automation going on).<br>
<br>
So does bind do a lookup of an RPZ name even if it is going to<br>
override it? And also, if this happens again, are there places I<br>
should look besides query-errors for indicators of why it is failing?<br>
<br>
Thanks for any help,<br>
  Adam Augustine<br>
-- <br>
Visit <a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list<br>
<br>
ISC funds the development of this software with paid support subscriptions. Contact us at <a href="https://www.isc.org/contact/" rel="noreferrer" target="_blank">https://www.isc.org/contact/</a> for more information.<br>
<br>
<br>
bind-users mailing list<br>
<a href="mailto:bind-users@lists.isc.org" target="_blank">bind-users@lists.isc.org</a><br>
<a href="https://lists.isc.org/mailman/listinfo/bind-users" rel="noreferrer" target="_blank">https://lists.isc.org/mailman/listinfo/bind-users</a><br>
</blockquote></div>