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