Re: [reSIProcate] ares doesn't send query to DNS servers of othersubnets

["Van C. Nguyen" <vann@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxx 
> [mailto:resiprocate-devel-bounces@xxxxxxxxxxxxxxxxxxxx] On 
> Behalf Of Van C. Nguyen
> Sent: Friday, July 13, 2007 6:15 PM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxx
> 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

Attachment: ares-and-multi-networks.patch
Description: Binary data