How to use static hints for local PTR records?

Is it possible to use the static hints module to provide local PTR records? This is hinted at in the documentation however no example is provided. Perhaps I am misinterpreting what is possible with kresd so if that is the case, please clarify.

You assign the address-name pairs just once, and both forward and PTR records get generated from those.

I think my issue is I am desiring local PTR records for local devices with RFC 1918 private addresses. Observe:

configured hosts file

[jon@fedora ~]$ cat /etc/knot-resolver/hosts.kresd
...
192.168.12.34 notarealhost.notarealdomain.zzz notarealhost
216.109.199.128 test.ptr.host.record.xyz

relevant portion of kresd.conf

(...)

-- Load useful modules
modules = {
        'hints > iterate',       -- Load /etc/hosts and allow custom root hints
        'serve_stale < cache',   -- Serve stale records when connection is poor
        'prefill',               -- Prefill cache with root zone data
        'rebinding < iterate',   -- Protect against rebinding attacks
        'stats',                 -- Track internal statistics
        'predict',               -- Prefetch expiring/frequent records
        'bogus_log'              -- Log DNSSEC failures
}

(...)

-- Load local host definitions
hints.config('/etc/knot-resolver/hosts.kresd')

(...)

results for reverse lookup of public IPv4: works as expected

~ ❯ dig -x 216.109.199.128

; <<>> DiG 9.10.6 <<>> -x 216.109.199.128
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55059
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;128.199.109.216.in-addr.arpa.	IN	PTR

;; ANSWER SECTION:
128.199.109.216.in-addr.arpa. 5	IN	PTR	test.ptr.host.record.xyz.

;; Query time: 69 msec
;; SERVER: 192.168.5.10#53(192.168.5.10)
;; WHEN: Wed Dec 22 15:27:30 EST 2021
;; MSG SIZE  rcvd: 95

results for reverse lookup of private RFC 1918 IPv4: blocked

~ ❯ dig -x 192.168.12.34

; <<>> DiG 9.10.6 <<>> -x 192.168.12.34
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 55866
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;34.12.168.192.in-addr.arpa.	IN	PTR

;; AUTHORITY SECTION:
34.12.168.192.in-addr.arpa. 10800 IN	SOA	34.12.168.192.in-addr.arpa. nobody.invalid. 1 3600 1200 604800 10800

;; ADDITIONAL SECTION:
explanation.invalid.	10800	IN	TXT	"Blocking is mandated by standards, see references on https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml"

;; Query time: 53 msec
;; SERVER: 192.168.5.10#53(192.168.5.10)
;; WHEN: Wed Dec 22 15:29:44 EST 2021
;; MSG SIZE  rcvd: 278

Edit: it looks like adding policy.add(policy.suffix(policy.PASS, {todname('168.192.in-addr.arpa.')})) to kresd.conf will override the built-in policy that broadly blocks queries for PTR records of private addresses.

Is there a better way to have kresd not block PTR requests for local addresses?

This should all be contained to the local resolver and never make it across the wire to the public Internet. Using the above policy override, a reverse query for a local address that isn't defined in a hint for kresd gets to the iterator stage and kresd queries upstream servers. I don't think this is desirable behavior so I understand why the default policy exists. I'd really like to be able to have PTR's for local (private) addresses but also not have to worry that PTR queries for addresses not defined in hints make it to upstream resolvers.

Any ideas?

Ah, right. You found the best way I know. We should've put a warning into hints docs. Policies take precedence before hints and know nothing about hints.

This is one of the design problems of current policy-related functionality. It will be fixed within #535 (this part already worked in the early prototype IIRC)

Policies take precedence before hints and know nothing about hints.

Is there a way to change the order of operation for policies and hints so hints would apply before policies? I did a modules.list() on my running instance and saw that the policy module came after the hints module in the list. Wasn't sure if that order was indicative of processing order internally though.

A related comment: what does the use of < and > signify in the modules = { ... } list? I couldn't find these defined clearly in the documentation and I don't think it's obvious what they do.

Well, this digs relatively deep into implementation details. Modules are linearly ordered, which is what you can see in modules.list() and choose by those signs*.

In this case messing with order can't help, because policy module is written to deny stuff in a very early phase before "normal resolution" starts and hints module is written to affect this "normal resolution".

* foo < bar means loading foo as closest predecessor of bar; foo > bar means loading foo as the closest successor of `bar.

It's like policy is on the client side of resolver and hints on the upstream side.

I tried to at least improve the docs now: !1244 (merged)

Thanks for all the feedback.

Ah yes having that in place should prevent further confusion with newer users wondering why local PTRs don't work. Local PTRs "just work" with dnsmasq so any users expecting similar functionality with kresd would be quite confused (as I was).