On Fri, Dec 6, 2019 at 2:45 PM Eric Orth <ericorth=
40google....@dmarc.ietf.org> wrote:
> Been reviewing the latest draft with a bunch of relevant experts within
> the Chrome team. As has been stated in previous emails and in WG sessions,
> we generally like the HTTPSSVC approach and are very interested in trying
> out an implementation.
>
> Some specific feedback:
>
> - Section 2.5: We see no valid reason to support an alias chain 8
> nodes long. Such a case is likely only configuration error, and following
> the full chain would subject our users to bad performance that the
> configurer is not likely to notice and fix. Therefore, unless somebody
> comes up with a good reason that longer chains need to be supported, we
> intend to only follow 1 or 2 links before giving up on following the chain
> further, and the spec should be updated to say that such chains should be
> limited as such. I hear not everybody in the stack can reasonably enforce
> this limit, so maybe state that longer chains are not valid, should not be
> created, and clients/resolvers that can enforce limits should use the value
> specced here for that enforcement.
>
>
There are several important points on this, particularly from the
perspective of DNS folks.
1. The main motivation for ANAME, and for us being happy with H6C
solving the problems with ANAME and making it un-necessary, is that current
"apex CNAME hacks" are all limited to incompatible vertically-integrated
providers. Too short an alias chain has the potential effect of
constraining actual use of H6C to vertically-integrated providers. This is
not acceptable, and non-negotiable; the minimum length needs to be
demonstrated as facilitating real-world use in heterogenous environments.
2. The whole concept of CNAME (and implicitly H6C) is that the owner of
the CNAME (left hand side) and the target (right hand side) aren't
guaranteed to be under control of a single administrative entity. The
operator of the target may not even be aware of being the target of a
CNAME. So, the semantic construct "configurer" isn't really guaranteed to
exist, and performance issues may not reside in a single entities' area of
responsibility.
3. Notwithstanding the desire of browsers to have good performance,
there is no way to force good performance universally, regardless of such
desire. DNS latency is often unrelated to number of iterations in
CNAME/DNAME/H8C.
4. Latency will only occur at the time of first resolution of any given
chain. Resolver caches will serve the results for min({TTL of all records
in the chain}). Refreshing expired records (similar to HAMMER) can mitigate
any cache expiry impact.
There are any number of reasons longer chains might be created, and I think
having data to analyze on the distribution of lengths of chains, plus the
relative popularity, should inform any choice of limit.
Once that data is available, I'd suggest something like 3 sigmas above
median value, as a starting point for the discussion.
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
