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: 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