Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
dig +dnssec +cd soa com -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
On Tue, 10 May 2011 15:17 +1000, Mark Andrews ma...@isc.org wrote: dig +dnssec +cd soa com dig +dnssec +cd soa com ; DiG 9.8.0-P1 +dnssec +cd soa com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 55492 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 14, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;com. IN SOA ;; ANSWER SECTION: com.900 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1305004673 1800 900 604800 86400 com.900 IN RRSIG SOA 8 1 900 20110517051753 20110510040753 36713 com. kV450cJYv8NlztaovFwY5ouWBBqDZq89o/uOdkVpHAvu/4wPiPTe60se Ay5/5BuA2O0ZBN/QEulqjb2xvULAHo5W3sgxdwx9spMTrU1Kdryw1+5Y zM19Kanl/tXgiPkRlidrLk6QEXx5GnMr6bYfayz7e4/vL5FL0nLjvIbb MF4= ;; AUTHORITY SECTION: com.3600IN NS g.gtld-servers.net. com.3600IN NS e.gtld-servers.net. com.3600IN NS j.gtld-servers.net. com.3600IN NS d.gtld-servers.net. com.3600IN NS b.gtld-servers.net. com.3600IN NS i.gtld-servers.net. com.3600IN NS h.gtld-servers.net. com.3600IN NS a.gtld-servers.net. com.3600IN NS k.gtld-servers.net. com.3600IN NS m.gtld-servers.net. com.3600IN NS c.gtld-servers.net. com.3600IN NS f.gtld-servers.net. com.3600IN NS l.gtld-servers.net. com.3600IN RRSIG NS 8 1 172800 20110516041548 20110509030548 36713 com. tx37OldYt1fgXR+rD/3ACR1BD3wR11m7Qtdslz1U9UyiBNbUK/swm4Uz /49U4A9Ndf5vCiybG0NJbBmEhJ2Gc+YzXf1Pv6NBZcEW63123NJf/igx z1DKZAJeF+HAlIhy/6Iuwvq8Z83+30kBC1G9ocRiUG5/CXr2X+WSSfFl Xsk= ;; Query time: 218 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 15:18:31 2011 ;; MSG SIZE rcvd: 637 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
date -u on the nameserver. It is Tue 10 May 2011 05:32:13 UTC as I send this. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
On Tue, 10 May 2011 15:32 +1000, Mark Andrews ma...@isc.org wrote: date -u on the nameserver. It is Tue 10 May 2011 05:32:13 UTC as I send this. here, date -u Mon May 9 22:34:59 UTC 2011 hrm? not good :-/ switch time server daemon to a known signed domain (clock.isc.org) service ntp restart ... 9 May 15:36:50 sntp[7762]: Started sntp 2011-05-09 15:36:55.874669 (+0800) +25198.977371 +/- 0.004883 secs Time synchronized with clock.isc.org Starting network time protocol daemon (NTPD) done ... date -u Tue May 10 05:37:43 UTC 2011 looks like problems with name resolution of time servers @ ntp startup? i'll dig further. in any case ... with this corrected, dig pir.org +dnssec ; DiG 9.8.0-P1 pir.org +dnssec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 50128 -- ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;pir.org. IN A ;; ANSWER SECTION: pir.org.272 IN A 173.201.238.128 pir.org.272 IN RRSIG A 5 2 300 20110523085011 20110509085011 38939 pir.org. LLK3y1HXm3/F3Tvq/b/cW4jnQC6gxtYlalPhM28w3tUzo2wS482vaWQr RF1DBvGTUD4uADNidjaftjkch7b2H1b+e5V4o0xQml/WpqCW/VqgLgxI g/yIg9WhP1Ec8uvWG2Ojy0ZIM0JKBBfFFlIxZVYqCyrY8WittyUOFlwo O48= ;; AUTHORITY SECTION: pir.org.271 IN NS ns1.yyz1.afilias-nst.info. pir.org.271 IN NS ns1.ams1.afilias-nst.info. pir.org.271 IN NS ns1.mia1.afilias-nst.info. pir.org.271 IN NS ns1.sea1.afilias-nst.info. pir.org.271 IN RRSIG NS 5 2 300 20110523085011 20110509085011 38939 pir.org. yUKJARGNwBWKFTi1V1nU5x38vcQrYPSn86G5MzjyMBjUWwZ3zZ4E+OMz P8svjTEdwKd6ibQGAp7aVEcqE3ruCnioqaXCZJsjT6YCaTpIjUMmRvpj tZUByl11+aqfcJuvfTNOo2PFtzRDv46vAlbZFf74fAK4AwNQa42OZlZC WVc= ;; Query time: 1 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 22:42:05 2011 ;; MSG SIZE rcvd: 494 dig www.adobe.com ; DiG 9.8.0-P1 www.adobe.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 33802 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.adobe.com. IN A ;; ANSWER SECTION: -- www.adobe.com. 3600IN CNAME www.wip4.adobe.com. www.wip4.adobe.com. 30 IN A 192.150.16.60 ;; AUTHORITY SECTION: wip4.adobe.com. 3600IN NS da1gtm001.adobe.com. wip4.adobe.com. 3600IN NS 3dns-5.adobe.com. ;; Query time: 862 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 22:40:34 2011 ;; MSG SIZE rcvd: 115 dig www.adobe.com +dnssec ; DiG 9.8.0-P1 www.adobe.com +dnssec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 6020 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.adobe.com. IN A ;; ANSWER SECTION: -- www.adobe.com. 3595IN CNAME www.wip4.adobe.com. www.wip4.adobe.com. 25 IN A 192.150.16.60 ;; AUTHORITY SECTION: wip4.adobe.com. 3595IN NS da1gtm001.adobe.com. wip4.adobe.com. 3595IN NS 3dns-5.adobe.com. ;; Query time: 1 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 22:40:39 2011 ;; MSG SIZE rcvd: 126 looks good, right? was this simply a wrong-time artifact? or is there something else up? DCh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
In message 1305006478.3040.1450174...@webmail.messagingengine.com, writes: On Tue, 10 May 2011 15:32 +1000, Mark Andrews ma...@isc.org wrote: date -u on the nameserver. It is Tue 10 May 2011 05:32:13 UTC as I send this. here, date -u Mon May 9 22:34:59 UTC 2011 hrm? not good :-/ switch time server daemon to a known signed domain (clock.isc.org) service ntp restart ... 9 May 15:36:50 sntp[7762]: Started sntp 2011-05-09 15:36:55.874669 (+0800) +25198.977371 +/- 0.004883 secs Time synchronized with clock.isc.org Starting network time protocol daemon (NTPD) done ... date -u Tue May 10 05:37:43 UTC 2011 looks like problems with name resolution of time servers @ ntp startup? i'll dig further. in any case ... with this corrected, [snipped] looks good, right? yes. was this simply a wrong-time artifact? or is there something else up? Simply the wrong time. The DNSKEY records for COM were signed far enough in the past to be valid as far as your nameserver was concerned. The SOA record for COM was being signed in the future as far as your nameserver was concerned. The expiry and inception dates for the records below. RRSIG DNSKEY ... 20110514182533 20110507182033 ... RRSIG SOA ... 20110517055901 20110510044901 ... May 9 22:34:59 UTC 2011 - 20110509223459 and it needs to be between the two values in the RRSIG record for the RRSIG to be considered valid. DNSSEC only needs wristwatch time accuracy however it is easy to get the time wrong if the server is configured in the wrong timezone. The error was equal to the local time offset from UTC which indicates it was running in UTC but set with the local time. Mark DCh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
On Tue, 10 May 2011 16:15 +1000, Mark Andrews ma...@isc.org wrote: looks good, right? yes. MANY thanks! i wouldn't have easily found this ... DNSSEC only needs wristwatch time accuracy however it is easy to get the time wrong if the server is configured in the wrong timezone. The error was equal to the local time offset from UTC which indicates it was running in UTC but set with the local time. not sure how to read that. now that my time's correct again, can/should I leave the server as is? or is there a specific recommendation for time setup on a DNS server? Thanks again, DCh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
In message 1305008349.11252.1450182...@webmail.messagingengine.com, writes : On Tue, 10 May 2011 16:15 +1000, Mark Andrews ma...@isc.org wrote: looks good, right? yes. MANY thanks! i wouldn't have easily found this ... DNSSEC only needs wristwatch time accuracy however it is easy to get the time wrong if the server is configured in the wrong timezone. The error was equal to the local time offset from UTC which indicates it was running in UTC but set with the local time. not sure how to read that. now that my time's correct again, can/should I leave the server as is? or is there a specific recommendation for time setup on a DNS server? date -u may now be correct but is plain date? If it isn't you should correct timezone for the server so that both date and date -u are correct. Otherwise you leave the server open to the accidental misconfiguration that probably caused this problem in the first place. Thanks again, DCh -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
On 05/10/2011 07:58 AM, Mark Andrews wrote: date -u may now be correct but is plain date? If it isn't you should correct timezone for the server so that both date and date -u are correct. Otherwise you leave the server open to the accidental misconfiguration that probably caused this problem in the first place. Also, depending on your OS, check what timezone the hardware (bios) clock is stored in, and when you next reboot the server, check that it pushes OS time - hardware time correctly, and reads it back correctly on startup. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
hi, not sure how to read that. now that my time's correct again, can/should I leave the server as is? or is there a specific recommendation for time setup on a DNS server? On Tue, 10 May 2011 16:58 +1000, Mark Andrews ma...@isc.org wrote: date -u may now be correct but is plain date? If it isn't you should correct timezone for the server so that both date and date -u are correct. Otherwise you leave the server open to the accidental misconfiguration that probably caused this problem in the first place. On Tue, 10 May 2011 10:37 +0100, Phil Mayers p.may...@imperial.ac.uk wrote: On 05/10/2011 07:58 AM, Mark Andrews wrote: Also, depending on your OS, check what timezone the hardware (bios) clock is stored in, and when you next reboot the server, check that it pushes OS time - hardware time correctly, and reads it back correctly on startup. thanks for the pointers. hwclock was wrong, too. after setting HWCLOCK=-u in '/etc/sysconfig/clock', after reboot, 'date', 'date -u', and 'hwclock' all now track correctly, and grep valid /etc/named.conf dnssec-validation yes; dig www.adobe.com | egrep ^www.adobe.com|WHEN www.adobe.com. 3398IN CNAME www.wip4.adobe.com. ;; WHEN: Tue May 10 07:37:31 2011 still works, and @ the correct time! lessons learned ... thanks again, DCh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
Hi. My bind v980-p1 svr is DNSSEC-enabled, and signed zones are publishing as DNSSEC-valid. I've both internal and external views: -- internal is authoritative and provides recursion for LAN clients -- external serves only as an authoritative hidden-primary feeding slaves via AXFR. all good. if i enable DNSSEC validation in the internal view, having imported the trusted key for the root, for known-good domains, a 'dig domain.com' returns DATA as expected, e.g., dig pir.org | egrep IN.*A|;; flags ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 0 ;pir.org. IN A pir.org.75 IN A 173.201.238.128 dig pir.org +dnssec | egrep IN.*A|;; flags ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 1 ;pir.org. IN A pir.org.95 IN A 173.201.238.128 pir.org.95 IN RRSIG A 5 2 300 20110523085011 20110509085011 38939 pir.org. LLK3y1HXm3/F3Tvq/b/cW4jnQC6gxtYlalPhM28w3tUzo2wS482vaWQr RF1DBvGTUD4uADNidjaftjkch7b2H1b+e5V4o0xQml/WpqCW/VqgLgxI g/yIg9WhP1Ec8uvWG2Ojy0ZIM0JKBBfFFlIxZVYqCyrY8WittyUOFlwo O48= pir.org.95 IN RRSIG NS 5 2 300 20110523085011 20110509085011 38939 pir.org. yUKJARGNwBWKFTi1V1nU5x38vcQrYPSn86G5MzjyMBjUWwZ3zZ4E+OMz P8svjTEdwKd6ibQGAp7aVEcqE3ruCnioqaXCZJsjT6YCaTpIjUMmRvpj tZUByl11+aqfcJuvfTNOo2PFtzRDv46vAlbZFf74fAK4AwNQa42OZlZC WVc= for known-bad domains 'dig domain.com' hesitates for a bit, then returns SERVFAIL -- no DATA. dig www.adobe.com ; DiG 9.8.0-P1 www.adobe.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 26024 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.adobe.com. IN A ;; Query time: 2948 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 12:21:28 2011 ;; MSG SIZE rcvd: 31 my understanding was that a 'dig domain.com +dnssec' on a known-bad domain would return DATA without the SERVFAIL, but it returns the same. e.g., dig www.adobe.com +dnssec ; DiG 9.8.0-P1 www.adobe.com +dnssec ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 4667 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.adobe.com. IN A ;; Query time: 69 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 12:21:32 2011 ;; MSG SIZE rcvd: 42 Shouldn't the +dnssec case for known-bad be returning DATA? Also, I'm unlcear about the proper use for validation. I *want* to validate, but have the DATA nonetheless returned, with appropriate FLAGS so that, e.g., Firefox + DNSSEC-extension can (1) resolve the domain, and (2) 'report' the DNSSEC state in-browser. The way things are working now, with validation enabled and NO DATA returned, domains simply don't resolve at all -- and, of course, the browser displays a failure. Is my expected usage _not_ appropriate? THanks, DCh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
On 05/09/2011 19:32, dchilton+b...@bestmail.us wrote: Hi. My bind v980-p1 svr is DNSSEC-enabled, and signed zones are publishing as DNSSEC-valid. I've both internal and external views: -- internal is authoritative and provides recursion for LAN clients -- external serves only as an authoritative hidden-primary feeding slaves via AXFR. Step 1 should be to separate those functions into separate processes. You're adding completely unnecessary complexity trying to shoehorn 2 substantially different features into the same process. for known-bad domains 'dig domain.com' hesitates for a bit, then returns SERVFAIL -- no DATA. It's not clear at all what you are defining as known bad here. www.adobe.com resolves just fine for me with or without +dnssec because adobe.com is not signed. Shouldn't the +dnssec case for known-bad be returning DATA? Known-bad in DNSSEC terms means a domain that is signed, but the signatures do not validate. In that case the queries should not return data. Also, I'm unlcear about the proper use for validation. I *want* to validate, but have the DATA nonetheless returned, with appropriate FLAGS so that, e.g., Firefox + DNSSEC-extension can (1) resolve the domain, and (2) 'report' the DNSSEC state in-browser. That's not at all how DNSSEC works, see above. The way things are working now, with validation enabled and NO DATA returned, domains simply don't resolve at all -- and, of course, the browser displays a failure. Is my expected usage _not_ appropriate? No, it isn't; however the fact that un-signed domains aren't returning data either is a problem. Split the features you described above into separate servers, remove the views stuff on the resolver, and try again. hth, Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
hi, On Mon, 09 May 2011 20:11 -0700, Doug Barton do...@dougbarton.us wrote: ... the fact that un-signed domains aren't returning data either is a problem. that's not returning DATA *and* reporting a SERVFAIL. not sure if they're one and the same issue. Split the features you described above into separate servers, remove the views stuff on the resolver, and try again. I'm confused by this advice, and what exactly you're proposing I do here. I've run this single-instance bind9 server in split-horizon mode serving up internal data with recursion to the lan just data with no recursion externally a couple of years with no apparent issues. I thought that was the purpose of internal/external views. Are you suggesting I need to run multiple bind9 servers, or some other config, to simply make DNSSEC validation work correctly for the LAN cleints? Thanks DCh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
This sounds like you have configured 'must-be-secure .;' which disables secure to insecure transitions within the must-be-secure namespace. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
Among numerous examples of folks running Bind9 in split-view mode similar to my config, I found this unanswered DNSSEC-related post, DNSSEC Validating Resolver and Views https://lists.isc.org/pipermail/bind-users/2010-March/079166.html which seems, at least, similar to the issue I'm seeing, ... This setup has been working for years but is now broken for clients querying from a guest network (via the guest view) unless the queries have checking disabled. ... Checking with my server for apparently unsigned 'www.adobe.com', dig www.adobe.com ; DiG 9.8.0-P1 www.adobe.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12026 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.adobe.com. IN A ;; Query time: 24 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 13:53:29 2011 ;; MSG SIZE rcvd: 31 dig www.adobe.com +cd ; DiG 9.8.0-P1 www.adobe.com +cd ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 50312 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.adobe.com. IN A ;; ANSWER SECTION: www.adobe.com. 3592IN CNAME www.wip4.adobe.com. www.wip4.adobe.com. 30 IN A 192.150.16.60 ;; AUTHORITY SECTION: wip4.adobe.com. 3337IN NS da1gtm001.adobe.com. wip4.adobe.com. 3337IN NS 3dns-5.adobe.com. ;; Query time: 52 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 13:53:37 2011 ;; MSG SIZE rcvd: 115 shows, as in the referenced post, that checking an dnssec-unsigned domain @ resolver with dnssec-validation enabled returns DATA only if that validation is DISABLED. DCh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
Hi, On Tue, 10 May 2011 13:52 +1000, Mark Andrews ma...@isc.org wrote: This sounds like you have configured 'must-be-secure .;' which disables secure to insecure transitions within the must-be-secure namespace. I'd not yet heard of that option. It's not present in my named.conf at all. Reading e.g. here, https://lists.isc.org/pipermail/bind-users/2004-July/051274.html, iiuc it doesn't seem to default to enabled. DCh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
Do you have dnssec-lookaside configured and if so how? -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
In message 130403.6599.1450152...@webmail.messagingengine.com, writes: Among numerous examples of folks running Bind9 in split-view mode similar to my config, I found this unanswered DNSSEC-related post, DNSSEC Validating Resolver and Views https://lists.isc.org/pipermail/bind-users/2010-March/079166.html which seems, at least, similar to the issue I'm seeing, ... This setup has been working for years but is now broken for clients querying from a guest network (via the guest view) unless the queries have checking disabled. ... Checking with my server for apparently unsigned 'www.adobe.com', dig www.adobe.com ; DiG 9.8.0-P1 www.adobe.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 12026 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.adobe.com. IN A ;; Query time: 24 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 13:53:29 2011 ;; MSG SIZE rcvd: 31 dig www.adobe.com +cd ; DiG 9.8.0-P1 www.adobe.com +cd ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 50312 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 0 ;; QUESTION SECTION: ;www.adobe.com. IN A ;; ANSWER SECTION: www.adobe.com. 3592IN CNAME www.wip4.adobe.com. www.wip4.adobe.com. 30 IN A 192.150.16.60 ;; AUTHORITY SECTION: wip4.adobe.com. 3337IN NS da1gtm001.adobe.com. wip4.adobe.com. 3337IN NS 3dns-5.adobe.com. ;; Query time: 52 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 13:53:37 2011 ;; MSG SIZE rcvd: 115 shows, as in the referenced post, that checking an dnssec-unsigned domain @ resolver with dnssec-validation enabled returns DATA only if that validation is DISABLED. What does dig DS adobe.com return? DCh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: proper setup of dnssec-validation to _always_ resolve, and retrieve DATA and status flags ?
hi, On Tue, 10 May 2011 14:48 +1000, Mark Andrews ma...@isc.org wrote: What does dig DS adobe.com return? dig DS adobe.com ; DiG 9.8.0-P1 DS adobe.com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 37646 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;adobe.com. IN DS ;; Query time: 2415 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 14:52:04 2011 ;; MSG SIZE rcvd: 27 and just for comparison, dig DS pir.org ; DiG 9.8.0-P1 DS pir.org ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 16298 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;pir.org. IN DS ;; ANSWER SECTION: pir.org.3581IN DS 54135 5 2 6CDE2DE97F1D07B23134440F19682E7519ADDAE180E20B1B1EC52E7F 58B2831D pir.org.3581IN DS 54135 5 1 225F055ACB65C8B60AD18B3640062E8C23A5FD89 ;; Query time: 1 msec ;; SERVER: 10.10.10.100#53(10.10.10.100) ;; WHEN: Mon May 9 14:52:06 2011 ;; MSG SIZE rcvd: 109 DCh ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
