Configuring the location of named .jnl files

Cameron Banowsky cameron at shebash.io
Mon Apr 26 15:12:48 UTC 2021


To echo what Kevin has said.

A TXT record is what is needed in the ZONE file. Furthermore with
Letsencrypt or any other CA you need to add a CAA record otherwise you run
the risk of returning a SERVFAIL with whatever client goes to validate that
record.


https://letsencrypt.org/docs/caa/



This record should go in the same zone file as your TXT record.


Hope that helps.


Cameron



On Mon, Apr 26, 2021 at 7:47 AM <bind-users-request at lists.isc.org> wrote:

> Send bind-users mailing list submissions to
>         bind-users at lists.isc.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.isc.org/mailman/listinfo/bind-users
> or, via email, send a message with subject or body 'help' to
>         bind-users-request at lists.isc.org
>
> You can reach the person managing the list at
>         bind-users-owner at lists.isc.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bind-users digest..."
>
>
> Today's Topics:
>
>    1. Re: Configuring the location of named .jnl files (Kevin Darcy)
>    2. Re: Using RNDC to control remote access to my BIND server
>       (Greg Donohoe)
>    3. Re: Using RNDC to control remote access to my BIND server
>       (Anand Buddhdev)
>    4. How to interpret BIND 9 JSON Counters (Dom Brown)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 26 Apr 2021 09:56:29 -0400
> From: Kevin Darcy <kevin.darcy at stellantis.com>
> To: ML BIND Users <bind-users at lists.isc.org>
> Subject: Re: Configuring the location of named .jnl files
> Message-ID:
>         <CAAeHe+x2qk1W9L3WYTzLRW=
> msKVKZYVCDc4G2Mv90WGSf2hq0g at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> [ 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.frey at 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 at lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.isc.org/pipermail/bind-users/attachments/20210426/a196f485/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 26 Apr 2021 15:04:27 +0100
> From: Greg Donohoe <dubgregd at gmail.com>
> To: Anand Buddhdev <anandb at ripe.net>
> Cc: bind-users at lists.isc.org
> Subject: Re: Using RNDC to control remote access to my BIND server
> Message-ID:
>         <
> CAMBNh5rYLCkgUHs+zToDXyBKAXeXeEXQ0CZPP699uQ9p8UEPHQ at mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks Anand.
> When using this TSIG solution is the key visible (clear) within the DNS
> packet being sent to the remote server or is it encrypted?
> Is this communication secure? eg if someone is sitting on the wire sniffing
> the packets, would they be able to extract the key ?
> Or is the security of the communication done through the ACL and the key is
> TSIG only used to allow me to make changes to the zone file?
> The main reason why I was leaning towards SSH was to try to ensure that all
> communication between local & remote was encrypted.
>
> Rgds,
> Greg.
>
> On Fri, Apr 23, 2021 at 2:21 PM Anand Buddhdev <anandb at ripe.net> wrote:
>
> > On 23/04/2021 14:24, Greg Donohoe wrote:
> >
> > Hi Greg,
> >
> > > In regards to the nsupdate, what is the best way to secure the
> > connection,
> > > so to ensure that only my local server can make the amendments to the
> > > remote server named & zone files?
> > > I dont want anyone/anything else other than my local machine to make
> any
> > > changes on my remote BIND server.
> >
> > You should create a TSIG key, and configure the zones on the remote
> > server to only accept dynamic DNS updates signed by this key. And then
> > use this key with nsupdate when sending your updates. Check the man page
> > of nsupdate and look at the '-k' and '-y' options for using tsig keys.
> >
> > You can additionally also configure your remote BIND to accept updates
> > only from certain IP addresses. For details on how to configure this,
> > please read the excellent documentation (especially section 4.2.29 and
> > the "allow-update" option):
> >
> > https://bind9.readthedocs.io/en/v9_16/
> >
> > Regards,
> > Anand Buddhdev
> >
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.isc.org/pipermail/bind-users/attachments/20210426/4cee450e/attachment-0001.htm
> >
>
> ------------------------------
>
> Message: 3
> Date: Mon, 26 Apr 2021 16:32:48 +0200
> From: Anand Buddhdev <anandb at ripe.net>
> To: Greg Donohoe <dubgregd at gmail.com>
> Cc: bind-users at lists.isc.org
> Subject: Re: Using RNDC to control remote access to my BIND server
> Message-ID: <115665a1-43f4-2c15-6482-a452acbe269e at ripe.net>
> Content-Type: text/plain; charset=utf-8
>
> Hi Greg,
>
> a TSIG key is *never* transmitted. A sender uses a TSIG key to generate
> a secure hash over the DNS content being sent, and sends the hash along
> with the DNS content. A receiver configured with the same key can then
> verify that hash. If it can, then it can apply the DNS content.
>
> If someone is sniffing the wire between the client and server, they can
> see the DNS content. This usually doesn't matter, because the DNS is
> usually public anyway. However, if a man-in-the-middle tries to modify
> the packet in any way, then the receiver will detect the change, because
> the hash will not verify, and the receiver can reject that packet as
> invalid.
>
> DNS was NOT designed to be encrypted, because as I wrote above, it's
> usually public data anyway.
>
> If you want to encrypt your dynamic DNS update anyway (even though
> there's good reason to do this), then you need to send your update over
> an encrypted session of some kind. The DNS protocol itself has recently
> been updated to allow for encryption, using DTLS (DNS-over-TLS). But
> while DNS resolvers can use this to send queries to suitably configured
> servers, I don't think "nsupdate" can use DTLS just yet (someone please
> correct me if I'm wrong). So your only alternative is to use another
> secure protocol, such as SSH, with port forwarding, to send your dynamic
> updates to the server.
>
> BUT AGAIN, there is usually no need for this. Do NOT overcomplicate your
> design for no reason.
>
> Regards,
> Anand
>
> On 26/04/2021 16:04, Greg Donohoe wrote:
> > Thanks Anand.
> > When using this TSIG solution is the key visible (clear) within the DNS
> > packet being sent to the remote server or is it encrypted?
> > Is this communication secure? eg if someone is sitting on the wire
> sniffing
> > the packets, would they be able to extract the key ?
> > Or is the security of the communication done through the ACL and the key
> is
> > TSIG only used to allow me to make changes to the zone file?
> > The main reason why I was leaning towards SSH was to try to ensure that
> all
> > communication between local & remote was encrypted.
> >
> > Rgds,
> > Greg.
> >
> > On Fri, Apr 23, 2021 at 2:21 PM Anand Buddhdev <anandb at ripe.net> wrote:
> >
> >> On 23/04/2021 14:24, Greg Donohoe wrote:
> >>
> >> Hi Greg,
> >>
> >>> In regards to the nsupdate, what is the best way to secure the
> >> connection,
> >>> so to ensure that only my local server can make the amendments to the
> >>> remote server named & zone files?
> >>> I dont want anyone/anything else other than my local machine to make
> any
> >>> changes on my remote BIND server.
> >>
> >> You should create a TSIG key, and configure the zones on the remote
> >> server to only accept dynamic DNS updates signed by this key. And then
> >> use this key with nsupdate when sending your updates. Check the man page
> >> of nsupdate and look at the '-k' and '-y' options for using tsig keys.
> >>
> >> You can additionally also configure your remote BIND to accept updates
> >> only from certain IP addresses. For details on how to configure this,
> >> please read the excellent documentation (especially section 4.2.29 and
> >> the "allow-update" option):
> >>
> >> https://bind9.readthedocs.io/en/v9_16/
> >>
> >> Regards,
> >> Anand Buddhdev
> >>
> >
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 26 Apr 2021 14:46:07 +0000
> From: Dom Brown <Dom.Brown at mycom-osi.com>
> To: "bind-users at lists.isc.org" <bind-users at lists.isc.org>
> Cc: Greg Choules <Greg.Choules at three.co.uk>
> Subject: How to interpret BIND 9 JSON Counters
> Message-ID:
>         <
> CWXP123MB3045D7583644D5FF1F7AEC30B6429 at CWXP123MB3045.GBRP123.PROD.OUTLOOK.COM
> >
>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi All,
> Wonder if you can help, I'm looking to input the BIND 9 JSON stats file to
> our OSS PM tool and I need some basic information on the counter types.
> Looking at the various counters I need to understand whether they are of
> type gauge (a snapshot in time) or counter (we need to calculate the delta
> between the last and the last but one values received).
>
> I think they are gauge but would be great if you can confirm.
>
> Additionally is there guidance on how the Network Elements and the time
> would be aggregated. Would they be aggregated by sum?
>
> Please feedback if my ask isn't clear. I hope you can help.
>
> BR,
> Dom Brown
> 07577 272977
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> https://lists.isc.org/pipermail/bind-users/attachments/20210426/94a03d39/attachment.htm
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
> ------------------------------
>
> End of bind-users Digest, Vol 3696, Issue 2
> *******************************************
>
-- 
Cameron Banowsky
c. 323-217-8592
o. 323-664-8285
https://shebash.io
https://calendly.com/banowsky








The content of this email is confidential and intended for the recipient
specified in message only. It is strictly forbidden to share any part of
this message with any third party, without a written consent of the sender.
If you received this message by mistake, please reply to this message and
follow with its deletion, so that we can ensure such a mistake does not
occur in the future.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210426/0aed5267/attachment-0001.htm>


More information about the bind-users mailing list