From reSIProcate
Revision as of 08:29, 2 February 2011 by Sgodin (talk | contribs)
Jump to navigation Jump to search


Why Asynchronous DNS


ares_gethostbyname() and ares_gethostbyaddr() (but not ares_query()!) ares functions will look in the following locations for the hosts file if it fails to find the entry via a DNS lookup

  • On *nix systems - /etc/hosts
  • On *nix systems when ETC_INET is defined - /etc/inet/hosts
  • On Win32 systems - location of hosts file is retrieved from registry - typically: c:\Windows\System32\drivers\etc\hosts
  • On OS X systems - the NetInfoManager, in the machines directory

If you put the following line into /etc/resolv.conf:

  lookup f b

you are telling the functions to look in the hosts (f)ile before DNS(b) servers. (b is for bind).

For windows environments the resolv.conf file will be retrieved from the drive of the working directory of the resip executable: ie. d:\etc\resolv.conf

Note that reSIProcate in its current implementation uses only ares_query(). So, /etc/hosts is ignored. (See also http://list.sipfoundry.org/archive/resiprocate-devel/msg04973.html thread.)

ENUM Support

The rutil library has a basic level of support for ENUM queries, as do the DNS related classes under resip/stack. Currently the stack will atempt ENUM DNS resolution if an enum suffix is configured, and if the user part of the URI to resolve is at least 2 characters and starts with a '+' character. This is true for both sip(s): and tel: URI's.

Current Limitations:

  1. The stack allows setting of multiple ENUM suffixes, but only ever uses the first one in the list.
  2. If an ENUM query returns a regular expression, then it will not be processed properly. Only straight substitutions are currently supported.

DNS Cache

reSIProcate DNS layer has a built-in cache that supports three different markers to help determine which DNS entries to use: whitelisted, greylisted and blacklisted.

  • whitelisted => stack will always use that tuple, regardless of the availability of others
  • greylisted => stack will only send to that tuple unless no other tuples remain (if all tuples are greylisted, they're all fair game
  • blacklisted => stack will refuse to send to that tuple

Generally, resip greylists on transport failure or transaction timeout, blacklists on a 503 with a Retry-After, and if support is compiled in (USE_DNS_VIP define), we whitelist whenever a transaction gets a response (this can help a client to re-use the same SBC/proxy for every request they send - some people feel this is a bad approach, but it is disabled at compile time by default). This means that in cases where a server is unreachable, resip will not full-on refuse to try to contact it again, since it is only greylisted. If the server _tells_ us to not contact it again for 10 seconds, we will honor that request, because that results in a blacklist.