> > ... let's deprecate these bit patterns altogether for OP=QUERY: > > > > QTYPE=255 > > Breaks some sendmail versions and qmail.
i once hacked sendmail internals, and what i remember is that it would try a QTYPE=ANY to see if it could get both the MX and its A in one shot, on the hopeful assumption that they had the same domain name. an earlier version had a bug whereby it didn't know ANY was hop-by-hop even in the presence of RD=1, so a partial answer of "A alone" was taken to mean there was no MX, but this was fixed before my son (who is now 17) was born. no version i know of will fail to make an explicit MX query if ANY comes up dry, or fail to make follow-on A queries if ANY comes up without an A. so, can you explain what you mean by "breaks", both for sendmail and qmail? > > QCLASS=255 > > QCLASS != IN seems more reasonable to me. i don't think we should foreclose the possibility that QCLASS != IN will be useful to somebody some day. do you know a specific risk for QCLASS != IN? > > RA=1 AND RD=0 > > By the responder or the initiator? nonrecursive queries of recursive servers are a useful diagnostic but also an information leak that can help an attacker shape their flows. peter koch has reminded me that a server that's both authoritative and recursive would not be able to answer wearing its authoritative hat if this were literally enforced, and while i think there should be no server wearing both a recursive hat and an authoritative hat, i don't think we should legislate against it in this proposal. so we can't literally outlaw a bit pattern, but we can say, if RD=0 then no non-authority data should be returned. > > and let's also make explicit that TCP is not to be used unless UDP > > returns TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only > > one SOA. > > I strongly oppose this approach. Unsolicited TCP has its place. are you strongly in favour of amending RFC 1035 4.2.2 to say that responders initiate close, or that timeouts of less than two minutes are allowed? this is the one of the least scalable and most vulnerable elements in all of DNS. with rich stevens gone and nobody to complete or champion T/TCP, we're left with several bad multipacket protocols including IP fragmentation and TCP for handling data larger than the MTU. i don't know how to make TCP scale for this, it's not like TCP/80 where server operators who want to handle a million simultaneous queries know that they'll need a lot of silicon+power to do it. did RDP (RFC 908, RFC 1151) ever achieve critical mass? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
