On 02/28/2013 06:21 PM, Mark Andrews wrote:
In message <512fb319.7030...@htt-consult.com>, Robert Moskowitz writes:
I MAY be doing something wrong, or my problem is elsewhere...
In zone htt. I have the DNSKEY RR:
htt. IN DNSKEY 257 3 7
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w
Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW
Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD
8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X
DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w==
So in my caching server's named.conf I added at the end:
include "/etc/named.trusted.key";
and this contains:
trusted-keys {
# DNSKEY for htt zone.
htt. 257 3 7
"AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w
Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW
Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD
8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X
DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w==";
};
And I am still getting:
Feb 28 14:35:17 klovia named[24806]: validating @0xb4855220: htt SOA:
got insecure response; parent indicates it should be secure
The forwarders are not DNSSEC enabled. "parent" here means named.conf.
The forwarder has:
dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;
and I just added the trusted-keys clause to the internal view via an
include. So now the trusted-keys clause is in the forward server and
the caching server. I no longer get on the forward server:
Feb 28 12:14:16 rigel named[786]: error (chase DS servers) resolving
'htt/DS/IN': 208.83.67.188#53
But still getting on caching server:
Feb 28 23:08:19 klovia named[466]: validating @0xb4655220: htt SOA:
got insecure response; parent indicates it should be secure
>From the recursive server run
dig @forwarder +dnssec htt soa
This should work and have RRSIG records. Do some other queries also
with +dnssec. negative responses should have NSEC/NSEC3 records if
they are coming from a signed zone.
dig +bufsize=4096 @rigel +dnssec htt soa
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6 <<>> +bufsize=4096
@rigel +dnssec htt soa
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;htt. IN SOA
;; ANSWER SECTION:
htt. 43200 IN SOA rigel.htt-consult.com.
rgm.htt-consult.com. 2013021402 7200 1200 1209600 7200
;; AUTHORITY SECTION:
htt. 43200 IN NS oqo3.htt.
htt. 43200 IN NS rigel.htt-consult.com.
;; ADDITIONAL SECTION:
oqo3.htt. 43200 IN AAAA 2607:f4b8:3:11:20c:96ff:fe40:cb63
rigel.htt-consult.com. 43200 IN A 208.83.67.188
rigel.htt-consult.com. 43200 IN AAAA 2607:f4b8:3:3:9254:5400:0:188
oqo3.htt. 43200 IN RRSIG AAAA 7 2 43200 20130330032518
20130228032518 63362 htt.
iOSHk0B9+OPDuKJiWP1ArR/eleHi7KNUmEiQAw9ztGLzzqh1zsoDH3ZA
Su6z2IlX33GS7FsdmeZB7SdflVsXSc4LyRFoX2lxHPopjo3M26w947J5
7RwmHZ8VvA9Q93BkyikhRai9s+ql4haXDcV+xW+lTz+cokkB5ASXY/Xh
X5JqkOO7XEjoliDCJxFF1OeSEk0p40U+d7f4SXccrVy940AJHbQJuOXb
TyvjHjrqOgo/5Gy2Att/MjN+cDYW79bDQCY4cDOLZ96ZCBSFqfaKUQq/
vIx7kqlb/RlM7tFcxm0pd7XsPfjRopac5FRXubLVAVrM/qP5I3RH+0Qy
NM4oHEYf2S72iPGIpkhrR5r8MfC8YS7nDFqFgcMbsxn42xku
;; Query time: 1 msec
;; SERVER: 2607:f4b8:3:3:9254:5400:0:188#53(2607:f4b8:3:3:9254:5400:0:188)
;; WHEN: Thu Feb 28 23:17:40 2013
;; MSG SIZE rcvd: 521
Why just oqo3.htt. with a RRSIG? All the hosts in htt. have RRSIG
records. And, no, 'host oqo3.htt.' also fails when run on klovia.
The logged for starting named does have:
Feb 28 14:35:00 klovia named[24806]: managed-keys-zone ./IN: loaded
serial 103
managed-keys in named.conf are just the initial keys used as the
starting point for RFC 5011 style trusted key managment. The runtime
keys are pulled from a seperate database. That message says that
the serial number for that database is 103.
So there is no message at startup about loading trusted-keys.
but nothing about trusted-keys loaded. In the
http://www.isc.org/software/bind/documentation/arm95 it shows the
trusted-keys clause before the global options. Does order matter; it
seems to for ACLs? Is there something else I am missing?
_______________________________________________
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