Re: Configuring the location of named .jnl files

[Ivan Avery Frey]

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

Re: Configuring the location of named .jnl files

[Mark Andrews]

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

NXDOMAIN processing

[bamberg2000 via bind-users]

Hi!
BIND 9.11.5, I forward the request ("forward zone" or global "forward first") 
to another server and I get NXDOMAIN. Is it possible to process NXDOMAIN other 
than "redirect zone"? I just want to repeat the request to another forwarder.

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

Re: Configuring the location of named .jnl files

[Ivan Avery Frey]

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

Re: Name server delegation

[Matus UHLAR - fantomas]

On 26.04.21 16:07, John W. Blue via bind-users wrote:

Since "" is a subzone inside of the example.com zone the answer is yes, it 
can be delegated.


however, the delegation must be done on example.com server (1.1.1.1)

local forwarding resolution of domains example.com and .example.com to
different server is different issue.


From: Karol Nowicki via bind-users 
Sent: Monday, April 26, 2021 10:24 AM
To: bind-users@lists.isc.org
Subject: Name server delegation

Its possible to delegate tld domain example.com to 1.1.1.1 name server and 
.example.com to 2.2.2.2 name server ?



--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Eagles may soar, but weasels don't get sucked into jet engines.
___
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

Re: Name server delegation

[John W. Blue via bind-users]

Since "" is a subzone inside of the example.com zone the answer is yes, it 
can be delegated.

John

Sent from Nine

From: Karol Nowicki via bind-users 
Sent: Monday, April 26, 2021 10:24 AM
To: bind-users@lists.isc.org
Subject: Name server delegation

Hi

Its possible to delegate tld domain example.com to 1.1.1.1 name server and 
.example.com to 2.2.2.2 name server ?


Wys?ane z Yahoo Mail do iPhone
___
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

Re: Configuring the location of named .jnl files

[Tony Finch]

Ivan Avery Frey  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.

You have had a bunch of helpful replies already, but your question
suggests to me that you might be making things more difficult than they
need to be. I have tried out configurations with non-default journal names
and I've decided it's more trouble than it is worth. For example, I added
the -J option to named-compilezone to improve support for custom journal
names, but the -j option for default journals is significantly more
convenient. And it's much nicer when I don't have journal options in every
zone{} clause in my config.

I know what they say about assuming, but I'm going to guess that you want
to put the jounal in a different directory because `named` complained that
it did not have write access to the directory containing your zone file.
If I'm right, you will soon find that `named` also wants to overwrite your
zone file, and the message I sent yesterday will probably be helpful:

https://lists.isc.org/pipermail/bind-users/2021-April/104472.html

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Dover, Wight, Portland, Plymouth, North Biscay: Easterly or
northeasterly 5 to 7, decreasing 3 or 4 later, then becoming variable
later. Slight or moderate, becoming smooth or slight, occasionally
rough at first in Plymouth and north Biscay. Fair. Good.

___
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

Name server delegation

[Karol Nowicki via bind-users]

Hi 
Its possible to delegate tld domain example.com to 1.1.1.1 name server and 
.example.com to 2.2.2.2 name server ? 


Wysłane z Yahoo Mail do iPhone
___
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

Re: Using RNDC to control remote access to my BIND server

[Tony Finch]

Anand Buddhdev  wrote:
>

Anand's advice is good, as usual :-)

But a small pedantic point:

> The DNS protocol itself has recently been updated to allow for
> encryption, using DTLS (DNS-over-TLS).

DTLS usually means "datagram TLS", i.e. TLS-over-UDP (RFC 6347). There's a
spec for DNS-over-DTLS (RFC 8094) but I have not seen much enthusiasm for
deploying it: DTLS combines all the disadvantages of UDP with all the
disadvantages of TLS. (Or worse: DTLS has a more complicated state machine
than normal TLS so there have been a bunch of DTLS-specific
vulnerabilities which makes me very reluctant to deploy it.)

There is a lot more enthusiasm for DNS-over-TLS (aka DoT) and
DNS-over-HTTPS (aka DoH), and maybe in the future DNS-over-QUIC.

But right now, none of these are particularly easy to get working as
transports for UPDATE, and as Anand said, it usually isn't necessary.

I'm looking forward to zone transfers over TLS, because public key
authentication (with client certificates) is a bit easier to deploy
between different organizations than TSIG secret key authentication.
There's not such a clear benefit for UPDATE-over-TLS where I'm sitting,
apart from the neatness of having all authenticated traffic over TLS.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Bailey: Northeast 5 to 7. Moderate or rough. Showers at first. Good.

___
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

Re: Configuring the location of named .jnl files

[Cameron Banowsky]

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

> Send bind-users mailing list submissions to
> bind-users@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-requ...@lists.isc.org
>
> You can reach the person managing the list at
> bind-users-ow...@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 
> To: ML BIND Users 
> Subject: Re: Configuring the location of named .jnl files
> Message-ID:
>  mskvkzyvcdc4g2mv90wgsf2h...@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  >
> 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
> >
> -- 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 
> To: Anand Buddhdev 
> Cc: bind-users@lists.isc.org
> Subject: Re: Using RNDC to control remote access to my BIND server
> Message-ID:
> <
> cambnh5rylckguhs+ztodxybkaxexeexq0czpp699uq9p8ue...@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 

How to interpret BIND 9 JSON Counters

[Dom Brown]

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

Re: Using RNDC to control remote access to my BIND server

[Anand Buddhdev]

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

Re: Using RNDC to control remote access to my BIND server

[Greg Donohoe]

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

Re: Configuring the location of named .jnl files

[Kevin Darcy via bind-users]

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

Re: Configuring the location of named .jnl files

[Petr Menšík]

Hi Ivan,

Visit [1] and search "journal" zone option. Similar as "file". At least
BIND 9.16 has support, it is also in man named.conf manual page in BIND
9.11. I think that is what you were looking for.

Regards,
Petr

1.
https://bind9.readthedocs.io/en/v9_16_13/reference.html#zone-statement-grammar

On 4/26/21 1:38 AM, Ivan Avery Frey 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.

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB



OpenPGP_signature
Description: OpenPGP digital signature
___
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