-----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.                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
>>> <si...@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@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
>>>
>>
>>
>>>> 
_______________________________________________
>> 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)

iEYEARECAAYFAlU/5qoACgkQKPyGmiibgrf/RgCfcf6b+lVyo/xXM1IE1n6uUsiw
OfkAn2rcjQxIR2O/AuNMj3lGvNdR3i5G
=fce7
-----END PGP SIGNATURE-----

_______________________________________________
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Reply via email to