On 27.10.2015 15:49, Pasi Sjöholm wrote:
> On 27.10.2015 15:00, SpiderX wrote:
>> This was fixed once (see commit
>> http://git.kernel.org/cgit/network/connman/connman.git/commit/src/dnsproxy.c?h=1.30&id=0439194ed0c5a90f61dbef86d9a51307764da2d7),
>> but then was refactored in later commits

Technically that commit is still working but the thing is that the
uncompress() and forward_dns_reply() are not able to handle few special
cases.

> I'm able to reproduce the issue. However it seems that connman's
> dnsproxy properly caches the response, so if I do "host -v -t a bz"
> immediately after the first query there will be a proper response.

Ok, it's not ConnMan's cache from where the response comes correctly on
the next time. The issue is:

1) Some upstream DNS-servers add details in the Authority and additional
sections of the reply when being queried. Eg. dnsmasq does this on this
on replies not coming from it's cache but for ones coming from the cache
it replies only the asked records.

First query:

host -t a -v bz.siirappi.com

--cut--
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31498
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; QUESTION SECTION:
;bz.siirappi.com.               IN      A

;; ANSWER SECTION:
bz.siirappi.com.        60      IN      A       1.2.3.4

;; AUTHORITY SECTION:
siirappi.com.           3367    IN      NS      ns2.afraid.org.
siirappi.com.           3367    IN      NS      ns1.siirappi.com.

;; ADDITIONAL
SECTION:http://git.kernel.org/cgit/network/connman/connman.git/tree/src/dnsproxy.c#n2056
ns1.siirappi.com.       60      IN      AAAA    2001:41d0:8:196a::2
ns2.afraid.org.         67      IN      A       208.43.71.243
ns2.afraid.org.         67      IN      AAAA    2607:f0d0:3001:92::2
--cut--

Second query (from cache):

--cut--
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53006
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;bz.siirappi.com.               IN      A

;; ANSWER SECTION:
bz.siirappi.com.        53      IN      A       1.2.3.4
--cut--

2) As a workaround Google's public DNS-servers seem not to have any
authority / additional sections in their replies. Those should work ok.

3) For me the uncompress() returns null when being asked to uncompress
nscount from the replies and that's enough for it to bail out.

(http://git.kernel.org/cgit/network/connman/connman.git/tree/src/dnsproxy.c#n2056)

--cut--
connmand[10470]: src/dnsproxy.c:forward_dns_reply() req 0x18c02b0 dstid
0x8fe0 altid 0x0865 rcode 0
connmand[10470]: src/dnsproxy.c:uncompress() count 1 ptr 0xbe9d2575 end
0xbe9d260b uptr 0xbe9d2128
connmand[10470]: src/dnsproxy.c:uncompress() pos 2 ulen 16 left 1017
name bsiirappicom
connmand[10470]: src/dnsproxy.c:uncompress() count 2 ptr 0xbe9d2585 end
0xbe9d260b uptr 0xbe9d2147
connmand[10470]: src/dnsproxy.c:uncompress() pos 2 ulen 13 left 986
namesiirappicom
connmand[10470]: src/dnsproxy.c:uncompress() pos 6 ulen 17 left 962
name nssiirappicom
connmand[10470]: src/dnsproxy.c:uncompress() failed dns_class != ns_c_in
--cut--

So I guess the bug itself is in the uncompress()-function.

JukkaR: can you please help me with this one as you know how the
uncompress() should work?

Br,
Pasi
_______________________________________________
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman

Reply via email to