[reSIProcate] ares doesn't send query to DNS servers of othersubnets
Van C. Nguyen
vann at counterpath.com
Mon Jul 23 21:36:21 CDT 2007
Attached is the patch to the problem described earlier. It needs to be
applied to
../rep/resiprocate/main/
It is agreed that this is a fix to a problem that is beyond the scope of the
DNS specifications: a setup/configuration problem of the host machine if you
will. It is considered a feature to ares.
By default, the feature is turned *off* so existing implementation will not
be affected (other then the few extra bytes of binary). To enable it, call
the static method DnsStub::enableDnsFeatures(
ExternalDns::TryServersOfNextNetworkUponRcode3 ) before creating the
SipStack. This configuration approach is based on the existing mechanism,
eg. static DnsStub::setDnsTimeoutAndTries.
Currently there's only a Win32 implementation.
Speak if you object to me adding this to the code base.
Van.
> -----Original Message-----
> From: resiprocate-devel-bounces at list.resiprocate.org
> [mailto:resiprocate-devel-bounces at list.resiprocate.org] On
> Behalf Of Van C. Nguyen
> Sent: Friday, July 13, 2007 6:15 PM
> To: resiprocate-devel at list.resiprocate.org
> Subject: [reSIProcate] ares doesn't send query to DNS servers
> of othersubnets
>
> Below is a description of a limitation of ares and a proposed
> solution. This limitation I do not believe is limited to just Windows.
>
>
> 1.0) Brief description
>
> When a host is connected to multiple subnets, via multiple
> adapters: be they physical or virtual, ares will only attempt
> to connect/send query to the first DNS server in its list of
> servers (ares_channeldata.servers), while not attempting the
> others when the query in question fails with 'No such name'
> (reply-code of 3, 0x0011). Ares will only attempt subsequent
> DNS servers - be they secondary of the one just tried or
> primary to the other subnets - if it fails to connect to the
> current server or if the request times out.
>
> The problem just described is most prevalent when one tries
> to resolve a hostname in the private network via VPN.
>
>
> 2.0) A little more detailed
>
> Suppose you have the setup below with the order of
> "Connections" (the order of DNS servers to try) as follows:
>
> Local LAN adapter
> primary DNS server: 192.168.0.90
> secondary DNS server: 192.168.0.91
> subnet-mask: 255.255.0.0
>
> VPN adapter
> primary DNS server: 10.20.0.1
> secondary DNS server: 10.20.0.2
> subnet-mask: 255.255.255.0
> - dns servers contain records for private host internal.example.com
>
> The order of adapters (the subnet's DNS server to be used for name
> resolution) can be viewed in Windows under:
> 'Control Panel | Network Connections | Advanced | Advanced
> Settings | Adapters and Bindings'.
>
> With the setup above, the ares' list of servers
> (ares_channeldata.servers) are as follows:
> 192.168.0.90, 192.168.0.91, 10.20.0.1, 10.20.0.2
>
> Should a UA wants to resolve the target internal.example.com
> to send the REGISTER request:
> * ares will send the DNS query to 192.168.0.90
> * server will respond with 'No such name'
> * ares will halt the operation and resip 503 the REGISTER request.
>
> Other applications such as Firefox and IE would send the
> query to the DNS server associated with the adapter/subnet
> first in the list, then should that fail, try the second and
> so on. One can easily verify this by snooping on the two adapters.
>
>
> 3.0) Proposed solution
>
> * Ares (struct server_state) should associate each DNS
> servers with its subnet, by way of its subnet address (subnet
> mask applied to DNS server IP, for V4 and subnet address bit
> range for V6 (2002::/64).
>
> * For each subnets/adapters, there's a set of DNS servers: be
> it primary, secondary or tertiary. For each set, one and only
> one of the servers will be tried should the query response
> 'No such name' be received. All the sets are tried until, of
> course, success or exhausted.
>
> * Save the subnet address in ares' server_state structure.
>
> * Check for rcode of 3 in process_answer and call the new
> function
> 'next_server_of_subnet_which_we_havent_visited_before' or
> something shorter.
>
> Will post a patch sometime next week.
>
> Van.
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.10.4/898 - Release
> Date: 7/12/2007
> 4:08 PM
>
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel at list.resiprocate.org
> https://list.resiprocate.org/mailman/listinfo/resiprocate-devel
>
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.476 / Virus Database: 269.10.6/902 - Release
> Date: 7/15/2007 2:21 PM
>
>
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.5.476 / Virus Database: 269.10.14/912 - Release Date: 7/22/2007
7:02 PM
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ares-and-multi-networks.patch
Type: application/octet-stream
Size: 15207 bytes
Desc: not available
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20070723/64d1a276/attachment.obj>
More information about the resiprocate-devel
mailing list