RE: BUG: dnsproxy.c does not strip domain name-part from search-queries correctly and all dns-servers should not queried at the same time.
Hi Jukka, >However the other problem still exists, forward_dns_reply() does not strip the >domain name part away from the answer-block (as discussed on IRC) which will >lead to fails. With fa7141ae55aadbe8faacb0cba2b1f864a2f20bf9: IP (tos 0x0, ttl 64, id 45410, offset 0, flags [DF], proto UDP (17), length 51) 127.0.0.1.56035 > 127.0.0.1.53: [bad udp cksum 0xfe32 -> 0x607b!] 63156+ A? warez. (23) IP (tos 0x0, ttl 64, id 45411, offset 0, flags [DF], proto UDP (17), length 85) 127.0.0.1.53 > 127.0.0.1.56035: [bad udp cksum 0xfe54 -> 0xa79d!] 63156 q: A? warez. 1/0/0 warez.siirappi.com. A 127.0.0.1 (57) Reverted fa7141ae55aadbe8faacb0cba2b1f864a2f20bf9: IP (tos 0x0, ttl 64, id 43076, offset 0, flags [DF], proto UDP (17), length 51) 127.0.0.1.41718 > 127.0.0.1.53: [bad udp cksum 0xfe32 -> 0x890e!] 1551+ A? warez. (23) IP (tos 0x0, ttl 64, id 43077, offset 0, flags [DF], proto UDP (17), length 67) 127.0.0.1.53 > 127.0.0.1.41718: [bad udp cksum 0xfe42 -> 0xf11f!] 1551 q: A? warez. 1/0/0 warez. A 127.0.0.1 (39) So I would suggest reverting fa7141ae55aadbe8faacb0cba2b1f864a2f20bf9 or fixing it. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: BUG: dnsproxy.c does not strip domain name-part from search-queries correctly and all dns-servers should not queried at the same time.
>> If I do that, I can see that the current way of stripping the domain name >> from reply is broken in forward_dns_reply() as it does not really strip out >> the domain name part: >> >> tcpdump (lo): >> IP (tos 0x0, ttl 64, id 36270, offset 0, flags [DF], proto UDP (17), length >> 48) >> 127.0.0.1.33898 > 127.0.0.1.53: 10971+ A? bz. (20) >> IP (tos 0x0, ttl 64, id 36271, offset 0, flags [DF], proto UDP (17), length >> 82) >> 127.0.0.1.53 > 127.0.0.1.33898: 10971 1/0/0 bz.siirappi.com. A 1.2.3.4 >> (54) >> >We could optimize the resolver a bit so that if the DNS server returns >not found for a query, we could wait until we get a "name found" >response before returning something to the client. Would you like to >investigate this more and send a patch? As stated on the other thread my analysis was bit wrong, however the patch which I sent fixes the problems when hostname queried is a valid domain tld. However the other problem still exists, forward_dns_reply() does not strip the domain name part away from the answer-block (as discussed on IRC) which will lead to fails. Br, Pasi ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: BUG: dnsproxy.c does not strip domain name-part from search-queries correctly and all dns-servers should not queried at the same time.
Hi Pasi, On ke, 2014-07-02 at 19:34 +, Pasi Sjöholm wrote: > Hi, > > (ip-addresses and domains have been modified) > > it seems that the current dnsproxy.c implementation queries all the available > dns-servers as soon as possible and only uses the first response as a result, > normally this would be ok but when doing search-query for domains it will not > work correctly. > > Let's have service with these settings: > Nameservers = [ 193.229.0.40 193.229.0.42 ] > Domains = [ siirappi.com ] > > Query for bz.siirappi.com will success correctly, but when querying for plain > bz this happens: > > On "public" interface all the nameservers are queried at "same time" and not > by first querying nameservers for interface which has a default route (one by > one and requiring timeout to expire before querying next one) and then the > other available dns-servers as a backups. > > tcpdump (public interface): > IP 10.1.0.175.44256 > 193.229.0.42.53: 62449+ A? bz. (20) > IP 10.1.0.175.44256 > 193.229.0.42.53: 60823+ A? bz.siirappi.com. (36) > IP 10.1.0.175.40848 > 193.229.0.40.53: 62449+ A? bz. (20) > IP 10.1.0.175.40848 > 193.229.0.40.53: 60823+ A? bz.siirappi.com. (36) > IP 193.229.0.40.53 > 10.1.0.175.40848: 62449 0/1/0 (85) > IP 193.229.0.40.53 > 10.1.0.175.40848: 60823 1/0/0 A 1.2.3.4 (52) > IP 193.229.0.42.53 > 10.1.0.175.44256: 62449 0/1/0 (85) > IP 193.229.0.42.53 > 10.1.0.175.44256: 60823 1/0/0 A 1.2.3.4 (52) > > tcpdump (lo): > IP 127.0.0.1.60262 > 127.0.0.1.53: 50453+ A? bz. (20) > IP 127.0.0.1.53 > 127.0.0.1.60262: 50453 0/1/0 (85) > > connmand log: > src/dnsproxy.c:udp_listener_event() Received 20 bytes (id 0x7410) > src/dnsproxy.c:parse_request() id 0x7410 qr 0 opcode 0 qdcount 1 arcount 0 > src/dnsproxy.c:parse_request() query bz. > src/dnsproxy.c:resolv() server 193.229.0.42 enabled 1 > src/dnsproxy.c:append_query() query bz. domain siirappi.com > src/dnsproxy.c:ns_resolv() req 0x1207780 dstid 0x3940 altid 0xbc28 > src/dnsproxy.c:resolv() server 193.229.0.40 enabled 1 > src/dnsproxy.c:append_query() query bz. domain siirappi.com > src/dnsproxy.c:ns_resolv() req 0x1207780 dstid 0x3940 altid 0xbc28 > src/dnsproxy.c:forward_dns_reply() Received 85 bytes (id 0x3940) > src/dnsproxy.c:forward_dns_reply() req 0x1207780 dstid 0x3940 altid 0xbc28 > rcode 0 > src/dnsproxy.c:cache_update() offset 0 hdr 0xbe832ba4 msg 0xbe832ba4 rcode 0 > src/dnsproxy.c:parse_response() qr 1 qdcount 1 > src/dnsproxy.c:forward_dns_reply() proto 17 sent 85 bytes to 9 > src/dnsproxy.c:forward_dns_reply() Received 52 bytes (id 0xbc28) > src/dnsproxy.c:forward_dns_reply() Received 85 bytes (id 0x3940) > src/dnsproxy.c:forward_dns_reply() Received 52 bytes (id 0xbc28) > > Only the first reply gets handled and that's the reply for plain bz.-query, > rest of the responses get ignored by forward_dns_reply(). > Therefore the user will not get value for bz.siirappi.com as expected, or he > might get if the UDP-response for it gets back to connman faster thant the > reply for bz.-query. > > The query order can be fixed easily in ns_resolv() by prioritizing the > append_domain-query but it still does not guarantee that the reply for it get > back first. > If I do that, I can see that the current way of stripping the domain name > from reply is broken in forward_dns_reply() as it does not really strip out > the domain name part: > > tcpdump (lo): > IP (tos 0x0, ttl 64, id 36270, offset 0, flags [DF], proto UDP (17), length > 48) > 127.0.0.1.33898 > 127.0.0.1.53: 10971+ A? bz. (20) > IP (tos 0x0, ttl 64, id 36271, offset 0, flags [DF], proto UDP (17), length > 82) > 127.0.0.1.53 > 127.0.0.1.33898: 10971 1/0/0 bz.siirappi.com. A 1.2.3.4 > (54) > > Only way to fix this: > 1. Query the search-domain (bz.siirappi.com.) first and only after the > connman will get either NXDomain-reply or the valid record for the query it > should continue. (In case of timeout -> query next nameserver). > 2. With NXDomain it should query the original search (bz.) and with valid > record it should return it to the client. As we want to get the results as fast as possible, then we cannot really send sequentially i.e., sending request and waiting answer to it before sending a new request. The request is sent to all servers at the same time and we take the first server that answers something. We could optimize the resolver a bit so that if the DNS server returns not found for a query, we could wait until we get a "name found" response before returning something to the client. Would you like to investigate this more and send a patch? > > OR > > Remove the domains search-functionality from connman and count on operating > system's domains search-functionality (eg. by defining search-patterns to > /etc/resolv.conf in linux). This would not work as expected. The reason is that if connman writes the search domain information to resolov.conf and if there are different services that have different search domains defined in th
