On Mon, Jul 24, 2023 at 1:14 PM Hongying Dong <hd7gr= 40virginia....@dmarc.ietf.org> wrote:
> 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? > If a client using the hints is unworkable for a domain, then the domain can always not include the hints. They are there for cases where some server might be able to do things slightly better if A/AAAA results are used but HTTPS hints are also acceptable, especially if the domain owner knows that the benefit of A/AAAA is not likely sufficient to make up for it if the client has to do extra DNS roundtrips and deal with extra chances for DNS failures. > 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? > Yes, exactly that. The vast majority of modern DNS clients have local cache mechanisms. > 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? > The client only needs to look at the HTTPS response and see if it contains the relevant A/AAAA records. If they are there, the client can use them and not need to make any additional queries. If the necessary records are not included in the response, it means the recursive server did not query them (or less likely, that the records do not exist). If the client receives the hints in a response but not A/AAAA records, the client then has the option between using the hints or waiting on the results for additional A/AAAA queries. > 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? > I believe this is mostly about ecosystem critical mass, but there may be special cases where a domain is only used for some specific use by specific clients where there may be more specific knowledge. > 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? > Chrome does not yet support any cases where hints or followup queries are necessary, only the more basic uses of HTTPS. It's in the plans, but just not implemented yet. When it is implemented, subject to change, but the current plan is to prefer using hints over blocking on additional queries (unless A/AAAA are available in the response or the cache). From our perspective, there's just very little chance the A/AAAA could be so much better for it to be worth making the user wait for additional query roundtrips. > > > 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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
