Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

[Paul Vixie <[e-mail]>]

> bert hubert <mailto:[e-mail]>
> Monday, March 16, 2015 11:23 PM
> On Mon, Mar 09, 2015 at 04:18:12PM +0100, bert hubert wrote:
>> On Mon, Mar 09, 2015 at 11:08:03AM -0000, D. J. Bernstein wrote:
>>> My "qmail" software is very widely deployed (on roughly 1 million SMTP
>>> server IP addresses) and, by default, relies upon ANY queries in a way
>>> that is guaranteed to work by the mandatory DNS standards.
> (...)
>> Do you think I read 4.3.2 wrong? Or is there another RFC that updates the
>> algorithm?
>
> Thanks to some clarification from Dan, I now understand that one can indeed
> rely on ANY queries to resolvers to either deliver a CNAME or no CNAME, in
> which case there is no CNAME. 

i'd like to see those clarifications. if any non-CNAME RRset had existed
and been cached, and then replaced by a CNAME, then ANY would not see
the CNAME until the last non-CNAME RRset had expired from that cache.

which is why, when i want to know if there is a CNAME, i ask if there's
a CNAME.

i realize that this only matters when the non-CNAME TTL's are one to two
weeks long, and weren't trimmed before replacement with the CNAME.
however, that situation is common enough that i dispute the phrase
quoted above, "guaranteed to work by mandatory DNS standards."

>
> Separately, I fail to see why we actually need to outlaw ANY queries when we
> can happily TC=1 them. 

TC=1'ing them would be a way to prevent them from being used as an
amplifying reflector. that is not the use case for this. the updated
document makes clear that the iteration complexity in split-authority
systems having a lightweight front end, is the situation where ANY is
painful.

there never was an ANY-related problem for which TC=1 was the solution.

-- 
Paul Vixie