On Tue, Sep 17, 2024 at 03:16:43PM +0200, Petr Špaček wrote:
> On 16. 09. 24 18:36, Otto Moerbeek wrote:
> > On Mon, Sep 16, 2024 at 06:08:10PM +0200, Stephane Bortzmeyer wrote:
> >
> > > On Mon, Sep 16, 2024 at 08:23:43AM -0700,
> > > Wes Hardaker <[email protected]> wrote
> > > a message of 38 lines which said:
> > >
> > > > > * One to say that the response was deliberately minimal (RFC 8482)
> > >
> > > > For #1 - a more exact definition would be helpful. Minimal how?
> > > > One thing we discovered writing the EDE draft is that it was better
> > > > tqo have more code that clearly indicated exactly how things were
> > > > being affected.
> > >
> > > EDE 29 (Synthesized) is not really a model here. It is quite
> > > vague. (With the current policy, it can be expected.)
> >
> > Synthesized is intended to mark an answer constructed by a resolver,
> > when the verbatim answer is not received earlier from an authoritative
> > server, but based on earlier answers to different question plus some
> > decision logic e.g. from RFC8020 or RFC8198.
> >
> > If there is a desire to have different EDEs for the differrent ways
> > answers can be syntesized, I'll be glad to come up with a list. Up
> > until now PowerDNS Recursor provides the details in the text part of
> > the EDE.
>
> I think EDE 29 (Synthesized) with text note "RFC 8482" is perfectly
> appropriate for the made-up HINFO answer to ANY (or RRSIG or ...) query.
>
> For other ANY cases, I'm not sure it is worth burning code on it. Nobody can
> rely on presence of EDE so it does not give the debugging person useful
> information anyway.
I must be misunderstanding. e.g. if I know I'm talking to a PowerDNS
Recursor, both the presense and absense of EDE tell me useful info
about what is going on and how the answer was obtained.
-Otto
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
