Re: Can't get rid of key

On 3/10/20 6:31 PM, Mark Andrews wrote: > and the content of /var/named/keys are? >> [285] # find . -name *cascocom.com* >> ./oldkeys/sha1/Kcascocom.com.+005+09675.key >> ./oldkeys/sha1/Kcascocom.com.+005+09675.private >> ./oldkeys/new/Kcascocom.com.+008+65509.private >>

Re: Can't get rid of key

On 3/10/20 5:51 PM, Mark Andrews wrote: > So what do you still have related to the zone? Have you examined the > contents of those files? Some of them may be binary so grep won’t work. > Are you actually looking in the right place. Are you running chroot? > Did you really stop named? How is

Can't get rid of key

I'm trying to clear a zone's dnssec records, or at least some of them - I removed the key files from the keys directory and removed the zone.* files (signed, jbk, jnl, etc) and restarted named. I did a recursive grep for the key id in question in /var/named and it's nowhere to be found, yet,

Re: key signing

On 3/10/20 4:03 PM, Mark Andrews wrote: > Firstly don’t blindly add DS records without first checking that the DNSKEYs > they refer to are published. DNSSEC is less tolerant of operator error and > sometimes things go wrong. There are lots of “wait until …” in managing > DNSSEC > and if you

key signing

I've got a test domain that I thought I had all working, but noticed the key signing key was missing, so I generated one and did an rndc loadkeys to get things updated, then generated a ds record for it and uploaded that to the registrar, however, it still shows broken, and when I look, I see that

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

On 3/5/20 5:26 AM, Tony Finch wrote: > I think those errors from dnssec-verify look to me like you have an > RSASHA256 KSK and an RSASHA1 ZSK. Your key files should all have names > like K*+008+* not K*+005+*. In older versions of BIND it's easy to > accidentally get a bad key by forgetting the

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

