Ah, thank you, Bob. That was exactly the pointer that I needed. For future people searching, the specific situation Bob refers to is discussed in the last paragraph of this section here: https://bind9.readthedocs.io/en/v9.20.4/reference.html#namedconf-statement-response-policy, which begins with "No DNS records are needed for a QNAME or Client-IP trigger; the name or IP address itself is sufficient, so in principle the query name need not be recursively resolved. "
To turn off the lookup one could use the "qname-wait-recurse no" setting. The documentation mentions the tradeoff of having this on by default with the sentence, "To prevent that information leak, by default any recursion needed for a request is done before any policy triggers are considered. Because listed domains often have slow authoritative servers, this behavior can cost significant time." Thanks again! Adam Augustine On Fri, Jan 3, 2025 at 1:41 PM Bob Harold <rharo...@umich.edu> wrote: > > 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. > Search for descriptions online. > > -- > Bob Harold > DNS and DHCP Hostmaster - UMNet > Information and Technology Services (ITS) > rharo...@umich.edu 734-647-6524 > > > On Fri, Jan 3, 2025 at 3:04 PM Adam Augustine <augustin...@gmail.com> wrote: >> >> I have an intermittent RPZ problem that I am troubleshooting. >> >> I do a lookup for "dnshealthcheck.privatelink.azurewebsites.net" which >> has a corresponding RPZ entry that looks like: >> dnshealthcheck.privatelink.azurewebsites.net A 10.254.254.254 >> >> A little after midnight, we started getting timeouts when looking up >> the name, as well as SERVFAILs: >> $ dig dnshealthcheck.privatelink.azurewebsites.net @ns02 >> ;; communications error to ns02#53: timed out >> >> ; <<>> DiG 9.18.28-S1 <<>> dnshealthcheck.privatelink.azurewebsites.net @ns02 >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 13401 >> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 1232 >> ; COOKIE: a960c89ec8cb08b10100000067781f4693fa76a27ba9bf46 (good) >> ;; QUESTION SECTION: >> ;dnshealthcheck.privatelink.azurewebsites.net. IN A >> >> ;; Query time: 4992 msec >> ;; SERVER: ns02#53(10.53.247.71) (UDP) >> ;; WHEN: Fri Jan 03 10:32:54 MST 2025 >> ;; MSG SIZE rcvd: 101 >> >> Turning up the logging for query-errors on one of the secondaries (I >> thought it was a zone transfer issue at the time) I saw these: >> 03-Jan-2025 10:46:48.863 query-errors: debug 3: client @0x7f67c0469168 >> ns02#49282 (dnshealthcheck.privatelink.azurewebsites.net): view >> Internal: rpz QNAME rewrite >> dnshealthcheck.privatelink.azurewebsites.net stop on qresult in >> rpz_rewrite(): timed out >> 03-Jan-2025 10:46:48.863 query-errors: debug 3: client @0x7f67b7aad168 >> ns02#41110 (dnshealthcheck.privatelink.azurewebsites.net): view >> Internal: rpz QNAME rewrite >> dnshealthcheck.privatelink.azurewebsites.net stop on qresult in >> rpz_rewrite(): timed out >> 03-Jan-2025 10:46:48.863 query-errors: debug 1: client @0x7f67c0469168 >> ns02#49282 (dnshealthcheck.privatelink.azurewebsites.net): view >> Internal: query failed (timed out) for >> dnshealthcheck.privatelink.azurewebsites.net/IN/A at query.c:8113 >> 03-Jan-2025 10:46:48.863 query-errors: debug 1: client @0x7f67b7aad168 >> ns02#41110 (dnshealthcheck.privatelink.azurewebsites.net): view >> Internal: query failed (timed out) for >> dnshealthcheck.privatelink.azurewebsites.net/IN/A at query.c:8113 >> 03-Jan-2025 10:46:48.863 query-errors: debug 4: fetch completed at >> resolver.c:4519 for dnshealthcheck.privatelink.azurewebsites.net/A in >> 10.000024: timed out/success >> [domain:azurewebsites.net,referral:0,restart:2,qrysent:0,timeout:0,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0] >> >> It seems queries for similar "A" records in the RPZ zone are also >> failing. I don't think all of them are, but maybe. They do all seem to >> be associated with azurewebsites.net from what I can see so far. >> >> I looked at the source for "query.c" at line 8113 and it looks like a >> logging function, and so doesn't seem to give me more information >> about what was going on when the timeout happened, though I am >> certainly not a programmer. >> >> And at one point on one of the servers, I stumbled across this: >> >> Jan 3 12:03:14 ns0 named[10233]: network unreachable resolving >> 'dnshealthcheck.privatelink.azurewebsites.net/A/IN': >> 2a01:111:4000:700::e0#53 >> >> Which surprised me. I figured if there was an "A" record for a name in >> an RPZ zone that bind would never do a lookup for it, since it would >> be overridden anyway. >> >> That said, it seems to correlate with at least one of the nameservers >> for azurewebsites.net being unreachable (ns1-224.azure-dns.com. >> 13.107.236.224). But that shouldn't matter since the resolver should >> switch to another. >> >> The issue ran for several hours, then resolved itself, then broke >> again for a few hours, then resolved itself again and things seem to >> be fine now. All without me doing anything (as far as I know, lots of >> automation going on). >> >> So does bind do a lookup of an RPZ name even if it is going to >> override it? And also, if this happens again, are there places I >> should look besides query-errors for indicators of why it is failing? >> >> Thanks for any help, >> Adam Augustine >> -- >> Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from >> this list >> >> ISC funds the development of this software with paid support subscriptions. >> Contact us at https://www.isc.org/contact/ for more information. >> >> >> bind-users mailing list >> bind-users@lists.isc.org >> https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
