$INCLUDE in zone file?

2021-02-03 Thread @lbutlr
Is the mechanism of using $INCLUDE  in the zone file still used? 

If so, do I need to update the  when moving to a new alg method or 
are they only used when initially creating a signed zone file or are they no 
longer needed at all?

-- 
'I'll tell you this!' shouted Rincewind. 'I'd rather trust me than
history! Oh, shit, did I just say that?'

___
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: Options for named startup docker

2021-02-03 Thread Bob Harold
On Mon, Feb 1, 2021 at 10:29 AM Christian Link 
wrote:

> Hello everyone,
>
> I am using the BIND Docker image in a Docker Compose setup. In this setup
> I would like to disable ipv4 and start the named daemon with the option
> "-4".
>

"-4" means "use IPv4 only"
Perhaps you want "-6" to use IPv6 only ?

-- 
Bob Harold


>
> Normally you can do this via the file /etc/default/named (In the options
> variable). Unfortunately, this file is ignored. I also tried it with the
> "Environment" parameter in docker-compose.yml, but this does not work
> either.
>
> What possibility do I have to give options to the named daemon without
> redefining the start command completely (e.g. via "command")?
>
> This is my docker-compose.yml
>
>
> version: '3.8'
> services:
>   bind:
> image: internetsystemsconsortium/bind9:9.16
> container_name: bind
> volumes:
>   - ./etc/bind:/etc/bind
>   - ./etc/default/named:/etc/default/named
>   - ./var/cache/bind:/var/cache/bind
>   - ./var/lib/bind:/var/lib/bind
>   - ./var/log:/var/log
> ports:
>   - 53:53/udp
>   - 53:53/tcp
>   - 127.0.0.1:953:953/tcp
> restart: always
> ___
> 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: Updating a DNSSEC config to use a different algorithm

2021-02-03 Thread Matthijs Mekking

Hi,

On 02-02-2021 18:16, @lbutlr wrote:

On 02 Feb 2021, at 07:36, Matthijs Mekking  wrote:

If the PDF is not working for you, perhaps https://bind9.readthedocs.io/ suits 
you better?


The PDF works fine, and I can search for "dnssec" and "policy" but it is using 
some emdash or similar character for the - in between which makes searching an issue (even if I 
copy the text from the PDF and then search for what.I copied).


(This domain has a RRSIG range of 2021010953 - 20210221230953)
I am guessing as soon as I add that DNSSEC-policy I also need to change each domain record from 
"auto-dnssec maintain;" to "dnssec-policy default;" or do I do that after the 
.state files have been created? (That doesn't sound right, but best to check).


I guess with "each domain record" you mean "each zone".


Yes. I still think of them as domains (because they are all domains in my case).


If you are migrating, don't change it to "dnssec-policy default;". This is a 
built-in policy that does not match your existing keys.


OK, now I am a bit confused.

In named.conf there is dsnssec-policy alg13-ksk-unlimited-zsk-60day { …

Then in the zone currently I have:

zone "kreme.com" { type primary; file "kreme.com.signed"; auto-dnssec maintain; 
allow-update { key "rndc-key"; }; }

Are you saying I need to change auto-dnssec maintain; to "dsnssec-policy 13;"?


No, sorry. I was saying don't change to "dnssec-policy default;" (which 
also uses 13). Change it to the dnssec-policy that you created that 
match your existing keys (alg-7).




I would recommend to first check if the .state files look correct before 
changing your dnssec-policy (do the keys in your zone match the .state file? 
Are the states set to OMNIPRESENT? Is the goal set to OMNIPRESENT?


I did this with a domain that does not get email as a test:

#v+
named.conf:
dnssec-policy alg13-ksk-unlimited-zsk-60day {
 keys {
ksk key-directory lifetime unlimited algorithm 7 2048;
zsk key-directory lifetime P60D algorithm 7 1024 ;
 };
};

zone "example.com" { type primary; file "example.com.signed"; dnssec-policy default; 
allow-update { key "rndc-key";}; };

; This is the state of key 2611, for mrsbutler.com.
Algorithm: 13
Length: 256
Lifetime: 0
KSK: yes
ZSK: yes
Generated: 20210202134627 (Tue Feb  2 06:46:27 2021)
Published: 20210202134627 (Tue Feb  2 06:46:27 2021)
Active: 20210202134627 (Tue Feb  2 06:46:27 2021)
PublishCDS: 20210203145127 (Wed Feb  3 07:51:27 2021)
DNSKEYChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
ZRRSIGChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
KRRSIGChange: 20210202155127 (Tue Feb  2 08:51:27 2021)
DSChange: 20210202134627 (Tue Feb  2 06:46:27 2021)
DNSKEYState: omnipresent
ZRRSIGState: rumoured
KRRSIGState: omnipresent
DSState: hidden
GoalState: omnipresent
#v-

I also have new key and private and state files for the alg 7 KSK and ZSK files 
for the zone I am testing with, and the old files are gone, so I think it 
migrated correctly?


Check your zone and see if they still have the alg 7 keys. If so you 
probably migrated correctly. You can use "rndc dnssec -status zone" to 
see about all the keys available for this zone.


What old files are gone? Named doesn't remove key files (yet).



But I guess that is what you meant by it using a single key for KSK and ZSK?


Yes, one key that has both the KSK and ZSK role.



Is there a reason NOT to use default? If I use default can I then eliminiate 
the dnssec-policy alg13-ksk-unlimited-zsk-60day { … } block entirely once the 
new keys and state files are created?


There could be reasons not to use the default, but we think the default 
policy suits most people. It has a single key and does not do scheduled 
rollovers.


If you want to have scheduled rollovers, different algorithm, prefer to 
have a separate KSK, tweak the signature lifetimes, etc. Then you can 
create your own dnssec-policy.




I tried to use `rndc dnssec -checkds published example.com" but it wants a -key 
and doesn't seem to want the name of the .key file, so not sure what the syntax is 
there and the man page on rndc isn't helping. Status, on the other hand:


-key id (id is the 5 digit number).



# rndc dnssec -status example
dnssec-policy: default
current time:  Tue Feb  2 10:01:32 2021

key: 1058 (NSEC3RSASHA1), ZSK
   published:  no
   zone signing:   no

   Key has been removed from the zone
   - goal:   hidden
   - dnskey: hidden
   - zone rrsig: unretentive

key: 37515 (NSEC3RSASHA1), KSK
   published:  no
   key signing:no

   Key has been removed from the zone
   - goal:   hidden
   - dnskey: hidden
   - ds: hidden
   - key rrsig:  hidden

key: 2611 (ECDSAP256SHA256), CSK
   published:  yes - since Tue Feb  2 06:46:27 2021
   key signing:yes - since Tue Feb  2 06:46:27 2021
   zone signing:   yes - since Tue Feb  2 06:46:27 2021

   No rollover scheduled
   - goal:   omnipresent