On 17.3.2017 20:54, Tony Finch wrote: > Petr Špaček <petr.spa...@nic.cz> wrote: >> >> The casse QTYPE=RRSIG should be made more prominent so it is understood >> and not misused as ANY. There are implementations like Knot Resolver >> which are work around missing RRSIG records in replies using >> QTYPE=RRSIG. > > Gosh! In what situations do you get missing RRSIGs? Is that not a sign > that either your upstream server doesn't support DO=1, or that you are > under attack from a malefactor / middlebox? Why not re-query a different > upstream server with the full query?
Tony, I agree with you. QTYPE=RRSIG is an attempt of drowning man to catch at a straw. It will certainly not work realiably and Knot is using it as solution of last resort if everything else failed. Please do not get distracted by this. My proposal is just about properly documenting QTYPE=RRSIG behavior so it is very clear from first read. The goal is to avoid having the very same discussion about under-defined behavior as we have around ANY today. If there is another RFC saying that QTYPE=RRSIG is special then please add a pointer to it. I might have missed that one. If there is none, please clarify the draft. I hope it clarifies that I have no objection to proposed behavior, just to the way it is described. Thank you for understanding. Proposals for clarification are here: https://mailarchive.ietf.org/arch/msg/dnsop/lZDOOOOnD1kCZQ1Zvm0YF6wbWtg > The BIND 9.11 minimal-any implementation treats RRSIG queries similarly to > ANY queries, so it only returns one RRset's RRSIGs (i.e. a subset of the > RRSIGs all with the same type-covered field). > > Cloudflare's response to RRSIG queries is REFUSED. Negligible risk of > interop problems in this case, unlike ANY. > > I think RRSIG is a diverting sideshow. It might merit a mention in the > abstract but I don't think it needs to be in the title. I'm certainly not insisting on title change. It just seemed as a cheap way to advertise that the document touhes on QTYPE=RRSIG so I did not see a reason for not mentioning it in the title. -- Petr Špaček @ CZ.NIC _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
