From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: [PATCH] unbound: make local zone transparent
Date: Tue, 28 Apr 2020 11:37:16 +0100
Message-ID: <2FAC887B-7CA9-460D-A13D-7FAC495795F7@ipfire.org>
In-Reply-To: <20200428103520.GA12000@tarvainen.info>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============1713284654963210124=="
List-Id: <development.lists.ipfire.org>

--===============1713284654963210124==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Well, we at least broke Giovanni=E2=80=99s 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 anythin=
g and not for others. The one that was not working was the domain of the fire=
wall itself.

Maybe it is enough to just add the domain setting for the firewall=E2=80=99s =
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> wr=
ote:
>=20
> 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.
>=20
> 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.
>=20
> Tapani
>=20
> On Tue, Apr 28, 2020 at 11:31:41AM +0100, Michael Tremer (michael.tremer(a)=
ipfire.org) wrote:
>>=20
>> I am sharing your concern and therefore used typetransparent because that =
seemed to be the right thing according to the documentation.
>>=20
>> What do you suggest we should use?
>>=20
>> -Michael
>>=20
>>> On 28 Apr 2020, at 11:03, Tapani Tarvainen <ipfire(a)tapanitarvainen.fi> =
wrote:
>>>=20
>>> On Tue, Apr 28, 2020 at 08:50:19AM +0000, Giovanni Aneloni (giovanni.anel=
oni(a)live.com) wrote:
>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>>> 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.
>>>=20
>>> I would consider that a bug in the check_mk thing, but I understand
>>> the point.
>>>=20
>>>> 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.
>>>=20
>>> 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.
>>>=20
>>> Probably not worth the trouble to make this a user-selectable option
>>> either.
>>>=20
>>> --=20
>>> Tapani Tarvainen
>>=20
>=20
> --=20
> Tapani Tarvainen


--===============1713284654963210124==--