Adding trusted-keys to named.conf
Robert Moskowitz
rgm at htt-consult.com
Fri Mar 1 04:21:45 UTC 2013
On 02/28/2013 06:21 PM, Mark Andrews wrote:
> In message <512FB319.7030404 at 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?
More information about the bind-users
mailing list