I agree with Ben on all points (*) and would prefer to see none of the proposed amendments published.
(*) I think that the push qualification is not necessary, but it is not as clearly a misunderstanding as Ben suggests. It clearly limits this to configured URIs, which seems in line with original intent. However, it likely denies access to server push in several cases, including after redirects. On Sat, Aug 29, 2020, at 00:41, Ben Schwartz wrote: [...] > The ".well-known" proposal (Section 6) does what RFC 8484 avoided > doing: it proposes an alternative encoding of DNS records in JSON. I would suggest that authors join the "resolver info" beauty contest. The use of .well-known rather than (for example) a link relation is clearly inferior for the reasons Ben mentions. But I tend to think that resource records are more appropriate for this particular application, as they work in more cases. > The 3XX proposal (Section 7) sends DNS records in the body of a 3XX > response. A client that doesn't follow a redirect isn't much use, so the question for me is whether the client gets the extra info it needs. It seems to me like clients will follow the redirect and discard any content. That would lead to the extra stuff being dropped. I would expect a DoH client to make a separate query if it needed more information to follow the redirect. A superior design would be to push necessary A/AAAA/CNAME records. If the client makes a query that ends up at the pushed URI, then this will save time without having to invent novel handling for HTTP messages. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
