unbound: make local zone transparent

  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>
---
  

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=1b6b8d97aac8a8056a4ef5c9d571a1947551e17f;hp=e4013c9dabd55f399b57939a4ad9b5192aac8077), 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
  

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