Re: Can't get rid of key

[Alan Batie]

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.com.+008+65509.key
>> ./oldkeys/new/Kcascocom.com.+008+20544.private
>> ./oldkeys/new/Kcascocom.com.+008+20544.key
>> ./oldkeys/old/Kcascocom.com.+008+28998.key
>> ./oldkeys/old/Kcascocom.com.+008+28998.private
>> ./oldkeys/old/Kcascocom.com.+008+30841.key
>> ./oldkeys/old/Kcascocom.com.+008+30841.private
>> ./slaves/cascocom.com.signed
>> ./slaves/cascocom.com
>> ./slaves/cascocom.com.jbk

Nothing relating to cascocom.com



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Can't get rid of key

[Alan Batie]

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 zone defined in named.conf?

Not chrooted; a dedicated vm; nothing references oldkeys - it didn't
even exist until I ran into this problem (nothing references those
subdirs either, but they were in the keys dir)

 [283] # pwd
/var/named
 [284] # find . -name cascocom.com
./slaves/cascocom.com
 [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.com.+008+65509.key
./oldkeys/new/Kcascocom.com.+008+20544.private
./oldkeys/new/Kcascocom.com.+008+20544.key
./oldkeys/old/Kcascocom.com.+008+28998.key
./oldkeys/old/Kcascocom.com.+008+28998.private
./oldkeys/old/Kcascocom.com.+008+30841.key
./oldkeys/old/Kcascocom.com.+008+30841.private
./slaves/cascocom.com.signed
./slaves/cascocom.com
./slaves/cascocom.com.jbk
 [286] # rm slaves/cascocom.com.*
 [287] # ls slaves/cascocom*
slaves/cascocom.com
 [288] # systemctl stop named
 [289] # ps ax | grep named
15709 pts/0S+ 0:00 grep --color=auto named
 [290] # systemctl start named
 [291] # ls slaves/cascocom*
slaves/cascocom.com  slaves/cascocom.com.jbk  slaves/cascocom.com.signed
 [292] # named-compilezone -f raw -F text -o -
cascocom.com slaves/cascocom.com.signed | head
zone cascocom.com/IN: loaded serial 2019125927 (DNSSEC signed)
OK
cascocom.com. 3600 IN SOA   ns1.peak.org. 
hostmaster.peak.org.
2019125927 900 900 604800 3600
cascocom.com. 3600 IN RRSIG SOA 8 2 3600 
20200410002937
20200310232937 28998 cascocom.com.
RTQDpWGWipSbvKpqCdqa1WCSikgpc2rXqBMxOY3Hi7cIseem7Uj1lL4K
XMu/FoXBJ2sz5wsBHb9zE0O777lJMlHszoP/0o1s22mB+spygR+zW/n4
+rWt/jvWHBQWhHF1Q3K/LDz0KeaV77xSkBqPOgABbKkeRa4QxCqPVk+t jDk=
; resign=20200410002937
cascocom.com. 3600 IN NSns1.peak.org.
cascocom.com. 3600 IN NSns2.peak.org.
cascocom.com. 3600 IN RRSIG NS 5 2 3600 
20200406201546
2020030720 9675 cascocom.com.
XDSu5nNT3aXHUVfuEYa5ALokVZsXbXcKkAxjfoxXpdMTRi0YcxZ3za+1
pTBzu1DcLyC1c8h3W6GI3fHCTfrahQRR1kJ1rKKoS+6xfGqwqsR+qQmZ
aylUrUFt+VUePeOsVS0MkYorK32GNIc3yYdPItvZcT4DAGp2s+3UsqsU dL4=
cascocom.com. 3600 IN RRSIG NS 8 2 3600 
20200409003642
20200310001739 28998 cascocom.com.
tfzUe76szQARBfTIYzfPFf8X8jPBd/6+Xe/h+y85OYC6TbcpsJLEDQRI
D9SnpTv8odEmzm+Tj+0jrR5+MXPNrw/Mn2u3tTZGzwlBNROpptdGBdGB
OoclVgDl0HXOpuKD1GfjO1o5hdoGjMvUNtV0Eb5UNuSEq8qq5KOgMtyR jRI=
; resign=20200406201546
cascocom.com. 3600 IN A 207.55.17.191
cascocom.com. 3600 IN RRSIG A 5 2 3600 
20200406201546
2020030720 9675 cascocom.com.
Qv0dFWG7AW/zjXz+rFh9O+o98KDP3LvuLfXM10/zZomRuz/s1MZ591OO
c1Py7/GEK7r6xIwl9PUgd5/4alZWYm5sl/kjqpTHkbADsp04LqzQcRwY
EMdrGuRuRe9eAJhDcBD306s0xoeceyNRKPZGbPSZKiCMQxjdhteL8toL rj0=

zone "cascocom.com" {
type slave;
file "/var/named/slaves/cascocom.com";
masters {
2607:f678::52;
};

key-directory "/var/named/keys";
auto-dnssec maintain;
inline-signing yes;
};





smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Can't get rid of key

[Alan Batie]

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 restarting named, the dnskey record returns, and the
other records have corresponding rrsig records.  Where else could the
key be coming from?  Thanks...



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: key signing

[Alan Batie]

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’t wait DNSSEC validations will fail as a result as you have 
> seen.

I have been trying to figure out a good way to validate that everything
is ready for the DS record to be published - a "zone_test" script, but
that's a separate issue.

> I see the following which indicates to me that 9675 is published but not 
> active
> and 28998 is published and active.

Yes, those are both zone signing keys (migrating from sha1 to sha256)


> [beetle:~/git/bind9] marka% 
> 
> and with the following DS records there isn’t secure path.
> 
> cascocom.com. 85427   IN  DS  9675 5 2 
> EBC1B325B8740433571AC648B0925A2158D5521446DFE50402142243E834F234
> cascocom.com. 85427   IN  DS  30841 8 2 
> E8870853532B4CF3588FE6B4DE59324F5E99C8C40F29CDED06845321CFDAB46C
> 
> now I don’t know exactly what you did but detected error will have been 
> logged.

I'm not sure how a DS record for 9675 got generated, as that's a zsk?

It might be better to wipe everything for this zone and start over as I
seem to have done something that got it very confused.




smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

key signing

[Alan Batie]

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 the zone signing key 28998 is self-signed, rather than being
signed by the zsk 30841?  Am I misunderstanding something here?

keys/Kcascocom.com.+008+28998.key:; This is a zone-signing key, keyid
28998, for cascocom.com.
keys/Kcascocom.com.+008+30841.key:; This is a key-signing key, keyid
30841, for cascocom.com.

;; ANSWER SECTION:
cascocom.com.   3600IN  DNSKEY  256 3 8
AwEAAbzsNZ6nTPgAjprXeuInoS24oSvDktzfDJxbd01Ggbpg+DCFHNQI
W9O2PlujvKPNZWw4I0lYNTREF4y3gl4sgBPRjaxv1Y274WBMgl/zNcDV
V7wBXBSHS3k/52HbP/KlL9kuxBKPbl40Kji3Fj2ZOpPuXxM+Y0uaYWeS 0kCgfs2h  ;
ZSK; alg = RSASHA256 ; key id = 28998
cascocom.com.   3600IN  RRSIG   DNSKEY 8 2 3600 20200409011715
20200310001715 28998 cascocom.com.
R2yjLkUxmoA8JEmcyaRx/t43OZXINXBjDTA0HhxBgtwhIIK9DRq7RnW1
bNjN88qqzGqjWIIE+AG7Xk+8PXRAUeyQzWFDkMrqbg/qxlBvK+MgMlTJ
VdWp2UdoDEn7A6feGNuoS7eBCDD+d+/DDjWZFU3D3YAIr6B7nJiu0hHF 8RQ=



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Alan Batie]

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 option to dnssec-keygen.

