Request an advice on Internet-draft about new EDE codes

[bortzmeyer]

• Program: Authoritative, Recursor, dnsdist (all of them)
• Issue type: Feature request

Short description

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.

Usecase

EDE are useful for debugging, and also to get information which may be useful about what was done.

Description

I would like to know if you would consider to implement all or some of these error codes (list in the draft) 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.

[omoerbeek]

• Tailoring: I can see its use, though it feels it a bit too broad: if ECS is use, presumably the answer is based on that (but you cannot be sure). If no ECS is used, it can be anything in the path. I would find a code that not only says "tailored" but also by whom and why more useful for debugging, though I can see negative sides of that as well as service providers are hesitant to include too much detail about the actual service implementation details.
• Minimal response: useful
• Local root: the description is quite strict: "means that the response comes from a local root". Or was meant: "a local root was involved", as in general resolver answers ar based on multiple (cached) answers from more than one authoritative server. e.g. a local root has been used to find the name servers of a TLD, but the actual answer comes from a TLD's auth.

[rgacogne]

Tailoring: I can see its use, though it feels it a bit too broad: if ECS is use, presumably the answer is based on that (but you cannot be sure). If no ECS is used, it can be anything in the path. I would find a code that not only says "tailored" but also by whom and why more useful for debugging, though I can see negative sides of that as well as service providers are hesitant to include too much detail about the actual service implementation details.

I guess the details that you would like to have could be set in the EXTRA-TEXT field, perhaps in a structured way.

Local root: the description is quite strict: "means that the response comes from a local root". Or was meant: "a local root was involved", as in general resolver answers ar based on multiple (cached) answers from more than one authoritative server. e.g. a local root has been used to find the name servers of a TLD, but the actual answer comes from a TLD's auth.

To me it would seem logical to set it as soon as a local root was involved indeed.