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
