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

Reply via email to