On Fri, Sep 11, 2020 at 5:16 PM Paul Hoffman <paul.hoff...@icann.org> wrote:
> On Sep 11, 2020, at 4:40 PM, Mark Andrews <ma...@isc.org> wrote:
> >
> > and why is it a RR type at all.
>
> So that the answer can be signed and thus validated.
>
> > An EDNS option or a opcode is better suited for this sort of thing.
>
> What advantages do those have that make the loss of validation worth it?
> It would be trivial for us to change the document to EDNS or and opcode if
> the WG wanted to lose the validation capability.
>
If it isn't an RR, it can't be cached, and can only be obtained directly
("from the horse's mouth" as it were).
Given the context (recursive to authoritative), that's (IMHO) a reasonable
assumption/requirement, for how to obtain the answer, and ensure the
"liveness" of it.
If you want to go down the JSON blob path, I'm pretty sure the JSON itself
could be signed, although I am not sure on the answer of "signed with
what", or "validated how"?
It does clarify things as far as general context, though.
It would always be the server itself speaking on its own behalf, regardless
of the name(s) it is known by.
I think that actually ensures that the obtained "capabilities" map to the
server with no room for misinterpretation or zone vs server semantic errors.
This is all essentially metadata.
Yes, it could be provisioned in DNS. That doesn't necessarily make DNS the
best place for it.
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
