cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
995
Views
0
Helpful
2
Replies

How to Disable the EDNS option OPT in the DNSlookup from Jabber Android?

david.alfaro
Level 1
Level 1

Hi Guys,

 

We recently have installed RMA vía Expressway.

 

In the most of the cases all of the client device types work fine in several networks (as internal as external), except some users who they are in their homes, using their domestic network with android devices.

 

When an user is in his home using its domestic connection, with jabber android, when he try to get connect, he receive the following error message

error.JPG

Now, when we change the local DNS settings of the domestic network, for example using now 8.8.8.8 or OpenDNS, the connection is succefull.

 

Also we have tested the jabber for windows in the same domestic network using the same Internal DNS, and the connection was right. So where is the problem? is it in the mobile phone, in the jabber app, or in the ISP router ?

 

So we found the following doing several tests.

 

First we got packet captures:

 

Using Jabber windows  with internal DNS targeting to the router (192.168.100.1), the result was succefull;

Using Jabber android with internal DNS targeting to the router (192.168.100.1), the result was failed

Using Jabber android with public DNS targeting to 8.8.8.8, the result was succefull

 

I attach packet captures for the three cases.

 

We have found that when the problem is showed, jabber android receive DNS response type authoritative server (that is impossible), in addition, the jabber android insert a extension EDNS type OPT, apparently the ISP router is not supporting this property, also receiving a error message of Malformed Packet. Unfortunately we have not access to the isp router

 

In the case of the jabber windows using internal DNS, the connection is OK (no EDNS option OPT is used)

log 6 OK.JPG

response

WINDOWS-OK.JPG

 

 

in the case of the jabber android using public DNS 8.8.8.8, the connection is OK

log 5 OK.JPG response

ANDROID-OK.JPG

 

 

and when the jabber android uses the internal DNS, the connection fail

 log 4 fail.JPG

response

ANDROID-FAIL.JPG

 

in the logs from expressway E, we found that when the internal DNS of the remote domestic network  is used, the get_edge_config is not correct

Exp E

log 1 fail.JPG

 

and when the DNS 8.8.8.8 is used, the connection is OK, and of course the get_edge_config is right

 

Exp E

log 2 OK.JPG

 

Exp C

 

log 3 OK.JPG

 

 

In order of all of above, is it possible the modify the dns lookup behavior (disabling EDNS tipe OPT) of the jabber android ? or whats is the difference between the DNS of the ISP in the domestic network and using a public DNS? why it fails with one DNS and works fine with the another one? Have you facing a similar issue? if so, how did you solve it??

 

many thanks in advance,

 

regards

 

 

 

 

2 Replies 2

EDNS OPT is inserted by the DNS client and not related to Jabber. In this
case its your Andriod phone. Does they user have DNS security again running
on the phone (such as cisco umbrella roaming client)? This will insert OPT

Can you share full pcap? It seems that DNS server responds correctly I want
to see whats happening next.

Hi Mohammed,

 

Excuse me for my reply too many late. Thanks for your patience.

 

I reviewed the applications in the device and I did not find any type of DNS security and stuff like that. I am adding the full packet capture of this scenario. I made some tests with another android device, and the result was the same, taking account this one is new and just extracted of its box, so I share the following captures

 

2018_05_12_152234.pcap is the capture with the original device what I opened the post with. It is a Huawei  Y6 MYA-L13 (android 6.0)

 

2018_05_12_145617.pcap is the capture with the new one, it is a Moto E4 (android 7.1.1).

 

The curious thing I seen, is that after the SRV record _collab-edge._tls is solved, the lookup of the record A split (or remove) the hostname of the full FQDN, leaving alone just the domain and then it try to solve the part of the domain.

 

In this case we saw that SRV record solve correctly hostname.domain, but when it try to solve record A, this remove the hostname part, and just leave alone the domain part to solve it, what it is not good.

 

 

best regards,