Re: [Dnsmasq-discuss] bugs.gentoo.org and dnssec
Hello Simon, thank you very much for looking into that. I can confirm that "dig ANY ipfire.org" is now correctly falling back to TCP and validates the result correctly. I passed a compiled binary on to the people who experienced the bug as well. If you do not hear back from me things should be fine. Best, -Michael On Tue, 2015-04-28 at 20:59 +0100, Simon Kelley wrote: > OK, that was an embarrassingly simple fix, in the git repo now, or the > 2.73rc7 tarball if you prefer. > > Interestingly, > > dig ANY ipfire.org > > to 8.8.8.8 gets an answer which fits a UDP packet, and therefore > doesn't trigger the bug. > > 178.63.73.246 does fall back to TCP, as your example shows, and does > trigger the problem. > > I'm not sure is this is relevant to Alon's problem, since the query > he's making has a small answer that doesn't trigger fallback to TCP, > though with DNSSEC information included, the answer is 1244 bytes, so > it _could_ trigger TCP on some links. > > It would be useful to test with 2.73rc7 Alon, if you can. > > > Many thanks for the tests and info. > > Cheers, > > Simon. > > On 28/04/15 13:00, Michael Tremer wrote: > > Hello, > > > > I am not sure if I am experiencing the same bug here or if it is > > somewhat different. > > > > When I try accessing some domains that use DNSSEC (like ipfire.org > > does, but this applies to other as well), I sometimes get SERVFAIL. > > This happens usually for bigger replies where fragmentation comes > > into the game. > > > > I think that I do not have a general issue with fragmentation or > > some issue with the upstream name servers, because everything goes > > well if I send the same query directly without going through > > dnsmasq. See below. > > > > dig ANY ipfire.org returns a huge number of records with lots of > > signatures and can be used to reproduce the issue with various > > upstream name servers. dnsmasq receives a truncated DNS reply (it's > > over 4k) and opens a TCP connection. As soon as dnsmasq is using > > TCP, the answer to the local system that made the request is always > > SERVFAIL. > > > > It also happens with "dig ANY ietf.org", but works with "dig ANY > > postbank.de" which replies with a DNS packet less than 4k. > > > > Other people have reported the same and/or similar issue over > > here: https://bugzilla.ipfire.org/show_bug.cgi?id=10786 > > > > They confirm that the issue also happens with 8.8.8.8. > > > > I captured the packets that dnsmasq is sending out to the upstream > > name servers and attached the pcap file. > > > > What can we do about this problem? It essentially makes DNSSEC > > unusable at the moment. > > > > Best, -Michael > > > > + dig ANY ipfire.org ;; Truncated, retrying in TCP mode. > > > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ANY ipfire.org ;; > > global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, > > status: SERVFAIL, id: 43712 ;; flags: qr rd ra; QUERY: 1, ANSWER: > > 0, AUTHORITY: 0, ADDITIONAL: 1 > > > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; > > QUESTION SECTION: ;ipfire.org. IN ANY > > > > ;; Query time: 52 msec ;; SERVER: 192.168.180.1#53(192.168.180.1) > > ;; WHEN: Tue Apr 28 13:49:20 CEST 2015 ;; MSG SIZE rcvd: 39 > > > > + dig ANY ipfire.org @178.63.73.246 ;; Truncated, retrying in TCP > > mode. > > > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ANY ipfire.org > > @178.63.73.246 ;; global options: +cmd ;; Got answer: ;; > > ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30094 ;; flags: qr > > rd ra ad; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 3 > > > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; > > QUESTION SECTION: ;ipfire.org. IN ANY > > > > ;; ANSWER SECTION: ipfire.org. 3571IN A > > 178.63.73.246 ipfire.org. > > 3571IN RRSIG A 8 2 3600 2015050700 2015041600 38274 > > ipfire.org. > > AafVd/T/gKOD35lqZihS89u4aH0T4YcIN3uWGihlF6ZufWk05zs9XBBj > > 8SAzs5yTOACe7Hb6iNpAr7B4TNvcqCfbDTkGRcfptaIoUl2CbJ015KSd > > OB2pHQxzzsGvqFc609egjP6cP4uh8cIK4JZ4iLD5ldT23x76nPWzUx4N > > d+ErCfq/UiWvf1vfuxIRP18otagfyK5AEG3U7VBoIH1rYtPov7LwbFmp > > EMRa27xWD/bYcMueDk9ojfgnqKK6jXQ8RqHoXR7SRsjV/HyCb6hSuTBc > > g+R+gykb/r082jTzon8kJKCcC7t7TWEdLY2WH+h1I3FN+f3iNhHoal/J l5cA+g== > > ipfire.org. 48822 IN NS ns2.lightningwirelabs.com. > > ipfire.org. > > 48822 IN NS ns3.lightningwirelabs.com. ipfire.org. > > 48822 IN NS > > ns1.lightningwirelabs.com. ipfire.org. 48822 IN RRSIG > > NS 8 2 86400 > > 2015050700 2015041600 38274 ipfire.org. > > LtEwh5KQuMZOM9aQphrCiSJA7R6Ubv+A7ip+7S+NwfOLRC+Eao5I/MGw > > AXprSNvFglwKYyj/8hmAHkByRcniXceu5e9DPL8GZnRrJEaNmPyNgv+j > > bSIS4jD4FSrhS6LPQzAVg6XA5r9B1y9SDPiqgDm+e3fkD8zg+ZmJuY2x > > XYw9JeV1c4pZVCjS6jflkZ/9LcZrNGjcDuNZxQCSFu3wD/fmxbJXfKZN > > e4zO8XE18Ul1c7ifGLLRM45MyedQK/Gz47KXCkC0zkVtmRPy
Re: [Dnsmasq-discuss] bugs.gentoo.org and dnssec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 OK, that was an embarrassingly simple fix, in the git repo now, or the 2.73rc7 tarball if you prefer. Interestingly, dig ANY ipfire.org to 8.8.8.8 gets an answer which fits a UDP packet, and therefore doesn't trigger the bug. 178.63.73.246 does fall back to TCP, as your example shows, and does trigger the problem. I'm not sure is this is relevant to Alon's problem, since the query he's making has a small answer that doesn't trigger fallback to TCP, though with DNSSEC information included, the answer is 1244 bytes, so it _could_ trigger TCP on some links. It would be useful to test with 2.73rc7 Alon, if you can. Many thanks for the tests and info. Cheers, Simon. On 28/04/15 13:00, Michael Tremer wrote: > Hello, > > I am not sure if I am experiencing the same bug here or if it is > somewhat different. > > When I try accessing some domains that use DNSSEC (like ipfire.org > does, but this applies to other as well), I sometimes get SERVFAIL. > This happens usually for bigger replies where fragmentation comes > into the game. > > I think that I do not have a general issue with fragmentation or > some issue with the upstream name servers, because everything goes > well if I send the same query directly without going through > dnsmasq. See below. > > dig ANY ipfire.org returns a huge number of records with lots of > signatures and can be used to reproduce the issue with various > upstream name servers. dnsmasq receives a truncated DNS reply (it's > over 4k) and opens a TCP connection. As soon as dnsmasq is using > TCP, the answer to the local system that made the request is always > SERVFAIL. > > It also happens with "dig ANY ietf.org", but works with "dig ANY > postbank.de" which replies with a DNS packet less than 4k. > > Other people have reported the same and/or similar issue over > here: https://bugzilla.ipfire.org/show_bug.cgi?id=10786 > > They confirm that the issue also happens with 8.8.8.8. > > I captured the packets that dnsmasq is sending out to the upstream > name servers and attached the pcap file. > > What can we do about this problem? It essentially makes DNSSEC > unusable at the moment. > > Best, -Michael > > + dig ANY ipfire.org ;; Truncated, retrying in TCP mode. > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ANY ipfire.org ;; > global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, > status: SERVFAIL, id: 43712 ;; flags: qr rd ra; QUERY: 1, ANSWER: > 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; > QUESTION SECTION: ;ipfire.org.IN ANY > > ;; Query time: 52 msec ;; SERVER: 192.168.180.1#53(192.168.180.1) > ;; WHEN: Tue Apr 28 13:49:20 CEST 2015 ;; MSG SIZE rcvd: 39 > > + dig ANY ipfire.org @178.63.73.246 ;; Truncated, retrying in TCP > mode. > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ANY ipfire.org > @178.63.73.246 ;; global options: +cmd ;; Got answer: ;; > ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30094 ;; flags: qr > rd ra ad; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 3 > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; > QUESTION SECTION: ;ipfire.org.IN ANY > > ;; ANSWER SECTION: ipfire.org.3571IN A > 178.63.73.246 ipfire.org. > 3571 IN RRSIG A 8 2 3600 2015050700 2015041600 38274 > ipfire.org. > AafVd/T/gKOD35lqZihS89u4aH0T4YcIN3uWGihlF6ZufWk05zs9XBBj > 8SAzs5yTOACe7Hb6iNpAr7B4TNvcqCfbDTkGRcfptaIoUl2CbJ015KSd > OB2pHQxzzsGvqFc609egjP6cP4uh8cIK4JZ4iLD5ldT23x76nPWzUx4N > d+ErCfq/UiWvf1vfuxIRP18otagfyK5AEG3U7VBoIH1rYtPov7LwbFmp > EMRa27xWD/bYcMueDk9ojfgnqKK6jXQ8RqHoXR7SRsjV/HyCb6hSuTBc > g+R+gykb/r082jTzon8kJKCcC7t7TWEdLY2WH+h1I3FN+f3iNhHoal/J l5cA+g== > ipfire.org. 48822 IN NS ns2.lightningwirelabs.com. > ipfire.org. > 48822 IN NS ns3.lightningwirelabs.com. ipfire.org. 48822 > IN NS > ns1.lightningwirelabs.com. ipfire.org.48822 IN RRSIG > NS 8 2 86400 > 2015050700 2015041600 38274 ipfire.org. > LtEwh5KQuMZOM9aQphrCiSJA7R6Ubv+A7ip+7S+NwfOLRC+Eao5I/MGw > AXprSNvFglwKYyj/8hmAHkByRcniXceu5e9DPL8GZnRrJEaNmPyNgv+j > bSIS4jD4FSrhS6LPQzAVg6XA5r9B1y9SDPiqgDm+e3fkD8zg+ZmJuY2x > XYw9JeV1c4pZVCjS6jflkZ/9LcZrNGjcDuNZxQCSFu3wD/fmxbJXfKZN > e4zO8XE18Ul1c7ifGLLRM45MyedQK/Gz47KXCkC0zkVtmRPybQN9lT+1 > NKRQJFNc8U6+Hb90eQSjudsrXK0V2Z7McO5OMOe305loKWhvW8KMkc/b KIKnEw== > ipfire.org. 2310IN SOA ns1.lightningwirelabs.com. > hostmaster.ipfire.org. 1430190033 10800 1800 604800 300 ipfire.org. > 2310 IN RRSIG SOA 8 2 3600 2015050700 2015041600 38274 > ipfire.org. > C8pSowvYXE3sngaZrOaevrbMtx3f3hKKkgRW51gebWBokxF7+5UuXclb > 9pZm16ArrMeMIQhR0d14Wamn0yhsrIo8eqgPbjTdn9VzNZnpXXcsxAXu > QJ4+vPGP92EfgDocqid7/9jKeJWtNZbgHJUfOwsEtYgS+gdP3L77k+gW > EAypTHtJqiE65sFHUWXlb9kwmpr1trq5DXnVBwtiiaBhbYeZryY3MTkl > MVyQEZe
Re: [Dnsmasq-discuss] bugs.gentoo.org and dnssec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 That's very useful information, thanks. I'll chase through what's going on, and come back here. Cheers, Simon. On 28/04/15 13:00, Michael Tremer wrote: > Hello, > > I am not sure if I am experiencing the same bug here or if it is > somewhat different. > > When I try accessing some domains that use DNSSEC (like ipfire.org > does, but this applies to other as well), I sometimes get SERVFAIL. > This happens usually for bigger replies where fragmentation comes > into the game. > > I think that I do not have a general issue with fragmentation or > some issue with the upstream name servers, because everything goes > well if I send the same query directly without going through > dnsmasq. See below. > > dig ANY ipfire.org returns a huge number of records with lots of > signatures and can be used to reproduce the issue with various > upstream name servers. dnsmasq receives a truncated DNS reply (it's > over 4k) and opens a TCP connection. As soon as dnsmasq is using > TCP, the answer to the local system that made the request is always > SERVFAIL. > > It also happens with "dig ANY ietf.org", but works with "dig ANY > postbank.de" which replies with a DNS packet less than 4k. > > Other people have reported the same and/or similar issue over > here: https://bugzilla.ipfire.org/show_bug.cgi?id=10786 > > They confirm that the issue also happens with 8.8.8.8. > > I captured the packets that dnsmasq is sending out to the upstream > name servers and attached the pcap file. > > What can we do about this problem? It essentially makes DNSSEC > unusable at the moment. > > Best, -Michael > > + dig ANY ipfire.org ;; Truncated, retrying in TCP mode. > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ANY ipfire.org ;; > global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, > status: SERVFAIL, id: 43712 ;; flags: qr rd ra; QUERY: 1, ANSWER: > 0, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; > QUESTION SECTION: ;ipfire.org.IN ANY > > ;; Query time: 52 msec ;; SERVER: 192.168.180.1#53(192.168.180.1) > ;; WHEN: Tue Apr 28 13:49:20 CEST 2015 ;; MSG SIZE rcvd: 39 > > + dig ANY ipfire.org @178.63.73.246 ;; Truncated, retrying in TCP > mode. > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ANY ipfire.org > @178.63.73.246 ;; global options: +cmd ;; Got answer: ;; > ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30094 ;; flags: qr > rd ra ad; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 3 > > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; > QUESTION SECTION: ;ipfire.org.IN ANY > > ;; ANSWER SECTION: ipfire.org.3571IN A > 178.63.73.246 ipfire.org. > 3571 IN RRSIG A 8 2 3600 2015050700 2015041600 38274 > ipfire.org. > AafVd/T/gKOD35lqZihS89u4aH0T4YcIN3uWGihlF6ZufWk05zs9XBBj > 8SAzs5yTOACe7Hb6iNpAr7B4TNvcqCfbDTkGRcfptaIoUl2CbJ015KSd > OB2pHQxzzsGvqFc609egjP6cP4uh8cIK4JZ4iLD5ldT23x76nPWzUx4N > d+ErCfq/UiWvf1vfuxIRP18otagfyK5AEG3U7VBoIH1rYtPov7LwbFmp > EMRa27xWD/bYcMueDk9ojfgnqKK6jXQ8RqHoXR7SRsjV/HyCb6hSuTBc > g+R+gykb/r082jTzon8kJKCcC7t7TWEdLY2WH+h1I3FN+f3iNhHoal/J l5cA+g== > ipfire.org. 48822 IN NS ns2.lightningwirelabs.com. > ipfire.org. > 48822 IN NS ns3.lightningwirelabs.com. ipfire.org. 48822 > IN NS > ns1.lightningwirelabs.com. ipfire.org.48822 IN RRSIG > NS 8 2 86400 > 2015050700 2015041600 38274 ipfire.org. > LtEwh5KQuMZOM9aQphrCiSJA7R6Ubv+A7ip+7S+NwfOLRC+Eao5I/MGw > AXprSNvFglwKYyj/8hmAHkByRcniXceu5e9DPL8GZnRrJEaNmPyNgv+j > bSIS4jD4FSrhS6LPQzAVg6XA5r9B1y9SDPiqgDm+e3fkD8zg+ZmJuY2x > XYw9JeV1c4pZVCjS6jflkZ/9LcZrNGjcDuNZxQCSFu3wD/fmxbJXfKZN > e4zO8XE18Ul1c7ifGLLRM45MyedQK/Gz47KXCkC0zkVtmRPybQN9lT+1 > NKRQJFNc8U6+Hb90eQSjudsrXK0V2Z7McO5OMOe305loKWhvW8KMkc/b KIKnEw== > ipfire.org. 2310IN SOA ns1.lightningwirelabs.com. > hostmaster.ipfire.org. 1430190033 10800 1800 604800 300 ipfire.org. > 2310 IN RRSIG SOA 8 2 3600 2015050700 2015041600 38274 > ipfire.org. > C8pSowvYXE3sngaZrOaevrbMtx3f3hKKkgRW51gebWBokxF7+5UuXclb > 9pZm16ArrMeMIQhR0d14Wamn0yhsrIo8eqgPbjTdn9VzNZnpXXcsxAXu > QJ4+vPGP92EfgDocqid7/9jKeJWtNZbgHJUfOwsEtYgS+gdP3L77k+gW > EAypTHtJqiE65sFHUWXlb9kwmpr1trq5DXnVBwtiiaBhbYeZryY3MTkl > MVyQEZebr/MUUQKAstgJ3l3U2Rikd5aolKecjEvC2UJ18atlWuuZFgh5 > f+J8vWoWABv5FwJAXxKHvvuNUJD3ca+Q0PGOJj87Wf+SlB+MGRiDfSiX avh2qQ== > ipfire.org. 529 IN MX 10 mail01.ipfire.org. > ipfire.org. 529 IN > RRSIG MX 8 2 3600 2015050700 2015041600 38274 ipfire.org. > UpsMIw7DF7810q1r7w81d2+Mfe6728iNX46WP8AZDhbI7vjyY41y33zD > rY4hDbBRfaZBCycrBKYmLj38FlXbFsxKGI+KMtAkhnEv4H3q7RjBo77u > u1BLEd5Tql5oVfCaLlgvoqnATiDOr8Hh/C6R3ukSItC+cLeVY6cmBeE5 > cvh6afqiPXhf9JLrEBpl3maxkx+307XThYW6u7ZE73k2xkNZbKb8ePrK > vcND4KQlbAvGgTgOstK+wIUn2yn1oH
Re: [Dnsmasq-discuss] bugs.gentoo.org and dnssec
Hello, I am not sure if I am experiencing the same bug here or if it is somewhat different. When I try accessing some domains that use DNSSEC (like ipfire.org does, but this applies to other as well), I sometimes get SERVFAIL. This happens usually for bigger replies where fragmentation comes into the game. I think that I do not have a general issue with fragmentation or some issue with the upstream name servers, because everything goes well if I send the same query directly without going through dnsmasq. See below. dig ANY ipfire.org returns a huge number of records with lots of signatures and can be used to reproduce the issue with various upstream name servers. dnsmasq receives a truncated DNS reply (it's over 4k) and opens a TCP connection. As soon as dnsmasq is using TCP, the answer to the local system that made the request is always SERVFAIL. It also happens with "dig ANY ietf.org", but works with "dig ANY postbank.de" which replies with a DNS packet less than 4k. Other people have reported the same and/or similar issue over here: https://bugzilla.ipfire.org/show_bug.cgi?id=10786 They confirm that the issue also happens with 8.8.8.8. I captured the packets that dnsmasq is sending out to the upstream name servers and attached the pcap file. What can we do about this problem? It essentially makes DNSSEC unusable at the moment. Best, -Michael + dig ANY ipfire.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ANY ipfire.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43712 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;ipfire.org.IN ANY ;; Query time: 52 msec ;; SERVER: 192.168.180.1#53(192.168.180.1) ;; WHEN: Tue Apr 28 13:49:20 CEST 2015 ;; MSG SIZE rcvd: 39 + dig ANY ipfire.org @178.63.73.246 ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ANY ipfire.org @178.63.73.246 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30094 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 21, AUTHORITY: 0, ADDITIONAL: 3 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ipfire.org.IN ANY ;; ANSWER SECTION: ipfire.org. 3571IN A 178.63.73.246 ipfire.org. 3571IN RRSIG A 8 2 3600 2015050700 2015041600 38274 ipfire.org. AafVd/T/gKOD35lqZihS89u4aH0T4YcIN3uWGihlF6ZufWk05zs9XBBj 8SAzs5yTOACe7Hb6iNpAr7B4TNvcqCfbDTkGRcfptaIoUl2CbJ015KSd OB2pHQxzzsGvqFc609egjP6cP4uh8cIK4JZ4iLD5ldT23x76nPWzUx4N d+ErCfq/UiWvf1vfuxIRP18otagfyK5AEG3U7VBoIH1rYtPov7LwbFmp EMRa27xWD/bYcMueDk9ojfgnqKK6jXQ8RqHoXR7SRsjV/HyCb6hSuTBc g+R+gykb/r082jTzon8kJKCcC7t7TWEdLY2WH+h1I3FN+f3iNhHoal/J l5cA+g== ipfire.org. 48822 IN NS ns2.lightningwirelabs.com. ipfire.org. 48822 IN NS ns3.lightningwirelabs.com. ipfire.org. 48822 IN NS ns1.lightningwirelabs.com. ipfire.org. 48822 IN RRSIG NS 8 2 86400 2015050700 2015041600 38274 ipfire.org. LtEwh5KQuMZOM9aQphrCiSJA7R6Ubv+A7ip+7S+NwfOLRC+Eao5I/MGw AXprSNvFglwKYyj/8hmAHkByRcniXceu5e9DPL8GZnRrJEaNmPyNgv+j bSIS4jD4FSrhS6LPQzAVg6XA5r9B1y9SDPiqgDm+e3fkD8zg+ZmJuY2x XYw9JeV1c4pZVCjS6jflkZ/9LcZrNGjcDuNZxQCSFu3wD/fmxbJXfKZN e4zO8XE18Ul1c7ifGLLRM45MyedQK/Gz47KXCkC0zkVtmRPybQN9lT+1 NKRQJFNc8U6+Hb90eQSjudsrXK0V2Z7McO5OMOe305loKWhvW8KMkc/b KIKnEw== ipfire.org. 2310IN SOA ns1.lightningwirelabs.com. hostmaster.ipfire.org. 1430190033 10800 1800 604800 300 ipfire.org. 2310IN RRSIG SOA 8 2 3600 2015050700 2015041600 38274 ipfire.org. C8pSowvYXE3sngaZrOaevrbMtx3f3hKKkgRW51gebWBokxF7+5UuXclb 9pZm16ArrMeMIQhR0d14Wamn0yhsrIo8eqgPbjTdn9VzNZnpXXcsxAXu QJ4+vPGP92EfgDocqid7/9jKeJWtNZbgHJUfOwsEtYgS+gdP3L77k+gW EAypTHtJqiE65sFHUWXlb9kwmpr1trq5DXnVBwtiiaBhbYeZryY3MTkl MVyQEZebr/MUUQKAstgJ3l3U2Rikd5aolKecjEvC2UJ18atlWuuZFgh5 f+J8vWoWABv5FwJAXxKHvvuNUJD3ca+Q0PGOJj87Wf+SlB+MGRiDfSiX avh2qQ== ipfire.org. 529 IN MX 10 mail01.ipfire.org. ipfire.org. 529 IN RRSIG MX 8 2 3600 2015050700 2015041600 38274 ipfire.org. UpsMIw7DF7810q1r7w81d2+Mfe6728iNX46WP8AZDhbI7vjyY41y33zD rY4hDbBRfaZBCycrBKYmLj38FlXbFsxKGI+KMtAkhnEv4H3q7RjBo77u u1BLEd5Tql5oVfCaLlgvoqnATiDOr8Hh/C6R3ukSItC+cLeVY6cmBeE5 cvh6afqiPXhf9JLrEBpl3maxkx+307XThYW6u7ZE73k2xkNZbKb8ePrK vcND4KQlbAvGgTgOstK+wIUn2yn1oHtjWiHIXJXG6iFPXIpjMFLIYH0u /HrKhtxT397H/3dR6HXJ0zIGD+Pt82HUjPblA+B3O05FzhXFMccydG6m ffJh9Q== ipfire.org. 2218IN NAPTR 30 0 "s" "SIP+D2T" "" _sip._tcp.ipfire.org. ipfire.org. 2218IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.ipfire.org. ipfire.org. 2218IN NAPTR 20 0 "s" "SIP+D2
Re: [Dnsmasq-discuss] bugs.gentoo.org and dnssec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 21/04/15 21:51, Alon Bar-Lev wrote: > On 21 April 2015 at 21:41, Simon Kelley > wrote: > > Thanks for the report. I just tested 2.72 and the current code in > git, and both worked fine, using Google public DNS (8.8.8.8) as > upstream. > > >> I can confirm that using 8.8.8.8 it is working correctly. > > > What do you know about the upstream server you're forwarding to? > Is there a possibility that it's "fiddling" with the data it > supplies? > > >> it may be, how can I check that? what do you need? Start with the results of dig @192.168.1.1 +dnssec 546330.bugs.gentoo.org please. Cheers, Simon. > > > Cheers, > > Simon. > > > On 21/04/15 18:55, Alon Bar-Lev wrote: Hi, When using bugs.gentoo.org with dnsmasq-2.72 and dnssec enabled, I cannot access attachments. The attachments are forwarded to a CNAME, for example: --- 546330.bugs.gentoo.org. 60 IN CNAME bugs-gossamer.gentoo.org. bugs-gossamer.gentoo.org. 300 IN CNAME gannet.gentoo.org. gannet.gentoo.org. 604800 IN A 204.187.15.4 --- When trying to access without dnssec all is ok: --- Apr 21 20:19:04 [dnsmasq] query[A] 546330.bugs.gentoo.org from 127.0.0.1 Apr 21 20:19:04 [dnsmasq] forwarded 546330.bugs.gentoo.org to 192.168.1.1 Apr 21 20:19:04 [dnsmasq] validation result is INSECURE Apr 21546330.bugs.gentoo.org. 20:19:04 [dnsmasq] reply 546330.bugs.gentoo.org is Apr 21 20:19:04 [dnsmasq] reply bugs-gossamer.gentoo.org is Apr 21 20:19:04 [dnsmasq] reply gannet.gentoo.org is 204.187.15.4 --- When trying to access with dnssec, notice the "validation result is BOGUS", no result is returned: --- Apr 21 20:09:33 [dnsmasq] query[A] 546330.bugs.gentoo.org from 127.0.0.1 Apr 21 20:09:33 [dnsmasq] forwarded 546330.bugs.gentoo.org to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] gentoo.org to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DS] gentoo.org to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] 8.8org to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DS] org to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] . to 10.38.5.26 Apr 21 20:09:33 [dnsmasq] reply . is DNSKEY keytag 19036 Apr 21 20:09:33 [dnsmasq] reply . is DNSKEY keytag 48613 Apr 21 20:09:33 [dnsmasq] reply org is DS keytag 21366 - Last output repeated twice - Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 3213 Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 21366 Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 9795 Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 34023 Apr 21 20:09:33 [dnsmasq] reply gentoo.org is DS keytag 46873 - Last output repeated twice - Apr 21 20:09:33 [dnsmasq] reply gentoo.org is DNSKEY keytag 52980 Apr 21 20:09:33 [dnsmasq] reply gentoo.org is DNSKEY keytag 46873 Apr 21 20:09:33 [dnsmasq] validation result is BOGUS Apr 21 20:09:33 [dnsmasq] reply 546330.bugs.gentoo.org is Apr 21 20:09:33 [dnsmasq] reply bugs-gossamer.gentoo.org is Apr 21 20:09:33 [dnsmasq] reply gannet.gentoo.org is 204.187.15.4 --- Maybe it is local issue of the dns I am using (I have no access to it), but maybe there is a issue at dnsmasq. Peer reported that local unbound is working properly. Regards, Alon Bar-Lev. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> >> ___ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlU4DFYACgkQKPyGmiibgrcZVwCdFC93BW0V4LZVTz+mcv7ODcA/ ZFgAn0fdKhcrynlnlDmqW6GPYMFzZTRe =C/uZ -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] bugs.gentoo.org and dnssec
On 21 April 2015 at 21:41, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > Thanks for the report. I just tested 2.72 and the current code in git, > and both worked fine, using Google public DNS (8.8.8.8) as upstream. > I can confirm that using 8.8.8.8 it is working correctly. > > What do you know about the upstream server you're forwarding to? Is > there a possibility that it's "fiddling" with the data it supplies? > it may be, how can I check that? what do you need? > > Cheers, > > Simon. > > > On 21/04/15 18:55, Alon Bar-Lev wrote: >> Hi, >> >> When using bugs.gentoo.org with dnsmasq-2.72 and dnssec enabled, I >> cannot access attachments. >> >> The attachments are forwarded to a CNAME, for example: --- >> 546330.bugs.gentoo.org. 60 IN CNAME >> bugs-gossamer.gentoo.org. bugs-gossamer.gentoo.org. 300 IN >> CNAME gannet.gentoo.org. gannet.gentoo.org. 604800 IN >> A 204.187.15.4 --- >> >> When trying to access without dnssec all is ok: --- Apr 21 20:19:04 >> [dnsmasq] query[A] 546330.bugs.gentoo.org from 127.0.0.1 Apr 21 >> 20:19:04 [dnsmasq] forwarded 546330.bugs.gentoo.org to 192.168.1.1 >> Apr 21 20:19:04 [dnsmasq] validation result is INSECURE Apr 21 >> 20:19:04 [dnsmasq] reply 546330.bugs.gentoo.org is Apr 21 >> 20:19:04 [dnsmasq] reply bugs-gossamer.gentoo.org is Apr 21 >> 20:19:04 [dnsmasq] reply gannet.gentoo.org is 204.187.15.4 --- >> >> When trying to access with dnssec, notice the "validation result >> is BOGUS", no result is returned: --- Apr 21 20:09:33 [dnsmasq] >> query[A] 546330.bugs.gentoo.org from 127.0.0.1 Apr 21 20:09:33 >> [dnsmasq] forwarded 546330.bugs.gentoo.org to 10.38.5.26 Apr 21 >> 20:09:33 [dnsmasq] dnssec-query[DNSKEY] gentoo.org to 10.38.5.26 >> Apr 21 20:09:33 [dnsmasq] dnssec-query[DS] gentoo.org to >> 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] 8.8org to >> 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DS] org to >> 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] . to >> 10.38.5.26 Apr 21 20:09:33 [dnsmasq] reply . is DNSKEY keytag >> 19036 Apr 21 20:09:33 [dnsmasq] reply . is DNSKEY keytag 48613 Apr >> 21 20:09:33 [dnsmasq] reply org is DS keytag 21366 - Last output >> repeated twice - Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY >> keytag 3213 Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag >> 21366 Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 9795 Apr >> 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 34023 Apr 21 >> 20:09:33 [dnsmasq] reply gentoo.org is DS keytag 46873 - Last >> output repeated twice - Apr 21 20:09:33 [dnsmasq] reply gentoo.org >> is DNSKEY keytag 52980 Apr 21 20:09:33 [dnsmasq] reply gentoo.org >> is DNSKEY keytag 46873 Apr 21 20:09:33 [dnsmasq] validation result >> is BOGUS Apr 21 20:09:33 [dnsmasq] reply 546330.bugs.gentoo.org is >> Apr 21 20:09:33 [dnsmasq] reply bugs-gossamer.gentoo.org is >> Apr 21 20:09:33 [dnsmasq] reply gannet.gentoo.org is >> 204.187.15.4 --- >> >> Maybe it is local issue of the dns I am using (I have no access to >> it), but maybe there is a issue at dnsmasq. >> >> Peer reported that local unbound is working properly. >> >> Regards, Alon Bar-Lev. >> >> ___ Dnsmasq-discuss >> mailing list Dnsmasq-discuss@lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQIcBAEBCAAGBQJVNpnRAAoJEBXN2mrhkTWiUQMP/AiTWkiSbANZLrNpGAZoAsq2 > TZBM0vimZX9cX6OsFQeDeAAiwzNoFL2oG22YL7oQXWyEJUjl4qlFS/aznrj1QlpJ > nf3gNqedkgK7XLj+tRJSmbNohEcD2xvSiX1nIhO0GZ29lVBzmNLSicgyvqjCEkcd > GUCrkbQiEmiiQmG6EOm0f8Jr5xIp24FwY2TZ9ZfEiU4+hx5KrU2z5uMczZPBQuMo > eUDuHhbS1et3kTbqP/p929OhdOrxEn0i9mDj360qoVy8XbYTPLZRCUVppSBXh32J > SpieR6evHjvcMTDPLVnrsP/H7IUbgoyJYE5E5m6gfI57tlkurNKjjQnrKgAV+S2l > Oxu5Ld4uN8Bb7n/MgH4p6n9I7RPIkGRR9nSlPrbJOCJhktzS+dBh80lP2N1mXScf > B6yn9Mo7yJ6ji66u/4A0lcDvafTeIGDdv54GjC76TNprXe7z3WvJyJDYhbelDadw > Sp+8pwtUbR4aCC21wHURMfxurAcmUVZ0mB9hnxfsnvsCBmFSpr4XetRXS+sIo3+X > mM3eITiIcHFh3pW3kWUjucgVl494GGO0Dq1hgjv4LFkqHQtY290hliQmBTKnat9Z > SZqmGRwQWK4QsVkHznbBHRCwozwgftR9O5s66GPQFDiZBDHZvvzasn8qpDbYzLy5 > IS86yr7FndM4zrwfLxdR > =/Iup > -END PGP SIGNATURE- > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] bugs.gentoo.org and dnssec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thanks for the report. I just tested 2.72 and the current code in git, and both worked fine, using Google public DNS (8.8.8.8) as upstream. What do you know about the upstream server you're forwarding to? Is there a possibility that it's "fiddling" with the data it supplies? Cheers, Simon. On 21/04/15 18:55, Alon Bar-Lev wrote: > Hi, > > When using bugs.gentoo.org with dnsmasq-2.72 and dnssec enabled, I > cannot access attachments. > > The attachments are forwarded to a CNAME, for example: --- > 546330.bugs.gentoo.org. 60 IN CNAME > bugs-gossamer.gentoo.org. bugs-gossamer.gentoo.org. 300 IN > CNAME gannet.gentoo.org. gannet.gentoo.org. 604800 IN > A 204.187.15.4 --- > > When trying to access without dnssec all is ok: --- Apr 21 20:19:04 > [dnsmasq] query[A] 546330.bugs.gentoo.org from 127.0.0.1 Apr 21 > 20:19:04 [dnsmasq] forwarded 546330.bugs.gentoo.org to 192.168.1.1 > Apr 21 20:19:04 [dnsmasq] validation result is INSECURE Apr 21 > 20:19:04 [dnsmasq] reply 546330.bugs.gentoo.org is Apr 21 > 20:19:04 [dnsmasq] reply bugs-gossamer.gentoo.org is Apr 21 > 20:19:04 [dnsmasq] reply gannet.gentoo.org is 204.187.15.4 --- > > When trying to access with dnssec, notice the "validation result > is BOGUS", no result is returned: --- Apr 21 20:09:33 [dnsmasq] > query[A] 546330.bugs.gentoo.org from 127.0.0.1 Apr 21 20:09:33 > [dnsmasq] forwarded 546330.bugs.gentoo.org to 10.38.5.26 Apr 21 > 20:09:33 [dnsmasq] dnssec-query[DNSKEY] gentoo.org to 10.38.5.26 > Apr 21 20:09:33 [dnsmasq] dnssec-query[DS] gentoo.org to > 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] 8.8org to > 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DS] org to > 10.38.5.26 Apr 21 20:09:33 [dnsmasq] dnssec-query[DNSKEY] . to > 10.38.5.26 Apr 21 20:09:33 [dnsmasq] reply . is DNSKEY keytag > 19036 Apr 21 20:09:33 [dnsmasq] reply . is DNSKEY keytag 48613 Apr > 21 20:09:33 [dnsmasq] reply org is DS keytag 21366 - Last output > repeated twice - Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY > keytag 3213 Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag > 21366 Apr 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 9795 Apr > 21 20:09:33 [dnsmasq] reply org is DNSKEY keytag 34023 Apr 21 > 20:09:33 [dnsmasq] reply gentoo.org is DS keytag 46873 - Last > output repeated twice - Apr 21 20:09:33 [dnsmasq] reply gentoo.org > is DNSKEY keytag 52980 Apr 21 20:09:33 [dnsmasq] reply gentoo.org > is DNSKEY keytag 46873 Apr 21 20:09:33 [dnsmasq] validation result > is BOGUS Apr 21 20:09:33 [dnsmasq] reply 546330.bugs.gentoo.org is > Apr 21 20:09:33 [dnsmasq] reply bugs-gossamer.gentoo.org is > Apr 21 20:09:33 [dnsmasq] reply gannet.gentoo.org is > 204.187.15.4 --- > > Maybe it is local issue of the dns I am using (I have no access to > it), but maybe there is a issue at dnsmasq. > > Peer reported that local unbound is working properly. > > Regards, Alon Bar-Lev. > > ___ Dnsmasq-discuss > mailing list Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJVNpnRAAoJEBXN2mrhkTWiUQMP/AiTWkiSbANZLrNpGAZoAsq2 TZBM0vimZX9cX6OsFQeDeAAiwzNoFL2oG22YL7oQXWyEJUjl4qlFS/aznrj1QlpJ nf3gNqedkgK7XLj+tRJSmbNohEcD2xvSiX1nIhO0GZ29lVBzmNLSicgyvqjCEkcd GUCrkbQiEmiiQmG6EOm0f8Jr5xIp24FwY2TZ9ZfEiU4+hx5KrU2z5uMczZPBQuMo eUDuHhbS1et3kTbqP/p929OhdOrxEn0i9mDj360qoVy8XbYTPLZRCUVppSBXh32J SpieR6evHjvcMTDPLVnrsP/H7IUbgoyJYE5E5m6gfI57tlkurNKjjQnrKgAV+S2l Oxu5Ld4uN8Bb7n/MgH4p6n9I7RPIkGRR9nSlPrbJOCJhktzS+dBh80lP2N1mXScf B6yn9Mo7yJ6ji66u/4A0lcDvafTeIGDdv54GjC76TNprXe7z3WvJyJDYhbelDadw Sp+8pwtUbR4aCC21wHURMfxurAcmUVZ0mB9hnxfsnvsCBmFSpr4XetRXS+sIo3+X mM3eITiIcHFh3pW3kWUjucgVl494GGO0Dq1hgjv4LFkqHQtY290hliQmBTKnat9Z SZqmGRwQWK4QsVkHznbBHRCwozwgftR9O5s66GPQFDiZBDHZvvzasn8qpDbYzLy5 IS86yr7FndM4zrwfLxdR =/Iup -END PGP SIGNATURE- ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