That sounds like a likely scenario actually

> (BTW I prefer to talk about "keys" when I have the files with both the
> public and private parts, and only talk about DNSKEYs when I'm referring
> to the public parts published in zone files.)

Seems reasonable, thanks



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Alan Batie]

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 `named` because it is easier.) But
> you might be able to follow my howto inserting a dnssec-signzone before
> rndc reload and you might get something that will approximately work...

I'm letting named do the automatic signing/generation of RRSIG records,
but unless I'm missing something, you still have to generate the DNSKEY
records manually.  dnssec-verify is the tool in question complaining
about not including RSASHA1 keys and signatures.  I'm still in the
initial phases of setting this up, so I don't have to worry about
algorithm rollover so much, as except for a couple of test domains,
there's no DS record to cause them to get used.  I did build scripts for
doing the zsk and ksk rollovers though.

In short, I'm setting things up so there's only two keys: ksk and zsk
using RSASHA256, which I think is the way things should be these days.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Alan Batie]

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 strong reasons for NOT generating SHA1 DNSKEY records!

That was my thought, but the tools complain about not having both...

# dnssec-verify -v 9 -I raw -o domain.com domain.com.signed
Loading zone 'domain.com' from file 'domain.com.signed'
Verifying the zone using the following algorithms: RSASHA256.
Missing self-signed KSK for algorithm RSASHA1
Missing ZSK for algorithm RSASHA256
The zone is not fully signed for the following algorithms: RSASHA1
RSASHA256.
dnssec-verify: fatal: DNSSEC completeness test failed.


