Re: [PATCH] unbound: make local zone transparent

[Tapani Tarvainen <ipfire@tapanitarvainen.fi>]

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

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