Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Duncan Bellamy <a.16bit.sysop@me.com>
Mime-Version: 1.0 (1.0)
Subject: Re: DNS resolvers and root hints
Date: Sat, 28 Mar 2020 06:24:33 +0000
Message-Id: <A1C5526E-D1EB-46A4-8797-974DAAD9E3DA@me.com>
References: <27d6-5e7e3700-5-1f83de00@177638993>
Cc: ~alpine/devel@lists.alpinelinux.org
In-Reply-To: <27d6-5e7e3700-5-1f83de00@177638993>
To: Jacob Thrane Lund <jtl@jjtc.eu>

I have some scripts for travis CI that use wget to check for new versions on=
 github and curl for ftp servers

Sent from my iPad

> On 27 Mar 2020, at 17:26, Jacob Thrane Lund <jtl@jjtc.eu> wrote:
>=20
> =EF=BB=BFOn Friday, March 27, 2020 16:13 CET, Natanael Copa <ncopa@alpinel=
inux.org> wrote:=20
>=20
>>> On Thu, 26 Mar 2020 18:58:41 +0000
>>> Duncan Bellamy <a.16bit.sysop@me.com> wrote:
>>>=20
>>> Hi
>>> I volunteer to be a maintainer for number 3 if that is chosen.=20
>>=20
>> 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.
>>=20
>> -nc
>=20
> Along those lines, it could be semi or fully automated with a GitLab subpr=
oject with a scheduled pipeline triggering merge requests on aports or pushi=
ng the changes directly.
>=20
> 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/
>=20
> Yours sincerely
> Jacob aka TBK
>=20
>>>=20
>>>> On 26 Mar 2020, at 11:46, Natanael Copa <ncopa@alpinelinux.org>
>>>> wrote:
>>>>=20
>>>> Hi!
>>>>=20
>>>> We got a request[1] to remove dns-root-hints package, which has
>>>> been a source of controversy in the past.
>>>>=20
>>>> 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.
>>>>=20
>>>> [1]: https://gitlab.alpinelinux.org/alpine/aports/issues/11324
>>>>=20
>>>> 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.
>>>>=20
>>>> As I see we have the following options:
>>>>=20
>>>> 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
>>>>=20
>>>>=20
>>>>=20
>>>> 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 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
>>>>=20
>>>>=20
>>>>=20
>>>> 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)
>>>>=20
>>>>=20
>>>>=20
>>>> 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
>>>>=20
>>>>=20
>>>>=20
>>>> Do we have other options?
>>>>=20
>>>> What do you think we should do?
>>>>=20
>>>> Are there any volunteers to do maintenance (for option 3)?
>>>>=20
>>>>=20
>>>> -nc =20
>>>=20