On 4/18/12 12:18 PM, Spain, Dr. Jeffry A. wrote:
>> ;; WARNING There is no DS for the zone: .
>> Isn't the "DS for the zone: ." what the "managed-keys" clause provides?
>
> Now I think I see what you mean. It is my understanding that DS records exist
> in parent zones and refer to child zones th
> Though I am still curious about this from the end of sigchase output:
> Launch a query to find a RRset of type DS for zone: .
> ;; NO ANSWERS: no more
> ;; WARNING There is no DS for the zone: .
> Isn't the "DS for the zone: ." what the "managed-keys" clause provides?
Now I think I see what you
On 4/18/12 11:48 AM, Spain, Dr. Jeffry A. wrote:
>> Isn't the "DS for the zone: ." what the "managed-keys" clause provides?
>> Though putting it back in didn't make the warning go away, so I must be
>> missing something else here...
>
> Any difference with dnssec-validation auto and removing the
> Why would 149.20.64.20 return ad then? It's not authoritative either...
As I understand it, you need a dnssec-enabled recursive resolver to get an AD
flag returned. An authoritative-only server will never return an AD flag. Jeff.
___
Please visit htt
> Isn't the "DS for the zone: ." what the "managed-keys" clause provides?
> Though putting it back in didn't make the warning go away, so I must be
> missing something else here...
Any difference with dnssec-validation auto and removing the managed-keys and
root hint zone? Jeff.
On 4/18/12 11:14 AM, Spain, Dr. Jeffry A. wrote:
> Alan: Comments on your configuration file:
I also forgot to remove the nameserver entries from resolv.conf after
installing bind. Sigh. Sorry to bother everyone...
Though I am still curious about this from the end of sigchase output:
Launch
Alan: Comments on your configuration file:
I believe that managed-keys... and zone "." { type hint... are built into bind
9.9.0 recursive resolvers and therefore not needed. You can enable the built in
root trust anchor by changing dnssec-validation from yes to auto.
I think that listen-on { 12
Because this IP has dnssec enabled and raindrop.us is signed :-)
Regards,
-
Carlos Eduardo Ribas
2012/4/18 Alan Batie
> On 4/18/12 10:46 AM, Carlos Ribas wrote:
>
> > Is your recursive resolver also authoritative for raindrop.us?
> > If so, you will not ge
On 4/18/12 10:46 AM, Carlos Ribas wrote:
> Is your recursive resolver also authoritative for raindrop.us?
> If so, you will not get the "ad" flag. You can
> test with DNS-OARC resolver [1]:
>
> # dig +dnssec +multiline @149.20.64.20 raindrop.us
Why would 149.20.64.20 return ad then? It's no
On 4/18/12 10:33 AM, Spain, Dr. Jeffry A. wrote:
> Your post is somewhat unclear to me. Querying from my bind 9.9.0 recursive
> resolver "dig @localhost raindrop.us +dnssec", I get an AD flag returned,
> suggesting that dnssec is working for raindrop.us. In your query "dig +dnssec
> +sigchase s
Hello,
Is your recursive resolver also authoritative for raindrop.us? If so,
you will not get the "ad" flag. You can test with DNS-OARC resolver [1]:
# dig +dnssec +multiline @149.20.64.20 raindrop.us
; <<>> DiG 9.7.3 <<>> +dnssec +multiline @149.20.64.20 raindrop.us
; (1 server found)
;; gl
> I'm testing out dnssec with bind 9.9.0's auto signing and a test domain; this
> appears to be working (see below, RRSIG records returned from the actual
> nameserver), however and attempt to validate fails with:
> # dig +dnssec +sigchase soa raindrop.us
> When I simply try to validate the root:
I'm testing out dnssec with bind 9.9.0's auto signing and a test domain;
this appears to be working (see below, RRSIG records returned from the
actual nameserver), however and attempt to validate fails with:
# dig +dnssec +sigchase soa raindrop.us
;; RRset to chase:
raindrop.us.987
13 matches
Mail list logo
