generate a set of request DNSsec

2012-04-18 Thread William Thierry SAMEN
Hi, i'm trying to implement DNSsec on my DNS zones and make a test performance to evaluate the charge of DNSsec on my servers. I'm faced with a big problem, *How can i generate a log file for my test?*it's a big problem for me, i'm working on Bind 9.8.1-P1 and i'm using dnsperf to inject requests

Re: generate a set of request DNSsec

2012-04-18 Thread WBrown
William wrote on 04/18/2012 05:45:21 AM: I'm faced with a big problem, How can i generate a log file for my test? it's a big problem for me, i'm working on Bind 9.8.1-P1 and i'm using dnsperf to inject requests on my servers. Did you have an idea? thank you for your help. What do you want

testing validation

2012-04-18 Thread Alan Batie
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

RE: testing validation

2012-04-18 Thread Spain, Dr. Jeffry A.
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: #

Re: testing validation

2012-04-18 Thread Carlos Ribas
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) ;; global

Re: testing validation

2012-04-18 Thread Alan Batie
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 soa

Re: testing validation

2012-04-18 Thread 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 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 not

Re: Test DNSSEC validation

2012-04-18 Thread Jan-Piet Mens
What is the best way to log DNSSEC failures in Bind without enforcing DNSSEC validation? That is I want to see what Bind would have rejected because of failed DNSSEC validation, but I do not want to return SERVFAIL to my client. I don't think that is possible without modifying the client(s)

Re: testing validation

2012-04-18 Thread Carlos Ribas
Because this IP has dnssec enabled and raindrop.us is signed :-) Regards, - Carlos Eduardo Ribas 2012/4/18 Alan Batie a...@peak.org On 4/18/12 10:46 AM, Carlos Ribas wrote: Is your recursive resolver also authoritative for raindrop.us? If so, you

RE: testing validation

2012-04-18 Thread Spain, Dr. Jeffry A.
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 {

Re: testing validation

2012-04-18 Thread Alan Batie
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

RE: testing validation

2012-04-18 Thread Spain, Dr. Jeffry A.
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.

RE: testing validation

2012-04-18 Thread Spain, Dr. Jeffry A.
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

Re: testing validation

2012-04-18 Thread Alan Batie
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

RE: testing validation

2012-04-18 Thread Spain, Dr. Jeffry A.
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 mean. It

Re: testing validation

2012-04-18 Thread Alan Batie
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 that are to

www.glb.hud.gov

2012-04-18 Thread Richard Laager
Are others timing out trying to resolve www.glb.hud.gov? This seems (though I haven't done extensive testing) to only happen to me with BIND. http://dnsviz.net/d/www.glb.hud.gov/dnssec/ shows a couple of DNSKEY warnings, so maybe that's it. I always suspect DNSSEC when I have problems with .gov