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