Received: from mail.jjtc.dk (jjtc.dk [212.237.182.190]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 54FDA781AB9 for <~alpine/devel@lists.alpinelinux.org>; Fri, 27 Mar 2020 15:48:57 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) by localhost (Mailerdaemon) with ESMTPSA id E3DB55B98B for <~alpine/devel@lists.alpinelinux.org>; Fri, 27 Mar 2020 16:48:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jjtc.eu; s=dkim; t=1585324127; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=whSpwm5SqhkdicqUe20VH5uvwNflKgksQ2TgFXfohAE=; b=ZKnGVnmZIJw6c8VanmVhCtH/t5gDcY56wK1YvhqWNQRlU/ile4OFeZyjr2aOxRR5XZfViE 4B/eJnMlQ7ZByzwaCp2hEsQ0vi6iL4D+cPEtSeOAcNm5g9euPQc6M8VdeaPhHnMJb4xnoW JnOIdHyOHBsqUqNpjeCnIZU87o1X0ZbfVTW6hLQw6f5ssax98+gVTETFUXshztG5f+pQWO bQdbvulZdvFveYChG43FrOr8V5N6kC2+4BBgxVuRoT5UQVJDLm5ovWeur2FExvYTIbP0jE mSBaPQZqDN92q4Jhdg8mnXpr2Me0fsHg7O4aXob7Tdn7lJ6a2apEB8eKUJps3g== Date: Fri, 27 Mar 2020 16:48:47 +0100 From: TBK To: "=?utf-8?Q?=7Ealpine/devel=40lists.alpinelinux.org?=" <~alpine/devel@lists.alpinelinux.org> Message-ID: <9F421575-812C-49E9-9AF7-C20BB0155DED@getmailspring.com> In-Reply-To: <20200327161329.6ff931bb@ncopa-desktop.copa.dup.pw> References: <20200327161329.6ff931bb@ncopa-desktop.copa.dup.pw> Subject: Re: DNS resolvers and root hints MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5e7e205f_4da41af0_eb8" X-Last-TLS-Session-Version: TLSv1.2 --5e7e205f_4da41af0_eb8 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline > That is great. Personally I think option 3 would be the most convenient > for end users. It is not much work but it needs to be done every 6 > months or so, and can be scripted. Could for example have a script to > create an MR or similar. Along those lines, it could be semi or fully automated with a GitLab subproject with a scheduled pipeline triggering merge requests on aports or pushing the changes directly. https://docs.gitlab.com/ee/ci/pipelines/schedules.html https://about.gitlab.com/blog/2017/09/05/how-to-automatically-create-a-new-mr-on-gitlab-with-gitlab-ci/ Yours sincerely Jacob aka TBK On Mar 27 2020, at 4:13 pm, Natanael Copa wrote: > On Thu, 26 Mar 2020 18:58:41 +0000 Duncan Bellamy wrote: > Hi > I volunteer to be a maintainer for number 3 if that is chosen. That is great. Personally I think option 3 would be the most convenient for end users. It is not much work but it needs to be done every 6 months or so, and can be scripted. Could for example have a script to create an MR or similar. -nc > > > On 26 Mar 2020, at 11:46, Natanael Copa > > wrote: > > > > Hi! > > > > We got a request[1] to remove dns-root-hints package, which has > > been a source of controversy in the past. > > > > The problem is that a DNS resolver needs the root hints to resolve > > and this data is not static, it changes over time. To fetch the > > updated root.hints you need an old version of it (eg it is a boot > > strap problem), so we ship a copy of root hints with our resolvers. > > > > [1]: https://gitlab.alpinelinux.org/alpine/aports/issues/11324 > > > > There are two problems with this: The root.hints gets outdated and > > need to b e maintained. We have been rightfully critizised for not > > maintain this well in the past. To solve this we provide a > > maintenance cron job that fetches it regularily. This leads to the > > second problem: Maintenance script requires gnupg to verify > > signature, so it introduces a big dependency chain for the > > resolvers. > > > > As I see we have the following options: > > > > 1) keep things as it currently is, provide a shared dns-root-hints > > with update script/cronjob. > > Pros: > > - resolvers work out of the box, inclusive maintenance > > - relatively low maintance for us. we only need keep the version in > > git master updated. (update one branch once every 6 months) > > Cons: > > - we have gnupg dependency for all resolvers, which may not be > > needed for everyone. > > - non trivial to remove gnupg if update script is not needed/used > > > > > > > > 2) keep dns-root-hints as optional package, but remove the hard > > dependency of it Pros: > > - relatively low maint enance for us. we only need update git master > > every six months. > > - give flexibility to use own solution or use the dns-roots-hits > > solution from alpine repos. > > Cons: > > - resolvers may not work out of the box and users may need to > > explicitly install the extra dns-root-hints package. This needs > > to be documented. > > - we still need to maintain the optional dns-root-hints package. > > - DNS resolving may break for users when they upgrade > > > > > > > > 3) keep dns-root-hints but exclude the update script > > Pros: > > - resolvers will work out of the box > > - we get rid of gnupg dependency > > - backwards compatible. upgrades will not break anything > > Cons: > > - more maintenance on us. we may need update the package every 6 > > months for our 5 maintained git branches. (master + 4 x > > 3.*-stable) > > > > > > > > 4) remove dns-root-hints and let user deal with it. > > Pros: > > - saves us for lots of work > > Cons: > > - resolvers will probably not work out of the box (at least unbound > > ships with an internal root.hints so I think unbound will work) > > - inconvenient for users who will have to write their own > > - DNS resolving may break for users when they upgrade > > > > > > > > Do we have other options? > > > > What do you think we should do? > > > > Are there any volunteers to do maintenance (for option 3)? > > > > > > -nc > --5e7e205f_4da41af0_eb8 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
> That is great. Personally I think option 3 would be the most co= nvenient
> for end users. It is not much work but it needs t= o be done every 6
> months or so, and can be scripted. Could= for example have a script to
> create an MR or similar.
Along those lines, it could be semi or fully automated with a = GitLab subproject with a scheduled pipeline triggering merge requests on = aports or pushing the changes directly.

