On Tue, Oct 29, 2019 at 6:10 PM Ben Schwartz wrote:
>
>
> On Tue, Oct 29, 2019 at 7:04 PM Paul Wouters wrote:
>
>> On Tue, 29 Oct 2019, Neil Cook wrote:
>>
>> > FWIW, I've previously stated a preference for dropping the use
>> of ".well-known" entirely, and using draft-00's "resolver-info.
On Tue, Oct 29, 2019 at 7:04 PM Paul Wouters wrote:
> On Tue, 29 Oct 2019, Neil Cook wrote:
>
> > FWIW, I've previously stated a preference for dropping the use
> of ".well-known" entirely, and using draft-00's "resolver-info.arpa" name
> instead of reverse-IP, in order to improve support f
On Tue, 29 Oct 2019, Neil Cook wrote:
FWIW, I've previously stated a preference for dropping the use of ".well-known"
entirely, and using draft-00's "resolver-info.arpa" name instead of reverse-IP, in order
to improve support for
passive forwarders. I understand this was changed i
Roman Danyliw has entered the following ballot position for
draft-ietf-dnsop-obsolete-dlv-01: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer
> On 28 Oct 2019, at 18:55, Ben Schwartz wrote:
> FWIW, I've previously stated a preference for dropping the use of
> ".well-known" entirely, and using draft-00's "resolver-info.arpa" name
> instead of reverse-IP, in order to improve support for passive forwarders. I
> understand this was c
The scenario I describe isn’t about discovering intermediate resolvers, it’s
about ensuring that you can use the described protocol to get the actual
resolver info when there’s an intermediate resolver in the path. That can be
achieved with the DNS-based mechanism in the draft, but not with the