Paul Hoffman wrote:
> https://tools.ietf.org/html/draft-hoffman-resolver-associated-doh-01
This draft specifies that the new zone is delegated to the AS112 servers,
but RFC 7534 says the "direct delegation" approach is only supported for
the original AS112 zones. As I understand it the plan for
Greetings again. Based on the technical input I received, I ripped out the
first-guess mechanism and replaced it with one that will work with validating
stub resolvers but still work with the same use cases.
It's clear some people here don't have the use cases listed in the draft;
that's fine,
everyone, please listen.
On Saturday, August 25, 2018 8:12:27 AM UTC Vittorio Bertola wrote:
> ...
> In the end, the policy of having your names resolved by default by a local
> server on your access network, while leaving you free to configure a
> different resolver that you find out-of-band if
> Il 24 agosto 2018 alle 17.26 Vladimír Čunát ha
> scritto:
>
>
> Still, personally I'd probably prefer to choose someone from a list of
> providers, as we might have quite a lot soon, and "I" might trust some of the
> names already, and the handshake will then verify that the name matches.
On Fri, Aug 24, 2018 at 10:26 AM Paul Hoffman
wrote:
> On Aug 24, 2018, at 6:43 AM, Vladimír Čunát
> wrote:
> >
> > On 08/24/2018 02:01 AM, Paul Hoffman wrote:
> >> Thoughts?
> >
> > Well, if the OS resolver is validating, it will SERVFAIL with such a
> > query.
>
> The protocol requires
On Aug 24, 2018, at 7:45 AM, Philip Homburg wrote:
>
>>> Well, if the OS resolver is validating, it will SERVFAIL with such a
>>> query.
>>
>> The protocol requires special handling of those specific queries,
>> so a resolver that understands the protocol will give the desired
>> answer. A
> > Well, if the OS resolver is validating, it will SERVFAIL with such a
> > query.
>
> The protocol requires special handling of those specific queries,
> so a resolver that understands the protocol will give the desired
> answer. A resolver that doesn't understand the answer will give
>
On 08/24/2018 04:25 PM, Paul Hoffman wrote:
> Forwarding resolvers do not need special casing, I believe. If the forwarding
> resolver understands the protocol, it will reply. If it doesn't understand
> the protocol, it will forward and give back whatever the upstream resolver
> tells it.
Oh,
On Aug 24, 2018, at 6:43 AM, Vladimír Čunát wrote:
>
> On 08/24/2018 02:01 AM, Paul Hoffman wrote:
>> Thoughts?
>
> Well, if the OS resolver is validating, it will SERVFAIL with such a
> query.
The protocol requires special handling of those specific queries, so a resolver
that understands
On Aug 23, 2018, at 6:29 PM, John Todd wrote:
>
>
> Wouldn’t that be simpler to use SRV, and require no new RRTYPE? If a
> previously-granted resolver via DHCP was 192.168.1.1, then a lookup and
> result of:
>
> _doh._tcp.1.1.168.192.in-addr.arpa. 86400 IN SRV 10 60 443
>
10 matches
Mail list logo
