Hi Mark, We are only using update to provision the acme challenge as described by RFC 8555 8.4. Nothing else.
If certbot (the acme client) behaves as it should provisioning and deprovisioning the resource record, then our zone file doesn't really change. I will ask my colleague why he feels our security policy is the right one. Ivan. On Mon, 26 Apr 2021 at 19:53, Mark Andrews <ma...@isc.org> wrote: > > Well if you are not allowed to update the zone file for “security reasons” > then > allowing a journal to be written shouldn’t be allowed for the same “security > reasons”. > There is no difference between updating a zone file and updating a journal > from a > security perspective. > > Additionally you will just be adding more and more processing to the startup > of named > if you have a un-writeable zone file as every change to the zone through the > life of > the zone will have to be applied serially. You will also have problems if > you have > to roll the zones serial number as journals really aren’t designed to be used > with > a zone file that is not being consolidated regularly. Journals are not > designed to > have serial numbers loop over. Which instance of serial 5 are you referring > too if > there are multiple 5s in the journal. > > I suggest that you go back as re-examine your security policy. Even SELinux > moves > dynamically updatable zones to a writable directory so that the zone files > can be > updated. > > Mark > > > On 27 Apr 2021, at 03:26, Ivan Avery Frey <ivan.avery.f...@gmail.com> wrote: > > > > Yes, I was using nsupdate to test my implementation. For security reasons > > the directory that holds the zone file is readonly for named. So named > > couldn't create its journal file there. I misinterpreted the reference > > manual for the description of the "journal" command. Where it mentioned > > that the "filename" could be overridden I wasn't thinking it could be a > > pathname. > > > > Just to clarify, I will be using the certbot client with the dns-rfc2136 > > plugin to receive my certificates. > > > > I wonder why they don't have a dns-local plugin. It would be a whole lot > > simpler. > > > > On Mon., Apr. 26, 2021, 09:57 Kevin Darcy via bind-users, > > <bind-users@lists.isc.org> wrote: > > [ Classification Level: GENERAL BUSINESS ] > > > > Ivan, > > I've never done the Let's Encrypt thing myself, but from my skim > > of the documentation, it appears they want you to place a TXT record in a > > specific part of your domain's namespace hierarchy. > > > > I sincerely hope you're not trying to write the TXT record directly to the > > journal file. That could lead to corruption, or, at the very least, your > > changes could be overwritten, since journal files are written dynamically. > > > > The safe way to update DNS programmatically is through the Dynamic Update > > extension to DNS, typically via the "nsupdate" command-line utility, or via > > various libraries/modules of scripting languages like Perl or Python. > > > > One of the bash-based ACME client implementations linked from Let's > > Encrypt's webpage, for instance, is github.com/bruncsak/ght-acme.sh, and > > for the DNS-01 challenge method, it feeds some commands to nsupdate. The > > code is rather crude, assuming no crypto-based authentication on the server > > side, among other things, but it's at least a start on a recommended way to > > update DNS data. Better than mucking around with journal files. > > > > There is a learning curve associated with Dynamic Update. On the server > > side, for instance, you'll need to establish permissions via allow-update. > > Limiting updates to localhost at least would protect your DNS data from > > unauthorized changes from remote hosts, but ideally, you'd generate a key > > and use that. > > > > > > - Kevin > > > > On Sun, Apr 25, 2021 at 7:39 PM Ivan Avery Frey <ivan.avery.f...@gmail.com> > > wrote: > > I'm trying to obtain certificates from Let's Encrypt using the DNS-01 > > challenge method. > > > > I just want to confirm that there is no option to configure the > > directory for the .jnl files independently of the zone files. > > _______________________________________________ > > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > > unsubscribe from this list > > > > ISC funds the development of this software with paid support subscriptions. > > Contact us at https://www.isc.org/contact/ for more information. > > > > > > 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 > > > > ISC funds the development of this software with paid support subscriptions. > > Contact us at https://www.isc.org/contact/ for more information. > > > > > > 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 > > > > ISC funds the development of this software with paid support subscriptions. > > Contact us at https://www.isc.org/contact/ for more information. > > > > > > 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 ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
