On 19Jan24, Dave Lawrence apparently wrote: > Mark Andrews writes: > > It’s a couple of lines of code in a nameserver to support QCOUNT=0. > > It will take more time debating this than it took to implement > > support for QCOUNT=0. > > Miek Gieben writes: > > yes, please, the amount of code that duplicates checks for > > QDCOUNT!=1 is staggering, and that just in the Golang eco-system. > > Well now I'm really a lot more curious about this.
As always, the truth is likely somewhere in the middle. Nearly two years ago on this very list I asked (https://lists.dns-oarc.net/pipermail/dns-operations/2022-March/021595.html) about the presence of QD=0 server cookies in the wild as I'd not seen any with a "from scratch" auth server I was implenting and was wondering whether it was worth adding support. I didn't get any positive responses but went ahead anyway since RFC7873 is Standards Track. This server is written in go and uses Miek's excellent dns package (github.com/miekg/dns) so I consider it part of the Golang eco-system. It's open source so if anyone wants to verify the following, I can send a link. As an exercise I just removed the QD=0 feature to see how much extra work it cost in the original implementation. Here's the SLOC counts according to github.com/boyter/scc: QD=0 Prod Tests Not supported 4252 4181 Supported 4288 4182 ---- ---- Diff 36 1 ---- ---- This is somewhat misleading because with QD=0 support the defaultMsgAcceptFunc has to be replaced with a custom function which is an exact clone of defaultMsgAcceptFunc() with one change: - if dh.Qdcount != 1 { + if dh.Qdcount > 1 { So if we don't count this clone as *new* code, say if miekg/dns supported QD=0 with a feature flag, the actual SLOC changes to the server reduce to: QD=0 Prod Tests Diff 36 1 Clone -32 ---- ---- 4 1 ---- ---- That is, 4 lines of production code and one additional row in a test-case table. In terms of just the code related to validating and processing the inbound query, those 4 lines represent 1% of the ~430 lines of relevant code which itself represents 10% of the complete server implementation. It's also the case that the implementation worried about QD=0 from day one which gave it a structural advantage of incorporating QD=0 into a standard logic flow. Existing implementations which have to retrofit may incur larger structural costs. You can spin this any way you want, so I'll let others draw their own conclusions. Before doing so though, I'll finish with one other stat of interest. In those aforementioned ~430 lines of query validation, over 20% consists of conditionals! So on one hand, dealing with QD=0 cost this implementation just one conditional; on the other hand, that one "if" lives in a sea of other conditionals due to DNS complexity. Mark. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
