From: "Jacob Thrane Lund" <jtl@jjtc.eu>
In-Reply-To: <20200327161329.6ff931bb@ncopa-desktop.copa.dup.pw>
Content-Type: text/plain; charset="utf-8"
Date: Fri, 27 Mar 2020 18:25:34 +0100
To: ~alpine/devel@lists.alpinelinux.org
MIME-Version: 1.0
Message-ID: <27d6-5e7e3700-5-1f83de00@177638993>
Subject: =?utf-8?q?Re=3A?= DNS resolvers and root hints
User-Agent: SOGoMail 4.3.0
Content-Transfer-Encoding: quoted-printable

On Friday, March 27, 2020 16:13 CET, Natanael Copa <ncopa@alpinelinux.o=
rg> wrote: 
 
> On Thu, 26 Mar 2020 18:58:41 +0000
> Duncan Bellamy <a.16bit.sysop@me.com> 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 convenie=
nt
> 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

Along those lines, it could be semi or fully automated with a GitLab su=
bproject 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 26 Mar 2020, at 11:46, Natanael Copa <ncopa@alpinelinux.org>
> > > 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 resolv=
e
> > > 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 resolver=
s.
> > > 
> > > [1]: https://gitlab.alpinelinux.org/alpine/aports/issues/11324
> > > 
> > > There are two problems with this: The root.hints gets outdated an=
d
> > > 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 th=
e
> > > 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-hint=
s
> > > 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/use=
d
> > > 
> > > 
> > > 
> > > 2) keep dns-root-hints as optional package, but remove the hard
> > > dependency of it Pros:
> > >  - relatively low maintenance for us. we only need update git mas=
ter
> > >    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 nee=
ds
> > > 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 unbo=
und
> > >    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  
> >