[erlang-questions] Number of dns resolvers

Raimo Niskanen raimo+erlang-questions@REDACTED
Tue Mar 9 12:40:13 CET 2010


Step up to at least R13B02 or try the undocumented kernel option:
$ erl -kernel gethost_poolsize 17

On Wed, Mar 03, 2010 at 01:41:55AM +0300, Konstantin Sorokin wrote:
> On Wed, Mar 3, 2010 at 1:30 AM, Yuri Ginsburg <yg@REDACTED> wrote:
> > That's the line:
> > {resolv_conf, "/etc/resolv.conf"}
> > that causes syntax error on R12... but is OK in R13..
> 
> No. At least it is not true for Erlang R13B0, which is shipped with fedora 12

I have tested and it works in R13B02 but not in R13B plain.
Unfortunately I have no R13B01 for quick testing but the
features were introduced in R13B02; part of release notes for
R13B02-1 <http://erlang.org/download/otp_src_R13B02-1.readme>:

--- kernel-2.13.3 -------------------------------------------------------

    OTP-7955  The DNS resolver client inet_res has been rewritten,
	      documented and released. See inet_res(3) and Erts User's
	      Guide: Inet configuration.

	      It can formally not be incompatible with respect to earlier
	      versions since there was no earlier official version. However
	      it was used before and some details have changed.

	      Configuration now initializes from /etc/resolv.conf and
	      /etc/hosts on all unix platforms regardless of which
	      distribution mode the node is started in. The directory
	      (/etc) these files are supposed to reside in can be changed
	      via an environment variable. These configuration file
	      locations can also be changed in the inet configuration. The
	      files are monitored for change and re-read, which makes a few
	      resolver configuration variables out of application control.
	      The /etc/hosts entries have now their own cache table that is
	      shadowed (with lookup method 'file' is used) by the
	      application configured host entries. This problem (that
	      inet_res configuration only worked for distribution mode long
	      names) was among other reported by Matthew O'Gorman many
	      moons ago.

	      The lookup methods are still 'native' only per default.
	      Resolver configuration is done on all Unix platforms just to
	      get a usable configuration for direct calls to inet_res.

	      The functions inet_res:nslookup/3..5 and
	      inet_res:nnslookup/4..4 are no longer recommended to use,
	      instead use inet_res:lookup/3..5 and inet_res:resolve/3..5
	      which provide clearer argument types and the possibility to
	      override options in the call.

	      Users of previous unsupported versions of inet_res have
	      included internal header files to get to the internal record
	      definitions in order to examine DNS replies. This is still
	      unsupported and there are access functions in inet_dns to use
	      instead. These are documented in inet_res(3).

	      Bug fix: a compression reference loop would make DNS message
	      decoding loop forever. Problem reported by Florian Weimer.

	      Bug fix and patch suggestion by Sergei Golovan: configuring
	      IPv6 nameservers did not work. His patch (as he warned)
	      created many UDP sockets; one per nameserver. This has been
	      fixed in the released version.

	      Improvement: inet_res is now EDNS0 capable. The current
	      implementation is simple and does not probe and cache EDNS
	      info for nameservers, which a fully capable implementation
	      probably should do. EDNS has to be enabled via resolver
	      configuration, and if a nameserver replies that it does not
	      support EDNS, inet_res falls back to a regular DNS query.

	      Improvement: now inet_res automatically falls back to TCP if
	      it gets a truncated answer from a nameserver.

	      Warning: some of the ancient and exotic record types handled
	      by inet_res and inet_dns are not supported by current
	      versions of BIND, so they could not be tested after the
	      rewrite, with reasonable effort, e.g MD, MF, NULL, and SPF.
	      The risk for bugs in these particular records is still low
	      since their code is mostly shared with other tested record
	      types.

> 
> [kvs@REDACTED ~]$ cat /home/kvs/.erl_inetrc
> %{file, resolv, "/etc/resolv.conf"}.
> {resolv_conf, "/etc/resolv.conf"}.
> {file, hosts, "/etc/hosts"}.
> {cache_size, 0}.
> {lookup, [dns]}.
> [kvs@REDACTED ~]$ erl -kernel inetrc "'/home/kvs/.erl_inetrc'"
> {error_logger,{{2010,3,3},{1,39,57}},"inet_config: syntax error in
> ~s~n",['/home/kvs/.erl_inetrc']}
> Erlang R13B01 (erts-5.7.2) [source] [rq:1] [async-threads:0] [hipe]
> [kernel-poll:false]
> 
> 
> =ERROR REPORT==== 3-Mar-2010::01:39:57 ===
> inet_config: syntax error in /home/kvs/.erl_inetrc
> Eshell V5.7.2  (abort with ^G)
> 1>
> [kvs@REDACTED ~]$ rpm -qa | grep erlang
> erlang-R13B-01.3.fc12.i686
> 
> -- 
> Konstantin Sorokin
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB


More information about the erlang-questions mailing list