Hi Hongying, 1. I don't think that synchronization between the A/AAAA and ipv4hint/ipv6hint is very important. As long as all the listed addresses are valid and reasonably appropriate, everything will work fine; there's no need for them to be the same. However, the draft does imagine that there is a risk of the IP hints being less carefully selected or out of date. 2. Using the hints is beneficial when (1) TargetName was not predicted (i.e. "." for HTTPS normally) and (2) its A/AAAA records are not already known to the client (and (3) the resolver does not provide the followup query optimization). In the absence of hints, the client would have to perform its own followup query and wait for an answer before initiating the connection attempt, resulting in delayed connection establishment. 3. Correct, "locally available" normally means "already in the local DNS cache". 4. Correct, the intention is that authoritative servers should stop including IP hints once most recursive resolvers become Section 4-compliant. 5. I have heard that Akamai CacheServe implements the optimization today. I don't know if there are other implementations. 6. I don't know much about the state of client implementations.
--Ben Schwartz ________________________________ From: DNSOP <dnsop-boun...@ietf.org> on behalf of Hongying Dong <hd7gr=40virginia....@dmarc.ietf.org> Sent: Monday, July 24, 2023 1:13 PM To: dnsop@ietf.org <dnsop@ietf.org> Subject: [DNSOP] Questions on DNS HTTPS/SVCB spec and deployment Hello,We are researchers at the University of Virginia studying some aspects of the DNS HTTPS/SVCB specification and how it is deployed in practice. We had a few questions we are hoping you can provide the answers to. Primarily we are examining Hello,We are researchers at the University of Virginia studying some aspects of the DNS HTTPS/SVCB specification and how it is deployed in practice. We had a few questions we are hoping you can provide the answers to. Primarily we are examining HTTPS right now, but if the answers can be generally provided for SVCB too, that would be great.* IPv4 and IPv6 hints. The "ipv4hint" and "ipv6hint" keys convey IP addresses that clients MAY use to reach the service. If A and AAAA records for TargetName are locally available, the client SHOULD ignore these hints. Otherwise, clients SHOULD perform A and/or AAAA queries for TargetName as in Section 3, and clients SHOULD use the IP address in those responses for future connections. Clients MAY opt to terminate any connections using the addresses in hints and instead switch to the addresses in response to the TargetName query. Failure to use A and/or AAAA response addresses could negatively impact load balancing or other geo-aware features and thereby degrade client performance. It seems to us that unless the IPv4 and IPv6 hints are kept diligently in sync with the actual addresses in the A and AAAA records, this could easily pose operational problems in the field. The draft appears to concur and says clients should see if they are "locally available", and otherwise "SHOULD" perform A/AAAA address lookups. If so, under what circumstances is it beneficial for an implementation to follow the "MAY" instruction of the first line in the above quoted paragraph and use the hints?Also what does "If the A and AAAA records for Targetname are _locally available_" mean? Is the expectation that HTTPS client applications run a local DNS cache from which this information could be extracted?The answer to the "MAY use hints" is suggested later on in this paragraph: These parameters are intended to minimize additional connection latency when a recursive resolver is not compliant with the requirements in Section 4, and SHOULD NOT be included if most clients are using compliant recursive resolvers. First, how would a client application generally know that a recursive server is compliant with Section 4 (i.e. proactively fetching the A and AAAA records for the HTTPS Targetname and providing them in the response)? Is there a proposed DNS API function that provides this information, or are clients expected to write custom code to parse the full response from a recursive server to figure this out? Second, how would a service operator publishing HTTPS records know if most of their clients are using compliant recursive servers to help them make a decision about including IP hints? Or does this statement imply that everyone should deploy IP hints until the ecosystem has gained a critical mass of recursive servers that are compliant?What recursive servers today support this optimization? We've examined several of the public DNS resolvers (Google, Cloudflare, Quad9, and OpenDNS) and none of them appear to. We haven't looked at the open source implementations yet, but if anyone can answer that would be appreciated too.Client implementation behavior in the field: What do existing web browsers/clients (e.g. Firefox, Chrome, Safari, etc) that support DNS HTTPS records do today? Under what conditions do they use the hints vs. query explicitly for address records? Thank you so much! Hongying -- Hongying Dong Ph.D. Candidate in Computer Engineering University of Virginia
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
