Re: managed-keys update when outgoing UDP is blocked

2020-02-25 Thread Branko Mijuskovic
Hi Tony, Thanks for that. But I'm curious, do you know does BIND failover to TCP if UDP timeouts during DNSKEY fetching? Thanks On Tue, Feb 25, 2020 at 12:47 AM Tony Finch wrote: > Branko Mijuskovic wrote: > > > > We have an authoritative DNS hidden master (bind-9.11.4-9) running behind > >

Re: managed-keys update when outgoing UDP is blocked

2020-02-25 Thread Tony Finch
Branko Mijuskovic wrote: > > But I'm curious, do you know does BIND failover to TCP if UDP timeouts > during DNSKEY fetching? Dunno. I have blocked both UDP and TCP on my hidden primary, and it is refreshing its trust anchors via my recursive servers OK, so it is not something I have had to worry

Re: managed-keys update when outgoing UDP is blocked

2020-02-25 Thread Evan Hunt
On Mon, Feb 24, 2020 at 09:47:01PM +0100, Branko Mijuskovic wrote: > We have an authoritative DNS hidden master (bind-9.11.4-9) running behind > the network where outgoing UDP traffic to unlisted IPs is blocked. > > We are using DNSSEC and I've noticed that we are getting following errors > in the

zsk rollover

2020-02-25 Thread Alan Batie
BIND 9.11.4-P2-RedHat-9.11.4-9.P2.el7 I'm testing zsk rollover on a currently unused domain, and expected the rollover to happen automatically Saturday, however it appears that it only partially has: according to https://dnssec-analyzer.verisignlabs.com/peakmail.com (if I read it right), the old k

Re: zsk rollover

2020-02-25 Thread Mark Andrews
Firstly unset the deletion date for the old key. It is way too early for incremental re-signing. Named replaces RRSIG *as-they-fall-due* for re-signing. With the defaults that takes 22.5 days with a sig-validity-interval of 30 days. All Inactivation does is STOP named signing records with that

Re: zsk rollover

2020-02-25 Thread Alan Batie
On 2/25/20 1:30 PM, Mark Andrews wrote: > Firstly unset the deletion date for the old key. It is way > too early for incremental re-signing. Named replaces RRSIG > *as-they-fall-due* for re-signing. With the defaults that > takes 22.5 days with a sig-validity-interval of 30 days. > > All Inact

Re: zsk rollover

2020-02-25 Thread Mark Andrews
> On 26 Feb 2020, at 08:40, Alan Batie wrote: > > On 2/25/20 1:30 PM, Mark Andrews wrote: >> Firstly unset the deletion date for the old key. It is way >> too early for incremental re-signing. Named replaces RRSIG >> *as-they-fall-due* for re-signing. With the defaults that >> takes 22.5 da

Re: zsk rollover

2020-02-25 Thread Alan Batie
On 2/25/20 2:22 PM, Mark Andrews wrote: > You could set "sig-validity-interval to 30 29;” if you want to see things > happen > faster. This causes the RRSIGs to have a 30 day validity interval and be > re-signed > 29 days before that expires. That sounds like a useful option, thanks! > Rememb

NS failover as opposed to A record failover

2020-02-25 Thread Scott A. Wozny
I know this isn’t a question ABOUT BIND, per se, but I think is still a question bind-users might have an answer to. I’ve seen various failover questions on the list, but nothing that talks specifically about NS records (at least nothing in the last decade), so I thought I’d inquire here. I’m

Re: NS failover as opposed to A record failover

2020-02-25 Thread Mark Andrews
> On 26 Feb 2020, at 09:51, Scott A. Wozny wrote: > > I know this isn’t a question ABOUT BIND, per se, but I think is still a > question bind-users might have an answer to. I’ve seen various failover > questions on the list, but nothing that talks specifically about NS records > (at least not