Still working out which ones it thinks are missing, as both appear to be
there - it would be nice if the tool was more specific...



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

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

[Alan Batie]

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 about can
handle SHA256 these days...



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zsk rollover

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

> Remember with DNSSEC you never move onto the next step without checking that 
> the
> last step completed first.  The next step can always be stalled.  This 
> applies to both
> online and offline signing.  There are lots of “wait until xxx” in DNSSEC 
> maintenance.
> Don’t schedule multiple steps at once.  Even with a single machine unexpected 
> events
> can happen.

Yup: publish, activate, deactivate, delete.  I've been letting it
generate rrsigs for a long time now, but figured it was time I get the
rollover process worked out so I can actually get dnssec enabled (with
the DS record tie-in) and be sure it's not going to break at some random
time in the future.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: zsk rollover

[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 Inactivation does is STOP named signing records with that
> key.  It does NOT cause old RRSIGs to be replaced.  This is
> deliberate.
> 
> You are using offline signing timings where everything in the
> zone is re-signed at once.  To use the offline time model just
> use 22.5 days as the time to sign the zone rather than the fictional
> 0 seconds.

I'm supposedly using inline-signing:
auto-dnssec maintain;
inline-signing yes;

I set the time as short as I could as I really don't want to wait a
month to see the rollover happen, but I suspect (and I think that's what
you said above) it's the date in the rrsig record that actually matters.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

zsk rollover

[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 key is still being used for signing the NSEC responses

Found 2 RRSIGs over DNSKEY RRset
RRSIG=46671 and DNSKEY=46671 verifies the DNSKEY RRset
Found 1 RRSIGs over NSEC RRset
RRSIG=1410 and DNSKEY=1410 verifies the NSEC RRset
NSEC proves no records of type A exist for peakmail.com
Found 1 RRSIGs over SOA RRset
RRSIG=46671 and DNSKEY=46671 verifies the SOA RRset

It looks like the old key (1410) is still signing the NS records too:

 [117] $ dig +dnssec ns peakmail.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> +dnssec ns peakmail.com
...
;; ANSWER SECTION:
peakmail.com.   2949IN  NS  ns1.peak.org.
peakmail.com.   2949IN  NS  ns2.peak.org.
peakmail.com.   2949IN  RRSIG   NS 8 2 3600 20200306103311 
20200205095819
1410 peakmail.com.
YNtR43oUskSKPTGg3GIiH6V3icJhFsHg5RxH7UeQ9LPpN8c2UIWfbn/p
zXd9EcxeYwjRL0BtDQ6ZZRKLq7UcUdpFBwVR6dJv+g0pJg9VUAVVM4t5
9HoAq3HdyoyVoXWoQiPcNg+qqAwzp42FxRI/qILCoApurX9rPxNESuDo
FjzcXxOmGv3FNHKdIr0WqTb4BW9MIpJGF3WWymg5zFMqSv4BQJkIgWr/
XyDr6jhjvMLUAgF45+Gi5lEiqjzmwGb9XTxVJz9oMDCInh4Pi5185huV
GXKkSGArZsI9t7Z+0Zi0E+s56cuN6Sq8J/HueYoxIWnUxr+35tyFRjvv SxLXWA==


However the new key is signing the SOA record:

 [116] $ dig +dnssec soa peakmail.com

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> +dnssec soa
...
;; ANSWER SECTION:
peakmail.com.   3600IN  SOA ns1.peak.org. 
hostmaster.peak.org. 2020012408
3600 900 604800 300
peakmail.com.   3600IN  RRSIG   SOA 8 2 3600 2020032400 
202003
46671 peakmail.com.
YA/1d55blWOqwqsbcaKEP7JO4nRbI2OyzSvhcPWukAim5wDhFUx1OkAd
8kLPpGp7eO/WEAiyFk/JPxkOqLB0c/Lu1MlF9pmAFhUMzsVkDsYu1+uE
kGyhUpj4GrOoA3xOpJ6rQLfmTTjGFTpCtrBmlIm/UltA9a3pw7PTwLks
ZhpYU+a5CXhbimgBgk40Do9DGfN0ToB4R9w+AlFqAKX3UEpv8PiR/MaR
nCfjWLwnbVjURBj0V3P1VJUX38v4rOVPAIivwesM7MhaVL1+s+Rfvu5r
guCSkkY0XQc3jeKSRSE25I7AxWYTs9T8NBq5ZgFqyvHZN7ZZ4vwxwg/r hsvUug==



The public key files in question:

; This is a zone-signing key, keyid 1410, for peakmail.com.
; Created: 20200110224135 (Fri Jan 10 14:41:35 2020)
; Publish: 20200110224135 (Fri Jan 10 14:41:35 2020)
; Activate: 20200110224135 (Fri Jan 10 14:41:35 2020)
; Inactive: 2020022200 (Fri Feb 21 16:00:00 2020)
; Delete: 2020022600 (Tue Feb 25 16:00:00 2020)
peakmail.com. IN DNSKEY 256 3 8
AwEAAd44dDiBOaLFp/sRC6Pr0Baas/gcR1udt/PFFP8JPbBU82Sv1bH6
d/+8HsH7oYYBJaEaupIgrVqi2RzzdvnbvvPJ0mEEnCrVysGpIZCORimR
7OA+DVz6FZHcvi7PE8yaY7D09PbghnhiKBnk+obhqbTqjfyazPu+amM6
aJxg/2crq0+w/XRcuwQ40Oj/iK/c6fnPm1GxfTQBB11jpMOWc1uwsFxw
Xgcv1bVUc4H6ERk0MrH2wZQTvrh2XG1WQju6uRSi5YE+dXy2HYH/YK02
mXvOdB2YPhddap6u2XQC1zrZcEtiIT1ifWcxQYzhAT5/xoFct3oH0m46 iW5vVtYhACc=

; This is a zone-signing key, keyid 46671, for peakmail.com.
; Created: 20200218234802 (Tue Feb 18 15:48:02 2020)
; Publish: 2020021900 (Tue Feb 18 16:00:00 2020)
; Activate: 2020022200 (Fri Feb 21 16:00:00 2020)
peakmail.com. IN DNSKEY 256 3 8
AwEAAbMVxTZ9vttRsad5iBUOXflyn+Px1U0tQ7taNBNxRpHy0GFn/mtI
W/S4xNorMNj7acKqzOzgXxUH90tc0PYbpg17WEGIyJC0OtlQJExpASXd
7cXG9Se6RvWDhWiiiEs7Z4fAVEzqegohK/V86TFY5+uBd1uN8DVBtHnz
M1IBekumCyMliqHL4+7xtVrZccu2CINo6TukJvfz+SI/jQJUjXbfyuDN
uVUPE+JVeuiwPC1Y++Wg+S9oJrpsSp8Vm+j/NqdescDRknhWMYZGQ5HL
6xXgrqGZJ6EGC3FgH7WXU6oAmYxSZE8mGZp/2IiXLTefX8Si3bDMLxOe Av7p/BAAbgM=




smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ip6 reverse delegation

[Alan Batie]

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
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

ip6 reverse delegation

[Alan Batie]

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
Address: 8.8.8.8#53
Aliases:

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
not found: 3(NXDOMAIN)



The authoritative nameserver is serving it up:

$ host -t ptr
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
ns1.rdrop.com
Using domain server:
Name: ns1.rdrop.com
Address: 2607:f678:1010::53#53
Aliases:

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
domain name pointer agora.rdrop.com.



The parent authoritative nameserver (for 2607:f678::/32) is serving the
correct delegation NS records:

$ host -t ns 0.1.0.1.8.7.6.f.7.0.6.2.ip6.arpa ns1.peak.org
Using domain server:
Name: ns1.peak.org
Address: 2607:f678::53#53
Aliases:

0.1.0.1.8.7.6.f.7.0.6.2.ip6.arpa name server ns1.rdrop.com.
0.1.0.1.8.7.6.f.7.0.6.2.ip6.arpa name server ns2.rdrop.com.



Even for the intermediate levels, though I don't think that should
actually be necessary once the delegation gets to the top level
(8.7.6.f.7.0.6.2.ip6.arpa):

$ host -t ns 1.0.1.8.7.6.f.7.0.6.2.ip6.arpa ns1.peak.org
Using domain server:
Name: ns1.peak.org
Address: 2607:f678::53#53
Aliases:

1.0.1.8.7.6.f.7.0.6.2.ip6.arpa name server ns1.peak.org.
1.0.1.8.7.6.f.7.0.6.2.ip6.arpa name server ns2.peak.org.

$ host -t ns 0.1.8.7.6.f.7.0.6.2.ip6.arpa ns1.peak.org
Using domain server:
Name: ns1.peak.org
Address: 2607:f678::53#53
Aliases:

0.1.8.7.6.f.7.0.6.2.ip6.arpa name server ns1.peak.org.
0.1.8.7.6.f.7.0.6.2.ip6.arpa name server ns2.peak.org.

$ host -t ns 1.8.7.6.f.7.0.6.2.ip6.arpa ns1.peak.org
Using domain server:
Name: ns1.peak.org
Address: 2607:f678::53#53
Aliases:

1.8.7.6.f.7.0.6.2.ip6.arpa name server ns2.peak.org.
1.8.7.6.f.7.0.6.2.ip6.arpa name server ns1.peak.org.

$ host -t ns 8.7.6.f.7.0.6.2.ip6.arpa ns1.peak.org
Using domain server:
Name: ns1.peak.org
Address: 2607:f678::53#53
Aliases:

8.7.6.f.7.0.6.2.ip6.arpa name server ns2.peak.org.
8.7.6.f.7.0.6.2.ip6.arpa name server ns1.peak.org.



But dig +trace ptr
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
stops at the delegation point:

...
8.7.6.f.7.0.6.2.ip6.arpa. 86400 IN  NS  ns1.peak.org.
8.7.6.f.7.0.6.2.ip6.arpa. 86400 IN  NS  ns2.peak.org.
8.7.6.f.7.0.6.2.ip6.arpa. 10800 IN  NSEC0.8.6.f.7.0.6.2.ip6.arpa. NS
RRSIG NSEC
8.7.6.f.7.0.6.2.ip6.arpa. 10800 IN  RRSIG   NSEC 5 10 10800 20200130213553
20200116203553 24441 0.6.2.ip6.arpa.
HB6oy5WCbGQH+RKy+FvQyQXSKhls4a/Enfryn/ef4pfE7b9cCuFDYhYm
RiMf739Ju+HRXl2Vj/+rzTSyjjnF7HZkkjVHdWn2avlir11h4oXrVmQY
yTPzPXXixlO0VJqQiBpq+XsPuZHqyIpYeu/KESXLphSHQbuSDk58Kjbg B/8=
;; Received 365 bytes from 2001:67c:e0::10#53(arin.authdns.ripe.net) in
138 ms

0.1.0.1.8.7.6.f.7.0.6.2.ip6.arpa. 300 IN SOAns1.peak.org.
hostmaster.peak.org. 2020011606 3600 3600 86400 300
;; Received 160 bytes from 2607:f678::53#53(ns1.peak.org) in 1 ms



ns1.peak.org is running bind 9.9.7-P2

The zone file is:

$ORIGIN .
$TTL 300; 5 minutes
0.1.0.1.8.7.6.f.7.0.6.2.ip6.arpa IN SOA ns1.peak.org. hostmaster.peak.org. (
2020011606 ; serial
3600   ; refresh (1 hour)
3600   ; retry (1 hour)
86400  ; expire (1 day)
300; minimum (5 minutes)
)
NS  ns1.rdrop.com.
NS  ns2.rdrop.com.



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

bind keyfile lookup failures

[Alan Batie]

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 private key file
/RSASHA1/27456: file not found

I did an strace and find that when it looks for

K.+008+.private

it's looking for a different 

I've re-run dnssec-keygen and rndc sign on the zones, but that doesn't
fix things.  I'm not sure what is going on or how to fix it...

The main impact is filling up the log file - these zones aren't tied
into the root chain yet, but I'd like to get it fixed...




smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: 9.11/dnstap on centos: fstrm

[Alan Batie]

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.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

9.11/dnstap on centos: fstrm

[Alan Batie]

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 "error file
not found"

Configuring without dnstap for now...



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

key type change causing errors

[Alan Batie]

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 keys out and
regenerated then with dnssec-keygen -a RSASHA256 -b 2048 -3
$zone_name, then ran the rndc loadkeys $zone_name and rndc signing
-nsec3param 1 0 10 $random_salt $zone_name commands given, for each of
the domains.

Several problems have now appeared after restarting named:

1.  The log file is spewing dns_dnssec_findzonekeys2: error reading
private key file domain/RSASHA1/57843: file not found

2.  Why is it apparently still doing sha1 when I believe I told it to
use sha256 with the keygen command.

3.  It is still generating NSEC records, not NSEC3 records

I've moved the old keys back and the spewing stopped, but there is one
test domain that was generating that file not found error even before
this attempt, even though the key is there with the rest of them
(key-directory /var/named/keys;), so I clearly don't understand what
the error is trying to tell me...  The number doesn't match so I wonder
if that's a clue?

Dec 27 13:06:58 ns6 named[20141]: zone ghat.peak.org/IN (signed):
sending notifies (serial 2013060537)
Dec 27 13:06:58 ns6 named[20141]: dns_dnssec_findzonekeys2: error
reading private key file ghat.peak.org/RSASHA1/43536: file not found

ns6.peak.org [475] # lf -l *ghat*
-rw-r--r-- 1 named named  435 Dec 27 13:06 Kghat.peak.org.+005+10701.key
-rw--- 1 named named 1010 Dec 27 13:06 Kghat.peak.org.+005+10701.private

By number doesn't match, I mean 43536 vs 10701, which I believe is the
key tag, but not sure where it would be getting the wrong one from?

Thanks for any pointers...



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inconsistent resolution

[Alan Batie]

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.

I was afraid that was going to be the answer.  Thanks...




smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Inconsistent resolution

[Alan Batie]

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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Bind 9.9.x operation with dnssec

[Alan Batie]

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
individual RRSIGs to be completely managed and rotated as needed by
bind, per
https://kb.isc.org/article/AA-00626/0/Inline-Signing-in-ISC-BIND-9.9.0-Examples.html
and the Admin Reference, however, at the end of 4.9.7, it says:

By default, this rollover completes in 30 days, after which it will be
safe to remove the old key from the DNSKEY RRset.

This implies that I'm going to have to go in and do housekeeping in the
keys directory, though I'm not sure when - I set this up in early March
(according to the key activation comments - who remembers details that
far back? ;-) ) and they haven't rotated yet...

I found some other tools based around rollerd, but I think that's
intended for managing pre-9.9.x keys, as it seems to assume a slightly
different key structure with .krf files in the zone file directory.

When it comes to the DS records registered at the registrar, I'm not
sure where that comes from: the only way I can see to get it is to do a
DS query from the nameserver (and at least one document basically said
that).  First, I'd like to know where it comes from, and second, it
seems much too small, given ksks are supposed to be bigger as a result
of being longer lived:

raindrop.us.1903IN  DS  41190 5 2
C2927E697D868DB1AEF54642E9B59079CF5412AAA36846290AB20215 9CBAFBEA

vs

raindrop.us.3600IN  DNSKEY  256 3 5
AwEAAb3vNnkqkoG7brIDkPDSbnFDeFV2FmD+RktZFL3DDIIkM9Xkpker
sFTscUWFeta/DEBg8Jvgznyw6iiBCPob5Q9Vluv4mT+HNAm5F2W5wLww
FkJ8ia1xuZoAAl3jCHW3Cj5Dkkr0yVSSZrbORJ1/PnnKhb09o2LPjMr6 /hUjzlzV

When it comes time to roll the DS key, it looks like I pick a lifetime,
say 3 months, generate a new DS key (how, such that 9.9.x will use it?
rndc sign zone seems like the way, but that looks like it will take
effect immediately; rndc loadkeys zone says it will update keys
without signing immediately, which looks good, will sign zone then
use those keys later?), add it at the registrar, wait the ttl, then tell
bind to switch (again, how?)




As for specific problems:

I have bind 9.9.1 setup and the zones configured with:

key-directory /var/named/keys;
auto-dnssec maintain;
inline-signing yes;

This is a Slave server, hidden master per example 2 in
https://kb.isc.org/article/AA-00626/0/Inline-Signing-in-ISC-BIND-9.9.0-Examples.html

/var/named/keys appears to have the zone signing keys/DNSKEY records.
/var/named/slaves have the .signed files with RRSIG records, presumably
signed with the zsks in the keys directory.

Next, I have a DS record configured at my registrar obtained with dig
from my nameserver, but that doesn't seem to be right, as

http://dnsviz.net/d/raindrop.us/dnssec/
and
http://dnssec-debugger.verisignlabs.com/raindrop.us

both complain about the link from the parent to my nameserver in the
chain.  dnsviz just says bogus without explaining what's bogus (though
RFC4641 4.2 implies that the keys *have* rolled somehow, without the
registrar being updated); verisign says it couldn't get a dnskey rr from
the nameservers, though I can:

# dig @ns1.raindrop.us dnskey raindrop.us
...
;; ANSWER SECTION:
raindrop.us.3600IN  DNSKEY  256 3 5
AwEAAb3vNnkqkoG7brIDkPDSbnFDeFV2FmD+RktZFL3DDIIkM9Xkpker
sFTscUWFeta/DEBg8Jvgznyw6iiBCPob5Q9Vluv4mT+HNAm5F2W5wLww
FkJ8ia1xuZoAAl3jCHW3Cj5Dkkr0yVSSZrbORJ1/PnnKhb09o2LPjMr6 /hUjzlzV

# dig @ns2.raindrop.us dnskey raindrop.us
...
;; ANSWER SECTION:
raindrop.us.3600IN  DNSKEY  256 3 5
AwEAAb3vNnkqkoG7brIDkPDSbnFDeFV2FmD+RktZFL3DDIIkM9Xkpker
sFTscUWFeta/DEBg8Jvgznyw6iiBCPob5Q9Vluv4mT+HNAm5F2W5wLww
FkJ8ia1xuZoAAl3jCHW3Cj5Dkkr0yVSSZrbORJ1/PnnKhb09o2LPjMr6 /hUjzlzV

Somehow, I think the DS isn't matching the DNSKEYs, causing them to be
rejected, but since bind generated both, I would hope it's internally
consistent...


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Checking for zone expiration?

[Alan Batie]

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 remaining time on a zone for monitoring?  If you fetch
the SOA, you get the full ttl, for obvious reasons, not the server's
timer...

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Checking for zone expiration?

[Alan Batie]

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 list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

testing validation

[Alan Batie]

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 IN  SOA ns1.raindrop.us. 
hostmaster.rdrop.com.
2012030815 3600 3600 86400 3600



Launch a query to find a RRset of type RRSIG for zone: raindrop.us.

;; RRSIG is missing for continue validation: FAILED


I have this included in the resolver's named.conf:

managed-keys {
   . initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ;
};

per https://calomel.org/dns_bind.html

When I simply try to validate the root:

# dig +dnssec +sigchase .
;; NO ANSWERS: no more
We want to prove the non-existence of a type of rdata 1 or of the zone:
there is no NSEC for this zone: validating that the zone doesn't exist

;; Impossible to verify the Non-existence, the NSEC RRset can't be
validated: FAILED

I'm not sure what to look for now...



# dig +dnssec @ns6.peak.org raindrop.us

;  DiG 9.9.0  +dnssec @ns6.peak.org raindrop.us
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 15953
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;raindrop.us.   IN  A

;; ANSWER SECTION:
raindrop.us.3600IN  A   199.26.172.34
raindrop.us.3600IN  RRSIG   A 5 2 3600 20120512011136 
20120412010327
41190 raindrop.us.
kH5rKfIHghbsiKLTMkO6GjDtXI0Afkgl2x74K0o0AKtDlTDfsk+2pPZ/
XwKj1k2jIYButqXximUjHOHQHK1bSru7V8DkkN7JF/wozTOiGCs777sO
s90jKmaHIIMSTbNcQgtDySqzPsd4Sn9Qp86Iykj0nvXyUeMib2bzPJ5S VBY=

