>>> If something gets an ANY response that does not include the thing it >>> really needs, how is it supposed to know that it needs to ask again? >> >> If something is unable to unambiguously ask for the exact thing it >> really needs, that's their problem. It's not a concern for this WG or >> the DNS protocol. > > Yes, I understand that is a popular opinion. However, I would argue > that it is unhelpfully elitist.
I disagree. This has to do with caching, so pretty fundamental to the DNS. > The traditional understanding of ANY == ALL is well ingrained in > developers. If the query goes directly to an authoritative name server, that has historically been the case, yes. If, on the other hand, you have an application making DNS queries, it typically uses a stub resolver, so sends all its queries via a caching recursive resolver. What you then get back as a response to an "ANY" query will depend on what other queries has already been resolved through that caching recursive resolver already, because in that context ANY means "all the records you might already have in the cache already for the given name". And even further, the different RRsets for the same name might have different TTLs, so will expire from the cache at different times. There is therefore absolutely no guarantee that the result of quering a recursive resolver and an authoritative name server with the same ANY query will produce the same result -- a recursive resolver can't know that it is "missing" records of certain types for the given query name. Only in the cases where the recursive resolver has no cached entries for the queried name, the ANY query would be passed on to the auth servers, and historically that has managed to fetch e.g. all of A, AAAA and MX in one transaction. However, you haven't been able to rely on that as the single method, so you need to code fallbacks to query the individual record types you need if any of them don't turn up as a result of an ANY query. In other words, a godawful mess for marginal gains. The proposed draft would in effect invalidate the "optimization" that the ANY query method might in some cases provide. No big loss, IMHO. Therefore I'm entirely with Jim on this one: if an application needs an MX record, it had better explicitly query for it. ANY has historically primarily been a debugging aid and isn't really suitable for use by applications. Regards, - Håvard _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
