DNSSEC and Firewalls (was Re: IPv4 ANYCAST setup)

[Sean Donelan <sean () donelan com>]

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.