On Mon, Nov 4, 2019 at 6:26 AM Stephane Bortzmeyer <[email protected]>
wrote:

> On Sun, Nov 03, 2019 at 05:33:34PM -0500,
>  John Levine <[email protected]> wrote
>  a message of 14 lines which said:
>
> > I thought it might be useful to make a list of possible ways to signal
> > that a server offers ADoT:
>
> I would like also a discussion on whether signaling is 1) good 2)
> necessary.
>
> Even if you get a signal, the reality may be out-of-sync with the
> signal, for instance because of a problem on the server side (remember
> AAAAs published without checking IPv6 connectivity works) or on the
> client side (port 853 blocked).


I'm less worried about the latter because I would expect recursive
resolvers to generally be operated by people who are able to establish
their port 853 status.

So, in any case, the client has to be
> ready to encounter a problem and to try a fallback.
>
> So, why not an "happy eyeball" (RFC 8305) approach? Check 53 and 853
> more or less in parallel and keep DoT if it works.
>

Well, this is why I asked about the threat model. If we care about active
attack, then this kind of approach does not work well.

-Ekr


> _______________________________________________
> dns-privacy mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy

Reply via email to