Re: [PATCH] unbound: make local zone transparent

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]

Well, we at least broke Giovanni’s setup here.

The reason why I added the lines in the first place was that unbound did not always check its local data first. It worked for some domains without anything and not for others. The one that was not working was the domain of the firewall itself.

Maybe it is enough to just add the domain setting for the firewall’s own domain.

Does anyone have some free time to figure that one out for me?

Best,
-Michael

> On 28 Apr 2020, at 11:35, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
> 
> My preference would be staying with typetransparent, for reasons
> described below, and in general to avoid making potentially disruptive
> changes to default let alone forced settings.
> 
> But as noted this is unlikely to affect more than a handful of
> users and those probably can figure out how to work around it.
> 
> Tapani
> 
> On Tue, Apr 28, 2020 at 11:31:41AM +0100, Michael Tremer (michael.tremer(a)ipfire.org) wrote:
>> 
>> I am sharing your concern and therefore used typetransparent because that seemed to be the right thing according to the documentation.
>> 
>> What do you suggest we should use?
>> 
>> -Michael
>> 
>>> On 28 Apr 2020, at 11:03, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> wrote:
>>> 
>>> On Tue, Apr 28, 2020 at 08:50:19AM +0000, Giovanni Aneloni (giovanni.aneloni(a)live.com) wrote:
>>> 
>>>> it shouldn't since "transparent" still forwards missing records, so
>>>> the mx problem would apply only if a A record is defined for the
>>>> domain itself.
>>> 
>>> That's exactly the situation I was thinking of: a split-view DNS,
>>> where the domain does have A record (also) inside the firewall but MX
>>> only on the outside. Not all that unusual in general although perhaps
>>> rare among IPFire users.
>>> 
>>>> Moreover the side effect is not just an annoyance: as an example I
>>>> use chieck_mk to monitor all nodes in my network and one of the
>>>> default check is the ability to resolve local names. With
>>>> typetransparent the result of the check (which is native, not
>>>> implemented by me) is detected as a failure in name resolution both
>>>> on linux and windows targets.
>>> 
>>> I would consider that a bug in the check_mk thing, but I understand
>>> the point.
>>> 
>>>> I agree that we are discussing a very specific subject, but it seems
>>>> to me that it should be best to stick with the default or have a
>>>> very stong point (which IMHO is missing in this case) to use a
>>>> different directive.
>>> 
>>> I'm not sure transparent is any more default than typetransparent
>>> here, both cause problems in some situations. But I can live with with
>>> it either way, this is no dealbreaker for me. It would be good to be
>>> aware of and document the implications, however.
>>> 
>>> Probably not worth the trouble to make this a user-selectable option
>>> either.
>>> 
>>> -- 
>>> Tapani Tarvainen
>> 
> 
> -- 
> Tapani Tarvainen