;; AUTHORITY SECTION:
raindrop.us.3600IN  NS  ns1.raindrop.us.
raindrop.us.3600IN  RRSIG   NS 5 2 3600 20120512011136 
20120412010327
41190 raindrop.us.
UQxIRpKV+b4opfCJx/j4oIFht8nqxpn1g0siOLI2XkxfVrnXHh17/ChT
X6PH5YOrF7D3v7AUMbVo+o8glSUfk1uML8i3C8H5lD/NmujPPrIqFaO/
6zCJen1q34FVunCoqfrYvYlaKHenFGsrpOl61H75ns0IjLMXSs+TRpIY GTs=

;; ADDITIONAL SECTION:
ns1.raindrop.us.3600IN  2607:f678::56
ns1.raindrop.us.3600IN  RRSIG    5 3 3600 20120512011136
20120412010327 41190 raindrop.us.
MhaOIt7D7kT8k4USk9Mpocw+tSx8WBSO/Yi+4F/YFV1ZVSXLKgYj4K4S
hTjVTBD3tCQYMJY+SkArlkoQRyTk4QYrLV8CP2TvvdrUPjZUZNAEMsuk
0NWsd2tLgStZ34yN0Pe1xa9P2SZjvsXJj1D1N5JNFxfS/OFCwMa9Hvcr atM=

