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 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 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 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



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

Hi
I volunteer to be a maintainer for number 3 if that is chosen. 

> 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 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 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 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 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
> 
> 
> 
> 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

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 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 <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 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 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 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 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
> > 
> > 
> > 
> > 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  
> 

> 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 <ncopa@alpinelinux.org> 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 >

On Friday, March 27, 2020 16:13 CET, Natanael Copa <ncopa@alpinelinux.org> 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 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

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 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 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 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 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 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
> > > 
> > > 
> > > 
> > > 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  
> >

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:
> 
> On Friday, March 27, 2020 16:13 CET, Natanael Copa <ncopa@alpinelinux.org> 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 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
> 
> 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 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 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 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 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 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
>>>> 
>>>> 
>>>> 
>>>> 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  
>>>