Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On 19 Aug 2008, at 22:32, Dean Anderson wrote: On Mon, 18 Aug 2008, bert hubert wrote: What's the rush with deprecating DNS/TCP btw? It languished in the shade for 25 years.. TCP doesn't work with Anycast, as was stated in RFC1546. I just returned from a week with no Internet, living in a tent on the Bruce Peninsular, and the lack of connectivity seems to have resulted in a temporal anomaly! Threads that were long since buried with the hard-tamped dirt of PR actions and BCP publications live once more! I conclude that disconnecting from the Internet for a week has serious consequences, and strongly advise against anybody else here trying such a foolhardy experiment. Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
On Wed, Aug 20, 2008 at 03:27:15PM +, Paul Vixie wrote: i answered this on namedroppers, where the thread actually belongs. at the risk of splitting hairs, the three different proposals did not all strive to change the protocol. Also, this started out from the observation that ANY queries might be routinely used where they probably shouldn't. Short of deprectaing QTYPE=* altogether, giving guidance to application programmers when and (most likely mostly) when not to use ANY might still be a good thing. QCLASS=* or ANY is already recommended against in RFC 1123, section 6.1.2.2 and penalized by RFC 1034, section 3.7.1 (must not set AA). -Peter ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
Peter Koch wrote: On Wed, Aug 20, 2008 at 03:27:15PM +, Paul Vixie wrote: i answered this on namedroppers, where the thread actually belongs. at the risk of splitting hairs, the three different proposals did not all strive to change the protocol. Also, this started out from the observation that ANY queries might be routinely used where they probably shouldn't. Short of deprectaing QTYPE=* altogether, giving guidance to application programmers when and (most likely mostly) when not to use ANY might still be a good thing. QCLASS=* or ANY is already recommended against in RFC 1123, section 6.1.2.2 and penalized by RFC 1034, section 3.7.1 (must not set AA). QTYPE=* and QCLASS=* aren't really comparable, in terms of use cases and practical value. Non-IN classes have pretty much become extinct since 1034/1035 were published, yet the range of RR types has grown significantly, thus making QTYPE=* potentially *more* useful than before (case in point, obtaining A and records in a single query). There are still nagging problems concerning the cache consistency/coherency of QTYPE=* queries, though (e.g. if one of the RRsets expires before the others, is the whole QTYPE=* cached RRset group now to be considered invalid?), and those would need to be clarified or worked around before QTYPE=* could see regular use. - Kevin ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
* Paul Vixie: better still, let's deprecate these bit patterns altogether for OP=QUERY: QTYPE=255 Breaks some sendmail versions and qmail. QCLASS=255 QCLASS != IN seems more reasonable to me. RA=1 AND RD=0 By the responder or the initiator? 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. -- 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
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
... 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
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
i answered this on namedroppers, where the thread actually belongs. -- 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
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR
In your previous mail you wrote: nobody to complete or champion T/TCP = it seems T/TCP is dead because of some security issues. In another thread about fragmentation (vs firewalls) someone proposed DCCP. At least, it avoids RFC 1035 4.2.2 (:-)! [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, 18 Aug 2008, bert hubert wrote: What's the rush with deprecating DNS/TCP btw? It languished in the shade for 25 years.. TCP doesn't work with Anycast, as was stated in RFC1546. And Root server operators are supposed to offer TCP to everyone, not just those that use the stateless UDP service that works with Anycast. Do you remember that David Kessens, then the Operations Area Director took out a PR action against me to silence discussion about Anycast Root server operations? --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
bert hubert wrote: On Mon, Aug 18, 2008 at 04:34:30PM +, Paul Vixie wrote: 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. This means disabling one of the more widely used MTAs. Could you please elaborate on this? Which MTA, how does it use DNS, and is the way it uses it intractable? It may require some work to beef up TCP support though, The problem, I think, is TCP itself, not TCP support within implementations. E.g. resource limits per IP address (16 bits of port number) don't scale to current-size Internet scale. So, short of dramatic changes to TCP that support better scalability and performance, it's kind of out of scope for DNS itself. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, Aug 18, 2008 at 05:27:24PM +, Paul Vixie wrote: TCP/53 a redheaded stepchild and its uses are all dangerous or unscalable. (that initiators do the close, and that responders have a minimum 2-minute timeout, says that any conformant implementation can be slapped down hard with a three line perl script running anywhere on the internet.) DNS over TCP is a damn sight easier than WWW over TCP. Ask the webserver guys about their query rates.. We've just had it easy over the past years, and it shows. The server I mean by the way is microsoft exchange, which likes to do DNS over TCP. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, Aug 18, 2008 at 07:20:16PM +, Paul Vixie wrote: We've just had it easy over the past years, and it shows. it *can't* scale. laws of physics. 'When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.' Consider this a compliment. The server I mean by the way is microsoft exchange, which likes to do DNS over TCP. so what does microsoft exchange do when it tries to talk to a tinydns service like everydns.net who doesn't implement TCP/53 at all? It doesn't need to - it speaks to resolvers. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
Paul's original proposal, C (if I interpret it correctly) applies to resolver-authority-server communications, not stub-resolver communications. no, i was pretty much ruling them out period. especially (RA=1 AND RD=0). however, i could accept a SHOULD NOT for ADNS vs. a SHOULD for RDNS on TCP/53 as long as we also add a SHOULD on RDNS for accept only transactions from intended clients, most likely from within the same LAN, campus, or ISP. SHOULD is great since people who don't do it are still compliant. opendns wouldn't be in trouble. but vendors would become advised to set their defaults to a non-global ACL and then TCP/53 is safer. -- 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
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, Aug 18, 2008 at 01:45:43PM -0400, Brian Dickson wrote: The problem, I think, is TCP itself, not TCP support within implementations. E.g. resource limits per IP address (16 bits of port number) don't scale to current-size Internet scale. It is possible to host 10 connections on 1 IP address and 1 port, and this happens in practice. Think, again, of webservers, which all have to listen on port 80, yet support lots of clients simultaneously. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, Aug 18, 2008 at 07:49:20PM +, Paul Vixie wrote: so what does microsoft exchange do when it tries to talk to a tinydns service like everydns.net who doesn't implement TCP/53 at all? It doesn't need to - it speaks to resolvers. what would it do if it had a TCP-forbidding firewall between it and its RDNS? Dunno, but when PowerDNS had TCP bugs in its resolver code, all the complaints I got were from Exchange users. What's the rush with deprecating DNS/TCP btw? It languished in the shade for 25 years.. I worry because it turns out a single multiplexed connection between a resolver and an authoritative server is just the ticket for doing almost unspoofeable queries while under attack. It serves as a semi-persistent channel (few seconds, minutes perhaps) over which all the queries triggering the questions that are under attack can safely be answered. So I care about DNS over TCP as part of the entropy raising arsenal that is (mostly) available today. I'd hate to see it taken away! Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
what would it do if it had a TCP-forbidding firewall between it and its RDNS? Dunno, but when PowerDNS had TCP bugs in its resolver code, all the complaints I got were from Exchange users. they'll cope. What's the rush with deprecating DNS/TCP btw? It languished in the shade for 25 years.. that's what we said about udp port randomization after bernstein invented it. -- 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
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, 18 Aug 2008, bert hubert wrote: On Mon, Aug 18, 2008 at 01:45:43PM -0400, Brian Dickson wrote: The problem, I think, is TCP itself, not TCP support within implementations. E.g. resource limits per IP address (16 bits of port number) don't scale to current-size Internet scale. It is possible to host 10 connections on 1 IP address and 1 port, and this happens in practice. Think, again, of webservers, which all have to listen on port 80, yet support lots of clients simultaneously. Bad example. One of the reasons we don't see more crypto per default on web browsing is precisely the limitations of SSL/CA's on using SSL with virtual host web sites. I'd hardly call the lack of port 443 a success story. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, Aug 18, 2008 at 06:11:14PM -0400, Paul Wouters wrote: It is possible to host 10 connections on 1 IP address and 1 port, and this happens in practice. Think, again, of webservers, which all have to listen on port 80, yet support lots of clients simultaneously. Bad example. One of the reasons we don't see more crypto per default on web browsing is precisely the limitations of SSL/CA's on using SSL with virtual host web sites. I'd hardly call the lack of port 443 a success story. I must be more stupid than normal - care to elaborate how limitations (I wasn't aware of, btw) on virtual webhosting authenticated and encrypted using SSL certificates have any bearing on the suitability of TCP/IP for DNS levels of performance? Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
Bad example. One of the reasons we don't see more crypto per default on web browsing is precisely the limitations of SSL/CA's on using SSL with virtual host web sites. I'd hardly call the lack of port 443 a success story. we don't need a reason to deprecate tcp/53 beyond what's written in rfc1035. -- 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
