[Bug 33144] New: DnsQuery_A API returns DNS_ERROR_BAD_PACKET when querying for MX records.
http://bugs.winehq.org/show_bug.cgi?id=33144
Bug #: 33144 Summary: DnsQuery_A API returns DNS_ERROR_BAD_PACKET when querying for MX records. Product: Wine Version: 1.5.25 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: filip.navara@gmail.com Classification: Unclassified
Step to reproduce:
1) Download DNSDataView tool from http://nirsoft.net/utils/dns_records_viewer.html (or any other nslookup-like tool) 2) Set it to query "emclient.com" for MX record. 3) Error 9502 (DNS_ERROR_BAD_PACKET) is returned instead of the actual DNS record.
Component: dnsapi (not available in the list) OS: Linux (Ubuntu), OS X 10.8
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #1 from Filip Navara filip.navara@gmail.com 2013-03-08 07:24:18 CST --- The bug was originally found when testing eM Client 5 (www.emclient.com) on Wine. It prevents the email client from properly detecting gmail.com / Google Apps accounts based on the MX records and thus the accounts are setup improperly.
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #2 from Hans Leidekker hans@meelstraat.net 2013-03-08 07:37:46 CST --- Works fine here. Can you attach a +dnsapi trace? Is MX the only type that fails?
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #3 from Filip Navara filip.navara@gmail.com 2013-03-08 07:48:17 CST --- Here's the DNSAPI log:
trace:dnsapi:DnsQuery_W (L"emclient.com",DNS_TYPE_MX,0x000001e8,0x0,0x32eb44,0x0) trace:dnsapi:DnsQuery_UTF8 ("emclient.com",DNS_TYPE_MX,0x000001e8,0x0,0x32eadc,0x0) fixme:dnsapi:dns_map_options option DNS_QUERY_WIRE_ONLY not implemented fixme:dnsapi:dns_map_options option DNS_QUERY_BYPASS_CACHE not implemented trace:dnsapi:dns_map_options netbios query disabled trace:dnsapi:DnsRecordListFree (0x0,1)
Is there anything else that could help diagnosing it? Tcpdump output? Using Google DNS servers in the host system?
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #4 from Filip Navara filip.navara@gmail.com 2013-03-08 07:49:23 CST --- I forgot to mention that other queries seems to work just fine. A SRV query for "_autodiscover._tcp.emclient.com" in the same session is successful.
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #5 from Filip Navara filip.navara@gmail.com 2013-03-08 08:12:10 CST --- Created attachment 43848 --> http://bugs.winehq.org/attachment.cgi?id=43848 Wireshark log
It's definitely specific to the network I am in. I've attached the Wireshark log for the DNS queries.
When connected to my mobile network the DNS MX query works just fine in Wine. The host nslookup tool returns correct results both when connected to the mobile network and the work network (the problematic one).
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #6 from Filip Navara filip.navara@gmail.com 2013-03-08 08:34:25 CST --- Created attachment 43849 --> http://bugs.winehq.org/attachment.cgi?id=43849 Wireshark log (Google DNS)
Attached is the same DNS query captured with Wireshark against Google DNS servers. The response from our local DNS server returns 13 authority resource records (RRs) and 11 additional RRs in addition to the 3 answer RRs. Google DNS returns just 3 answer RRs. Perhaps Wine has a bug in parsing these additional records.
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #7 from Hans Leidekker hans@meelstraat.net 2013-03-08 08:41:36 CST --- (In reply to comment #6)
Created attachment 43849 [details] Wireshark log (Google DNS)
Attached is the same DNS query captured with Wireshark against Google DNS servers. The response from our local DNS server returns 13 authority resource records (RRs) and 11 additional RRs in addition to the 3 answer RRs. Google DNS returns just 3 answer RRs. Perhaps Wine has a bug in parsing these additional records.
I get 2 A records in the additional section (the IP addresses of the MX hosts in the same domain).
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #8 from Filip Navara filip.navara@gmail.com 2013-03-08 10:07:15 CST --- Part of the problem may be the fact that at least one of the DNS responses I see in the Wireshark logs has 580 bytes. The NS_PACKETSZ constant on my machine is defined as 512, thus the packet is most probably getting truncated.
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #9 from Hans Leidekker hans@meelstraat.net 2013-03-08 10:11:41 CST --- (In reply to comment #8)
Part of the problem may be the fact that at least one of the DNS responses I see in the Wireshark logs has 580 bytes. The NS_PACKETSZ constant on my machine is defined as 512, thus the packet is most probably getting truncated.
Makes sense. Did you verify that this works on Windows?
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #10 from Filip Navara filip.navara@gmail.com 2013-03-08 10:17:55 CST --- Yes, I did and this works in Windows just fine. The DNS responses in Wireshark are roughly the same in Windows and OS X. Could this be addressed by checking the return value of res_query against NS_PACKETSZ and then dynamically reallocating the buffer if necessary?
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #11 from Hans Leidekker hans@meelstraat.net 2013-03-08 10:43:12 CST --- (In reply to comment #10)
Yes, I did and this works in Windows just fine. The DNS responses in Wireshark are roughly the same in Windows and OS X. Could this be addressed by checking the return value of res_query against NS_PACKETSZ and then dynamically reallocating the buffer if necessary?
I suspect these large packets have a maximum size too. If it's EDNS it appears to be 4096 bytes. I don't know what else might be needed to parse them correctly.
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #12 from Filip Navara filip.navara@gmail.com 2013-03-08 10:48:02 CST --- I'm not sure what is the size limit, but I presume there is one. The current parsing code seems to work fine with the DNS responses from my Wireshark log. I've manually injected them into the code instead of calling res_query and the rest of the code seems to behave correctly.
http://bugs.winehq.org/show_bug.cgi?id=33144
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Component|-unknown |dnsapi
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #13 from Hans Leidekker hans@meelstraat.net 2013-03-09 04:42:25 CST --- Created attachment 43864 --> http://bugs.winehq.org/attachment.cgi?id=43864 patch
ISC people suggest a maximum size of 4096 and the wikipedia page on EDNS says that the format is backwards compatible. So how about this patch?
http://bugs.winehq.org/show_bug.cgi?id=33144
--- Comment #14 from Filip Navara filip.navara@gmail.com 2013-03-09 04:45:56 CST --- Works for me.
http://bugs.winehq.org/show_bug.cgi?id=33144
Hans Leidekker hans@meelstraat.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |8981bbd464c1b1dc0704c9624c8 | |955168d2e35db Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #15 from Hans Leidekker hans@meelstraat.net 2013-03-12 14:38:13 CDT --- Fixed by 8981bbd464c1b1dc0704c9624c8955168d2e35db.
http://bugs.winehq.org/show_bug.cgi?id=33144
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #16 from Alexandre Julliard julliard@winehq.org 2013-03-15 14:46:40 CDT --- Closing bugs fixed in 1.5.26.
-
wine-bugs＠winehq.org