[erlang-questions] how to debug inet_res?

[Raimo Niskanen]

On Tue, Feb 12, 2013 at 06:49:57PM +0100, Benoit Chesneau wrote:
> On Tue, Feb 12, 2013 at 5:17 PM, Raimo Niskanen
> <raimo+erlang-questions@REDACTED> wrote:
> > On Tue, Feb 12, 2013 at 04:28:17PM +0100, Benoit Chesneau wrote:
> >> Hi all,
> >>
> >> I am using a custom version of Erlang on iOS and for some reasons I
> >> ignore yet the DNS resolution is failing in some networks. Since you
> >> can't launch ports on iOS due to the sandboxing, Erlang is using the
> >> module inet_res to do the resolution. Which works well on some network
> >> but return {error, nxdomain} in an office at Singapore.
> >>
> >> Testing the same domain name on desktop with native or inet_res return
> >> the IP address correctly. For now I have written a small nif to do the
> >> gethostbyname call but I'm still curious to know why it fails on IOS.
> >> not sure which kind of test I should do. Any idea?
> >
> > inet_res is the DNS resolver client written in Erlang. It does not call
> > gethostbyname. The module inet_gethost_native uses an external port
> > program to call gethostbyname.
> >
> > For inet_res, first try this:
> >     rr(inet_res).
> >     inet_res:resolve("google.com", in, a).
> >
> > If that does not work; I first suggest you call inet_db:get_rc() to get a
> > summary of what settings are used (on both machines) and compare.
> 
> I did that this is why i'm speaking about inet_res.
> 
> On ios: {file, dns} where the desktop has native. To compare both
> machine I did a test using `inet_res:gethostbyname/1` and
> `inet_hosts:gethostbyname/1`  on the same network (wifi).

Did that mean there is an rc entry {lookup,[file,dns]} on iOS?

> 
> in each case inet_hosts weren't working (desktop is on the mac),
> strangely it returns {error, nxdomain} on the desktop and {error,
> timeout} on ios. inet_res resolution is working on the desktop and not
> on iOS.

The module inet_hosts is the backend for the lookup method 'file' that
looks into an internal cache of what was found when reading /etc/hosts.
You can only expect to find 'localhost' and such there.

The lookup method that calls gethostbyname in the OS is called 'native'
and uses the backend module inet_gethost_native. It also uses an external
port program inet_gethost that may pose problems for those who port to
e.g iOS... Maybe that is why you have {lookup,[file,dns]} instead of the
default {lookup,[native]}. The native resolver is the one that is aimed
to be the most correct since it uses OS native calls hence the OS name
resolution configuration.

It may be so that the default behaviour for inet_res of monitoring
/etc/resolv.conf does not work on iOS since there maybe is no such file;
who knows how the resolver is configured on iOS? inet_res has to figure
out a nameserver - try using {nameservers,[{{127,0,0,1},53}]} since there
might be a DNS caching server running on the loopback interface.

> 
> >
> > Then you can look at the internal ETS table ets:i(inet_db) and compare them
> > on both machines.
> >
> > To use a specific nameserver:
> >     inet_res:resolve("google.com", in, a, [{nameservers,[{{8,8,8,8},53}]}]).
> >
> > That looks up Googles address at Googles public nameserver 8.8.8.8.
> > It does not work for me since I am behind a company firewall that does not
> > allow outgoing DNS queries. I have to use a local nameserver. That local
> > nameserver should be found in the ets table inet_db which should show in
> > the inet_db:get_rc() output. If so e.g inet_res:gethostbyname("google.com")
> > will produce a hostent record.
> >
> > Note. There is some magic in play indicated by an automatic default entry
> > {resolv_conf,"/etc/resolv.conf"} in the inet_db:get_rc() output. That causes
> > inet_res to update inet_db with content from /etc/resolv.conf before doing
> > a DNS query.
> >
> > So do an inet_res call first; then if it does not work check the internal
> > tables. Compare the tables before and after the first call.
> 
> 
> Thanks will try that.
> >
> > You can also add an argument 'verbose' to the argument 4 option list of
> > inet_res:resolve/4 that will show which servers are tried and what they
> > reply / timeout.
> >
> 
> I didn't know about the verbose option, will try it as well. I will
> update the thread with my results here.
> 
> - benoît
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB