DNSSEC and Firewalls (was Re: IPv4 ANYCAST setup)
Sean Donelan
sean at donelan.com
Wed Mar 31 07:19:07 UTC 2010
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.
More information about the NANOG
mailing list