;; Query time: 253 msec
;; SERVER: 2607:f678:10::53#53(2607:f678:10::53)
;; WHEN: Tue Apr 17 23:29:08 2012
;; MSG SIZE  rcvd: 615




___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: testing validation

[Alan Batie]

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 raindrop.us, is the resolver dnssec-enabled? I assume this 
 would be one of the resolvers listed in your resolv.conf file. It appears 
 that ns6.peak.org is not a recursive resolver. Does it have a zone file for 
 raindrop.us?

That's somewhat reassuring in that at least the authoritative server
seems to be working, meaning it's my resolver that isn't.

Sorry about the clarity - I am working with two machines, each running
bind 9.9.0: ns6.peak.org is the test authoritative server which is
serving the test domain, raindrop.us.  I'm using another machine as a
dnssec enabled resolver to do the testing from with this named.conf:


include /var/named/rdrop.blocks;
include /var/named/peak.blocks;

options {
directory /var/named;
pid-file /var/run/named/pid;

listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };

allow-query {
127.0.0.1;
::1;
rdrop_blocks;
peak_blocks;
};
allow-recursion {
127.0.0.1;
::1;
rdrop_blocks;
peak_blocks;
};
allow-transfer { none; };

dnssec-enable yes;
dnssec-validation yes;
masterfile-format text;

