On 11. 09. 24 15:22, Stephane Bortzmeyer wrote:
In the current registry for Extended DNS Error Codes (RFC 8914), there
are codes that may be interesting to add:
* One to say that the response was deliberately minimal (RFC 8482)
* One to say that the response comes from a local root (RFC 8806)
* One to say that the response has been tailored because of ECS (RFC
7871) [the most useful, IMHO]
I am thinking about asking for a registration. Policy for this
registry is "first come, first served". Before I start sending email
to IANA, I ask your advice. Is it a good idea? Will the authors of
resolver / authoritative software use it?
I was asked for feedback with an implementer hat on, so here it goes:
TL;DR 3. Minimal response makes sense if exploded into several codes for
RFC 8482 section 4.1/4.2/4.3. The other two, I don't think so.
### 2. Tailoring
> This response code, TBD, means that the response has been tailored on
the basis of the IP address of the client. It can be from its actual IP
address in the query (DNS-based load balancing), or because of ECS (EDNS
Client Subnet, [RFC7871]). It MAY be sent by authoritative servers or
resolvers, for instance when they implement ECS. Note that the fact that
the server accepts ECS can also be seen in the EDNS part of the
response, but it does not mean that ECS was actually used to tailor the
answer. Also, this response code is more general than just ECS.
> If a resolver receives this EDE from an authoritative server, it
SHOULD copy it in the response sent to its client.
I'm not sure what to do if tailoring has multiple inputs. What if
tailored response if based on (IP address, load on target servers)
tuple? Include the EDE? Or not? Or include two EDEs? I think we can't
even list all the possible inputs, and I don't like the current definition.
Second thing is that it probably does not make sense to send this when
ECS option is actually present in the answer, but then ... code
complexity ... Bleh.
Conclusion: I don't like it. If we want to supply this information then
I think we should just add the ECS option with scope to the answer
instead of a fuzzily defined EDE.
### 3. Minimal response
> This response code, TBD, means that the response was deliberately
minimal. It can be because the request was using the QTYPE ANY, as
documented by [RFC8482]. Or it can be also for cases like "glue records
not sent since I wanted to save bits". It MAY be sent by authoritative
servers or resolvers.
Originally I thought that code 29 Synthetized is good enough, but I got
convinced by Wes Harderer that more granularity makes sense for
debugging tools. So - IMHO it should use multiple codes for distinct
cases described in RFC 8482 and _do not_ cover anything outside of RFC
8482. In the end implementations tend to pick one of the N options, so
it should not be significant code complexity on the responder side while
providing fine-grained information to receiver.
Conclusion: Seems reasonable **if** it uses multiple codes for distinct
cases.
### 4. Local root
> This response code, TBD, means that the response comes from a local
> root, as documented in [RFC8806]. It MAY be sent by resolvers using
> a local root.
Depending on the responder in question, there might be no distinction at
all between "local root" and "normal zone". Also a distinction between
"pure resolver" and a generic DNS responder might get sorta fuzzy. All
in all I think this particular code is too vague and possibly harder to
determine from inside implementation without an an additional config,
and I'm certainly against adding config knobs just for this EDE.
Conclusion: Please don't.
--
Petr Špaček
Internet Systems Consortium
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
