> > On Oct 1, 2007, at 9:24 PM, Mark Andrews wrote: > > >> > >> Note that in real deployments just this behavior has broken things > >> on occasion, as many firewall and other such policy application =20 > >> points > >> assume things like DNS resolution will only be UDP/53 transactions. > > > > That assumption has always been wrong. > > Not in my experience. I repeat. The ASSUMPTION as ALWAYS been wrong. From day one the DNS specified fall back to TCP for QUERY. > Actually, there are two separate things here. One, is implementation/ > product, the other is configuration and device administration. I'm not > sure how your average user would separate the two from a practical > standpoint, and it really doesn't matter. > > I'm aware of at two products in the last few months that, in production > deployment forced TCP switch-over, only to find that this broke name > resolution completely for a large pool of subscribers. It still doesn't mean that many are badly configured only that some are badly configured. > In addition, in my own experience, more often than not when folks > clamp down firewall policies, in particular in enterprise or =20 > "restricted" > space, they often deny all TCP/53 to address spaces (in one case the > culprit for the brokenness above). And I presume they adjusted the policy once they discovered how idiotic it is. > Another common place to see policies that block TCP/53 is roaming > access points captive user environments. E.g., SSH tunneling over > DNS was easy enough over UDP. I didn't say that it didn't occur. Some people are stupid. > To further support my statement, just google for +"firewall policy" > +TCP/53 +DNS, here are a few examples: > > http://www.whitehats.ca/downloads/cerberus/Rick_Wanner_GCFW.pdf > > Service: The enabled service is DNS (domain-udp, port 53/udp). =20 > Firewall-1=92s DNS service by > default contains both domain-udp (53/udp) and domain-tcp (53/tcp). =20 > We have removed domain- > tcp from the object definition, on the grounds that we will not be =20 > permitting zone transfers. It will > be necessary to watch carefully since removing domain-tcp also means =20 > that long dns-queries will > not be supported. It is important to note that this will not work =20 > unless =93Accept UDP replies=94 is > enabled on the Firewall-1 Security Properties screen. Without =20 > =93Accept UDP replies=94 enabled, the > queries will still be allowed through the firewall, but the replies =20 > will be dropped on the firewall. So. It just means they intend to live dangerously. This policy will bite them at some point. > http://security.ucdavis.edu/basic_firewall_rules.pdf: > > Allow DNS (UDP 53) to internal DNS server =96 If the unit runs internal =20= > > DNS servers this > rule is recommended. The rule is needed if a Windows Active Directory =20= > > server is hosted > on the internal network. You must permit TCP 53 for zone transfer =20 > capability, however > this permission should not be applied by default. Someone should talk to ucdavis.edu and get this idiocy pulled. > Right or wrong, it's quite common. > > > I would also dispute the "many" above. Most firewalls > > actually handle the transition to TCP perfectly fine. There > > are the odd few that are misconfigured. When that happens > > people complain because nameservers resolution fails. Either > > the dataset is "fixed" or the firewall is fixed. > > I'd be quite interested in any pointers you might have to empirical > evidence supporting this position. I don't believe it's an odd few > that are misconfigured, I believe it's often done as a conscious > effort. Because there are lots of recursive and authoritative nameservers out there behind firewalls that get it right. I've seen many more complaints about UDP packets > 512 bytes being blocked than complaints about fallback to TCP failing. Most people actually do the right thing without thinking about it. The allow TCP out to anything this includes DNS servers. Most allow both UDP and TCP in to their nameservers. This is the silent majority. Mark > -danny= -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf