Discussion:
searchdns does not work in connman 1.30
(too old to reply)
SpiderX
2015-10-27 13:00:13 UTC
Permalink
Hello,

# connmand -v
1.30

Here is current service config:
connmanctl> services ethernet_64315095faf8_cable
/net/connman/service/ethernet_64315095faf8_cable
Type = ethernet
Security = [ ]
State = online
Favorite = True
Immutable = False
AutoConnect = True
Name = Wired
Ethernet = [ Method=auto, Interface=enp37s0,
Address=64:31:50:95:FA:F8, MTU=1500 ]
IPv4 = [ Method=dhcp, Address=10.21.5.154, Netmask=255.255.255.0,
Gateway=10.21.5.250 ]
IPv4.Configuration = [ Method=dhcp ]
IPv6 = [ ]
IPv6.Configuration = [ Method=off ]
Nameservers = [ 91.193.69.4, 91.193.69.22 ]
Nameservers.Configuration = [ ]
Timeservers = [ 10.21.5.250, ntp.time.in.ua, ntp2.time.in.ua,
ntp3.time.in.ua ]
Timeservers.Configuration = [ ]
Domains = [ gts.dp.ua ]
Domains.Configuration = [ gts.dp.ua ]
Proxy = [ Method=direct ]
Proxy.Configuration = [ ]
Provider = [ ]

Domains = [ gts.dp.ua ]. so gts.dp.ua should be appended to dns query.

~ $ host -v nefrit1
Trying "nefrit1"
Host nefrit1 not found: 3(NXDOMAIN)
Received 100 bytes from 127.0.0.1#53 in 0 ms

tcpdump:
# tcpdump -npi enp37s0 port 53
dropped privs to tcpdump
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp37s0, link-type EN10MB (Ethernet), capture size 262144 bytes
14:27:51.032322 IP 10.21.5.154.32905 > 91.193.69.4.53: 51887+ A? nefrit1. (25)
14:27:51.032337 IP 10.21.5.154.32905 > 91.193.69.4.53: 84+ A?
nefrit1.gts.dp.ua. (35)
14:27:51.032345 IP 10.21.5.154.59459 > 91.193.69.22.53: 51887+ A? nefrit1. (25)
14:27:51.032350 IP 10.21.5.154.59459 > 91.193.69.22.53: 84+ A?
nefrit1.gts.dp.ua. (35)
14:27:51.032760 IP 91.193.69.22.53 > 10.21.5.154.59459: 51887 NXDomain
0/1/0 (100)
14:27:51.032773 IP 91.193.69.22.53 > 10.21.5.154.59459: 84* 1/2/2 A
91.193.69.12 (119)
14:27:51.033253 IP 91.193.69.4.53 > 10.21.5.154.32905: 84 1/2/2 A
91.193.69.12 (119)
14:27:51.040717 IP 91.193.69.4.53 > 10.21.5.154.32905: 51887 NXDomain
0/1/0 (100)

So, we have two queries to two nameservers. Two of them have returned
NXDomain, and this result was sent back to a client.
I think this behaviour is wrong, client shouldn't get NXDomain when
other non-nxdomain replies from nameservers exist.

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

-----
Vladimir Pavljuchenkov
Pasi Sjöholm
2015-10-27 13:49:02 UTC
Permalink
Post by SpiderX
~ $ host -v nefrit1
Trying "nefrit1"
Host nefrit1 not found: 3(NXDOMAIN)
Received 100 bytes from 127.0.0.1#53 in 0 ms
So, we have two queries to two nameservers. Two of them have returned
NXDomain, and this result was sent back to a client.
I think this behaviour is wrong, client shouldn't get NXDomain when
other non-nxdomain replies from nameservers exist.
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
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.

Though, it would be nice if it would work also when the response is not
in the cache. I will try to check what broke it..

First try:
host -v -t a bz
Trying "bz"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44260
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;bz. IN A

Received 20 bytes from 127.0.0.1#53 in 122 ms

Second try:
host -v -t a bz
Trying "bz"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26675
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;bz. IN A

;; ANSWER SECTION:
bz. 49 IN A 1.2.3.4

Received 38 bytes from 127.0.0.1#53 in 7 ms

Br,
Pasi
Pasi Sjöholm
2015-10-29 13:06:18 UTC
Permalink
Post by Pasi Sjöholm
Post by SpiderX
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.
Post by Pasi Sjöholm
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

Loading...