* Paul Vixie: [QTYPE=ANY deprecation]
> so, can you explain what you mean by "breaks", both for sendmail and > qmail? I thought deprecation means that responders (especially resolvers) are free to discard such queries. At least that's how the binary label deprecation was interpreted by some folks. I don't see how this would be different, at least for resolvers. [QCLASS != IN deprecation] > 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? Reducing the arbitrariness of the DNS header reduces the risk that you run into a query/response loop with some other service (like chargen or time). >> > RA=1 AND RD=0 >> >> By the responder or the initiator? > > nonrecursive queries of recursive servers [snip] Ahem, my concern was that the RA bit is set by the responder, while the RD bit is set by the initiator. RA=1 *queries* don't make much sense, no matter what the RD bit is. As Peter Koch noted, RA=1, RD=0 responses occur in the wild. So I was confused. [DNS over TCP deprecation] >> 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? No need to update RFC 1035, RFC 1123 already did that: "A name server MAY limit the resources it devotes to TCP queries" (section 6.1.3.2). > 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. I agree it's a bad idea to roll out TCP-only resolvers without changes on the authoritative side. An EDNS0 flag saying "I'm willing to take the TCP load" might be necessary. > did RDP (RFC 908, RFC 1151) ever achieve critical mass? Not likely, given that the acronym has been reused for something totally different. I think for reliable datagram transport with some deployment, you need to use SCTP. I've never seen this RDP in the wild. -- Florian Weimer <[EMAIL PROTECTED]> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
