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 s

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 no

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 th

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 rem

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

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 in

Inconsistent resolution

We're having a very similar problem to the thread "question about how a particular dig works ...", in that "dig +trace" works and "dig" doesn't (which implies a problem with the local resolving named). This particular story is that someone didn't get a domain renewed in time (the oregonisonline.ne

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 gl

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 ___

Re: what do you use for logging?

On 1/17/13 10:48 AM, Jan-Piet Mens wrote: >> By the way, all of the BIND10 logging >> messages are unique and we provide a paragraph or more documentation for >> each of its 933 possible log identifiers!) > > I haven't checked whether you have that, but that screams for a CLI > utility to show

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

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 k

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 Inact

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

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 a

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 extre

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 `na

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

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: 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 don’

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, after

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 the

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 >> ./oldkeys/new/Kcascocom.c

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

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 https://lists.i

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 priv

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 Addr

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 Descripti