query-source address 127.0.0.1 port *;
version named;
};

managed-keys {
   . initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ;
};

zone . {
  type hint;
  file named.root;
};

zone 0.0.127.in-addr.arpa {
  type master;
  file master/localhost-reverse.db;
};

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: testing validation

[Alan Batie]

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 authoritative either...

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: testing validation

[Alan Batie]

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 a query to find a RRset of type DS for zone: .
;; NO ANSWERS: no more

;; WARNING There is no DS for the zone: .


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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: testing validation

[Alan Batie]

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 managed-keys and 
 root hint zone? Jeff.

No; I did turn on auto and removed the managed-keys and hint, noticed
the warning and tried turning validation back to yes with the
managed-keys, but that didn't change the warning.  dig still reports
successful validation even with the warning though...

# dig @localhost +dnssec raindrop.us

;  DiG 9.9.0  @localhost +dnssec raindrop.us
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 1578
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

...

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: testing validation

[Alan Batie]

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 be trusted. Thus there 
 is no DS record referring to the root zone, as it by definition has no 
 parent. The root trust anchor provided by managed-keys or dnssec-validation 
 serves the same purpose as this non-existent DS record. The warning above 
 makes sense in this context. Jeff.

Right - although the trust anchor is provided, it's not actually a DS
record, so you still get the warning...

Now on to research key rotation management...

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users