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@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@tapanitarvainen.fi wrote:
On Tue, Apr 28, 2020 at 08:50:19AM +0000, Giovanni Aneloni (giovanni.aneloni@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