Comments -- which may have been discussed in the WG before, in which case ignore them:
- The discovery method seems to be that you look at the NS RR IP address and attempt DoT on port 853. But the requirements doc https://tools.ietf.org/html/draft-ietf-dprive-phase2-requirements-02 in requirement 7 suggests that instead of this that they auth SLD admin would specify secure transport preferences. Presumably this would be in some DNS RR in the SLD. Your proposed discovery method and what is suggested in the requirements doc seem to be at odds. - Why suggest attempting to contact via an IP rather than a FQDN in the URI? I know sometimes managing the TLS certs based on IPs rather than FQDNs can be problematic in some deployments. - Is it necessary to specify the transport cache? If it helps with performance everyone will do it. And the section other than saying there MUST be a cache does not specify anything else. Jason On 1/13/21, 8:07 PM, "dns-privacy on behalf of Paul Hoffman" <[email protected] on behalf of [email protected]> wrote: Greetings again. I have updated draft-pp-recursive-authoritative-opportunistic to include comments from the WG on -03, and to include timings that I have determined by experimenting on a large database of domain names of "typical" web sites. I am writing up that research now, but because the WG asked me to put data-driven timeouts in the draft, I did so in advance of the research. Draft: https://datatracker.ietf.org/doc/draft-pp-recursive-authoritative-opportunistic/ Diff: https://tools.ietf.org/rfcdiff?url2=draft-pp-recursive-authoritative-opportunistic-04.txt Comments before or during the interim are clearly welcome. --Paul Hoffman _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
