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.