On Mon, 29 Mar 2010, Kevin Oberman wrote:
Fix your security officers!
I have talked to multiple security officers (who are generally not
really knowledgeable on networks) who had 53/tcp blocked and none have
yet agreed to change it. The last one told me that blocking 53/tcp is
"standard industry practice" as per his firewall training. Point out
what RFCs said simply bounced off of him. He said that if the protocols
would not handle blocked 53/tcp, the protocols would have to be
changed. Opening the port was simply not open to discussion.
They don't seen to really care if things are broken and seem to feel
that it is up to "the network" to accommodate their idea of normal
firewall configuration.
I will say that these were at federal government facilities. I hope the
commercial world is a bit more in touch with reality.
If you are with a US Federal agency having problems like this, or any
other issues with your DNSSEC deployment, please include them in the
DNSSEC survey every US Federal executive agency has been tasked to submit
by the Office of Management and Budget.
http://iase.disa.mil/stigs/stig/dns_stig_v4r1_20071017.pdf
If, for example, an organization placed an authoritative server in its
DMZ but limited zone transfers to servers behind the firewall, then it
could allow inbound and outbound UDP 53 to and from the DMZ name server
to allow queries, but deny TCP 53 in both directions to prohibit zone
transfers. This configuration, however, is strongly discouraged because
it may prevent legitimate DNS transactions that involve large responses
(e.g., a DNSSEC signature). In general, limitations on queries, zone
updates and transfers should be implemented in the name server's
configuration rather than through configuration of firewalls, routers,
or other communications devices.
