[dns-operations] EDNS and TLDs

[Bob Harold]

On Wed, Nov 16, 2016 at 8:56 AM, Florian Weimer <fweimer at redhat.com> wrote:

> On 11/16/2016 02:21 PM, Bob Harold 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?
>>
>
> BIND will still process the DNS UPDATE messages, so that it can return the
> right response code.
>
> 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.
>>
>
> As far as I know, your configuration change does not disable DNS UPDATE
> processing because BIND determines the UPDATE capability of a view only
> after it has found the view, which requires parsing the packet.
>
> BIND could have a global flag indicating whether any view has UPDATE
> capability, an if it is not set, reject UPDATE messages early.  I'm not
> sure if this change is worth it, or if all DNS UPDATE related bugs have
> been ironed out.
>
> Florian
>

In general I agree.  If there are bugs in BIND packet processing that are
not quickly fixed, then using a firewall (or iptables rule) in the interim
is a reasonable solution.  But I would avoid it if possible.
Adding an early exit if no updates are permitted might be a reasonable
optimization to make.

-- 
Bob Harold
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20161116/51448768/attachment.html>