From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: [PATCH] unbound: make local zone transparent Date: Thu, 07 May 2020 22:18:38 +0100 Message-ID: <324092E8-7A64-40F5-BB12-AA064A68B2CD@ipfire.org> In-Reply-To: =?utf-8?q?=3CAM0PR03MB6051D20846940B492D613E60FCAC0=40AM0PR03MB?= =?utf-8?q?6051=2Eeurprd03=2Eprod=2Eoutlook=2Ecom=3E?= MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7428156327507478734==" List-Id: --===============7428156327507478734== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable 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 wr= ote: >=20 > Hi Tapani and Michael, >=20 > to further dig-in the issue I've made a wireshark trace recording two queri= es, 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 P= TR 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 AA= AA proxy.casa.int >=20 > 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 >=20 > As you can see there's not a trivial difference between the answers. >=20 > The first has code 0: >=20 > Flags: 0x8580 Standard query response, No error > 1... .... .... .... =3D Response: Message is a response > .000 0... .... .... =3D Opcode: Standard query (0) > .... .1.. .... .... =3D Authoritative: Server is an authority for domain > .... ..0. .... .... =3D Truncated: Message is not truncated > .... ...1 .... .... =3D Recursion desired: Do query recursively > .... .... 1... .... =3D Recursion available: Server can do recursive qu= eries > .... .... .0.. .... =3D Z: reserved (0) > .... .... ..0. .... =3D Answer authenticated: Answer/authority portion = was not authenticated by the server > .... .... ...0 .... =3D Non-authenticated data: Unacceptable > .... .... .... 0000 =3D Reply code: No error (0) >=20 >=20 > In second case the actual response contains a reply code 3: >=20 > Flags: 0x8183 Standard query response, No such name > 1... .... .... .... =3D Response: Message is a response > .000 0... .... .... =3D Opcode: Standard query (0) > .... .0.. .... .... =3D Authoritative: Server is not an authority for d= omain > .... ..0. .... .... =3D Truncated: Message is not truncated > .... ...1 .... .... =3D Recursion desired: Do query recursively > .... .... 1... .... =3D Recursion available: Server can do recursive qu= eries > .... .... .0.. .... =3D Z: reserved (0) > .... .... ..0. .... =3D Answer authenticated: Answer/authority portion = was not authenticated by the server > .... .... ...0 .... =3D Non-authenticated data: Unacceptable > .... .... .... 0011 =3D 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: >=20 > [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 >=20 > With "transparent" would have been 0. >=20 > Almost all users will survive (or even not notice it) anyway because most D= NS clients will simply ignore the failures and take just the good answers, bu= t 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 a= re receiving. >=20 > Also the documentation of unbound clearly states that if no type is specifi= ed when declaring local-data the zone will be created as "transparent" so tha= t's it's the default; typetrasparent must on the opposite be declared intenti= onally. >=20 > 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 >=20 > Best regards, > Giovanni >=20 > Da: Development per conto di Micha= el Tremer > Inviato: marted=C3=AC 28 aprile 2020 12:37 > A: Tapani Tarvainen > Cc: development(a)lists.ipfire.org > Oggetto: Re: [PATCH] unbound: make local zone transparent > =20 > Well, we at least broke Giovanni=E2=80=99s setup here. >=20 > The reason why I added the lines in the first place was that unbound did no= t always check its local data first. It worked for some domains without anyth= ing and not for others. The one that was not working was the domain of the fi= rewall itself. >=20 > Maybe it is enough to just add the domain setting for the firewall=E2=80=99= s own domain. >=20 > Does anyone have some free time to figure that one out for me? >=20 > Best, > -Michael >=20 > > On 28 Apr 2020, at 11:35, Tapani Tarvainen = wrote: > >=20 > > 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. > >=20 > > 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. > >=20 > > Tapani > >=20 > > On Tue, Apr 28, 2020 at 11:31:41AM +0100, Michael Tremer (michael.tremer(= a)ipfire.org) wrote: > >>=20 > >> I am sharing your concern and therefore used typetransparent because tha= t seemed to be the right thing according to the documentation. > >>=20 > >> What do you suggest we should use? > >>=20 > >> -Michael > >>=20 > >>> On 28 Apr 2020, at 11:03, Tapani Tarvainen wrote: > >>>=20 > >>> On Tue, Apr 28, 2020 at 08:50:19AM +0000, Giovanni Aneloni (giovanni.an= eloni(a)live.com) wrote: > >>>=20 > >>>> 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. > >>>=20 > >>> 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. > >>>=20 > >>>> 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. > >>>=20 > >>> I would consider that a bug in the check_mk thing, but I understand > >>> the point. > >>>=20 > >>>> 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. > >>>=20 > >>> 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. > >>>=20 > >>> Probably not worth the trouble to make this a user-selectable option > >>> either. > >>>=20 > >>> --=20 > >>> Tapani Tarvainen > >>=20 > >=20 > > --=20 > > Tapani Tarvainen --===============7428156327507478734==--