In article
you write:
>-=-=-=-=-=-
>
>Can I ask why you went with resolver-info.arpa instead of
>.{in-addr,ip6}.arpa of the resolver IP to which the query is being
>issued? I think the temp-field2. trick still works, and maybe we
>could get DNSSEC validation (IDK about dnssec validation in the r
>
> 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 pr
Moin!
On 30 Apr 2019, at 14:16, Paul Vixie wrote:
can dns be like tcp, put into maintainance mode, no new features?
That was the hope I believe when dnsext was closed, but then dnsop
extended it’s charter and here we are. While I’m not disagreeing
with what you propose I believe that ship has
Can I ask why you went with resolver-info.arpa instead of
.{in-addr,ip6}.arpa of the resolver IP to which the query is being
issued? I think the temp-field2. 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 a
can dns be like tcp, put into maintainance mode, no new features?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
[[ GH. The abstract of the draft says it should be discussed on the ADD
list. That's wrong, it belongs here. ]]
[[ GH2. I didn't include the draft info.
Title : DNS Resolver Information Self-publication
Authors : Puneet Sood
Roy
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
Hi,
Jan and everyone else, thanks for your feedback. It feels indeed like we
should continue with the behavior that ANAME will take precedence over A
and when on the same name. I shall go over the draft and see if the
text is correct in that sense.
Best regards,
Matthijs
On 4/30/19 11:56
On Fri, Apr 26, 2019 at 8:30 PM 神明達哉 wrote:
> > Jan Včelák mentioned that at least NS1 uses a different order of
> > priority: If an sibling address record exists next to the ANAME it takes
> > precedence and no target lookup is done for that address record type.
>
> if there's a specific use case