[Dnsmasq-discuss] bugs.gentoo.org and dnssec

Michael Tremer michael.tremer at ipfire.org
Wed Apr 29 10:28:56 BST 2015


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.		3571	IN	A	178.63.73.246 ipfire.org.
> > 3571	IN	RRSIG	A 8 2 3600 20150507000000 20150416000000 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
> > 20150507000000 20150416000000 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.		2310	IN	SOA	ns1.lightningwirelabs.com.
> > hostmaster.ipfire.org. 1430190033 10800 1800 604800 300 ipfire.org.
> > 2310	IN	RRSIG	SOA 8 2 3600 20150507000000 20150416000000 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 20150507000000 20150416000000 38274 ipfire.org.
> > UpsMIw7DF7810q1r7w81d2+Mfe6728iNX46WP8AZDhbI7vjyY41y33zD
> > rY4hDbBRfaZBCycrBKYmLj38FlXbFsxKGI+KMtAkhnEv4H3q7RjBo77u
> > u1BLEd5Tql5oVfCaLlgvoqnATiDOr8Hh/C6R3ukSItC+cLeVY6cmBeE5
> > cvh6afqiPXhf9JLrEBpl3maxkx+307XThYW6u7ZE73k2xkNZbKb8ePrK
> > vcND4KQlbAvGgTgOstK+wIUn2yn1oHtjWiHIXJXG6iFPXIpjMFLIYH0u
> > /HrKhtxT397H/3dR6HXJ0zIGD+Pt82HUjPblA+B3O05FzhXFMccydG6m ffJh9Q== 
> > ipfire.org.		2218	IN	NAPTR	30 0 "s" "SIP+D2T" ""
> > _sip._tcp.ipfire.org. ipfire.org.		2218	IN	NAPTR	10 0 "s"
> > "SIPS+D2T" "" _sips._tcp.ipfire.org. ipfire.org.		2218	IN	NAPTR	20
> > 0 "s" "SIP+D2U" "" _sip._udp.ipfire.org. ipfire.org.		2218	IN	RRSIG
> > NAPTR 8 2 3600 20150507000000 20150416000000 38274 ipfire.org.
> > rAPEpDgizACsrPwCQquMc+lJgm0pcpYxmDMlUUBIZLLDncVyYT4rTkQf
> > Ch7sBusMbS55gx3CKb0diubVHRHrYG35m6iyMAkhoLlL4QgBl9W6Mm/5
> > cky6cKNTH7DZYcapoM0gdZ16BwmkLzaf3YbxsKnkj9WKPOTZ3gDiJUrT
> > H+K+F8n9yB3YTZh2UiF6rkCzh70gyvgE7GtDWmo8NuU06hv96V0vFzaO
> > 0dshzkEeGlxO895CIBN9n3VmTJGkje3aPrfQO9AQAQtvANizpGlDYX5d
> > k4r0xdTUf9JxHpovOSwgHHW8H6OGv4GlGDeEekvpH47gsRhxvPI+B1dl 64BsFA== 
> > ipfire.org.		175	IN	DNSKEY	257 3 8
> > AwEAAaR10OZmKeoNxl4ncrBPg6FSAIfa8w80WjSz3dBmxKb4jdjno/Ux
> > 6PaxoCbiA2AJ9EaVeB1R80MQpv5dbFDGn0EHHwLnuWJOpoqC4t2uGvbt
> > OA8i8rPaCf4+gLJyUEsndPe56jXDB962B63aoj7B+Vxot2CWgtZrp+3l
> > bueiQzgvscMUqVmwW5oQs6qTlR+Ml3sD15SEn22zoHRD6VKo71jWUqeF
> > plbInDnSE0v+e9hl4e8SCwiHkmZ6XWnMddOHbRdtZN6T/zXgqc1dFha8
> > XjVovROASTipPq7XNyfDeMsnY7WFGS/wBsw3Ek8NZfVmfmykPrZja7eJ
> > xaRxmbip+/s= ipfire.org.		175	IN	DNSKEY	256 3 8
> > AwEAAa5gMm2ujJ+ptGn/sGpWIGNJdcMd/F1Fi9oW1b/hjVyBuUtqKF7X
> > yHeGxu70TkIW8ehqaRcLglI5MX6lPcBBVI69f1Oxc8CwbvL2Wf6NIzTZ
> > cR/ooCgdWJA93UwoL7/IRn9+1G7LA+R7KS2BLxt0U6zn+8lhliMStg9d
> > QhjLF9txECtqz2G5GAAXiUMSeVALtzOC/kVk2FgIcFWgkroQy8QQSUBA
> > wkkbNHzGpLeTzMNB9KFfOZvDDwmyNN0v21YpaHkQ+z14U97cK7I1j28w
> > hZ+nH8H/DWER34wj4jqLxNKU9RMzdkj7ac1OitIjhB+p3mhXLDtNyGTA
> > symGY09zD/c= ipfire.org.		175	IN	RRSIG	DNSKEY 8 2 300
> > 20150507000000 20150416000000 54142 ipfire.org.
> > Vemwsm1CWRG3vyooc3djrspfaOMaYhBS9LNg8kIvS3yscMc39RY9dPik
> > 8AKjWr39SyNGWWcyAO79MAzFHFd0ZjCxvJkzmKRv9sqQgrMNAWQ20FB6
> > 2n5AxZbz90BrSLsXnh0tfvMK/Ex8qSCqA10+4D06JD6cBQ+vl6ndCCDU
> > c9yzrJ4pUNXUTpsYH4VlhEjrcw1VgoS/gF7rQwhA56J+RDnvbb9/sUiD
> > 11mrZ1K+qCKEUfs8hoY6kUc/2/pkabK+n3QzmAX6cCBeOsEyxFJ2tlOQ
> > xjZrKp9xh2BxqnRuDVs3IYdlVhA0T60s+tXIev/lGCivKugB/F1fniae vN3Z0A== 
> > ipfire.org.		271	IN	NSEC3PARAM 1 0 1 9BFD ipfire.org.		271	IN	RRSIG
> > NSEC3PARAM 8 2 300 20150507000000 20150416000000 38274 ipfire.org.
> > G9FvcJBYLIu4RTgkp1mQXkS1pw4S9YgtgIxeIFcMLtRgkjEyYwYLrEUD
> > aRjdrSLNVx9Wfi3lz+vNLratHzTG3Qa+qfWwsffl5jwNIgbEq9mD6tzR
> > hbgy5cJ+TzQ4NgLQ1jzkDzGmolSMkd06LhK3CkwqpUBsxixySoPtvSfD
> > OflIm7Y0YBeE3OcCVzGGwU1OcCemK+57FL4HGOuNVd/YUyvawLtm02MU
> > A30/up0OcBW+3ENlw8dF2E5UdzIrSuRqPd2BYg+LrW1rKgNQd32ewKGF
> > 4qtyyQA6WoqchokFnyMIIW3KaC6w5toD3imGpsWgBuSXus6r8kc/bDtP 0hQGxg== 
> > ipfire.org.		2310	IN	SPF	"v=spf1 mx mx:tx-team.de -all" ipfire.org.
> > 2310	IN	RRSIG	SPF 8 2 3600 20150507000000 20150416000000 38274
> > ipfire.org.
> > Ky7sCewWYtekiI+mxy2wXOVgwePDa2KZJhS4Gi3n3esm056VwJj6Lztw
> > bMCtND+jhL9HQv8pByWc1U/4XeBLH90RTbI0I6ZPnEpxU/H3925TOJl7
> > xUtEStWTUlsSFKvpxvajwvmw0BMbbw9ZYlSR6yMOUNgjCpO3haMtpFit
> > FEOOybEqD6WMP/u7NC5DOH9xiJDeSVQPaN9KiYHVG5AcvtPy+zcgfyys
> > YL7O1SvCzOitQpmaas/dtuJAsB57My9FlnlgrzDodV+UzqoOzFk+Ye+T
> > tvvwjnBrjWaOiiX6ZnfK7VpvHlbKpKLjgcTSdoue0DYBW/mfQbuGXKOx J6gczw==
> > 
> > ;; ADDITIONAL SECTION: mail01.ipfire.org.	3428	IN	A	178.63.73.247 
> > mail01.ipfire.org.	3428	IN	AAAA	2001:470:7183:25::1
> > 
> > ;; Query time: 20 msec ;; SERVER: 178.63.73.246#53(178.63.73.246) 
> > ;; WHEN: Tue Apr 28 13:49:20 CEST 2015 ;; MSG SIZE  rcvd: 3389
> > 
> > + dig forum.ipfire.org
> > 
> > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> forum.ipfire.org ;;
> > global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY,
> > status: NOERROR, id: 8057 ;; flags: qr rd ra ad; QUERY: 1, ANSWER:
> > 2, AUTHORITY: 0, ADDITIONAL: 1
> > 
> > ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;;
> > QUESTION SECTION: ;forum.ipfire.org.		IN	A
> > 
> > ;; ANSWER SECTION: forum.ipfire.org.	703	IN	CNAME
> > web01.ipfire.org. web01.ipfire.org.	3006	IN	A	178.63.73.246
> > 
> > ;; Query time: 0 msec ;; SERVER: 192.168.180.1#53(192.168.180.1) ;;
> > WHEN: Tue Apr 28 13:49:20 CEST 2015 ;; MSG SIZE  rcvd: 91
> > 
> > 
> > On Wed, 2015-04-22 at 22:02 +0100, Simon Kelley wrote:
> >> On 21/04/15 21:51, Alon Bar-Lev wrote:
> >>> On 21 April 2015 at 21:41, Simon Kelley
> >>> <simon at thekelleys.org.uk> 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 -d -p 10000 --dnssec
> >> --conf-file=trust-anchors.conf --no-resolv --server=178.63.73.246
> >> --log-queries --dnssec-check-unsigned 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 <CNAME> Apr 21 20:19:04
> >>>>>> [dnsmasq] reply bugs-gossamer.gentoo.org is <CNAME> 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
> >>>>>> <CNAME> Apr 21 20:09:33 [dnsmasq] reply 
> >>>>>> bugs-gossamer.gentoo.org is <CNAME> 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 at lists.thekelleys.org.uk 
> >>>>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >>>>>>
> >>>>
> >>>>
> >>>>>>
> >>
> >>>>>> 
> _______________________________________________
> >>>> Dnsmasq-discuss mailing list 
> >>>> Dnsmasq-discuss at lists.thekelleys.org.uk 
> >>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >>>
> >>
> >>
> >>>> 
> _______________________________________________
> >> Dnsmasq-discuss mailing list 
> >> Dnsmasq-discuss at lists.thekelleys.org.uk 
> >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20150429/4e41ddcd/attachment.sig>


More information about the Dnsmasq-discuss mailing list