generate a set of request DNSsec
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 on my servers. Did you have an idea? thank you for your help. -- Cordialement. Thierry *SAMEN.* ___ 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
Re: generate a set of request DNSsec
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 to log? The ARM covers the topic of logging pretty well, as does the grasshopper book. Bind's logging is nice in that you can log different information to different locations. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ 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
testing validation
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 IN SOA ns1.raindrop.us.
hostmaster.rdrop.com.
2012030815 3600 3600 86400 3600
Launch a query to find a RRset of type RRSIG for zone: raindrop.us.
;; RRSIG is missing for continue validation: FAILED
I have this included in the resolver's named.conf:
managed-keys {
. initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ;
};
per https://calomel.org/dns_bind.html
When I simply try to validate the root:
# dig +dnssec +sigchase .
;; NO ANSWERS: no more
We want to prove the non-existence of a type of rdata 1 or of the zone:
there is no NSEC for this zone: validating that the zone doesn't exist
;; Impossible to verify the Non-existence, the NSEC RRset can't be
validated: FAILED
I'm not sure what to look for now...
# dig +dnssec @ns6.peak.org raindrop.us
; DiG 9.9.0 +dnssec @ns6.peak.org raindrop.us
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 15953
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;raindrop.us. IN A
;; ANSWER SECTION:
raindrop.us.3600IN A 199.26.172.34
raindrop.us.3600IN RRSIG A 5 2 3600 20120512011136
20120412010327
41190 raindrop.us.
kH5rKfIHghbsiKLTMkO6GjDtXI0Afkgl2x74K0o0AKtDlTDfsk+2pPZ/
XwKj1k2jIYButqXximUjHOHQHK1bSru7V8DkkN7JF/wozTOiGCs777sO
s90jKmaHIIMSTbNcQgtDySqzPsd4Sn9Qp86Iykj0nvXyUeMib2bzPJ5S VBY=
;; AUTHORITY SECTION:
raindrop.us.3600IN NS ns1.raindrop.us.
raindrop.us.3600IN RRSIG NS 5 2 3600 20120512011136
20120412010327
41190 raindrop.us.
UQxIRpKV+b4opfCJx/j4oIFht8nqxpn1g0siOLI2XkxfVrnXHh17/ChT
X6PH5YOrF7D3v7AUMbVo+o8glSUfk1uML8i3C8H5lD/NmujPPrIqFaO/
6zCJen1q34FVunCoqfrYvYlaKHenFGsrpOl61H75ns0IjLMXSs+TRpIY GTs=
;; ADDITIONAL SECTION:
ns1.raindrop.us.3600IN 2607:f678::56
ns1.raindrop.us.3600IN RRSIG 5 3 3600 20120512011136
20120412010327 41190 raindrop.us.
MhaOIt7D7kT8k4USk9Mpocw+tSx8WBSO/Yi+4F/YFV1ZVSXLKgYj4K4S
hTjVTBD3tCQYMJY+SkArlkoQRyTk4QYrLV8CP2TvvdrUPjZUZNAEMsuk
0NWsd2tLgStZ34yN0Pe1xa9P2SZjvsXJj1D1N5JNFxfS/OFCwMa9Hvcr atM=
;; Query time: 253 msec
;; SERVER: 2607:f678:10::53#53(2607:f678:10::53)
;; WHEN: Tue Apr 17 23:29:08 2012
;; MSG SIZE rcvd: 615
___
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
RE: testing validation
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: # dig +dnssec +sigchase . ;; NO ANSWERS: no more # dig +dnssec @ns6.peak.org raindrop.us ;; WARNING: recursion requested but not available 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 raindrop.us, is the resolver dnssec-enabled? I assume this would be one of the resolvers listed in your resolv.conf file. It appears that ns6.peak.org is not a recursive resolver. Does it have a zone file for raindrop.us? 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
Re: testing validation
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 options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 28120
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;raindrop.us. IN A
;; ANSWER SECTION:
raindrop.us.3600 IN A 199.26.172.34
raindrop.us.3600 IN RRSIG A 5 2 3600 20120512011136 (
20120412010327 41190 raindrop.us.
kH5rKfIHghbsiKLTMkO6GjDtXI0Afkgl2x74K0o0AKtD
lTDfsk+2pPZ/XwKj1k2jIYButqXximUjHOHQHK1bSru7
V8DkkN7JF/wozTOiGCs777sOs90jKmaHIIMSTbNcQgtD
ySqzPsd4Sn9Qp86Iykj0nvXyUeMib2bzPJ5SVBY= )
;; Query time: 787 msec
;; SERVER: 149.20.64.20#53(149.20.64.20)
;; WHEN: Wed Apr 18 14:39:45 2012
;; MSG SIZE rcvd: 227
It's working fine.
[1] - https://www.dns-oarc.net/oarc/services/odvr
Best regards,
-
Carlos Eduardo Ribas
2012/4/18 Alan Batie a...@peak.org
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 IN SOA ns1.raindrop.us.
hostmaster.rdrop.com.
2012030815 3600 3600 86400 3600
Launch a query to find a RRset of type RRSIG for zone: raindrop.us.
;; RRSIG is missing for continue validation: FAILED
I have this included in the resolver's named.conf:
managed-keys {
. initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ;
};
per https://calomel.org/dns_bind.html
When I simply try to validate the root:
# dig +dnssec +sigchase .
;; NO ANSWERS: no more
We want to prove the non-existence of a type of rdata 1 or of the zone:
there is no NSEC for this zone: validating that the zone doesn't exist
;; Impossible to verify the Non-existence, the NSEC RRset can't be
validated: FAILED
I'm not sure what to look for now...
# dig +dnssec @ns6.peak.org raindrop.us
; DiG 9.9.0 +dnssec @ns6.peak.org raindrop.us
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 15953
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;raindrop.us. IN A
;; ANSWER SECTION:
raindrop.us.3600IN A 199.26.172.34
raindrop.us.3600IN RRSIG A 5 2 3600 20120512011136
20120412010327
41190 raindrop.us.
kH5rKfIHghbsiKLTMkO6GjDtXI0Afkgl2x74K0o0AKtDlTDfsk+2pPZ/
XwKj1k2jIYButqXximUjHOHQHK1bSru7V8DkkN7JF/wozTOiGCs777sO
s90jKmaHIIMSTbNcQgtDySqzPsd4Sn9Qp86Iykj0nvXyUeMib2bzPJ5S VBY=
;; AUTHORITY SECTION:
raindrop.us.3600IN NS ns1.raindrop.us.
raindrop.us.3600IN RRSIG NS 5 2 3600
20120512011136 20120412010327
41190 raindrop.us.
UQxIRpKV+b4opfCJx/j4oIFht8nqxpn1g0siOLI2XkxfVrnXHh17/ChT
X6PH5YOrF7D3v7AUMbVo+o8glSUfk1uML8i3C8H5lD/NmujPPrIqFaO/
6zCJen1q34FVunCoqfrYvYlaKHenFGsrpOl61H75ns0IjLMXSs+TRpIY GTs=
;; ADDITIONAL SECTION:
ns1.raindrop.us.3600IN 2607:f678::56
ns1.raindrop.us.3600IN RRSIG 5 3 3600
20120512011136
20120412010327 41190 raindrop.us.
MhaOIt7D7kT8k4USk9Mpocw+tSx8WBSO/Yi+4F/YFV1ZVSXLKgYj4K4S
hTjVTBD3tCQYMJY+SkArlkoQRyTk4QYrLV8CP2TvvdrUPjZUZNAEMsuk
0NWsd2tLgStZ34yN0Pe1xa9P2SZjvsXJj1D1N5JNFxfS/OFCwMa9Hvcr atM=
;; Query time: 253 msec
;; SERVER: 2607:f678:10::53#53(2607:f678:10::53)
;; WHEN: Tue Apr 17 23:29:08 2012
;; MSG SIZE rcvd: 615
___
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
___
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
Re: testing validation
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 raindrop.us, is the resolver dnssec-enabled? I assume this
would be one of the resolvers listed in your resolv.conf file. It appears
that ns6.peak.org is not a recursive resolver. Does it have a zone file for
raindrop.us?
That's somewhat reassuring in that at least the authoritative server
seems to be working, meaning it's my resolver that isn't.
Sorry about the clarity - I am working with two machines, each running
bind 9.9.0: ns6.peak.org is the test authoritative server which is
serving the test domain, raindrop.us. I'm using another machine as a
dnssec enabled resolver to do the testing from with this named.conf:
include /var/named/rdrop.blocks;
include /var/named/peak.blocks;
options {
directory /var/named;
pid-file /var/run/named/pid;
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
allow-query {
127.0.0.1;
::1;
rdrop_blocks;
peak_blocks;
};
allow-recursion {
127.0.0.1;
::1;
rdrop_blocks;
peak_blocks;
};
allow-transfer { none; };
dnssec-enable yes;
dnssec-validation yes;
masterfile-format text;
query-source address 127.0.0.1 port *;
version named;
};
managed-keys {
. initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq QxA+Uk1ihz0= ;
};
zone . {
type hint;
file named.root;
};
zone 0.0.127.in-addr.arpa {
type master;
file master/localhost-reverse.db;
};
___
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
Re: testing validation
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 authoritative either... ___ 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
Re: Test DNSSEC validation
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) to query with Checking Disabled. It sounds to me as though you're looking for a add-cd-to-all-queries option on a validating BIND recursor; that doesn't exist, as far as I know. -JP ___ 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
Re: testing validation
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 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 authoritative either... ___ 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
RE: testing validation
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 { 127.0.0.1; }; will prevent your resolver from
accepting queries from network sources, and so is inconsistent with your
allow-query statement. Consider omitting listen-on and changing listen-on-v6 to
{any;}.
Consider adding zones for
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa and
localhost.
Jeff.
___
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
Re: testing validation
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 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? Though putting it back in didn't make the warning go away, so I must be missing something else here... ___ 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
RE: testing validation
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. ___ 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
RE: testing validation
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 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
Re: testing validation
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 managed-keys and root hint zone? Jeff. No; I did turn on auto and removed the managed-keys and hint, noticed the warning and tried turning validation back to yes with the managed-keys, but that didn't change the warning. dig still reports successful validation even with the warning though... # dig @localhost +dnssec raindrop.us ; DiG 9.9.0 @localhost +dnssec raindrop.us ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 1578 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ... ___ 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
RE: testing validation
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 is my understanding that DS records exist in parent zones and refer to child zones that are to be trusted. Thus there is no DS record referring to the root zone, as it by definition has no parent. The root trust anchor provided by managed-keys or dnssec-validation serves the same purpose as this non-existent DS record. The warning above makes sense in this context. Jeff. ___ 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
Re: testing validation
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 be trusted. Thus there is no DS record referring to the root zone, as it by definition has no parent. The root trust anchor provided by managed-keys or dnssec-validation serves the same purpose as this non-existent DS record. The warning above makes sense in this context. Jeff. Right - although the trust anchor is provided, it's not actually a DS record, so you still get the warning... Now on to research key rotation management... ___ 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
www.glb.hud.gov
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 domains, but I commented out dnssec-enable yes in my named.conf and it didn't help. -- Richard ___ 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
