> On Mar 9, 2015, at 11:16 AM, Edward Lewis <edward.le...@icann.org> wrote: > > On 3/9/15, 7:08, "D. J. Bernstein" <d...@cr.yp.to> wrote: > >> The common theme of CNAME/MX/A and A/AAAA is that there's widepread >> interest in being able to easily retrieve multiple record types. What >> I'm saying is not that query type ANY is the ultimate answer (clearly it >> can be improved); what I'm saying is that these are protocol issues, and >> that protocol changes need to be handled by an appropriately chartered >> IETF working group. > > (I removed the dns-operations list from this because this needs to be > discussed on DNSOP.) > > > Dan, > > You're right. But. > > Operators are not bound to comply with what the IETF documents. > > As much as operators shouldn't bully the IETF nor the public for which the > serve, the street goes two ways. The IETF is not able to and should not > bully them. The IETF is supposed to provide us with an interoperable way > to operate and is supposed to have documents that reflect "running code.”
I would be interested in hearing the results you had from disabling ANY queries, or anyone else results. This isn’t standing in opposition to change, but trying to understand the true scope and nature of this problem. Perhaps I’m missing parts of the problem, but the qmail issue has existed for 10 years. Firefox recently turned on and back off ANY queries in 36.0 and 36.0.1 to try to keep performance what it should be for websites that have low TTLs vs being ‘sticky’ to an old A/AAAA record. >> * Second: The merits of the protocol modification have to be properly >> discussed in that working group, to evaluate the costs and benefits >> of the protocol modification---and to consider whether there are >> better ways to achieve the same benefits. > > > If operators find that a protocol needs to be modified to be properly > operated, the IETF ought to adjust the protocol definition. Having a > migration path would be a plus too. (Said tongue in cheek.) > > But - "finding that a protocol needs to be modified" is not as easy as > that - hence my quoting of your words above. I’m concerned a change of this sort will cause a number of people to see something as ‘broken’ where it really is not. If we are dealing with code that will break things for existing users, giving them broad warning is important, even if they are using/abusing this capability of the DNSs system today. - Jared _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
