Syntex for primary/secondary

[@lbutlr]

When seeing up a secondary zone what do I replace # with in following (the 
old syntax was masters instead od master, so I am guessing it needs a new 
keyword)?

zone "example.com" {
  type secondary;
  # { 192.168.10.1; };
  file "/var/lib/bind/db.example.com";
};

in https://bind9.readthedocs.io/en/v9_16_4/reference.html it appears that the 
syntax is till masters?

4.2.11. masters Statement Grammar

masters  [ port  ] [ dscp
 ] { (  |  [
port  ] |  [ port
 ] ) [ key  ]; ... }; 




-- 
Man is born free, but is everywhere in chains.

___
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: unknown option 'trust-anchors'

[Mark Andrews]

Yes, that is the issue.

> On 6 Jul 2020, at 08:36, @lbutlr  wrote:
> 
> On 05 Jul 2020, at 07:51, @lbutlr via bind-users  
> wrote:
>> mail # rndc reload
>> rndc: 'reload' failed: failure
>> mail # tail /var/log/messages
>> Jul  5 07:41:24 mail.covisp.net named[53940] 
>> /usr/local/etc/namedb/bind.keys:29: unknown option 'trust-anchors'
>> Jul  5 07:41:24 mail.covisp.net named[53940] reloading configuration failed: 
>> failur
> 
> When checking on things I see that despite INSTALLING bind 9.16 I neglected 
> to restart bind at the time, so the running version is still 9.14.11. Could 
> this be the cause of this issue? I am loathe to stop and restart named in 
> case this is NOT the issue and I then end up with a non-functioning primary 
> DNS. 
> 
> 
> 
> -- 
> 'The only reason we're still alive now is that we're more fun alive
>   than dead,' said Granny's voice behind her. --Lords and Ladies
> 
> ___
> 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

Re: unknown option 'trust-anchors'

[@lbutlr]

On 05 Jul 2020, at 07:51, @lbutlr via bind-users  
wrote:
> mail # rndc reload
> rndc: 'reload' failed: failure
> mail # tail /var/log/messages
> Jul  5 07:41:24 mail.covisp.net named[53940] 
> /usr/local/etc/namedb/bind.keys:29: unknown option 'trust-anchors'
> Jul  5 07:41:24 mail.covisp.net named[53940] reloading configuration failed: 
> failur

When checking on things I see that despite INSTALLING bind 9.16 I neglected to 
restart bind at the time, so the running version is still 9.14.11. Could this 
be the cause of this issue? I am loathe to stop and restart named in case this 
is NOT the issue and I then end up with a non-functioning primary DNS. 



-- 
'The only reason we're still alive now is that we're more fun alive
than dead,' said Granny's voice behind her. --Lords and Ladies

___
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: $INCLUDE Kexamle.com.+007...

[@lbutlr]

On 05 Jul 2020, at 10:12, Tony Finch  wrote:
> @lbutlr  wrote:
> 
>> When a domain configuration file contains an include line for the key,
>> where is that include looking for the key file?
> 
> ... good question, I have avoided having to find that out ...

Heh.

> So it sounds like "the current directory" is the answer to your question.

That would certainly explain why it fails then.

> However, I don't think you need to $INCLUDE key files. I think maybe that
> used to be a thing when signing a zone had to involve dnssec-signzone? But
> nowadays even dnssec-signzone will automatically insert public keys into
> the signed zone.

Ah, that would be good. When I resolve the other issue I posted about I will 
check that.

My configuration started in … um… 1995? I'm sure I should start all over with 
the 9.16 manual from scratch, but you know, I have all this TV to watch. 

> Does that make sense?

It does, and thank you.



-- 
It's against my programming to impersonate a deity.

___
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: $INCLUDE Kexamle.com.+007...

[Tony Finch]

@lbutlr  wrote:

> When a domain configuration file contains an include line for the key,
> where is that include looking for the key file?

... good question, I have avoided having to find that out ...

> I'm in a situation where the keys seems to work fine for updating
> DNSSEC, but nsdiff complains the key file is not found.

Well, nsdiff uses named-compilezone to canonicalize zone files, and the
named-compilezone manual lists a couple of options that affect $INCLUDE:

   -t directory
  Chroot to directory so that include directives in the configura‐
  tion file are processed as if run by a similarly chrooted named.

   -w directory
  chdir  to  directory  so  that relative filenames in master file
  $INCLUDE directives work.  This  is  similar  to  the  directory
  clause in named.conf.

So it sounds like "the current directory" is the answer to your question.

However, I don't think you need to $INCLUDE key files. I think maybe that
used to be a thing when signing a zone had to involve dnssec-signzone? But
nowadays even dnssec-signzone will automatically insert public keys into
the signed zone.

When you're doing automatic signing with named (which you have to do if
you are using nsupdate to alter the zone), the keys are included in the
signed zone based on their timing metatata, which you can set with
dnssec-settime. [There's also the new key policy stuff which I have not
yet tried out properly.]

So the actual answer is, you don't explicitly $INCLUDE the keys in the
zone, so questions about current directories do not arise.

Does that make sense?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lough Foyle to Carlingford Lough: Southwest veering west, 6 to gale 8, then
veering northwest 4 to 6 later. Moderate or rough, becoming slight or moderate
south of rathlin island. Showers,thundery at first. Good, occasionally
moderate.___
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

unknown option 'trust-anchors'

[@lbutlr via bind-users]

In named.conf I have 
dnssec-enable yes;
dnssec-validation auto;

# rndc managed-keys status
view: _default
next scheduled event: Sun, 05 Jul 2020 20:43:00 GMT

name: .
keyid: 20326
algorithm: RSASHA256
flags: SEP
next refresh: Sun, 05 Jul 2020 20:43:00 GMT
trusted since: Mon, 21 Jan 2019 14:53:55 GMT
 mail # rndc reload
rndc: 'reload' failed: failure
 mail # tail /var/log/messages
Jul  5 07:41:24 mail.covisp.net named[53940] 
/usr/local/etc/namedb/bind.keys:29: unknown option 'trust-anchors'
Jul  5 07:41:24 mail.covisp.net named[53940] reloading configuration failed: 
failure

Bind is currently running just fine and has been since 8 June.

The bind.keys file has:

# See https://data.iana.org/root-anchors/root-anchors.xml for current trust
# anchor information for the root zone.

But that URL does not load and gives an XML error.



-- 
-=> 

 <=-

___
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