Fixes: https://bugzilla.ipfire.org/show_bug.cgi?id=12391 Change local zone to "trasnparent" instead of "typetrasnparent" to avoid NXDOMAIN when querying local hosts
Signed-off-by: Giovanni Aneloni giovanni.aneloni@live.com --- diff --git a/src/initscripts/system/unbound b/src/initscripts/system/unbound index acbf6f5b5..825ac74ec 100644 --- a/src/initscripts/system/unbound +++ b/src/initscripts/system/unbound @@ -81,7 +81,7 @@ write_hosts_conf() { # Skip empty domainnames [ "${domainname}" = "" ] && continue
- echo "local-zone: ${domainname} typetransparent" + echo "local-zone: ${domainname} transparent" done < /var/ipfire/main/hosts | sort -u
# Add all hosts
Hello Giovanni,
welcome and thanks for the patch. Makes sense to me. :-)
Thanks, and best regards, Peter Müller
Reviewed-by: Peter Müller peter.mueller@ipfire.org
Fixes: https://bugzilla.ipfire.org/show_bug.cgi?id=12391 Change local zone to "trasnparent" instead of "typetrasnparent" to avoid NXDOMAIN when querying local hosts
Signed-off-by: Giovanni Aneloni giovanni.aneloni@live.com
diff --git a/src/initscripts/system/unbound b/src/initscripts/system/unbound index acbf6f5b5..825ac74ec 100644 --- a/src/initscripts/system/unbound +++ b/src/initscripts/system/unbound @@ -81,7 +81,7 @@ write_hosts_conf() { # Skip empty domainnames [ "${domainname}" = "" ] && continue
- echo "local-zone: ${domainname} typetransparent" + echo "local-zone: ${domainname} transparent" done < /var/ipfire/main/hosts | sort -u
# Add all hosts
Won't this break things, e.g., in a situation where a local name has MX in external DNS?
That is probably fairly rare and fixable by adding similar MX records locally, but at least users should be warned about the possibility.
On the other hand does it really fix anything other than annoyance? Non-type-specific DNS queries hardly ever happen other than manually anyway.
Tapani
On Tue, Apr 28, 2020 at 12:23:57AM +0200, Giovanni Aneloni (giovanni.aneloni@live.com) wrote:
Fixes: https://bugzilla.ipfire.org/show_bug.cgi?id=12391 Change local zone to "trasnparent" instead of "typetrasnparent" to avoid NXDOMAIN when querying local hosts
Signed-off-by: Giovanni Aneloni giovanni.aneloni@live.com
diff --git a/src/initscripts/system/unbound b/src/initscripts/system/unbound index acbf6f5b5..825ac74ec 100644 --- a/src/initscripts/system/unbound +++ b/src/initscripts/system/unbound @@ -81,7 +81,7 @@ write_hosts_conf() { # Skip empty domainnames [ "${domainname}" = "" ] && continue
echo "local-zone: ${domainname} typetransparent"
echo "local-zone: ${domainname} transparent" done < /var/ipfire/main/hosts | sort -u # Add all hosts
Hi Tapani,
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. Ref: https://linux.die.net/man/5/unbound.conf
transparent If there is a match from local data, the query is answered. Otherwise if the query has a different name, the query is resolved normally. If the query is for a name given in localdata but no such type of data is given in localdata, then a noerror nodata answer is returned. If no local-zone is given local-data causes a transparent zone to be created by default. Since "transparent" is the implicit default i believe it was the actual type until version 143, when typetransparent was specified (see https://git.ipfire.org/?p=ipfire-2.x.git;a=commitdiff;h=1b6b8d97aac8a8056a4e...), so this is a rollback more than a patch.
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 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.
Best regards, Giovanni
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.
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
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
Well, we at least broke Giovanni’s setup here.
The reason why I added the lines in the first place was that unbound did not always check its local data first. It worked for some domains without anything and not for others. The one that was not working was the domain of the firewall itself.
Maybe it is enough to just add the domain setting for the firewall’s own domain.
Does anyone have some free time to figure that one out for me?
Best, -Michael
On 28 Apr 2020, at 11:35, Tapani Tarvainen ipfire@tapanitarvainen.fi wrote:
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
-- Tapani Tarvainen
Hi Tapani and Michael,
to further dig-in the issue I've made a wireshark trace recording two queries, the first with "transparent" and the second with "typetransparent":
72 5.576072 10.5.11.125 10.5.11.31 DNS 113 Standard query response 0x0001 PTR 125.11.5.10.in-addr.arpa PTR ipfire.casa.int 86 5.636905 10.5.11.125 10.5.11.31 DNS 90 Standard query response 0x0008 A proxy.casa.int A 10.5.11.125 88 5.640906 10.5.11.125 10.5.11.31 DNS 74 Standard query response 0x0009 AAAA proxy.casa.int
964 37.666747 10.5.11.125 10.5.11.31 DNS 113 Standard query response 0x0001 PTR 125.11.5.10.in-addr.arpa PTR ipfire.casa.int 978 37.731525 10.5.11.125 10.5.11.31 DNS 90 Standard query response 0x0008 A proxy.casa.int A 10.5.11.125 980 37.827968 10.5.11.125 10.5.11.31 DNS 131 Standard query response 0x0009 No such name AAAA proxy.casa.int SOA sns.dns.icann.org
As you can see there's not a trivial difference between the answers.
The first has code 0:
Flags: 0x8580 Standard query response, No error 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .1.. .... .... = Authoritative: Server is an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... ...0 .... = Non-authenticated data: Unacceptable .... .... .... 0000 = Reply code: No error (0)
In second case the actual response contains a reply code 3:
Flags: 0x8183 Standard query response, No such name 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... ...0 .... = Non-authenticated data: Unacceptable .... .... .... 0011 = Reply code: No such name (3)
The reply code of 3 translates in return code of 1 (error), for instance:
[root@ipfire ~]# host proxy.casa.int proxy.casa.int has address 10.5.11.125 Host proxy.casa.int not found: 3(NXDOMAIN) Host proxy.casa.int not found: 3(NXDOMAIN) [root@ipfire ~]# echo $? 1
With "transparent" would have been 0.
Almost all users will survive (or even not notice it) anyway because most DNS clients will simply ignore the failures and take just the good answers, but relying on resiliency features should not be the production attitude. To be fair, this is not something that is specifically tied to my setup and is not something I've to report to check_mk (or to ISC to ask them to patch nslookup in bind-tools), they are doing their job reporting the error they are receiving.
Also the documentation of unbound clearly states that if no type is specified when declaring local-data the zone will be created as "transparent" so that's it's the default; typetrasparent must on the opposite be declared intentionally.
Life is all about choices and is up to you to decide which is best for the project, jut be aware that typetransparent consistently delivers NXDOMAINS to the clients and forward each query upstream (with associated overhead), it's not just something that works form some cases and doesn't in other. If any trace or other material can help feel free to ask.
Best regards, Giovanni
________________________________ Da: Development development-bounces@lists.ipfire.org per conto di Michael Tremer michael.tremer@ipfire.org Inviato: martedì 28 aprile 2020 12:37 A: Tapani Tarvainen ipfire@tapanitarvainen.fi Cc: development@lists.ipfire.org development@lists.ipfire.org Oggetto: Re: [PATCH] unbound: make local zone transparent
Well, we at least broke Giovanni’s setup here.
The reason why I added the lines in the first place was that unbound did not always check its local data first. It worked for some domains without anything and not for others. The one that was not working was the domain of the firewall itself.
Maybe it is enough to just add the domain setting for the firewall’s own domain.
Does anyone have some free time to figure that one out for me?
Best, -Michael
On 28 Apr 2020, at 11:35, Tapani Tarvainen ipfire@tapanitarvainen.fi wrote:
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
-- Tapani Tarvainen
Hello together,
Please excuse my late reply, but I have a very busy inbox right now...
On 28 Apr 2020, at 16:16, Giovanni Aneloni giovanni.aneloni@live.com wrote:
Hi Tapani and Michael,
to further dig-in the issue I've made a wireshark trace recording two queries, the first with "transparent" and the second with "typetransparent":
Great work!
72 5.576072 10.5.11.125 10.5.11.31 DNS 113 Standard query response 0x0001 PTR 125.11.5.10.in-addr.arpa PTR ipfire.casa.int 86 5.636905 10.5.11.125 10.5.11.31 DNS 90 Standard query response 0x0008 A proxy.casa.int A 10.5.11.125 88 5.640906 10.5.11.125 10.5.11.31 DNS 74 Standard query response 0x0009 AAAA proxy.casa.int
964 37.666747 10.5.11.125 10.5.11.31 DNS 113 Standard query response 0x0001 PTR 125.11.5.10.in-addr.arpa PTR ipfire.casa.int 978 37.731525 10.5.11.125 10.5.11.31 DNS 90 Standard query response 0x0008 A proxy.casa.int A 10.5.11.125 980 37.827968 10.5.11.125 10.5.11.31 DNS 131 Standard query response 0x0009 No such name AAAA proxy.casa.int SOA sns.dns.icann.org
As you can see there's not a trivial difference between the answers.
The first has code 0:
Flags: 0x8580 Standard query response, No error 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .1.. .... .... = Authoritative: Server is an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... ...0 .... = Non-authenticated data: Unacceptable .... .... .... 0000 = Reply code: No error (0)
In second case the actual response contains a reply code 3:
Flags: 0x8183 Standard query response, No such name 1... .... .... .... = Response: Message is a response .000 0... .... .... = Opcode: Standard query (0) .... .0.. .... .... = Authoritative: Server is not an authority for domain .... ..0. .... .... = Truncated: Message is not truncated .... ...1 .... .... = Recursion desired: Do query recursively .... .... 1... .... = Recursion available: Server can do recursive queries .... .... .0.. .... = Z: reserved (0) .... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server .... .... ...0 .... = Non-authenticated data: Unacceptable .... .... .... 0011 = Reply code: No such name (3)
I consider this incorrect. It should be 0 and return no data.
The reply code of 3 translates in return code of 1 (error), for instance:
[root@ipfire ~]# host proxy.casa.int proxy.casa.int has address 10.5.11.125 Host proxy.casa.int not found: 3(NXDOMAIN) Host proxy.casa.int not found: 3(NXDOMAIN) [root@ipfire ~]# echo $? 1
With "transparent" would have been 0.
Almost all users will survive (or even not notice it) anyway because most DNS clients will simply ignore the failures and take just the good answers, but relying on resiliency features should not be the production attitude. To be fair, this is not something that is specifically tied to my setup and is not something I've to report to check_mk (or to ISC to ask them to patch nslookup in bind-tools), they are doing their job reporting the error they are receiving.
Also the documentation of unbound clearly states that if no type is specified when declaring local-data the zone will be created as "transparent" so that's it's the default; typetrasparent must on the opposite be declared intentionally.
Life is all about choices and is up to you to decide which is best for the project, jut be aware that typetransparent consistently delivers NXDOMAINS to the clients and forward each query upstream (with associated overhead), it's not just something that works form some cases and doesn't in other. If any trace or other material can help feel free to ask.
Yes, so accepting the patch would make things clear on our side and would go back to the former behaviour.
I suppose that worked for Tapani, too?
Best, -Michael
Acked-by: Michael Tremer michael.tremer@ipfire.org
Best regards, Giovanni
Da: Development development-bounces@lists.ipfire.org per conto di Michael Tremer michael.tremer@ipfire.org Inviato: martedì 28 aprile 2020 12:37 A: Tapani Tarvainen ipfire@tapanitarvainen.fi Cc: development@lists.ipfire.org development@lists.ipfire.org Oggetto: Re: [PATCH] unbound: make local zone transparent
Well, we at least broke Giovanni’s setup here.
The reason why I added the lines in the first place was that unbound did not always check its local data first. It worked for some domains without anything and not for others. The one that was not working was the domain of the firewall itself.
Maybe it is enough to just add the domain setting for the firewall’s own domain.
Does anyone have some free time to figure that one out for me?
Best, -Michael
On 28 Apr 2020, at 11:35, Tapani Tarvainen ipfire@tapanitarvainen.fi wrote:
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
-- Tapani Tarvainen
-
Giovanni Aneloni -
Michael Tremer -
Peter Müller -
Tapani Tarvainen