On 3/3/20 5:26 PM, Tony Finch wrote: > If you are doing an algorithm rollover, you should have 2 keys (ZSK and > KSK) for each algorithm, 4 keys total. I only use dnssec-signzone if I'm > testing or doing something weird, so I'm not familiar with it. (In > production I use automatic signing in

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

On 3/3/20 8:59 AM, Tony Finch wrote: > Alan Batie wrote: >> >> This is timely as I was about to ask if there's any reason to generate >> SHA1 DNSKEY records? I should think that anything I care about can >> handle SHA256 these days... > > There are extremely

Re: Changes BIND 9.15+ source distribution (gz -> xz, and SHA1 deprecation)

On 12/19/19 1:16 AM, Ondřej Surý wrote: > The other change we will introduce early next year (timed with BIND 9.16.0 > release) is the deprecation of SHA1 checksums. This is timely as I was about to ask if there's any reason to generate SHA1 DNSKEY records? I should think that anything I care

Re: zsk rollover

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

Re: zsk rollover

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

zsk rollover

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

Re: ip6 reverse delegation

On 1/16/20 6:07 PM, Rick Dicaire wrote: > Shouldn't you also have an NS record that points to the upstream NS > thats subdelegating  0.1.0.1.8.7.6.f.7.0.6.2.ip6.arpa to rdrop.com > NSes? Doh! Thank you, that was the mistake I made and it's working now... smime.p7s

ip6 reverse delegation

I'm having a problem getting ipv6 reverse delegation to work and I'm hoping someone can tell me what I'm missing, as it seems to me this should be pretty straightforward: $ host 4.3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.0.1.8.7.6.f.7.0.6.2.ip6.arpa 8.8.8.8 Using domain server: Name: 8.8.8.8

bind keyfile lookup failures

I've had bind 9.9.4 doing dnssec for a few years now. All the zones are configured with: key-directory "/var/named/keys"; auto-dnssec maintain; inline-signing yes; I just added a bunch of zones, and 8 of them are failing with: dns_dnssec_findzonekeys2: error reading

Re: 9.11/dnstap on centos: fstrm

On 12/2/16 5:06 PM, Robert Edmonds wrote: > This package is not in CentOS 7 itself, but it is available from the > Fedora EPEL 7 repository, according to: Thanks! smime.p7s Description: S/MIME Cryptographic Signature ___ Please visit

9.11/dnstap on centos: fstrm

I'm trying to build 9.11-P1 on Centos 7 with dnstap enabled. Configure complains: checking for library containing fstrm_iothr_init... no configure: error: The fstrm library was not found. Please install fstrm! yum knows nothing of fstrm Google only finds centos fstrm on pkgs.org, which returns

key type change causing errors

I've been using bind 9.9 to do inline signing for a while experimentally. The keys were initialized with a basic dnssec-keygen $zone_name. I decided to upgrade the keys from sha1 to sha256 and from nsec to nsec3; using the instructions at https://kb.isc.org/article/AA-00711 I moved all the old

Re: Inconsistent resolution

On 9/18/12 6:02 PM, Mark Andrews wrote: Name servers cannot be cnames. The DNS protocol cannot be made to work reliably when they are CNAMEs without changing the definition of glue and the additional section processing rules. CNAME records are NOT added as glue, A and are added as glue.

Re: Inconsistent resolution

On 9/18/12 6:02 PM, Mark Andrews wrote: If you want the nameservers to be ns1.peak.org and ns2.peak.org update the NS records and update the delegation. PS: FWIW, I already have this in process... smime.p7s Description: S/MIME Cryptographic Signature

Bind 9.9.x operation with dnssec

I'm a little confused wading through the massive amount of detail about dnssec, and have two main questions: 1. General key management 2. Specific problems with my test domain setup (raindrop.us) For general key management: With auto-dnssec maintain, I expect the Zone Signing Keys and the

Checking for zone expiration?

We had a rather key zone mysteriously expire on a slave this morning - the log files show a transfer a couple weeks ago, but it hadn't been updated so there was no reason for one since and there were no log entries about failed connection attempts. I was wondering if there's a way to check the

Re: Checking for zone expiration?

Thanks! I'll try the various monitoring options... I don't have try-tcp-refresh no, so I'm afraid that doesn't explain it either... ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing

testing validation

I'm testing out dnssec with bind 9.9.0's auto signing and a test domain; this appears to be working (see below, RRSIG records returned from the actual nameserver), however and attempt to validate fails with: # dig +dnssec +sigchase soa raindrop.us ;; RRset to chase: raindrop.us.987

Re: testing validation

On 4/18/12 10:33 AM, Spain, Dr. Jeffry A. wrote: Your post is somewhat unclear to me. Querying from my bind 9.9.0 recursive resolver dig @localhost raindrop.us +dnssec, I get an AD flag returned, suggesting that dnssec is working for raindrop.us. In your query dig +dnssec +sigchase soa

Re: testing validation

On 4/18/12 10:46 AM, Carlos Ribas wrote: Is your recursive resolver also authoritative for raindrop.us? If so, you will not get the ad flag. You can test with DNS-OARC resolver [1]: # dig +dnssec +multiline @149.20.64.20 raindrop.us Why would 149.20.64.20 return ad then? It's not

Re: testing validation

On 4/18/12 11:14 AM, Spain, Dr. Jeffry A. wrote: Alan: Comments on your configuration file: I also forgot to remove the nameserver entries from resolv.conf after installing bind. Sigh. Sorry to bother everyone... Though I am still curious about this from the end of sigchase output: Launch

Re: testing validation

On 4/18/12 11:48 AM, Spain, Dr. Jeffry A. wrote: Isn't the DS for the zone: . what the managed-keys clause provides? Though putting it back in didn't make the warning go away, so I must be missing something else here... Any difference with dnssec-validation auto and removing the

Re: testing validation

On 4/18/12 12:18 PM, Spain, Dr. Jeffry A. wrote: ;; WARNING There is no DS for the zone: . Isn't the DS for the zone: . what the managed-keys clause provides? Now I think I see what you mean. It is my understanding that DS records exist in parent zones and refer to child zones that are to