Re: [PATCH] unbound: make local zone transparent

Re: [PATCH] unbound: make local zone transparent

[Peter Müller]

[-- Attachment #1: Type: text/plain, Size: 1154 bytes --]

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(a)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(a)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

Re: [PATCH] unbound: make local zone transparent

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 8022 bytes --]

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(a)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(a)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(a)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(a)ipfire.org>

> 
> Best regards,
> Giovanni
> 
> Da: Development <development-bounces(a)lists.ipfire.org> per conto di Michael Tremer <michael.tremer(a)ipfire.org>
> Inviato: martedì 28 aprile 2020 12:37
> A: Tapani Tarvainen <ipfire(a)tapanitarvainen.fi>
> Cc: development(a)lists.ipfire.org <development(a)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(a)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(a)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(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
> >> 
> > 
> > -- 
> > Tapani Tarvainen

Re: R: [PATCH] unbound: make local zone transparent

[Tapani Tarvainen]

[-- Attachment #1: Type: text/plain, Size: 1544 bytes --]

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

Re: [PATCH] unbound: make local zone transparent

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 1880 bytes --]

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

Re: [PATCH] unbound: make local zone transparent

[Tapani Tarvainen]

[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]

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(a)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(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
> 

-- 
Tapani Tarvainen

Re: [PATCH] unbound: make local zone transparent

[Michael Tremer]

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]

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(a)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(a)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(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
>> 
> 
> -- 
> Tapani Tarvainen

Re: [PATCH] unbound: make local zone transparent

[Tapani Tarvainen]

[-- Attachment #1: Type: text/plain, Size: 1376 bytes --]

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(a)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(a)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

-- 
Tapani Tarvainen

[PATCH] unbound: make local zone transparent

[Giovanni Aneloni]

[-- Attachment #1: Type: text/plain, Size: 803 bytes --]

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(a)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