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.