[FR] Support for RESINFO RRType 261 (RFC9606)

[mdavids]

Current behavior
It seems that the RFC9606 RESINFO RRType 261 is not yet supported.
(I checked version 1.22.0)

Describe the desired feature
Support RESINFO RRType

Potential use-case
For example to be able to use it in local-data, like:

local-data: 'resolver.arpa RESINFO "qnamemin temp-dnssecval infourl=https://example.nl"'

[gthess]

Hi @mdavids,

I added the RESINFO type, so the potential use-case can be used in the configuration.

However I believe this needs a second pass in the future (why I leave the issue open atm), to properly address the RFC.
With that in mind, Unbound needs to intercept the RESINFO type (because it could be any name AFAIK) and, if enabled to reply, give out the information or refuse otherwise. It would be possible to custom configure the contents of the record to accommodate for unknown keys like temp-dnsseceval in your example.

[mdavids]

Thank you for doing this. And I appreciate you leave the issue open for a second pass.

I've been thinking about this as well, as the RFC raises some questions with me. It might perhaps be a bit ambiguous.

The RFC says that a client: "MUST set the RD bit to 0 and MUST discard the response if the AA flag in the response is set to 0".

The 'local-data method' seems to provide the proper response under these conditions (I tested it with TXT, for the lack of RESINFO), so that could be sufficient. But maybe you can think of better ways to implement RFC9606-support in Unbound?

To me RFC9606 has some resemblance with RFC4892 ("id.server"), but then again, maybe not. It seems okay to forward any RESINFO queries when there is no local-data or similar 'interception mechanism' defined, given the RD and AA requirements mentioned above. But I'm still a bit puzzled here.

Anyway... You might want to test this in real life with DNS4ALL, where we made an attempt to implement it:

dig +https +norec @resolver.dns4all.eu RESINFO resolver.dns4all.eu

dig +https +norec @resolver.dns4all.eu RESINFO resolver.arpa

With and without RD-bit, to see the difference. What do you think?

Also, please note the DoH-option, which is one of two REQUIRED options mentioned in the _Security Consideration_s section. The other one is 'local DNSSEC validation', which I don't quite understand (we do not prohibit Do53 however, because we don't care).

[gthess]

The RFC says that a client: "MUST set the RD bit to 0 and MUST discard the response if the AA flag in the response is set to 0".

I believe the part about the AA flag is so that client is sure the reply is coming from the resolver itself.
The part about the RD is for the resolver to not try and process/forward that further if it doesn't know about RESINFO.

So I believe if your resolver knows about RESINFO, it can reply with the AA flag and don't care about the client RD bit because it will never try to resolve it in the first place.

To me RFC9606 has some resemblance with RFC4892 ("id.server"), but then again, maybe not. It seems okay to forward any RESINFO queries when there is no local-data or similar 'interception mechanism' defined, given the RD and AA requirements mentioned above. But I'm still a bit puzzled here.

Actually this is exactly how I was planning to implement this. Intercept the RESINFO type regardless of the qname and return back the information depending how Unbound is configured. If no information is to be returned, refused would be used. But since Unbound would know about RESINFO, it will never process the query further.

The other one is 'local DNSSEC validation', which I don't quite understand (we do not prohibit Do53 however, because we don't care).

I don't think that DNSSEC can help in practice. For sure you can't sign resolver.arpa, and having signed information in a zone-ish thing does not mean that the resolver that happens to serve that record has those capabilities. It would also be an operational nightmare I suppose.
So transport security does help for the client, but the resolver can just answer with RESINFO anywhere.

---

Btw I am thinking along these lines for configuration (also note to self):

server:
    ...
    resinfo: yes
    resinfo-qnamemin: yes
    resinfo-exterr: yes
    resinfo-exterr-override: "<provide own values for the exterr key>"
    resinfo-infourl: ""
    resinfo-override: "<a whole custom RESINFO record, it will override everything>"
    resinfo-additional: "<additional data to include, like temp-dnsseceval"
    ...

[mdavids]

FYI: please note that I did not make up 'temp-dnsseceval' entirely out of the blue:

https://datatracker.ietf.org/doc/draft-bortzmeyer-add-resinfo-dnssecval-dns64/