>> Try this one: dig @bind.odvr.dns-oarc.net. isc.org +dnssec You should >> get an AD flag returned and a variety of RRSIG records. Jeff.
> I hope I'm not missing any concepts here, but there should be a public key to > verify the RRSIG, where's that? Shouldn't the server return additional DNSKEY > records? The public key is the DNSKEY record whose private key was used to create the RRSIG. It's in the zone data but won't be returned in response to a query from dig unless you ask for it, e.g. 'dig @bind.odvr.dns-oarc.net. isc.org dnskey +dnssec'. That doesn't mean that the recursive resolver, in this case bind.odvr.dns-oarc.net, isn't looking at the DNSKEY records as part of its internal DNSSEC validation process. > Also if I replace bind.odvr.dns-oarc.net. with one of the root nameservers, > why is it that AD flag is not set? The root nameservers are DNSSEC capable. The AD flag is only set by recursive resolvers that are capable of validating a DNSSEC chain of trust. The root servers are DNSSEC-capable but are authoritative servers, i.e. they only return information from their own zone files and can't validate a chain of trust. Here's a possibly missing concept. There are three entities involved in your dig queries: 1. A stub resolver, which is your system running dig. 2. A recursive resolver, which is bind.odvr.dns-oarc.net, and which issues a series of queries on your behalf in order to get the answer you asked for and do DNSSEC validation on it. It does so without returning to you the internals of that process. 3. A series of authoritative name servers, which bind.odvr.dns-oarc.net queries to get the answer you want. Again you don't see this activity with dig. Jeffry A. Spain Network Administrator Cincinnati Country Day School _______________________________________________ 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
