[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bind9-users
Subject:    Re: No SIG validation occurring (was Re: DNSSEC signed zones working properly?)
From:       Jim Reid <jim () rfc1035 ! com>
Date:       2004-06-09 14:31:50
Message-ID: 20910.1086791510 () gromit ! rfc1035 ! com
[Download RAW message or body]

>>>>> "Kevin" == Kevin  <bind@gnosys.biz> writes:

    >> You might also want to check out RIPE's DNSSEC training course
    >> notes at: http://www.ripe.net/training/dnssec/material

    Kevin> I studied this course in detail over about two hours,
    Kevin> experimenting with both servers as I did so to make sure
    Kevin> that my setup matched the one described in the course that
    Kevin> relates to DNSSEC.

    Kevin> I guess the most important issue here is that my "verifying
    Kevin> resolving name server" seems not to be doing any verifying.

Have you told the name server to do DNSSEC verification? Check the ARM
for details of the dnssec-enable option. Bear in mind that the above
course notes are older than the current 9.3 betas and some BIND9
features have changed. This option wasn't around for the snapshot that
was used to prepare those notes.

    Kevin> Is there a named.conf option that I need to use to ask the
    Kevin> forwarding server to do validation?  

Yes, that appears to be the case. Though I've not yet played with
DNSSEC and the current 9.3 beta. Your mileage may vary. You might also
want to explore the dnssec-must-be-secure option. Keep away from the
stuff about dnssec-lookaside: this is for a handful of the most
clueful DNSSEC geeks.

    Kevin> How does it know to treat the query from dig as a query for
    Kevin> which it _should_ do validation?  

Because it's been told to do DNSSEC validation and it has a
suitable trusted-keys{} statement.

    Kevin> Does that come from dig's +dnssec option (setting a DO flag
    Kevin> or something like that)?

No. This is just a hint to the name server that the client is
DNSSEC-aware. The DO bit just says "I speak DNSSEC. Give me any DNSSEC
related RRs for this query if you have them.". The main point of this
bit is to avoid name servers always returning keys & signatures and
then having legacy applications or resolvers barf on these unknown (to
them) RR types. The intention is DNSKEYs, RRSIGs and so on should only
get returned to clients who've explicitly said they're able to handle
them.

Another approach to checking DNSSEC validation could be the sigchase
stuff in the 9.3.0beta4 dig that Rob referred to. It's #ifdef'ed out
by default and seems to be undocumented. If you go down this path,
you'll be better to ask for help in one of the DNSSEC mailing lists.

[prev in list] [next in list] [prev in thread] [next in thread]