Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Am 15.04.20 um 08:56 schrieb Reindl Harald: > > > Am 15.04.20 um 08:51 schrieb Klaus Darilion: >> Hello! >> >> What is the rationale of: >> >> bind9 (1:9.13.6-1) experimental; urgency=medium >> ... >> * Rename the init scripts to named to match the name of the daemon >> >> >> Since years, Debian and Ubuntu User, and plenty of scripts and automation >> software (Puppet ...), know that the service is called "bind9". I think it >> is very confusing and will cause lots of headaches once Ubuntu 18.04 or >> Debian 11 is released. >> >> So I really do not understand this renaming. >> >> The software is "Bind 9". The package is "bind9". The service for long time >> was "bind9". The config is in /etc/bind. Only the binary is named. So it >> would have made more sense to rename the binary. (actually the binary is not >> so important for end users: they install the package and manage the service >> and usually do not have to worry about the name of the binary). >> >> It would be great if you undo this change before release of 18.04 > > you confuse the upstream project with your distribution > > bind9 was completly wrong in the debian world as well as apache2 for > httpd, on sane distributions it's "httpt" and "named" all the years > beause it's nonsense to throw vesions in service names BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all [root@srv-rhsoft:~]$ systemctl status sddm ● sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/display-manager.service.d [root@srv-rhsoft:~]$ systemctl status display-manager.service ● sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/display-manager.service.d └─security.conf, start-before.conf [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/sddm.service [Unit] Description=Simple Desktop Display Manager Conflicts=getty@tty1.service After=getty@tty1.service systemd-logind.service [Service] ExecStart=/usr/bin/sddm Restart=always EnvironmentFile=-/etc/sysconfig/sddm [Install] Alias=display-manager.service ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
> -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von Reindl > Harald > Gesendet: Mittwoch, 15. April 2020 09:05 > An: bind-users@lists.isc.org > Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to > named? > > > > Am 15.04.20 um 08:56 schrieb Reindl Harald: > > > > > > Am 15.04.20 um 08:51 schrieb Klaus Darilion: > >> Hello! > >> > >> What is the rationale of: > >> > >> bind9 (1:9.13.6-1) experimental; urgency=medium > >> ... > >> * Rename the init scripts to named to match the name of the daemon > >> > >> > >> Since years, Debian and Ubuntu User, and plenty of scripts and > automation software (Puppet ...), know that the service is called "bind9". I > think it is very confusing and will cause lots of headaches once Ubuntu 18.04 > or Debian 11 is released. > >> > >> So I really do not understand this renaming. > >> > >> The software is "Bind 9". The package is "bind9". The service for long time > was "bind9". The config is in /etc/bind. Only the binary is named. So it would > have made more sense to rename the binary. (actually the binary is not so > important for end users: they install the package and manage the service and > usually do not have to worry about the name of the binary). > >> > >> It would be great if you undo this change before release of 18.04 > > > > you confuse the upstream project with your distribution > > > > bind9 was completly wrong in the debian world as well as apache2 for > > httpd, on sane distributions it's "httpt" and "named" all the years > > beause it's nonsense to throw vesions in service names > > BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all > > [root@srv-rhsoft:~]$ systemctl status sddm > ● sddm.service - Simple Desktop Display Manager >Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor > preset: enabled) > Drop-In: /etc/systemd/system/display-manager.service.d > > [root@srv-rhsoft:~]$ systemctl status display-manager.service > ● sddm.service - Simple Desktop Display Manager >Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor > preset: enabled) > Drop-In: /etc/systemd/system/display-manager.service.d >└─security.conf, start-before.conf > > [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/sddm.service > [Unit] > Description=Simple Desktop Display Manager > Conflicts=getty@tty1.service > After=getty@tty1.service systemd-logind.service > > [Service] > ExecStart=/usr/bin/sddm > Restart=always > EnvironmentFile=-/etc/sysconfig/sddm > > [Install] > Alias=display-manager.service Can you please describe what you want to point out? I can not follow you. Klaus ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
> > It would be great if you undo this change before release of 18.04 > > you confuse the upstream project with your distribution > > bind9 was completly wrong in the debian world as well as apache2 for > httpd, on sane distributions it's "httpt" and "named" all the years > beause it's nonsense to throw vesions in service names I do not complain about the version number, but of the name. And in my opinion it is not sane to call a service/package httpd if the name of the software is Apache. regards Klaus ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Am 15.04.20 um 09:08 schrieb Klaus Darilion: The software is "Bind 9". The package is "bind9". The service for long time >> was "bind9". The config is in /etc/bind. Only the binary is named. So it >> would >> have made more sense to rename the binary. (actually the binary is not so >> important for end users: they install the package and manage the service and >> usually do not have to worry about the name of the binary). It would be great if you undo this change before release of 18.04 >>> >>> you confuse the upstream project with your distribution >>> >>> bind9 was completly wrong in the debian world as well as apache2 for >>> httpd, on sane distributions it's "httpt" and "named" all the years >>> beause it's nonsense to throw vesions in service names >> >> BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all >> >> [root@srv-rhsoft:~]$ systemctl status sddm >> ● sddm.service - Simple Desktop Display Manager >>Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor >> preset: enabled) >> Drop-In: /etc/systemd/system/display-manager.service.d >> >> [root@srv-rhsoft:~]$ systemctl status display-manager.service >> ● sddm.service - Simple Desktop Display Manager >>Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor >> preset: enabled) >> Drop-In: /etc/systemd/system/display-manager.service.d >>└─security.conf, start-before.conf >> >> [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/sddm.service >> [Unit] >> Description=Simple Desktop Display Manager >> Conflicts=getty@tty1.service >> After=getty@tty1.service systemd-logind.service >> >> [Service] >> ExecStart=/usr/bin/sddm >> Restart=always >> EnvironmentFile=-/etc/sysconfig/sddm >> >> [Install] >> Alias=display-manager.service > > Can you please describe what you want to point out? I can not follow you that every other distibution calls it all the time "named" and "httpd" and it's painful every time you toch a debian setup you have to remember "apache" and "bind9" what if bind10 wouldn't have failed and you get a software update after some years? what if httpd releases 3.0 ina few years besides that "apache" is completly wrong to begin with becaus eit could be Apache Tomcat, Apache Trafficserver, Apache Httpd mainly that this is a distribution issue and when they are smart you can type "systemctl reload named" and "systemctl reload bind9" without confusing people which know it's named outside the debian world Units can be aliased (have an alternative name), by creating a symlink from the new name to the existing name in one of the unit search paths. For example, systemd-networkd.service has the alias dbus-org.freedesktop.network1.service, created during installation as a symlink, so when systemd is asked through D-Bus to load dbus-org.freedesktop.network1.service, it'll load systemd-networkd.service. As another example, default.target — the default system target started at boot — is commonly symlinked (aliased) to either multi-user.target or graphical.target to select what is started by default. Alias names may be used in commands like disable, start, stop, status, and similar, and in all unit dependency directives, including Wants=, Requires=, Before=, After= ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Am 15.04.20 um 09:09 schrieb Klaus Darilion: >>> It would be great if you undo this change before release of 18.04 >> >> you confuse the upstream project with your distribution >> >> bind9 was completly wrong in the debian world as well as apache2 for >> httpd, on sane distributions it's "httpt" and "named" all the years >> beause it's nonsense to throw vesions in service names > > I do not complain about the version number, but of the name. > > And in my opinion it is not sane to call a service/package httpd if the name > of the software is Apache seriously? https://www.apache.org/ https://downloads.apache.org/httpd/ https://downloads.apache.org/tomcat/ https://downloads.apache.org/trafficserver/ and what do you do after httpd-3.0 is out? you won't have httpd2 and httpd3 on the same system from your distribution ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, 15 Apr 2020, Klaus Darilion wrote: -Ursprüngliche Nachricht- Von: bind-users Im Auftrag von Reindl Harald Gesendet: Mittwoch, 15. April 2020 09:05 An: bind-users@lists.isc.org Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to named? Am 15.04.20 um 08:56 schrieb Reindl Harald: Am 15.04.20 um 08:51 schrieb Klaus Darilion: Hello! What is the rationale of: bind9 (1:9.13.6-1) experimental; urgency=medium ... * Rename the init scripts to named to match the name of the daemon Since years, Debian and Ubuntu User, and plenty of scripts and automation software (Puppet ...), know that the service is called "bind9". I think it is very confusing and will cause lots of headaches once Ubuntu 18.04 or Debian 11 is released. So I really do not understand this renaming. The software is "Bind 9". The package is "bind9". The service for long time was "bind9". The config is in /etc/bind. Only the binary is named. So it would have made more sense to rename the binary. (actually the binary is not so important for end users: they install the package and manage the service and usually do not have to worry about the name of the binary). It would be great if you undo this change before release of 18.04 you confuse the upstream project with your distribution bind9 was completly wrong in the debian world as well as apache2 for httpd, on sane distributions it's "httpt" and "named" all the years beause it's nonsense to throw vesions in service names BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all [root@srv-rhsoft:~]$ systemctl status sddm ● sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/display-manager.service.d [root@srv-rhsoft:~]$ systemctl status display-manager.service ● sddm.service - Simple Desktop Display Manager Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/display-manager.service.d └─security.conf, start-before.conf [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/sddm.service [Unit] Description=Simple Desktop Display Manager Conflicts=getty@tty1.service After=getty@tty1.service systemd-logind.service [Service] ExecStart=/usr/bin/sddm Restart=always EnvironmentFile=-/etc/sysconfig/sddm [Install] Alias=display-manager.service Can you please describe what you want to point out? I can not follow you. You can set aliases in the service file and call the service whatever you like (multiple names possible, too). I admit, this has nothing to do with the package name. Though: you should complain to debian/ubuntu/..., not upstream (=here) about package name changes. Regarding version numbers: In the world, where I come from (arch linux), version numbers are only appended for *legacy* packages - e.g. "bind9" would be valid, if there is a "bind" package, that has a higher version than 9. Btw.: bind is packaged as "bind" for years on arch linux. regards, Erich Klaus ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEE3p92iMrPBP64GmxZCu7JB1Xae1oFAl6WtScACgkQCu7JB1Xa e1oenBAAloNKuOGmXxJsf8qLa3MxagpaCQNwSvf5IrfbMXfRELMEJ/phXujI+Aim KAbmTyklYLF/esuUzl9ttj02OBlyx7+blDOQtHmkC8kgtyBzWXI99Nk6pWGAS4hs cxIMsNHqgIcH22Tv254eWaJjV/rxeB5xVrK4TbZn2JD7Mz/6GOrPgNDsEa4SoCER q+q/8bUauH8JryvHBidOQ3at06XGkl/CEOZz2VcWohE+/K32giJmNK2XTJAoIMQ6 s49sgp9pWjv+fP9pbbniS2HTHlYn4rhyGJk3LlRfbyN9iYRSfOB52/xog/egl8Ur lfi8BDotghbmm19it9f0chtNPyob/FytrcMt1iQxfvkFDHPfaRmh/cCkT7elsPHa s8ypNodJULyocKIrkwsabV4+rFau05SZVRNoIMAOdwSTvRUJfbmDY5dgjJl0QDOy 5WvAfEVXJ3Q/rZEqtsXowlOGLLyA+tRyb1wTsH7b4vBdzZhXt3mLdo3yTz+UDQnv mcWPC5LoW94M9KAF2t9C1yS90/8IPY2B8lKsJ+XoWAdMKm8oWstvAh+tGvccGiuT ITkPv14ht+Ev8X+f5gD2WyXQI1H3Udm8NFXMYj32XPh4GpqRXvcobpNY7ezWXm/j yQWzI3FxGdelPE3fH/k49KELhj7mdiBeacmmyZSEzW/C1FynQec= =5NW9 -END PGP SIGNATURE-___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [External] AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On 4/15/2020 3:09 AM, Klaus Darilion wrote: > I do not complain about the version number, but of the name. > > And in my opinion it is not sane to call a service/package httpd if the name > of the software is Apache. For me, adding the version number can make sense if there is an intention to have both X and Y running on machines simultaneously. Or if there is a need / ability to choose one version with more than one being provided by the distro. Apache httpd 1 versus 2, was a real choice not many years ago. MySQL 5 versus 8 has a similar situation now. I'm sure I can point out others where the version number in the service is a pathway to upgrades. And with Apache HTTPD, you've picked a special naming case. It is the granddaddy of the entire Apache Software Foundation and has morphed from being called just "Apache" to "Apache httpd". Calling the service apachehttpd might be good and differentiate it from the ~383 Apache projects (https://projects.apache.org/) and other httpd daemons. But it's been just httpd in a lot of distros for over 20 years so a LOT of historical convention here. Unfortunately, the exact name is up to the distribution, not really the project. So this is really a discussion for an Ubuntu/Debian mailing list, not this one. Regards, KAM ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: [External] AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Am 15.04.20 um 09:21 schrieb Kevin A. McGrail: > On 4/15/2020 3:09 AM, Klaus Darilion wrote: >> I do not complain about the version number, but of the name. >> >> And in my opinion it is not sane to call a service/package httpd if the name >> of the software is Apache. > > For me, adding the version number can make sense if there is an > intention to have both X and Y running on machines simultaneously. Or > if there is a need / ability to choose one version with more than one > being provided by the distro. Apache httpd 1 versus 2, was a real > choice not many years ago. MySQL 5 versus 8 has a similar situation > now. I'm sure I can point out others where the version number in the > service is a pathway to upgrades. in all that cases the default package of the distribution (at least outside debian) is unversioned and you can optin to an older or newer major version by explicit install "mysql8" but the expected default in just do "dnf install mysqld" and if you can install both at the same time (depends on packaging) https://linux.die.net/man/8/alternatives is the way to go ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
> -Ursprüngliche Nachricht- > Von: bind-users Im Auftrag von Reindl > Harald > Gesendet: Mittwoch, 15. April 2020 09:17 > An: bind-users@lists.isc.org > Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to > named? > > > > Am 15.04.20 um 09:09 schrieb Klaus Darilion: > >>> It would be great if you undo this change before release of 18.04 > >> > >> you confuse the upstream project with your distribution > >> > >> bind9 was completly wrong in the debian world as well as apache2 for > >> httpd, on sane distributions it's "httpt" and "named" all the years > >> beause it's nonsense to throw vesions in service names > > > > I do not complain about the version number, but of the name. > > > > And in my opinion it is not sane to call a service/package httpd if the name > of the software is Apache > > seriously? > > https://www.apache.org/ > > https://downloads.apache.org/httpd/ > https://downloads.apache.org/tomcat/ > https://downloads.apache.org/trafficserver/ > > and what do you do after httpd-3.0 is out? > > you won't have httpd2 and httpd3 on the same system from your > distribution Why not? With postgresql it is very common. You have postgresql-X and a meta package pointing to the newest version. That's propapbly not what "every distribution" does, but how a good distribution like Debian and Ubuntu does it. It is very very sane to have the version number in the package, and a package without version number pointing to the newest version. Eg. this is how the Linux kernel is handled in Debian/Ubuntu. What about python? Only a single python interpreter is allowed with your good distros? In Debian you have all oft hem installed at the same time - this is a very very good approach! But as you have missed again - I do not complain about the version number, but that a "winning team" was changed without seeing a problem. regards Klaus ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Am 15.04.20 um 09:42 schrieb Klaus Darilion: >> -Ursprüngliche Nachricht- >> Von: bind-users Im Auftrag von Reindl >> Harald >> Gesendet: Mittwoch, 15. April 2020 09:17 >> An: bind-users@lists.isc.org >> Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to >> named? >> >> >> >> Am 15.04.20 um 09:09 schrieb Klaus Darilion: > It would be great if you undo this change before release of 18.04 you confuse the upstream project with your distribution bind9 was completly wrong in the debian world as well as apache2 for httpd, on sane distributions it's "httpt" and "named" all the years beause it's nonsense to throw vesions in service names >>> >>> I do not complain about the version number, but of the name. >>> >>> And in my opinion it is not sane to call a service/package httpd if the name >> of the software is Apache >> >> seriously? >> >> https://www.apache.org/ >> >> https://downloads.apache.org/httpd/ >> https://downloads.apache.org/tomcat/ >> https://downloads.apache.org/trafficserver/ >> >> and what do you do after httpd-3.0 is out? >> >> you won't have httpd2 and httpd3 on the same system from your >> distribution > > Why not? With postgresql it is very common. You have postgresql-X and a meta > package pointing to the newest version. That's propapbly not what "every > distribution" does, but how a good distribution like Debian and Ubuntu does > it. not over a long time outsuide the LTS world because nobody will maintain it (besides that it's not the main point of my last message) and how does that fix your wrong assumption "in my opinion it is not sane to call a service/package httpd if the name of the software is Apache" we are using httpd on backends and trafficserver as reverse proxy - who of both apache projects is listening when i scream "apache" to my servers? > It is very very sane to have the version number in the package, and a package > without version number pointing to the newest version. Eg. this is how the > Linux kernel is handled in Debian/Ubuntu well, than complain at your distribution given that your mails are landing in the nic.at folder (we are a registrar) and i know that nic.at normally has a very good technical expertise i guess you are new there may i ask you talk to your seniors how and where to complain about distribution level changes and besides you are at the wrong list it's nothing easier than make your owen overrides and aliases with systemd-dropins so that you can call "systemctl relaod/restart/start/stop" with whatever name you like no matter how the distribution is calling the service that's far quicker implemented and deployed even before you deploy the update itself as it took to write your initial mail ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
> On 15 Apr 2020, at 09:05, Reindl Harald wrote: > > BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all Is this the case of you being rude instead of getting the facts? bind9 (1:9.15.3-2) unstable; urgency=medium * Fix the section for bind9 alias in the systemd unit [GL #1193] -- Ondřej Surý Wed, 28 Aug 2019 21:35:44 +0200 $ cat named.service [Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network.target Wants=nss-lookup.target Before=nss-lookup.target [Service] EnvironmentFile=-/etc/default/named ExecStart=/usr/sbin/named -f $OPTIONS ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop [Install] WantedBy=multi-user.target Alias=bind9.service -- Ondřej Surý ond...@isc.org signature.asc Description: Message signed with OpenPGP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
your changelog snippet is handeled as signature seperator so a forward when someone starts complaining "Since years, Debian and Ubuntu User, and plenty of scripts and automation software (Puppet ...), know that the service is called" i assume that he at least would have tried if something is broken *before* complain and so it's a logicla assumption the alias is missing Debian/Ubuntu packages and what should be done there before the next major release of the distribution don't belong here anyways Weitergeleitete Nachricht Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to named? Datum: Wed, 15 Apr 2020 10:04:39 +0200 Von: Ondřej Surý > On 15 Apr 2020, at 09:05, Reindl Harald wrote: > > BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all Is this the case of you being rude instead of getting the facts? bind9 (1:9.15.3-2) unstable; urgency=medium * Fix the section for bind9 alias in the systemd unit [GL #1193] $ cat named.service [Unit] Description=BIND Domain Name Server Documentation=man:named(8) After=network.target Wants=nss-lookup.target Before=nss-lookup.target [Service] EnvironmentFile=-/etc/default/named ExecStart=/usr/sbin/named -f $OPTIONS ExecReload=/usr/sbin/rndc reload ExecStop=/usr/sbin/rndc stop [Install] WantedBy=multi-user.target Alias=bind9.service ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Klaus, the default and preferred init system on both Debian and Ubuntu is systemd, and the unit has proper Alias, so it is recognized also under "bind9" name. The sysv-rc script doesn’t have the capability of aliases, so unfortunately, there’s a downfall from the renaming, but it would not make sense to have a different name for different init systems. If you are using sysvinit, the choice and the suffering that comes from that choice is all yours. The renaming was done as it was a logical choice, the service is starting a daemon, and not a package, and daemon name is `named`. Also it is the name used by RPM based systems and Arch Linux and Gentoo, so it was also made to make BIND 9 packages in Debian/Ubuntu more unified with rest of the Linux world. Ondrej -- Ondřej Surý ond...@isc.org > On 15 Apr 2020, at 08:51, Klaus Darilion wrote: > > Hello! > > What is the rationale of: > > bind9 (1:9.13.6-1) experimental; urgency=medium > ... > * Rename the init scripts to named to match the name of the daemon > > > Since years, Debian and Ubuntu User, and plenty of scripts and automation > software (Puppet ...), know that the service is called "bind9". I think it is > very confusing and will cause lots of headaches once Ubuntu 18.04 or Debian > 11 is released. > > So I really do not understand this renaming. > > The software is "Bind 9". The package is "bind9". The service for long time > was "bind9". The config is in /etc/bind. Only the binary is named. So it > would have made more sense to rename the binary. (actually the binary is not > so important for end users: they install the package and manage the service > and usually do not have to worry about the name of the binary). > > It would be great if you undo this change before release of 18.04. > > regards > Klaus > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users signature.asc Description: Message signed with OpenPGP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Am 15.04.20 um 10:08 schrieb Ondřej Surý: > you need to stop being rude to people on the bind-users mailing list, > personal attacks are not acceptable behaviour here. You should apologize > to Klaus. it's not a personal attack to clearly point out that discussions of distribution level changes don't belong to upstream lists and that one within a company should at least consult someone internally with more expierience and after "it is not sane to call a service/package httpd if the name of the software is Apache" i simply had enough it's also not a personal attack to point out that you could stop press "reply-all" on a mailing list so that your off-list copy which is quicker but has no list-headers don't break my reply-list button and threading >> On 15 Apr 2020, at 09:59, Reindl Harald wrote: >> >> given that your mails are landing in the nic.at folder (we are a >> registrar) and i know that nic.at normally has a very good technical >> expertise i guess you are new there >> >> may i ask you talk to your seniors how and where to complain about >> distribution level changes and besides you are at the wrong list it's >> nothing easier than make your owen overrides and aliases with >> systemd-dropins so that you can call "systemctl >> relaod/restart/start/stop" with whatever name you like no matter how the >> distribution is calling the service ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Thanks for answer! So actually it is just a cosmetic change not addressing a real problem. I will miss the bind9 service :-( Klaus > -Ursprüngliche Nachricht- > Von: Ondřej Surý > Gesendet: Mittwoch, 15. April 2020 10:15 > An: Klaus Darilion > Cc: bind-users@lists.isc.org > Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to > named? > > Klaus, > > the default and preferred init system on both Debian and Ubuntu is systemd, > and the unit has proper Alias, so it is recognized also under "bind9" name. > > The sysv-rc script doesn’t have the capability of aliases, so unfortunately, > there’s > a downfall from the renaming, but it would not make sense to have a > different name > for different init systems. If you are using sysvinit, the choice and the > suffering that > comes from that choice is all yours. > > The renaming was done as it was a logical choice, the service is starting a > daemon, > and not a package, and daemon name is `named`. Also it is the name used by > RPM > based systems and Arch Linux and Gentoo, so it was also made to make BIND > 9 packages > in Debian/Ubuntu more unified with rest of the Linux world. > > Ondrej > -- > Ondřej Surý > ond...@isc.org > > > On 15 Apr 2020, at 08:51, Klaus Darilion wrote: > > > > Hello! > > > > What is the rationale of: > > > > bind9 (1:9.13.6-1) experimental; urgency=medium > > ... > > * Rename the init scripts to named to match the name of the daemon > > > > > > Since years, Debian and Ubuntu User, and plenty of scripts and automation > software (Puppet ...), know that the service is called "bind9". I think it is > very > confusing and will cause lots of headaches once Ubuntu 18.04 or Debian 11 is > released. > > > > So I really do not understand this renaming. > > > > The software is "Bind 9". The package is "bind9". The service for long time > was "bind9". The config is in /etc/bind. Only the binary is named. So it would > have made more sense to rename the binary. (actually the binary is not so > important for end users: they install the package and manage the service and > usually do not have to worry about the name of the binary). > > > > It would be great if you undo this change before release of 18.04. > > > > regards > > Klaus > > ___ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe > from this list > > > > bind-users mailing list > > bind-users@lists.isc.org > > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
> Am 15.04.20 um 10:08 schrieb Ondřej Surý: > > you need to stop being rude to people on the bind-users mailing list, > > personal attacks are not acceptable behaviour here. You should apologize > > to Klaus. > > it's not a personal attack to clearly point out that discussions of > distribution level changes don't belong to upstream lists and that one As it seems your are very smart you probably have noticed that Ondřej did the change in den Debian package and is also very active an this mailing list. Further I am not they only bind-user using Debian/Ubuntu so probably other bind-user are also interested in the reason for the renaming. Hence, I on purpose used this mailing list. > within a company should at least consult someone internally with more > expierience and after "it is not sane to call a service/package httpd if > the name of the software is Apache" i simply had enough Your personal experience is not the gobal truth. It is your opinion but other experienced pepole see it different than you. Have a nice day Klaus FIN ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On Wed 15/Apr/2020 10:15:09 +0200 Ondřej Surý wrote: > The renaming was done as it was a logical choice, the service is starting a > daemon, > and not a package, and daemon name is `named`. Also it is the name used by RPM > based systems and Arch Linux and Gentoo, so it was also made to make BIND 9 > packages > in Debian/Ubuntu more unified with rest of the Linux world. > Calling it /renamed/ would have been beyond criticism... Best Ale -- signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On Wed, 2020-04-15 at 10:35 +0200, Klaus Darilion wrote: > Thanks for answer! > > So actually it is just a cosmetic change not addressing a real problem. > > I will miss the bind9 service :-( Wait until you find out about Predicatable Network Interface Names and iptables rules. :) -Jim P. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
Am 15.04.20 um 14:17 schrieb Jim Popovitch via bind-users: > On Wed, 2020-04-15 at 10:35 +0200, Klaus Darilion wrote: >> Thanks for answer! >> >> So actually it is just a cosmetic change not addressing a real problem. >> >> I will miss the bind9 service :-( > > > Wait until you find out about Predicatable Network Interface Names and > iptables rules. :) "net.ifnames=0 biosdevname=0" is your friend :-) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On Wed, 2020-04-15 at 14:21 +0200, Reindl Harald wrote: > > Am 15.04.20 um 14:17 schrieb Jim Popovitch via bind-users: > > On Wed, 2020-04-15 at 10:35 +0200, Klaus Darilion wrote: > > > Thanks for answer! > > > > > > So actually it is just a cosmetic change not addressing a real problem. > > > > > > I will miss the bind9 service :-( > > > > Wait until you find out about Predicatable Network Interface Names and > > iptables rules. :) > > "net.ifnames=0 biosdevname=0" is your friend :-) s! Didn't you know that is suppose to be difficult for people to figure out? :) -Jim P. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND9 DoT/DoH - request for comments
Hello All, I'm currently working on DoH/DoT design - most specifically, the configuration syntax that will be used to set up DoH/DoT. Since removing or modifying options in named.conf is very hard I want it to be done properly - hence this request for comments. The current design document is here: https://gitlab.isc.org/isc-projects/bind9/-/wikis/DoT/DoH-Design Feel free to comment either here on the mailing list or on the following ticket in our Gitlab: https://gitlab.isc.org/isc-projects/bind9/-/issues/1144 We especially look forward for feedback from people who are actively using DoT/DoH - what are other implementations doing well, what are they missing? Witold Kręcicki ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind v9.16.2 build, inconsistent GeoIP2 configuration options usage ?
cosmetic config error
building 9.16.2, config options include
--disable-geoip support GeoIP2 geolocation ACLs if available
[default=yes]
(this^^ is confusing usage; do you DISABLE-geoip in order TO 'support GeoIP2
geolocation ACLs if available' ?
shouldn't that be "--enable-geoip" [default=yes]?)
...
--with-geoip2 deprecated, use --with-maxminddb
--with-maxminddb=PATH Build with MaxMind GeoIP2 support (auto|yes|no|path)
[default=auto]
since I have installed GeoIP2*,
pkg-config --cflags --libs libmaxminddb
-I/usr/local/include -L/usr/local/lib64 -lmaxminddb
ls -al /usr/local/{include,lib64}/*maxmind*
-rw-r--r-- 1 root root 507 Mar 18 18:27
/usr/local/include/maxminddb_config.h
-rw-r--r-- 1 root root 8.4K Mar 18 18:27
/usr/local/include/maxminddb.h
-rwxr-xr-x 1 root root 943 Mar 18 18:27
/usr/local/lib64/libmaxminddb.la*
lrwxrwxrwx 1 root root 21 Mar 18 18:27
/usr/local/lib64/libmaxminddb.so -> libmaxminddb.so.0.0.7*
lrwxrwxrwx 1 root root 21 Mar 18 18:27
/usr/local/lib64/libmaxminddb.so.0 -> libmaxminddb.so.0.0.7*
-rwxr-xr-x 1 root root 122K Mar 18 18:27
/usr/local/lib64/libmaxminddb.so.0.0.7*
ls -al /var/lib/GeoIP2/
total 71M
drwxr-xr-x 2 named root 4.0K Apr 2 03:15 ./
drwxr-xr-x 85 root root 4.0K Apr 12 19:11 ../
-rw-rw-r-- 1 named root 6.4M Apr 15 12:09 GeoLite2-ASN.mmdb
-rw-rw-r-- 1 named root 61M Apr 15 12:09 GeoLite2-City.mmdb
-rw-rw-r-- 1 named root 3.7M Apr 15 12:09 GeoLite2-Country.mmdb
and *DO* want to "support GeoIP2 geoloc ACLs", building here with
--disable-geoip=yes \
--with-maxminddb=/var/lib/GeoIP2 \
FAILs with
configure: error: invalid feature name: geoip=yes
switching to
- --disable-geoip=yes \
+ --disable-geoip \
--with-maxminddb=/var/lib/GeoIP2 \
configure completes, reporting 'old' GeoIP support is correctly DISabled
but there's NO mention of GeoIP2/Lite support, i.e., *maxminddb
Optional features enabled:
Mutex lock type: adaptive
IPv6 support (--enable-ipv6)
Python tools (--with-python)
XML statistics (--with-libxml2)
JSON statistics (--with-json-c): -I/usr/include/json-c -ljson-c
HTTP zlib compression (--with-zlib)
LMDB database to store configuration for 'addzone' zones
(--with-lmdb)
IDN support (--with-libidn2)
Print backtrace on crash (--enable-backtrace)
Use symbol table for backtrace, named only (--enable-symtable)
Use GNU libtool (--with-libtool)
DNSSEC validation active by default (--enable-auto-validation)
Dynamically loadable zone (DLZ) drivers:
None
---
Features disabled or unavailable on this platform:
...
GeoIP2 access control (--enable-geoip)
...
after subsequent
make depend
make
make install
named -v
BIND 9.16.2 (Stable Release)
checking, the maxmind lib *is* linked
ldd `which named`
libmaxminddb.so.0 => /usr/lib64/libmaxminddb.so.0
(0x7f94618d8000)
so, *is* available GeoIP2 support with available DBs enabled, and this is just
a _reporting_ error?
or is it not correctly/completely enabled ... ?
what is the correct, complete config specification for using installed GeoIP2
support?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind v9.16.2 build, inconsistent GeoIP2 configuration options usage ?
Hi,
you are right this is a bit confusing, but you need to specify both:
--enable-geoip (as the feature independent of used libraries)
--with-maxmindsb (where to find the libraries)
Ondrej
--
Ondřej Surý — ISC
> On 15 Apr 2020, at 22:07, PGNet Dev wrote:
>
> cosmetic config error
>
> building 9.16.2, config options include
>
> --disable-geoip support GeoIP2 geolocation ACLs if available
> [default=yes]
>
> (this^^ is confusing usage; do you DISABLE-geoip in order TO 'support GeoIP2
> geolocation ACLs if available' ?
> shouldn't that be "--enable-geoip" [default=yes]?)
>
>
>
> ...
> --with-geoip2 deprecated, use --with-maxminddb
> --with-maxminddb=PATH Build with MaxMind GeoIP2 support (auto|yes|no|path)
> [default=auto]
>
> since I have installed GeoIP2*,
>
>pkg-config --cflags --libs libmaxminddb
>-I/usr/local/include -L/usr/local/lib64 -lmaxminddb
>
>ls -al /usr/local/{include,lib64}/*maxmind*
>-rw-r--r-- 1 root root 507 Mar 18 18:27
> /usr/local/include/maxminddb_config.h
>-rw-r--r-- 1 root root 8.4K Mar 18 18:27 /usr/local/include/maxminddb.h
>-rwxr-xr-x 1 root root 943 Mar 18 18:27
> /usr/local/lib64/libmaxminddb.la*
>lrwxrwxrwx 1 root root 21 Mar 18 18:27
> /usr/local/lib64/libmaxminddb.so -> libmaxminddb.so.0.0.7*
>lrwxrwxrwx 1 root root 21 Mar 18 18:27
> /usr/local/lib64/libmaxminddb.so.0 -> libmaxminddb.so.0.0.7*
>-rwxr-xr-x 1 root root 122K Mar 18 18:27
> /usr/local/lib64/libmaxminddb.so.0.0.7*
>
>ls -al /var/lib/GeoIP2/
>total 71M
>drwxr-xr-x 2 named root 4.0K Apr 2 03:15 ./
>drwxr-xr-x 85 root root 4.0K Apr 12 19:11 ../
>-rw-rw-r-- 1 named root 6.4M Apr 15 12:09 GeoLite2-ASN.mmdb
>-rw-rw-r-- 1 named root 61M Apr 15 12:09 GeoLite2-City.mmdb
>-rw-rw-r-- 1 named root 3.7M Apr 15 12:09 GeoLite2-Country.mmdb
>
> and *DO* want to "support GeoIP2 geoloc ACLs", building here with
>
>--disable-geoip=yes \
>--with-maxminddb=/var/lib/GeoIP2 \
>
> FAILs with
>
>configure: error: invalid feature name: geoip=yes
>
> switching to
>
> ---disable-geoip=yes \
> +--disable-geoip \
>--with-maxminddb=/var/lib/GeoIP2 \
>
> configure completes, reporting 'old' GeoIP support is correctly DISabled
> but there's NO mention of GeoIP2/Lite support, i.e., *maxminddb
>
>Optional features enabled:
>Mutex lock type: adaptive
>IPv6 support (--enable-ipv6)
>Python tools (--with-python)
>XML statistics (--with-libxml2)
>JSON statistics (--with-json-c): -I/usr/include/json-c -ljson-c
>HTTP zlib compression (--with-zlib)
>LMDB database to store configuration for 'addzone' zones (--with-lmdb)
>IDN support (--with-libidn2)
>Print backtrace on crash (--enable-backtrace)
>Use symbol table for backtrace, named only (--enable-symtable)
>Use GNU libtool (--with-libtool)
>DNSSEC validation active by default (--enable-auto-validation)
>Dynamically loadable zone (DLZ) drivers:
>None
>
> ---
>Features disabled or unavailable on this platform:
>...
>GeoIP2 access control (--enable-geoip)
>...
>
> after subsequent
>
>make depend
>make
>make install
>
>named -v
>BIND 9.16.2 (Stable Release)
>
> checking, the maxmind lib *is* linked
>
>ldd `which named`
>libmaxminddb.so.0 => /usr/lib64/libmaxminddb.so.0 (0x7f94618d8000)
>
>
> so, *is* available GeoIP2 support with available DBs enabled, and this is
> just a _reporting_ error?
> or is it not correctly/completely enabled ... ?
>
> what is the correct, complete config specification for using installed GeoIP2
> support?
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind v9.16.2 build, inconsistent GeoIP2 configuration options usage ?
On 4/15/20 1:50 PM, Ondřej Surý wrote: > you are right this is a bit confusing, but you need to specify both: > > --enable-geoip (as the feature independent of used libraries) > --with-maxmindsb (where to find the libraries) thx i'd also suggest - --with-maxmiddb + --with-libmaxmiddb to match pkg-config --list-all | grep max libmaxminddb libmaxminddb - C library for the MaxMind DB file format this --with-maxmindsb suggests to enter the location of the DBs (as spec'd with 'geoip-directory' in named.conf) doing so will pass config with no error, but then FAIL in 'make' step. shouldn't config _check_ for a valid lib in any path spec'd in --with-maxmindsb=/path/to/ ? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind v9.16.2 build, inconsistent GeoIP2 configuration options usage ?
On 4/15/20 2:46 PM, PGNet Dev wrote: > On 4/15/20 1:50 PM, Ondřej Surý wrote: >> you are right this is a bit confusing, but you need to specify both: >> >> --enable-geoip (as the feature independent of used libraries) >> --with-maxmindsb (where to find the libraries) > > thx > > i'd also suggest and, of course ... 'maxminddb' consistently everywhere. my typing's atrocious! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Debian/Ubuntu: Why was the service renamed from bind9 to named?
On 4/15/20 8:15 AM, Ondřej Surý wrote: Klaus, the default and preferred init system on both Debian and Ubuntu is systemd, and the unit has proper Alias, so it is recognized also under "bind9" name. The sysv-rc script doesn’t have the capability of aliases, so unfortunately, there’s a downfall from the renaming, but it would not make sense to have a different name for different init systems. If you are using sysvinit, the choice and the suffering that comes from that choice is all yours. The renaming was done as it was a logical choice, the service is starting a daemon, and not a package, and daemon name is `named`. Also it is the name used by RPM based systems and Arch Linux and Gentoo, so it was also made to make BIND 9 packages in Debian/Ubuntu more unified with rest of the Linux world. An even more beautiful name would have been "iscbind" : beta$ svcs -l iscbind fmri svc:/network/dns/iscbind:default name ISC BIND 9.11.16 SPARC V9 genunix enabled true stateonline next_state none state_time Thu Feb 20 04:35:15 2020 logfile /var/svc/log/network-dns-iscbind:default.log restartersvc:/system/svc/restarter:default contract_id 196663 dependency require_all/none svc:/system/filesystem/local (online) dependency require_any/error svc:/network/loopback (online) dependency optional_all/error svc:/milestone/network (online) beta$ Sadly the newer releases will never be *easily* ported back to old Solaris but we all need to move forwards. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
9.16.2 / DNSSEC / DS records
Updating from 9.14.11 to 9.16.2, and migrating existing signed zones to dnssec-policy, and have couple questions, probably quite trivial... We have signed zones with different key algorithms, now I want everything under the same ecdsa256 policy. I guess when the key algorithm changes, example from 8 to 13, we need to update the DS key at the registrar as well? About the DS keys, where can I find or retrieve them after the zone is automatically resigned by the dnssec-policy, to insert in to Hover.com's zone data? The Finnish Traficom .fi root service was able to retrieve the new DS records it self, but for Hover need to insert them manually. Do I need to keep the old DS records at the registrar for some period of time, of can I just swap the information there, without breaking anything? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
VS: 9.16.2 / DNSSEC / DS records
And yet, after updating Gemtrade.fi to dnssec-policy, ZSK and KSK both "13", and updating the DS record at the .fi root, I still get: (algorithm 13 not supportedsignature verification failed) In Verisign DNSSEC verifier. Lähettäjä: bind-users Puolesta Jukka Pakkanen Lähetetty: 16. huhtikuuta 2020 1:22 Vastaanottaja: bind-us...@isc.org Aihe: 9.16.2 / DNSSEC / DS records Updating from 9.14.11 to 9.16.2, and migrating existing signed zones to dnssec-policy, and have couple questions, probably quite trivial... We have signed zones with different key algorithms, now I want everything under the same ecdsa256 policy. I guess when the key algorithm changes, example from 8 to 13, we need to update the DS key at the registrar as well? About the DS keys, where can I find or retrieve them after the zone is automatically resigned by the dnssec-policy, to insert in to Hover.com's zone data? The Finnish Traficom .fi root service was able to retrieve the new DS records it self, but for Hover need to insert them manually. Do I need to keep the old DS records at the registrar for some period of time, of can I just swap the information there, without breaking anything? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.16.2 / DNSSEC / DS records
> On 16 Apr 2020, at 09:21, Jukka Pakkanen wrote: > > Updating from 9.14.11 to 9.16.2, and migrating existing signed zones to > dnssec-policy, and have couple questions, probably quite trivial… > > We have signed zones with different key algorithms, now I want everything > under the same ecdsa256 policy. I guess when the key algorithm changes, > example from 8 to 13, we need to update the DS key at the registrar as well? Yes. > About the DS keys, where can I find or retrieve them after the zone is > automatically resigned by the dnssec-policy, to insert in to Hover.com’s zone > data? dnssec-policy will publish CDS and CDNSKEY records after the right amount of time and if your registrar is checking they will automatically update the DS RRset in the parent zone. Otherwise you can use dnssec-dsfromkey to generate DS records from the DNSKEY records. > The Finnish Traficom .fi root service was able to retrieve the new DS records > it self, but for Hover need to insert them manually. > > Do I need to keep the old DS records at the registrar for some period of > time, of can I just swap the information there, without breaking anything? You can swap but note you need to wait until all caches are free of the records they where only signed with algorithm 8. Once the DS records are published you have to wait until all old DS records that listed algorithm 8 have cleared from caches before you stop signing with algorithm 8. There should be no CDS or CDNSKEY records for algorithm 8 when you do this. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: 9.16.2 / DNSSEC / DS records
Well the tester doesn’t support algorithm 13. The red x’s should be cautions as they aren’t failures (no working ds/dnskey pairs for supported algorithms in use), but rather the zone should be treated as insecure by the tester. Mark > On 16 Apr 2020, at 09:28, Jukka Pakkanen wrote: > > And yet, after updating Gemtrade.fi to dnssec-policy, ZSK and KSK both “13”, > and updating the DS record at the .fi root, I still get: > > (algorithm 13 not supportedsignature verification failed) > > In Verisign DNSSEC verifier. > > > Lähettäjä: bind-users Puolesta Jukka > Pakkanen > Lähetetty: 16. huhtikuuta 2020 1:22 > Vastaanottaja: bind-us...@isc.org > Aihe: 9.16.2 / DNSSEC / DS records > > Updating from 9.14.11 to 9.16.2, and migrating existing signed zones to > dnssec-policy, and have couple questions, probably quite trivial… > > We have signed zones with different key algorithms, now I want everything > under the same ecdsa256 policy. I guess when the key algorithm changes, > example from 8 to 13, we need to update the DS key at the registrar as well? > > About the DS keys, where can I find or retrieve them after the zone is > automatically resigned by the dnssec-policy, to insert in to Hover.com’s zone > data? > > The Finnish Traficom .fi root service was able to retrieve the new DS records > it self, but for Hover need to insert them manually. > > Do I need to keep the old DS records at the registrar for some period of > time, of can I just swap the information there, without breaking anything? > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
