From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] unbound: make local zone transparent Date: Tue, 28 Apr 2020 11:31:41 +0100 Message-ID: In-Reply-To: <20200428100338.GB6783@tarvainen.info> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3641596686632064400==" List-Id: --===============3641596686632064400== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I am sharing your concern and therefore used typetransparent because that see= med 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 wr= ote: >=20 > On Tue, Apr 28, 2020 at 08:50:19AM +0000, Giovanni Aneloni (giovanni.anelon= i(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 --===============3641596686632064400==--