Message ID | AM0PR03MB605172FBC34473CAF58BECD5FCAF0@AM0PR03MB6051.eurprd03.prod.outlook.com |
---|---|
State | Accepted |
Headers |
Return-Path: <development-bounces@lists.ipfire.org> Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) server-digest SHA384 client-signature ECDSA (P-384) client-digest SHA384) (Client CN "mail01.haj.ipfire.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 499zpK0FKXz3xQy for <patchwork@web04.haj.ipfire.org>; Mon, 27 Apr 2020 22:24:09 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail02.haj.ipfire.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 499zpH3WfBzdp; Mon, 27 Apr 2020 22:24:07 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 499zpG6P9vz2y3Z; Mon, 27 Apr 2020 22:24:06 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-384) client-signature ECDSA (P-384)) (Client CN "mail01.haj.ipfire.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 499zpF49K2z2y3Z for <development@lists.ipfire.org>; Mon, 27 Apr 2020 22:24:05 +0000 (UTC) Received: from EUR05-AM6-obe.outbound.protection.outlook.com (mail-am6eur05olkn20821.outbound.protection.outlook.com [IPv6:2a01:111:f400:7e1b::821]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 499zpD4lNCzdp for <development@lists.ipfire.org>; Mon, 27 Apr 2020 22:24:04 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nQPz+E9BKsnLG+4KT8Ksk7AEod079SRlUl08RHdChFvrkXEdLZoNkNF46b0Mi7gPH/4X2s631GaHQE2S8ecU5lliMRo29BjMAf8vP/ThKx4oWPyOInrLZNcxtmes6n0cqJl5NlAJOPdAuR3IQ7rxLWbqR1F4Kst5D/3JOWhaRcd8CI4a79WuxU2TtYu6TDL8websX1N4tFwS5tVAwx95fDWT40JEV4ZBJKRpE1tzPBpfVlL4+wG3PRVhrpBsbSJE+igEnciLbRscaFJ5I1BVlwF049eGYs0usr/9Al1jXGubuXhFTKMo8Ta02/m5ZiL+Q5UCq8y0hwpg6XzJ528vHA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zSUbP5TxpORysOWY/YTJzfnpVeaIhrs7kIqbzQVLeRg=; b=HAnAq+vQCIqAyN4KYBQv3eDyYISru6hcwafMuyMNvmWr125rjjs8LQvetcv/vAAFf3pi39BYUUSKrjzTs4iLy5f78wCIztEAeChoVLV5gP/MNDrTVcRaO/qHUHsCEuztXdTnNyrhSQMtA/exzOmXd9umgNPyouDghTX3urSSd4I0d/oWAHRxovQfoAv/3r1gQxaMNFv2dZEM9khnti96cME0una/qfWufvOE4bk67DFLjfb7a3IHrH0ps6JOY2gmDtAc2sxcSq56GQ7RfR/uYjaUfv7pDPgZ7FphlWBtdhzgIZcR/Fd4aAgOAVBjMjDwBmCs4shTf5OBK9PTDTmHUw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=live.com; dmarc=pass action=none header.from=live.com; dkim=pass header.d=live.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zSUbP5TxpORysOWY/YTJzfnpVeaIhrs7kIqbzQVLeRg=; b=qXXUKRwhAcxdy24GHusOfdjxfDxRHyZryRA9qXLQ0OYU2a0QbiypPeiRO7VLKe3gWZ8QWCP6w2NUsujbcoAcHh1kz9peRBTzvEpi+ue+ePNOyzFN7W1x5WwZDmlXoTCKw4fijyxhYxKiPqGRH2zkQiQbCSy59HR241sBL+f0LAVXfLMghgPqwhE63c/Wv0BNw6pWRD+OraIVfn1fq6of7QpZL7NdPIN9e13UV17lSGDi/y5aic6FaCZCgWi3j1RuHENDFnxneMMBCdV18K/UwA4e4kxtxCNZpoMntf0uGxsLtrWuIzWwbKIMED5tSxjmwleCSC1CHMw6WSBxNxbh4w== Received: from VI1EUR05FT033.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc12::45) by VI1EUR05HT186.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc12::290) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.15; Mon, 27 Apr 2020 22:23:57 +0000 Received: from AM0PR03MB6051.eurprd03.prod.outlook.com (2a01:111:e400:fc12::44) by VI1EUR05FT033.mail.protection.outlook.com (2a01:111:e400:fc12::440) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.15 via Frontend Transport; Mon, 27 Apr 2020 22:23:57 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:697FF4331A012EEB2F857DCE79050DA2360CE14330098AACC0A323719470CD2F; UpperCasedChecksum:3CFC618543DE9076B0B7437CB12C046DC8E225C1D4EC4E1DE37F2AA6CE263C2C; SizeAsReceived:7699; Count:47 Received: from AM0PR03MB6051.eurprd03.prod.outlook.com ([fe80::90b4:a103:d06b:6e77]) by AM0PR03MB6051.eurprd03.prod.outlook.com ([fe80::90b4:a103:d06b:6e77%2]) with mapi id 15.20.2937.023; Mon, 27 Apr 2020 22:23:57 +0000 To: development@lists.ipfire.org From: Giovanni Aneloni <giovanni.aneloni@live.com> Subject: [PATCH] unbound: make local zone transparent Message-ID: <AM0PR03MB605172FBC34473CAF58BECD5FCAF0@AM0PR03MB6051.eurprd03.prod.outlook.com> Date: Tue, 28 Apr 2020 00:23:57 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Language: it-IT Content-Transfer-Encoding: 7bit X-ClientProxiedBy: MRXP264CA0016.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:15::28) To AM0PR03MB6051.eurprd03.prod.outlook.com (2603:10a6:208:158::19) X-Microsoft-Original-Message-ID: <d46030b6-9ec1-b6b5-3013-0ed97ac90c16@live.com> MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [10.5.11.2] (82.52.117.203) by MRXP264CA0016.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:15::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2937.13 via Frontend Transport; Mon, 27 Apr 2020 22:23:56 +0000 X-Microsoft-Original-Message-ID: <d46030b6-9ec1-b6b5-3013-0ed97ac90c16@live.com> X-TMN: [t8OyCg2Yo5/0a/PDL9Ro+65tEw7guJcq] X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 47 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: e2f73d68-d163-4da5-1c98-08d7eaf9ad16 X-MS-TrafficTypeDiagnostic: VI1EUR05HT186: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: c6jo7SEFIq0r4O6iG0dgqRDN+7Mzbc4k2fZZdcy6nn+Km9rq6scoTRzTbuiouzKycIcyUVrBTuYfeYHOyoJ7Ch/OaJNRVhmZPTcUHPQ3lFSbZTGarLpXIXg0izjca10QdK8J3rQ6tffaynjT9UtTTia1r3vG5ps0dbGVg57tNKW679g7u6lLfZv8RF0YmJT4rdtixBeb8R5TItnwkZntuVK5afI6eaRShA6yrfEm68SLlXMKsSJXHSQv1+noHUAr X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:0; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR03MB6051.eurprd03.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:; DIR:OUT; SFP:1901; X-MS-Exchange-AntiSpam-MessageData: jh5IfaBx6TgrDFFyN+mPR+yBXMAutmqagjwrSMdO4sbkasl6PErk3iwE2WuuDNBL1W5b0ENYjiODxDhWtidclyfzRRMzjlO20Suh5PvRPwvrXqhqGepQBqjcvJE2ELEluJRd+IN1XLGk3EmHS3VDpg== X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-Network-Message-Id: e2f73d68-d163-4da5-1c98-08d7eaf9ad16 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Apr 2020 22:23:56.9767 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1EUR05HT186 ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=lists.ipfire.org; s=202003rsa; t=1588026244; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=zSUbP5TxpORysOWY/YTJzfnpVeaIhrs7kIqbzQVLeRg=; b=EX+xhYfDQjQnCdnDO8cQKQ1PqNw3NeDU1IZ1x417IF71KIlKw5bKcIhIjxgwocdut6UFuD 3ylk34rC6mNxwFzT7C33ySPCSmQkG7H7K3pFBODycbLUSdKH5HXiPdJu8CVlyUqXVlwr1H D/UV+b4+Dud5N4X36iPsEX1BwooyF8ODV6vncyOCtriT0/wf1SQA431A54fU15QEfp1/Te cQns3OwgyAKMu5hPEHKj8A39Tck3CBdkivIl+LFYbq9NbfGCFFZkmSSbVQTFuKy8Kg9wbY 9oc2pzb449jkUTu/PcfZiHWl/D8i4rPfPuqtU5SFqNGC7frjX3R6cv7qvFqcYg== ARC-Seal: i=2; s=202003rsa; d=lists.ipfire.org; t=1588026244; a=rsa-sha256; cv=pass; b=waa20sQ/d/7P/3vg3mRCDeSK9Nal90Ad4SnuWn9PbyX9s5TEGMyv5Z65QtTMIMTVK79fat yWT39NNSoAqyMiau8YhIVK0LOJrG/9fM28JkndAouvjc/IO+Bk2oP1tqgfQZ8eZdSYg+HJ zvEUz0g/3OIz/gn2/8B7IQBDcw3YWPezcI1krmStJKjOblgsZNlFCXMiBMcWhPwhw4sRw1 KtuxfnjC5nOYZT+1uLJFU7bEgrmnsqAZl1LK2Y6bjvZteeyqxf7tpsvcqdzYrXEtnT1MNd Muk3HaNX1nuJfV6DipebLx/Sw0NvJXK5lJYG3ImbGznxiUmyEKEG5pMqok7B5Q== ARC-Authentication-Results: i=2; mail01.ipfire.org; dkim=pass header.d=live.com header.s=selector1 header.b=qXXUKRwh; arc=pass (microsoft.com:s=arcselector9901:i=1); dmarc=pass (policy=none) header.from=live.com; spf=pass (mail01.ipfire.org: domain of giovanni.aneloni@live.com designates 2a01:111:f400:7e1b::821 as permitted sender) smtp.mailfrom=giovanni.aneloni@live.com Authentication-Results: mail01.ipfire.org; dkim=pass header.d=live.com header.s=selector1 header.b=qXXUKRwh; dmarc=pass (policy=none) header.from=live.com; spf=pass (mail01.ipfire.org: domain of giovanni.aneloni@live.com designates 2a01:111:f400:7e1b::821 as permitted sender) smtp.mailfrom=giovanni.aneloni@live.com X-Rspamd-Queue-Id: 499zpD4lNCzdp X-Spamd-Result: default: False [-2.80 / 11.00]; RCVD_TLS_LAST(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; R_DKIM_ALLOW(-0.20)[live.com:s=selector1]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[live.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; ARC_SIGNED(0.00)[i=2]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; RECEIVED_SPAMHAUS_PBL(0.00)[82.52.117.203:received]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MX_GOOD(-0.01)[]; DKIM_TRACE(0.00)[live.com:+]; DMARC_POLICY_ALLOW(-0.50)[live.com,none]; NEURAL_HAM(-1.04)[-1.042]; IP_REPUTATION_SPAM(0.12)[asn: 8075(0.12), country: US(-0.00), ip: 2a01:111:f400:7e1b::821(0.00)]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[live.com]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; BAYES_HAM(-2.37)[97.09%]; DWL_DNSWL_NONE(0.00)[live.com:dkim] X-Rspamd-Server: mail01.haj.ipfire.org X-BeenThere: development@lists.ipfire.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFire development talk <development.lists.ipfire.org> List-Unsubscribe: <https://lists.ipfire.org/mailman/options/development>, <mailto:development-request@lists.ipfire.org?subject=unsubscribe> List-Archive: <http://lists.ipfire.org/pipermail/development/> List-Post: <mailto:development@lists.ipfire.org> List-Help: <mailto:development-request@lists.ipfire.org?subject=help> List-Subscribe: <https://lists.ipfire.org/mailman/listinfo/development>, <mailto:development-request@lists.ipfire.org?subject=subscribe> Errors-To: development-bounces@lists.ipfire.org Sender: "Development" <development-bounces@lists.ipfire.org> |
Series |
unbound: make local zone transparent
|
|
Commit Message
Giovanni Aneloni
April 27, 2020, 10:23 p.m. UTC
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>
---
Comments
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
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