Re: Bind forgets my changes with nsupdate

2023-10-08 Thread Michael Richardson

201907-b...@planhack.com wrote:
>> My solution is not to mix dynamic update with other access.  Instead,
>> I put in CNAMEs in the signed zone to a sub-zone (or other zone) where
>> I do exclusive dynamic update.  This isn't perfect, but it works well
>> enough to allow dns-01 (certbot/LetsEncrypt) to be able to refresh my
>> certificates.

> Not perfect? What issues did you see? Thanks!

a) there are still a number of situations where systems do not follow CNAMEs 
when
   they should.  Particularly relating to RFC2317 reverse delegations.

b) using a second zones introduces additional possibilities for DNSSEC to be
   broken.

c) cruft accumulates in the second zone, and some of it does not get deleted.

d) updates to secondaries sometimes take longer than certbot is able to cope 
with.
   ("up-arrow-return" solves the problem if interactive.  Cron running a week
   later usually works)

--
]   Never tell me the odds! | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works| network architect  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[






signature.asc
Description: PGP signature
-- 
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: KASP Rollover = Immediate Loss of DNSKEY (Why Do Inactive Keys Disappear?)

2023-10-08 Thread Mark Andrews


> On 8 Oct 2023, at 02:16, Eddie Rowe  wrote:
> 
> When performing a key rollover using the KASP I continue to see the DNSKEY 
> IMMEDIATELY disappear rather than staying active for the appropriate period 
> of time with the test zone having a 3 hour TTL.  I first encountered this 
> behavior with RHEL 9.2 with BIND 9.16.23-RH (Extended Support Version) with a 
> ZSK key in testing and now with Fedora and 9.18.19 with as generic as a setup 
> that you can have with the default DNSSEC policy.  I know the manner that 
> rollovers are handled with the default policy may be different, but I still 
> do not think the DNSKEY should disappear immediately on rollover since it is 
> set to being inactive.
> 
> Said another way...why do keys that are set to an inactive state by the KASP 
> process immediately disappear as they should still be in the zone but no 
> longer used to sign data?
> 
> Steps to Reproduce:
> 1.  Setup generic BIND installation with a test zone with default DNSSEC 
> policy with inline signing.
> 2.  Run dig to see the DNSKEY.
> 3.  Run the rollover command.
> 4.  Run dig to see the DNSKEY - note the original DNSKEY is gone and the new 
> one appears.

Given the parent zone doesn’t have DS records for the zone and there is no 
private trust anchor published,
there is no harm in changing the DNSKEYs immediately.  Try again and this time 
tell named that there are
DS records published for the zone.  

rndc dnssec -keyid value -checkds published zone

This is also how you tell named about private trust anchors which are 
equivalent to publishing DS records
in the parent.

> Expected Result:
> 1.  Two DNSKEY values immediately after the rollover.
> 2.  The original DNSKEY should be removed from cache at a later time based on 
> the TTL of the zone and the KASP handles this.  These date/times appear in 
> the .key and .state after the rollover but the key appears to no longer be 
> available which I believe cause a DNSSEC failure.
> 
> -
> [root@localhost dnssec.example]# named -v
> BIND 9.18.19 (Extended Support Version) 
> -
> [root@localhost dnssec.example]# yum info bind
> Last metadata expiration check: 1:34:57 ago on Fri 06 Oct 2023 04:14:09 PM 
> CDT.
> Installed Packages
> Name : bind
> Epoch: 32
> Version  : 9.18.19
> Release  : 1.fc38
> Architecture : x86_64
> Size : 1.6 M
> Source   : bind-9.18.19-1.fc38.src.rpm
> Repository   : @System
> From repo: updates
> Summary  : The Berkeley Internet Name Domain (BIND) DNS (Domain Name 
> System) server
> URL  : https://www.isc.org/downloads/bind/
> License  : MPL-2.0 AND ISC AND MIT AND BSD-3-Clause AND BSD-2-Clause
> Description  : BIND (Berkeley Internet Name Domain) is an implementation of 
> the DNS
>  : (Domain Name System) protocols. BIND includes a DNS server 
> (named),
>  : which resolves host names to IP addresses; a resolver library
>  : (routines for applications to use when interfacing with DNS); 
> and
>  : tools for verifying that the DNS server is operating properly.
> -
> [root@localhost ~]# dig @localhost dnssec.example dnskey +multi
> 
> ; <<>> DiG 9.18.19 <<>> @localhost dnssec.example dnskey +multi
> ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11680
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: 9e07c9760c4d71fc010065208d2a6696e86824aebb8e (good)
> ;; QUESTION SECTION:
> ;dnssec.example.IN DNSKEY
> 
> ;; ANSWER SECTION:
> dnssec.example. 3600 IN DNSKEY 257 3 13 (
> KHL+WEwOQA3iK5hTllDiZEZGsj3muffHMtFQLVz7yf1w
> GqQipJ4ARhlwALPRlPJNaNRBmOj5bJZwTqYXglH9cQ==
> ) ; KSK; alg = ECDSAP256SHA256 ; key id = 
> 22645
> 
> ;; Query time: 5 msec
> ;; SERVER: ::1#53(localhost) (UDP)
> ;; WHEN: Fri Oct 06 17:41:46 CDT 2023
> ;; MSG SIZE  rcvd: 151
> -
> [root@localhost dnssec.example]# cat *22645.key
> ; This is a key-signing key, keyid 22645, for dnssec.example.
> ; Created: 20231006172923 (Fri Oct  6 12:29:23 2023)
> ; Publish: 20231006172923 (Fri Oct  6 12:29:23 2023)
> ; Activate: 20231006193423 (Fri Oct  6 14:34:23 2023)
> ; SyncPublish: 20231006193423 (Fri Oct  6 14:34:23 2023)
> dnssec.example. 3600 IN DNSKEY 257 3 13 
> KHL+WEwOQA3iK5hTllDiZEZGsj3muffHMtFQLVz7yf1wGqQipJ4ARhlw 
> ALPRlPJNaNRBmOj5bJZwTqYXglH9cQ==
> -
> [root@local