https://docs.gitlab= .com/ee/ci/pipelines/schedules.html
https://about.gitlab.com/bl= og/2017/09/05/how-to-automatically-create-a-new-mr-on-gitlab-with-gitlab-= ci/

Yours sincerely
Jacob aka TBK

On Mar 27 2020, at 4:13 pm, Nata= nael Copa <ncopa=40alpinelinux.org> wrote:
On= Thu, 26 Mar 2020 18:58:41 +0000 Duncan Bellamy wrote: > Hi > I vol= unteer to be a maintainer for number 3 if that is chosen. That is great. = Personally I think option 3 would be the most convenient for end users. I= t is not much work but it needs to be done every 6 months or so, and can = be scripted. Could for example have a script to create an MR or similar. = -nc > > > On 26 Mar 2020, at 11:46, Natanael Copa > > wrot= e: > > > > Hi=21 > > > > We got a request=5B1=5D = to remove dns-root-hints package, which has > > been a source of co= ntroversy in the past. > > > > The problem is that a DNS reso= lver needs the root hints to resolve > > and this data is not stati= c, it changes over time. To fetch the > > updated root.hints you ne= ed an old version of it (eg it is a boot > > strap problem), so we = ship a copy of root hints with our resolvers. > > > > =5B1=5D= : https://gitlab.alpinelinux.org/alpine/aports/issues/11324 > > >= ; > There are two problems with this: The root.hints gets outdated and= > > need to be maintained. We have been rightfully critizised for = not > > maintain this well in the past. To solve this we provide a = > > maintenance cron job that fetches it regularily. This leads to = the > > second problem: Maintenance script requires gnupg to verify= > > signature, so it introduces a big dependency chain for the >= ; > resolvers. > > > > As I see we have the following opti= ons: > > > > 1) keep things as it currently is, provide a sha= red dns-root-hints > > with update script/cronjob. > > Pros: = > > - resolvers work out of the box, inclusive maintenance > >= ; - relatively low maintance for us. we only need keep the version in >= ; > git master updated. (update one branch once every 6 months) > &= gt; Cons: > > - we have gnupg dependency for all resolvers, which m= ay not be > > needed for everyone. > > - non trivial to remov= e gnupg if update script is not needed/used > > > > > >= > > 2) keep dns-root-hints as optional package, but remove the har= d > > dependency of it Pros: > > - relatively low maintenance= for us. we only need update git master > > every six months. > = > - give flexibility to use own solution or use the dns-roots-hits >= ; > solution from alpine repos. > > Cons: > > - resolvers = may not work out of the box and users may need to > > explicitly in= stall the extra dns-root-hints package. This needs > > to be docume= nted. > > - we still need to maintain the optional dns-root-hints p= ackage. > > - DNS resolving may break for users when they upgrade &= gt; > > > > > > > 3) keep dns-root-hints but exclude= the update script > > Pros: > > - resolvers will work out of= the box > > - we get rid of gnupg dependency > > - backwards= compatible. upgrades will not break anything > > Cons: > > -= more maintenance on us. we may need update the package every 6 > >= months for our 5 maintained git branches. (master + 4 x > > 3.*-st= able) > > > > > > > > 4) remove dns-root-hints an= d let user deal with it. > > Pros: > > - saves us for lots of= work > > Cons: > > - resolvers will probably not work out of= the box (at least unbound > > ships with an internal root.hints so= I think unbound will work) > > - inconvenient for users who will h= ave to write their own > > - DNS resolving may break for users when= they upgrade > > > > > > > > Do we have other op= tions=3F > > > > What do you think we should do=3F > > = > > Are there any volunteers to do maintenance (for option 3)=3F &g= t; > > > > > -nc >
--5e7e205f_4da41af0_eb8--