[dns-operations] EDNS and TLDs

Phillip Hallam-Baker phill at hallambaker.com
Fri Nov 18 16:25:41 UTC 2016

On Wed, Nov 16, 2016 at 8:21 AM, Bob Harold <rharolde at umich.edu> wrote:

> On Wed, Nov 16, 2016 at 8:00 AM, Florian Weimer <fweimer at redhat.com>
> wrote:
>> On 10/29/2016 11:06 AM, Phil Regnauld wrote:
>>> Mark Andrews (marka) writes:
>>>> Thanks.  Firewall are the biggest problems at the moment.
>>>         Firewalls in front of DNS servers still puzzle me.
>> If you want to run BIND, a packet filter in front of it currently is the
>> only way to switch off processing of DNS UPDATE messages in BIND, so I can
>> see why people do this.
>> Florian
> Why not just:
> ​​
>       allow-update { none; };
> in BIND?
> I would expect that to be not much work processing than what the firewall
> has to do, and less because of the overhead of the firewall.  And
> definitely less likely to break things - the filter in the firewall in
> likely to mis-categorize some packets it has not thought of.

​In a high security environment, the configuration is usually determined by
the need to audit rather than efficiency.

The role of a firewall is simply to gather together as many features that
require audit into one place. This has been considered best security
practice since Lampson was writing on this in the 70s.

If you want security, you are best off concentrating all the settings for a
particular security role into one place. Separation of duties is good, but
the separation has to be explicit and documented. So in a secure site,
there would be a firewall of the main servers under control of one admin
and a separate admin would have control of the servers themselves.

​The problem that arises in separation of duties is that ​unless you treat
policy failures as a breach, you can quickly end up with worse security.
That happened in a case that I was involved in that went to trial earlier
this year.

​So I would not accept the above setting unless it could be instrumented
​with an alarm:

      allow-update { set-off-security-alarm ("Firewall policy failure")};

​Sure, this is not something that you would do on core DNS supporting a
major TLD. But those systems don't run BIND or anything close. The front
end of those systems is in essence performing the same policy enforcement
role as a firewall does.

But it is very definitely something that you are going to find the auditors
insist on in many environments.​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20161118/773a18ff/attachment.html>

More information about the dns-operations mailing list