Can I ask why you went with resolver-info.arpa instead of
<rev-ip>.{in-addr,ip6}.arpa of the resolver IP to which the query is being
issued? I think the temp-field2.<stuff> trick still works, and maybe we
could get DNSSEC validation (IDK about dnssec validation in the rev-ip
..arpa space).
On Tue, 30 Apr 2019 at 14:10, Paul Hoffman <[email protected]> wrote:
> [[ GAAAAH. The abstract of the draft says it should be discussed on the
> ADD list. That's wrong, it belongs here. ]]
>
> [[ GAAAAH2. I didn't include the draft info.
> Title : DNS Resolver Information Self-publication
> Authors : Puneet Sood
> Roy Arends
> Paul Hoffman
> Filename : draft-sah-resolver-information-00.txt
> Pages : 9
> Date : 2019-04-30 ]]
>
> Greetings again. Puneet, Roy and I have just published a -00 with an idea
> for how to get information about a recursive resolver from the resolver, if
> it wants to give that information. This is an outgrowth of my earlier work
> in the DOH WG on draft-ietf-doh-resolver-associated-doh. The discussion on
> that latter draft in Prague had a couple of people saying "this should be
> more general than just DoH" and "what about DoT", which sparked the idea
> for draft-sah-resolver-information.
>
> Note as you read this document that we have *not* started filling in the
> kind of information that a resolver might return; we haven't even specified
> the DoH stuff. We wanted to be sure that DNSOP folks thought that the
> direction here might be viable; if so, I'll write an associated draft for a
> resolver's associated DoH and DoT servers, and some of you might start
> writing drafts for other ideas.
>
> Also note that this is explicitly only for resolvers; we might later do a
> second protocol for authoritative servers who want to give information
> about themselves (such as if they do DoT, if that moves forward in DPRIVE).
> The reason for the split is that a resolver that doesn't know the protocol
> here might pass the query on to the authoritative servers for the root or
> .arpa, and the response to the stub would then be ambiguous.
>
> We look forward to your bashing and/or support.
>
> --Paul Hoffman
>
>
> _______________________________________________
> DNSOP mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
>
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
