On 3/9/15, 11:36, "Jared Mauch" <ja...@puck.nether.net> wrote:
>I would be interested in hearing the results you had from disabling ANY >queries, or anyone else results. We got a few complaints to the help desk. To quiet this, we resumed answering with a mind to stopping again in the future. The next was to take on messaging towards a resumption of disabling ANY responses, this did happen (and there are presentations in some archives as a result of this) including the set of slides I refer to as my manifesto (DNS-OARC, Dublin workshop). Then events overcame concern about the ANY load. Our system became over-provisioned enough to handle the extra load we experienced and we developed a solution to handling DDos flood attacks. Inside operations, the ANY queries were no longer a concern. I'll add that what never rose up as an issue, as is mentioned in the blog post, was the complication in assembling the ANY response in face of tailored responses. From this I cannot conclude anything, either we didn't see the complication or we never looked hard enough. But I can see that this could be an issue. >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. I think you are correct is saying that there are missing parts of the problem. Not saying "you are missing" but I believe that there hasn't been a formal tradeoff analysis documented and made public. I'm a bit concerned that some have proposed expanding the scope to include other queries (meta- and RRSIG) without having the problem fully discussed. And this opens the door to whether "Firefox was brow-beaten" or observed load caused Firefox to be convinced to reverse course. >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. While I am of the opinion that disabling ANY queries would be a good thing to do, I'll admit that I am not certain. I could be wrong. I haven't undertaken any such study because my motivation to spend time on this has evaporated (no longer being an operator for one). But I will contribute my experiences and hypothesis to anyone performing the study.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
