[FR] Request an advice on Internet-draft about new EDE codes

[bortzmeyer]

Describe the desired feature
The Internet draft draft-bortzmeyer-more-edes creates three new EDE (Extended DNS Errors) codes. At the IETF meeting in Dublin in november, Petr Špaček suggested to request feedback from implementors.

Therefore, I would like to know if you would consider to implement all or some of these error codes and if you find them useful.

Note that the policy for the EDE registry is just "first come, first served" so consensus is not strictly necessary but would obviously be cool.

Potential use-case
Debugging and information

[wcawijngaards]

For these three ede codes, there are now no plans to use them. No specific need for them exists, that has us want them already. For debugging purposes, it could be added to have support for them. The additional information that EDE provides is useful for debugging, and so they could be useful to extend the information.

In debug by reading through voluminous logs of Unbound, the information from these code is mostly obvious from the response itself. I mean that a minimal response looks like that, and ecs has its own code, and hyperlocal roots show from config, and often these considerations are not part of the problem. But more debug information is helpful.

[gthess]

For the sake of discussion my concerns are:

• IP tailoring, this can already be covered by one of the available blocked, censored, prohibited, forged answer. Not sure if operators would like to be specific about IP. For the example of ECS, you can tell by the returned option if the answer is tailored for your IP range, or available for all networks (i.e., 0.0.0.0/0).
• Minimal response, for operators that configure minimal responses it seems counter intuitive to enlarge the response with EDE codes because then Unbound would almost always reply with the given EDE code.
• Local root, not clear to me if that would be attached to root replies specifically or any answer that started iterating from the local root down.

With my implementer's hat on if these were to be introduced they would probably be configurable and not turned on by default when ede: yes is used.

[bortzmeyer]

* IP tailoring, this can already be covered by one of the available blocked, censored, prohibited, forged answer. 

I do not see the relationship.

For the example of ECS, you can tell by the returned option if the answer is tailored for your IP range, or available for all networks (i.e., 0.0.0.0/0).

No, the reply just says that the server understands ECS, not that this specific address was tailored.

% dig +subnet=92.0.2.0/24 @8.8.8.8 www.bortzmeyer.org 

; <<>> DiG 9.18.28-1~deb12u2-Debian <<>> +subnet @8.8.8.8 www.bortzmeyer.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61275
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
; CLIENT-SUBNET: 92.0.2.0/24/0
;; QUESTION SECTION:
;www.bortzmeyer.org.	IN A

;; ANSWER SECTION:
www.bortzmeyer.org.	3445 IN	A 80.77.95.49
www.bortzmeyer.org.	3445 IN	RRSIG A 13 3 86400 (
				20241212031111 20241127203526 21439 bortzmeyer.org.
				GwUhBuO4kgz4Qt55Lpq2CykhkdMowgxxTMhOX32wHQxO
				dcI2HTwD6WWy5iBJTJZtovMFVWB2YpoTXY1jQoa/0g== )

;; Query time: 20 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Tue Dec 03 11:47:52 CET 2024
;; MSG SIZE  rcvd: 184

(Here, there is just one address so no tailorisation.)

[gthess]

I do not see the relationship.

I mean that based on IP an answer could be tailored (forged answer, censored), or denied (blocked, censored, prohibited). And it could rely on configuration per local data or RPZ file you load.

No, the reply just says that the server understands ECS, not that this specific address was tailored.

That answer has a SCOPE PREFIX-LENGHT of 0 which means that the reply is good for all networks. If that was higher it would mean alternate answers exist for other networks. The FAMILY and SOURCE PREFIX-LENGTH are always echoed back from the auth name server.
I maybe was not precise by using the '0.0.0.0/0' notation earlier, instead I should have used just '/0'.