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(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf