Re: named validating @0x...: ... SOA: no valid signature found
On 12-07-20 07:16 PM, Mark Andrews wrote: dnssec-validation auto; Well, this seems to have done the trick. Changing it from yes to auto has eliminated most (almost all in fact) of the validation warnings/errors I was getting in my logs. tells named to use the compiled in root key in addition to enabling validation. A. So yes just enables validation but doesn't use any compiled in root key? If so, this is an annoying (all due respect) and small but important distinction. I'm not sure about anyone else, but a yes/no/auto selector to me means either an explicit yes or explicit no with auto meaning some kind of do what you think is right in terms of making it yes or no. I don't typically think of it as no or yes plus some additional functionality. Anyway, you have my since appreciation for persevering with me in my efforts to figure this out. b. signature.asc Description: OpenPGP digital signature ___ 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: named validating @0x...: ... SOA: no valid signature found
On 12-05-15 09:01 AM, Phil Mayers wrote: Sorry about the way delayed response. There seems to be some confusion about which list/group gmane is following. Isn't it more likely it's a local problem? Indeed. But what, is the question (and I do have the answer, now -- see below). Which version of bind are you running? I was running 9.8.3 and now 9.9.1-P1 Does *any* zone validate Yes. e.g. try: dig +dnssec @localhost www.ic.ac.uk # dig +dnssec @localhost www.ic.ac.uk ; DiG 9.9.1-P1 +dnssec @localhost www.ic.ac.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 725 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 13 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.ic.ac.uk. IN A ;; ANSWER SECTION: www.ic.ac.uk. 3600IN A 155.198.140.14 www.ic.ac.uk. 3600IN RRSIG A 5 4 3600 20120812165527 20120713164639 4743 ic.ac.uk. UZDw0aM0xPFXAmb5/PReP8hSWR/eNmMA479JFoZyHmxRrepTaJWLya+R 1F2Y2LI/T12QlFkw09KBsgZo+hGr2MWfPyMAjNttzDLCqGM7dDNBUnuz H4G7DUnTvpnIV3VcLHqIh2z+j5ZmBb4+O4MIbNbBh8reVIacM8jgGNPH Evs= ;; AUTHORITY SECTION: ic.ac.uk. 86400 IN NS ns1.ic.ac.uk. ic.ac.uk. 86400 IN NS authdns1.csx.cam.ac.uk. ic.ac.uk. 86400 IN NS ns2.ic.ac.uk. ic.ac.uk. 86400 IN NS ns0.ic.ac.uk. ic.ac.uk. 86400 IN RRSIG NS 5 3 86400 20120806213024 20120707210235 4743 ic.ac.uk. AYa7xE/1ZDMvt0c1wGY/+eu4vgbJm4EV+i+1YYZhtLu44bdnHndfptNZ ECxeOI8JVeaKUq1zPspK9UnTCLFDkfCq9cIVFjZhpHQSPHtd3Vss40Vl gKrOG6qm4RfmPbLaUDKxu/LsR/W+iRbbiwI2fsso34BTUJeKPZGwqHPG j9k= ;; ADDITIONAL SECTION: ns0.ic.ac.uk. 86400 IN A 155.198.142.80 ns0.ic.ac.uk. 86400 IN 2001:630:12:600:1::80 ns1.ic.ac.uk. 86400 IN A 155.198.142.81 ns1.ic.ac.uk. 86400 IN 2001:630:12:600:1::81 ns2.ic.ac.uk. 86400 IN A 155.198.142.82 authdns1.csx.cam.ac.uk. 86400 IN A 131.111.12.37 authdns1.csx.cam.ac.uk. 86400 IN 2001:630:212:12::d:a1 ns0.ic.ac.uk. 86400 IN RRSIG A 5 4 86400 20120807164706 20120708162343 4743 ic.ac.uk. SDz7qZbq+O/SMopAP4L1W9QeeuJu6+vBW25h4WIoDmFgXb+OPx3/M/6H 6pBFUpO2XoBfurRHly0r2yy7C4x3X7vth8nT9Xo16ZL9nauYwbUIM3f3 zDECyEzrkPf8EDcwRYycOJfcKcAlxG0FiPBav+WJW8PNMR43YAsr6w5D ZLU= ns0.ic.ac.uk. 300 IN RRSIG 5 4 300 20120809142748 20120710132748 4743 ic.ac.uk. U+LTVkUNoTWXNTabEd/rt15qze4iLWhDFyw+inaYgToGxYA5y3JS+fnx qfe2+GUFSLOz/Xo6czEe7728vCLgXzLQckAyS3g56NUfHKyXO1WWa6lQ k1r9UoNOSj5vTu0YLQN1FgP4aSFjowZzeQtbX//aDXZEVHKjNz4UFwBA zPs= ns1.ic.ac.uk. 86400 IN RRSIG A 5 4 86400 20120816015657 20120717011404 4743 ic.ac.uk. dFRwdOkf670aLyyLtnLAYwo18XQGIFgT8YWQukrsj514pINSR5WUkcpd ReUOGLy9+RDEfpWwDsvdp1DLrxbUzElTF5Qkg/1d76qqB6WxmnQq6lqz r5zKgfh9GNZHKrAOzvLcxlUFhd2xm1NXjktjIhb6CLH+qrJRR9h9+Zxy MlQ= ns1.ic.ac.uk. 300 IN RRSIG 5 4 300 20120809142748 20120710132748 4743 ic.ac.uk. OBSX8EyrqDcE6QzArCOaecx3Rf5fuBqfMctc/6M+3SnCHqQ9Dzp0YZly 2f6OJXu2JCrR4lGEUfgnA8rXDCKLgkzVIWFZi4y0GVuY2VHXhBptT9ri P0xRDqytbK9FAmIQMjn0gVuRBA6FhHhalh59FrcimXT/DyEj3TjsW2iD IsQ= ns2.ic.ac.uk. 86400 IN RRSIG A 5 4 86400 20120804065011 20120705063843 4743 ic.ac.uk. IQ9KZAqCZLRpDwSpFpwor5ru7ltRfgBkFITKVs5ICz0fGrMQ9uWeWVY2 CLNVmPeXtMseId7Y67+CM4q2Zu+zfBtSiLlDbbqD13FnSdmjqLCHF4PG 7UVW1Z9uqjSHndKuuXeihNUSogyDZyoqf1b4SRcmRwOjgsM7HX0gWy87 jBs= ;; Query time: 451 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 20 07:24:59 2012 ;; MSG SIZE rcvd: 1466 ...and you should see: ; -HEADER- opcode: QUERY, status: NOERROR, id: 18199 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 11 Note the ad flag - authenticated data. Yup, I did see that. The problem here seems to be fragmented UDP. I only ever receive the first fragment. Since I am tcpdumping on the external interface of my router, I know it's not my router dropping it (which does have an iptables policy installed, but tcpdump happens before iptables AFAIU; that is you see *everything* with tcpdump, even on an interface where iptables is set to drop traffic). I can only assume it's my ISP or something upstream. I am able to receive fragmented ICMP however. For example: $ ping -M want -s 3000 74.125.226.17 PING 74.125.226.17 (74.125.226.17) 3000(3028) bytes of data. 3008 bytes from 74.125.226.17: icmp_req=1 ttl=58 time=29.1 ms 3008 bytes from 74.125.226.17: icmp_req=2 ttl=58 time=28.2 ms 3008 bytes from 74.125.226.17: icmp_req=3 ttl=58 time=28.6 ms 3008 bytes from 74.125.226.17: icmp_req=4 ttl=58 time=29.0 ms 3008 bytes from 74.125.226.17: icmp_req=5 ttl=58 time=29.9 ms 3008 bytes from 74.125.226.17: icmp_req=6 ttl=58 time=28.8
Re: named validating @0x...: ... SOA: no valid signature found
On 12-07-20 08:34 AM, Brian J. Murrell wrote: The problem here seems to be fragmented UDP. I seem to have misdiagnosed this due to tcpdump peculiarities. I only initially saw/suspected the problem since my capture for port 53 packets was including (only the first) ipv4 fragments. When adding a capture specifically to get all ipv4 fragments in addition to my port 53 packets, I do see all of the fragments. So back to the drawing board. In my previous posting, I was able to demonstrate that I do get some queries authenticated, but others (corresponding to the errors in my logs) are not. For example: Jul 20 08:59:37 linux named[17472]: validating @0xf48d01b0: 119.in-addr.arpa SOA: no valid signature found and sure enough: # dig +dnssec @localhost 119.in-addr.arpa SOA ; DiG 9.9.1-P1 +dnssec @localhost 119.in-addr.arpa SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 49713 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;119.in-addr.arpa. IN SOA ;; ANSWER SECTION: 119.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 3006082431 7200 1800 604800 172800 119.in-addr.arpa. 172800 IN RRSIG SOA 5 3 172800 20120819055026 20120720045026 31291 119.in-addr.arpa. DxSB8J+SsHzLRv/qiFdQOLQ4eYEgCm6lUGr5/qoMje7iY9OIaaXmH/WM GwbTDdT7YNXfkZ7ZfpEnE5N9OeNW6Wghi8Wcerpy3OmEYMTWc1ZNgH70 KC8Rhth23mCkv+IdCEsirVKdgTgLYsRlPFMbp6WQveMQRyJwvGJQm4QI Ejk= ;; AUTHORITY SECTION: 119.in-addr.arpa. 78212 IN NS ns1.apnic.net. 119.in-addr.arpa. 78212 IN NS sec1.authdns.ripe.net. 119.in-addr.arpa. 78212 IN NS ns2.lacnic.net. 119.in-addr.arpa. 78212 IN NS ns4.apnic.net. 119.in-addr.arpa. 78212 IN NS ns3.apnic.net. 119.in-addr.arpa. 78212 IN NS apnic1.dnsnode.net. 119.in-addr.arpa. 78212 IN NS tinnie.arin.net. ;; ADDITIONAL SECTION: ns1.apnic.net. 167 IN A 202.12.29.25 ns1.apnic.net. 164129 IN 2001:dc0:2001:0:4608::25 ns2.lacnic.net. 82967 IN A 200.3.13.11 ns2.lacnic.net. 164257 IN 2001:13c7:7002:3000::11 ns3.apnic.net. 167 IN A 202.12.28.131 ns3.apnic.net. 164129 IN 2001:dc0:1:0:4777::131 ns4.apnic.net. 167 IN A 202.12.31.140 ns4.apnic.net. 164129 IN 2001:dc0:4001:1:0:1836:0:140 sec1.authdns.ripe.net. 167 IN A 193.0.9.3 apnic1.dnsnode.net. 3767IN A 194.146.106.106 tinnie.arin.net.35918 IN A 199.212.0.53 tinnie.arin.net.35918 IN 2001:500:13::c7d4:35 sec1.authdns.ripe.net. 167 IN RRSIG A 5 4 3600 20120819100246 20120720090246 16848 ripe.net. PnInozslOygv30AuohnYIzlCkeShxybKYeZ4114kpClfsMB/t3liXNmw in7Ha8Mh1mOZFtv2lvYDNlnrZgO65xXkUwsH2iz1jCMFU6ZjwGhqVhaX PpN6T6BXDHSohpFkVlx0yu9J7BcPMuCD6FJB5yLF4V0UUkJoPOXFAKBa mto= ;; Query time: 239 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 20 09:02:18 2012 ;; MSG SIZE rcvd: 892 no ad bit set. But why? Cheers, b. signature.asc Description: OpenPGP digital signature ___ 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: named validating @0x...: ... SOA: no valid signature found
On 20/07/12 14:03, Brian J. Murrell wrote: # dig +dnssec @localhost 119.in-addr.arpa SOA ; DiG 9.9.1-P1 +dnssec @localhost 119.in-addr.arpa SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 49713 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14 What do you see if you: 1. Clear the cache 2. Start tcpdump 3. Do this query Presumably there is a failing DNS query somewhere underlying this. Or, what happens if you start bind up in debug mode and run the query? There will be a lot of output, but I've found most problems to be fairly obvious if you read through it. ___ 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: named validating @0x...: ... SOA: no valid signature found
In message 50095065.3050...@interlinx.bc.ca, Brian J. Murrell writes: On 12-05-15 09:01 AM, Phil Mayers wrote: =20 Sorry about the way delayed response. There seems to be some confusion about which list/group gmane is following. =20 Isn't it more likely it's a local problem? Indeed. But what, is the question (and I do have the answer, now -- see below). Which version of bind are you running? I was running 9.8.3 and now 9.9.1-P1 Does *any* zone validate Yes. e.g. try: =20 dig +dnssec @localhost www.ic.ac.uk # dig +dnssec @localhost www.ic.ac.uk ; DiG 9.9.1-P1 +dnssec @localhost www.ic.ac.uk ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 725 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 5, ADDITIONAL: 13 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.ic.ac.uk. IN A ;; ANSWER SECTION: www.ic.ac.uk. 3600IN A 155.198.140.14 www.ic.ac.uk. 3600IN RRSIG A 5 4 3600 20120812165527= 20120713164639 4743 ic.ac.uk. UZDw0aM0xPFXAmb5/PReP8hSWR/eNmMA479JFoZyHm= xRrepTaJWLya+R 1F2Y2LI/T12QlFkw09KBsgZo+hGr2MWfPyMAjNttzDLCqGM7dDNBUnuz H= 4G7DUnTvpnIV3VcLHqIh2z+j5ZmBb4+O4MIbNbBh8reVIacM8jgGNPH Evs=3D ;; AUTHORITY SECTION: ic.ac.uk. 86400 IN NS ns1.ic.ac.uk. ic.ac.uk. 86400 IN NS authdns1.csx.cam.ac.uk. ic.ac.uk. 86400 IN NS ns2.ic.ac.uk. ic.ac.uk. 86400 IN NS ns0.ic.ac.uk. ic.ac.uk. 86400 IN RRSIG NS 5 3 86400 201208062130= 24 20120707210235 4743 ic.ac.uk. AYa7xE/1ZDMvt0c1wGY/+eu4vgbJm4EV+i+1YYZh= tLu44bdnHndfptNZ ECxeOI8JVeaKUq1zPspK9UnTCLFDkfCq9cIVFjZhpHQSPHtd3Vss40Vl= gKrOG6qm4RfmPbLaUDKxu/LsR/W+iRbbiwI2fsso34BTUJeKPZGwqHPG j9k=3D ;; ADDITIONAL SECTION: ns0.ic.ac.uk. 86400 IN A 155.198.142.80 ns0.ic.ac.uk. 86400 IN 2001:630:12:600:1::80 ns1.ic.ac.uk. 86400 IN A 155.198.142.81 ns1.ic.ac.uk. 86400 IN 2001:630:12:600:1::81 ns2.ic.ac.uk. 86400 IN A 155.198.142.82 authdns1.csx.cam.ac.uk. 86400 IN A 131.111.12.37 authdns1.csx.cam.ac.uk. 86400 IN 2001:630:212:12::d:a1 ns0.ic.ac.uk. 86400 IN RRSIG A 5 4 86400 2012080716470= 6 20120708162343 4743 ic.ac.uk. SDz7qZbq+O/SMopAP4L1W9QeeuJu6+vBW25h4WIoD= mFgXb+OPx3/M/6H 6pBFUpO2XoBfurRHly0r2yy7C4x3X7vth8nT9Xo16ZL9nauYwbUIM3f3 = zDECyEzrkPf8EDcwRYycOJfcKcAlxG0FiPBav+WJW8PNMR43YAsr6w5D ZLU=3D ns0.ic.ac.uk. 300 IN RRSIG 5 4 300 201208091427= 48 20120710132748 4743 ic.ac.uk. U+LTVkUNoTWXNTabEd/rt15qze4iLWhDFyw+inaY= gToGxYA5y3JS+fnx qfe2+GUFSLOz/Xo6czEe7728vCLgXzLQckAyS3g56NUfHKyXO1WWa6lQ= k1r9UoNOSj5vTu0YLQN1FgP4aSFjowZzeQtbX//aDXZEVHKjNz4UFwBA zPs=3D ns1.ic.ac.uk. 86400 IN RRSIG A 5 4 86400 2012081601565= 7 20120717011404 4743 ic.ac.uk. dFRwdOkf670aLyyLtnLAYwo18XQGIFgT8YWQukrsj= 514pINSR5WUkcpd ReUOGLy9+RDEfpWwDsvdp1DLrxbUzElTF5Qkg/1d76qqB6WxmnQq6lqz = r5zKgfh9GNZHKrAOzvLcxlUFhd2xm1NXjktjIhb6CLH+qrJRR9h9+Zxy MlQ=3D ns1.ic.ac.uk. 300 IN RRSIG 5 4 300 201208091427= 48 20120710132748 4743 ic.ac.uk. OBSX8EyrqDcE6QzArCOaecx3Rf5fuBqfMctc/6M+= 3SnCHqQ9Dzp0YZly 2f6OJXu2JCrR4lGEUfgnA8rXDCKLgkzVIWFZi4y0GVuY2VHXhBptT9ri= P0xRDqytbK9FAmIQMjn0gVuRBA6FhHhalh59FrcimXT/DyEj3TjsW2iD IsQ=3D ns2.ic.ac.uk. 86400 IN RRSIG A 5 4 86400 2012080406501= 1 20120705063843 4743 ic.ac.uk. IQ9KZAqCZLRpDwSpFpwor5ru7ltRfgBkFITKVs5IC= z0fGrMQ9uWeWVY2 CLNVmPeXtMseId7Y67+CM4q2Zu+zfBtSiLlDbbqD13FnSdmjqLCHF4PG = 7UVW1Z9uqjSHndKuuXeihNUSogyDZyoqf1b4SRcmRwOjgsM7HX0gWy87 jBs=3D ;; Query time: 451 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 20 07:24:59 2012 ;; MSG SIZE rcvd: 1466 =20 ...and you should see: =20 ; -HEADER- opcode: QUERY, status: NOERROR, id: 18199 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 1= 1 =20 Note the ad flag - authenticated data. Yup, I did see that. The problem here seems to be fragmented UDP. I only ever receive the first fragment. Since I am tcpdumping on the external interface of my router, I know it's not my router dropping it (which does have an iptables policy installed, but tcpdump happens before iptables AFAIU; that is you see *everything* with tcpdump, even on an interface where iptables is set to drop traffic). I can only assume it's my ISP or something upstream. They are most probably permitting the responses based on the UDP ports but as the fragments don't have the UDP header they are dropped. pass udp from any to any frag or similar is needed. All ICMP fragments have ICMP in the protocol field of the the IP header so if the firewall permits all ICMP they just
Re: named validating @0x...: ... SOA: no valid signature found
On Fri, Jul 20, 2012 at 6:03 AM, Brian J. Murrell br...@interlinx.bc.cawrote: On 12-07-20 08:34 AM, Brian J. Murrell wrote: The problem here seems to be fragmented UDP. I seem to have misdiagnosed this due to tcpdump peculiarities. I only initially saw/suspected the problem since my capture for port 53 packets was including (only the first) ipv4 fragments. When adding a capture specifically to get all ipv4 fragments in addition to my port 53 packets, I do see all of the fragments. Just because you see the fragments on the wire doesn't mean they're getting past the local firewall and being reassembled. For example, if you're using ip6tables on a Linux kernel = 2.6.20 IPv6 fragments aren't allowed through properly [1]. What OS/kernel are you using? Casey [1] See https://dnssec.surfnet.nl/?p=464 ___ 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: named validating @0x...: ... SOA: no valid signature found
On 12-07-20 09:11 AM, Phil Mayers wrote: Or, what happens if you start bind up in debug mode and run the query? There will be a lot of output, but I've found most problems to be fairly obvious if you read through it. Yeah, there is a lot of output. Too big of a haystack for me to find the needle I'm afraid. I probably had way too much debug enabled. I'd be happy to trim it back if desired. Just tell me which categories you'd want to see and what severity to set. In any case, the log is at http://brian.interlinx.bc.ca/119.in-addr.arpa.debug and the query I did was: dig +dnssec @localhost 119.in-addr.arpa SOA The log should be as brief as it can be as I started named, did the query and waited for the response and then stopped bind. Just for good measure, since I think I have posted this before, but here are the options I have set in my bind configuration with regard to dnssec: dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; Cheers, b. signature.asc Description: OpenPGP digital signature ___ 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: named validating @0x...: ... SOA: no valid signature found
In message jubkum$qve$1...@dough.gmane.org, Brian J. Murrell writes: On 12-07-20 08:34 AM, Brian J. Murrell wrote: =20 The problem here seems to be fragmented UDP. I seem to have misdiagnosed this due to tcpdump peculiarities. I only initially saw/suspected the problem since my capture for port 53 packets was including (only the first) ipv4 fragments. When adding a capture specifically to get all ipv4 fragments in addition to my port 53 packets, I do see all of the fragments. So back to the drawing board. In my previous posting, I was able to demonstrate that I do get some queries authenticated, but others (corresponding to the errors in my logs) are not. For example: Jul 20 08:59:37 linux named[17472]: validating @0xf48d01b0: 119.in-addr= =2Earpa SOA: no valid signature found and sure enough: # dig +dnssec @localhost 119.in-addr.arpa SOA ; DiG 9.9.1-P1 +dnssec @localhost 119.in-addr.arpa SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 49713 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;119.in-addr.arpa. IN SOA ;; ANSWER SECTION: 119.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-txt-r= ecord-of-zone-first-dns-admin.apnic.net. 3006082431 7200 1800 604800 1728= 00 119.in-addr.arpa. 172800 IN RRSIG SOA 5 3 172800 2012081905= 5026 20120720045026 31291 119.in-addr.arpa. DxSB8J+SsHzLRv/qiFdQOLQ4eYEgC= m6lUGr5/qoMje7iY9OIaaXmH/WM GwbTDdT7YNXfkZ7ZfpEnE5N9OeNW6Wghi8Wcerpy3OmEY= MTWc1ZNgH70 KC8Rhth23mCkv+IdCEsirVKdgTgLYsRlPFMbp6WQveMQRyJwvGJQm4QI Ejk=3D= ;; AUTHORITY SECTION: 119.in-addr.arpa. 78212 IN NS ns1.apnic.net. 119.in-addr.arpa. 78212 IN NS sec1.authdns.ripe.net. 119.in-addr.arpa. 78212 IN NS ns2.lacnic.net. 119.in-addr.arpa. 78212 IN NS ns4.apnic.net. 119.in-addr.arpa. 78212 IN NS ns3.apnic.net. 119.in-addr.arpa. 78212 IN NS apnic1.dnsnode.net. 119.in-addr.arpa. 78212 IN NS tinnie.arin.net. ;; ADDITIONAL SECTION: ns1.apnic.net. 167 IN A 202.12.29.25 ns1.apnic.net. 164129 IN 2001:dc0:2001:0:4608::25 ns2.lacnic.net. 82967 IN A 200.3.13.11 ns2.lacnic.net. 164257 IN 2001:13c7:7002:3000::11 ns3.apnic.net. 167 IN A 202.12.28.131 ns3.apnic.net. 164129 IN 2001:dc0:1:0:4777::131 ns4.apnic.net. 167 IN A 202.12.31.140 ns4.apnic.net. 164129 IN 2001:dc0:4001:1:0:1836:0:= 140 sec1.authdns.ripe.net. 167 IN A 193.0.9.3 apnic1.dnsnode.net. 3767IN A 194.146.106.106 tinnie.arin.net.35918 IN A 199.212.0.53 tinnie.arin.net.35918 IN 2001:500:13::c7d4:35 sec1.authdns.ripe.net. 167 IN RRSIG A 5 4 3600 20120819100246= 20120720090246 16848 ripe.net. PnInozslOygv30AuohnYIzlCkeShxybKYeZ4114kp= ClfsMB/t3liXNmw in7Ha8Mh1mOZFtv2lvYDNlnrZgO65xXkUwsH2iz1jCMFU6ZjwGhqVhaX = PpN6T6BXDHSohpFkVlx0yu9J7BcPMuCD6FJB5yLF4V0UUkJoPOXFAKBa mto=3D ;; Query time: 239 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 20 09:02:18 2012 ;; MSG SIZE rcvd: 892 no ad bit set. But why? The NS RRset is the delegation records and as such has no RRSIGs. If you turn on minimal-responses the NS rrset won't be added and AD won't be cleared. AD is only set to 1 if all the records in the answer and authority sections are marked as secure. Cheers, b. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: named validating @0x...: ... SOA: no valid signature found
On 12-07-20 10:42 AM, Mark Andrews wrote: The NS RRset is the delegation records and as such has no RRSIGs. If you turn on minimal-responses the NS rrset won't be added and AD won't be cleared. AD is only set to 1 if all the records in the answer and authority sections are marked as secure. OK. So I added: minimal-responses yes; and the dig response does indeed look much more minimal, but the ad bit is still not being set: # dig +dnssec @localhost 119.in-addr.arpa SOA ; DiG 9.9.1-P1 +dnssec @localhost 119.in-addr.arpa SOA ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 45253 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;119.in-addr.arpa. IN SOA ;; ANSWER SECTION: 119.in-addr.arpa. 172800 IN SOA ns1.apnic.net. read-txt-record-of-zone-first-dns-admin.apnic.net. 3006082431 7200 1800 604800 172800 119.in-addr.arpa. 172800 IN RRSIG SOA 5 3 172800 20120819055026 20120720045026 31291 119.in-addr.arpa. DxSB8J+SsHzLRv/qiFdQOLQ4eYEgCm6lUGr5/qoMje7iY9OIaaXmH/WM GwbTDdT7YNXfkZ7ZfpEnE5N9OeNW6Wghi8Wcerpy3OmEYMTWc1ZNgH70 KC8Rhth23mCkv+IdCEsirVKdgTgLYsRlPFMbp6WQveMQRyJwvGJQm4QI Ejk= ;; Query time: 720 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri Jul 20 10:50:21 2012 ;; MSG SIZE rcvd: 310 Strangely I didn't get an error logged about there being no valid signature for 119.in-addr.arpa SOA though. Cheers, b. signature.asc Description: OpenPGP digital signature ___ 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: named validating @0x...: ... SOA: no valid signature found
On 20/07/12 15:33, Brian J. Murrell wrote: On 12-07-20 09:11 AM, Phil Mayers wrote: Or, what happens if you start bind up in debug mode and run the query? There will be a lot of output, but I've found most problems to be fairly obvious if you read through it. Yeah, there is a lot of output. Too big of a haystack for me to find the needle I'm afraid. I probably had way too much debug enabled. I'd be happy to trim it back if desired. Just tell me which categories you'd want to see and what severity to set. In any case, the log is at http://brian.interlinx.bc.ca/119.in-addr.arpa.debug and the query I did was: A quick skim suggests that you aren't able to validate the root, but are able to validate DLV, which is why a subset of sites are working - those still with DLV entries. If you can validate www.ic.ac.uk but not www.cam.ac.uk (who have now left DLV) then this might confirm it. No idea why the root isn't valid for you, given you are running a recent bind - presumably the managed-keys config is messed up somehow. Have you tried a clean install; blow away the entire /var/named and config hierarchy and start again? ___ 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: named validating @0x...: ... SOA: no valid signature found
In message 50096c2b.1080...@interlinx.bc.ca, Brian J. Murrell writes:
Just for good measure, since I think I have posted this before, but here
are the options I have set in my bind configuration with regard to dnssec=
:
dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;
Turn on validation using the root's DNSKEY.
auto-dnssec maintian;
or
managed-keys {
. initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=;
};
Currently you are only using DLV and 119.in-addr.arpa and parent zones
are not in the DLV registry.
Cheers,
b.
--enig5965E6494F1E722963B87E50
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAJbCwACgkQl3EQlGLyuXBbywCcDYbboiJuyhXfP9AuztJjJana
ZhcAoNgNAIdBwEbR9ZjpHTl7S9xlZrSB
=CrUS
-END PGP SIGNATURE-
--enig5965E6494F1E722963B87E50--
--===7481589219356167105==
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
___
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
--===7481589219356167105==--
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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: named validating @0x...: ... SOA: no valid signature found
On 20/07/12 16:21, Mark Andrews wrote: In message 50096c2b.1080...@interlinx.bc.ca, Brian J. Murrell writes: Just for good measure, since I think I have posted this before, but here are the options I have set in my bind configuration with regard to dnssec= : dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; FWIW, on 9.8 the only other line we have (for reasons of permissions) is: managed-keys-directory /var/named/data/dynamic; I don't see why those 3 lines aren't sufficient for him? Turn on validation using the root's DNSKEY. auto-dnssec maintian; I thought that was for master zones, not recursion/validation? Or am I missing something? ___ 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: named validating @0x...: ... SOA: no valid signature found
In message 500978a5.4070...@imperial.ac.uk, Phil Mayers writes: On 20/07/12 16:21, Mark Andrews wrote: In message 50096c2b.1080...@interlinx.bc.ca, Brian J. Murrell writes: Just for good measure, since I think I have posted this before, but here are the options I have set in my bind configuration with regard to dnssec= : dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; FWIW, on 9.8 the only other line we have (for reasons of permissions) is: managed-keys-directory /var/named/data/dynamic; I don't see why those 3 lines aren't sufficient for him? Turn on validation using the root's DNSKEY. auto-dnssec maintian; I thought that was for master zones, not recursion/validation? Or am I missing something? My bad. dnssec-validation auto; is what I was thinking about. ___ 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: named validating @0x...: ... SOA: no valid signature found
In message 500985c0.3000...@interlinx.bc.ca, Brian J. Murrell writes: On 12-07-20 11:40 AM, Mark Andrews wrote: =20 In message 500978a5.4070...@imperial.ac.uk, Phil Mayers writes: On 20/07/12 16:21, Mark Andrews wrote: In message 50096c2b.1080...@interlinx.bc.ca, Brian J. Murrell wri= tes: Just for good measure, since I think I have posted this before, but = here are the options I have set in my bind configuration with regard to d= nssec=3D : dnssec-enable yes; dnssec-validation yes; dnssec-lookaside auto; =20 My bad. dnssec-validation auto; is what I was thinking about. Interesting. Is auto for that value different/better than yes, which I have configured already? Cheers, b. dnssec-validation auto; tells named to use the compiled in root key in addition to enabling validation. Depending on the version this is a plain trusted-key or a managed-key. If NS_SYSCONFDIR/bind.keys exists and is readable its contents override the built in contents. The root key(s) and dlv.isc.org key(s) are loaded from this file for dnssec-validation auto; and dnssec-lookaside auto; respectively. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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: named validating @0x...: ... SOA: no valid signature found
On 12-05-02 09:29 AM, Mark Andrews wrote: * a firewall blocking EDNS queries. * using a non DNSSEC enabled forwarder so you don't get signatures. * a firewall blocking fragmented UDP and named falling back to plain DNS. * other packet loss causing named to fallback to plain DNS. Given that I have confirmed EDNS works with: dig edns-v4-ok.isc.org TXT dig edns-v6-ok.isc.org TXT and that I don't have a firewall that would/should be dropping (properly) fragmented UDP[1] and I have no other indications of packet loss, are we looking at a bug in BIND9 to explain this (mis-)behavior? Cheers, b. [1] I'd be happy to test and provide evidence if anyone has a test that will do so. Perhaps a dig command targeted at one of the many failures that my logs are constantly showing? signature.asc Description: OpenPGP digital signature ___ 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: named validating @0x...: ... SOA: no valid signature found
On 15/05/12 13:22, Brian J. Murrell wrote: On 12-05-02 09:29 AM, Mark Andrews wrote: * a firewall blocking EDNS queries. * using a non DNSSEC enabled forwarder so you don't get signatures. * a firewall blocking fragmented UDP and named falling back to plain DNS. * other packet loss causing named to fallback to plain DNS. Given that I have confirmed EDNS works with: dig edns-v4-ok.isc.org TXT dig edns-v6-ok.isc.org TXT and that I don't have a firewall that would/should be dropping (properly) fragmented UDP[1] and I have no other indications of packet loss, are we looking at a bug in BIND9 to explain this (mis-)behavior? Isn't it more likely it's a local problem? Which version of bind are you running? Does *any* zone validate e.g. try: dig +dnssec @localhost www.ic.ac.uk ...and you should see: ; -HEADER- opcode: QUERY, status: NOERROR, id: 18199 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 11 Note the ad flag - authenticated data. ___ 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: named validating @0x...: ... SOA: no valid signature found
On 12-05-02 09:29 AM, Mark Andrews wrote:
The zones are signed. Possible reason are:
* a firewall blocking EDNS queries.
This shouldn't be the case. Outgoing traffic from the bind9 server
being used here should be completely unfettered.
* using a non DNSSEC enabled forwarder so you don't get signatures.
I believe my forwarder (bind9 server) is DNSSEC enabled:
options {
...
// enable DNSSEC
dnssec-enable yes;
dnssec-validation yes;
// as of 9.7, use auto instead
// dnssec-lookaside . trust-anchor dlv.isc.org.;
dnssec-lookaside auto;
};
* a firewall blocking fragmented UDP and named falling back to
plain DNS.
Again, the firewall should be allowing bind9 to do whatever it wants.
* other packet loss causing named to fallback to plain DNS.
I'm not seeing any evidence of that here otherwise.
Can you prescribe any tests that I can do to [dis-]prove any of the
above theories?
Cheers and much thanks,
b.
signature.asc
Description: OpenPGP digital signature
___
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: named validating @0x...: ... SOA: no valid signature found
In message jnrabn$olm$1...@dough.gmane.org, Brian J. Murrell writes: Not having dipped my toe into DNSSEC yet (yes, I know, but time is always so scarce)... So I am seeing a bunch of this sort of thing in my BIND logs now: 04:02:18 named validating @0xb0f58988: 124.in-addr.arpa SOA: no valid sig= nature found 04:02:18 named validating @0xb0f58988: 124.in-addr.arpa NSEC: no valid si= gnature found 04:02:18 named validating @0xb0f58988: 227.124.in-addr.arpa NSEC: no vali= d signature found 04:03:30 named validating @0xb0f58988: net SOA: no valid signature found 04:03:30 named validating @0xb0f58988: a1rt98bs5qgc9nfi51s9hci47uljg6jh.n= et NSEC3: no valid signature found 04:03:30 named validating @0xb0f58988: 5VI63OJ105LD6R767I45IDJR5Q55T1R1.n= et NSEC3: no valid signature found 04:03:30 named validating @0xb0f58988: EEE0K4ONQCCHCJQTQ5VJD52NKJTEHAJN.n= et NSEC3: no valid signature found 04:03:30 named validating @0xb0f4d8c0: uk SOA: no valid signature found 04:03:30 named validating @0xb21ea7c0: u1fmklfv3rdcnamdc64sekgcdp05bbiu.u= k NSEC3: no valid signature found 04:03:30 named validating @0xb0f67990: pl SOA: no valid signature found 04:03:30 named validating @0xb18914a0: RVLFSE0643QVHS3RI8VPKGANFBCJVJ06.p= l NSEC3: no valid signature found 04:03:31 named validating @0xb0f949d0: GSV9U2BOSCL9B9TQAL1UAV4BNVI9EVUE.p= l NSEC3: no valid signature found 04:03:31 named validating @0xb21cc520: org SOA: no valid signature found 04:03:31 named validating @0xb18f2c08: org SOA: no valid signature found 04:03:31 named validating @0xb21ea7c0: fk47636n6psb8mv7rdu6tpdhas69cbjp.o= rg NSEC3: no valid signature found 04:03:31 named validating @0xb0fe6528: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o= rg NSEC3: no valid signature found 04:03:31 named validating @0xb0f61960: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o= rg NSEC3: no valid signature found 04:03:31 named validating @0xb21cc520: 4rkhv4s4situ82j70sp5tq5utm12o2t8.o= rg NSEC3: no valid signature found 04:03:31 named validating @0xb18f2c08: ic8a82pge1m0qdob5sce1e3613hqr7br.o= rg NSEC3: no valid signature found 04:03:31 named validating @0xb0f949d0: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o= rg NSEC3: no valid signature found 04:03:31 named validating @0xb0f949d0: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o= rg NSEC3: no valid signature found 04:03:31 named validating @0xb0f949d0: org SOA: no valid signature found 04:03:31 named validating @0xb18914a0: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o= rg NSEC3: no valid signature found 04:03:31 named validating @0xb21e1518: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o= rg NSEC3: no valid signature found 04:09:43 named validating @0xb0f58988: 117.in-addr.arpa SOA: no valid sig= nature found 04:09:43 named validating @0xb0f58988: 117.in-addr.arpa NSEC: no valid si= gnature found 04:09:43 named validating @0xb0f58988: 240.117.in-addr.arpa NSEC: no vali= d signature found 04:13:52 named validating @0xb0f58988: 27.in-addr.arpa SOA: no valid sign= ature found 04:13:52 named validating @0xb0f58988: 22.115.27.in-addr.arpa NSEC: no va= lid signature found 04:13:52 named validating @0xb0f58988: 99.114.27.in-addr.arpa NSEC: no va= lid signature found 04:15:16 named validating @0xb0f58988: 117.in-addr.arpa SOA: no valid sig= nature found 04:15:16 named validating @0xb0f58988: 117.in-addr.arpa NSEC: no valid si= gnature found 04:15:16 named validating @0xb0f58988: 99.20.117.in-addr.arpa NSEC: no va= lid signature found 04:15:48 named validating @0xb0f58988: org SOA: no valid signature found 04:15:48 named validating @0xb0f58988: h9p7u7tr2u91d0v0ljs9l1gidnp90u3h.o= rg NSEC3: no valid signature found 04:15:48 named validating @0xb0f58988: osfek8jf3dv7trcfcuheumjh9bpmjkeq.o= rg NSEC3: no valid signature found 04:15:48 named validating @0xb0f58988: vai6s58iqmjmin7ju8mq61aju3q4ms5h.o= rg NSEC3: no valid signature found And am wondering what they are really telling me. Are they all different flavours of zone is not signed or are they more like zone is supposed to be signed but there are problems with it? Cheers, b. The zones are signed. Possible reason are: * a firewall blocking EDNS queries. * using a non DNSSEC enabled forwarder so you don't get signatures. * a firewall blocking fragmented UDP and named falling back to plain DNS. * other packet loss causing named to fallback to plain DNS. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ 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
