< Previous by Date Date Index Next by Date >
< Previous in Thread Thread Index Next in Thread >

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


 inlined.

> -----Original Message-----
> From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx] 
> Sent: Monday, July 16, 2007 7:10 AM
> To: Van C. Nguyen
> Cc: resiprocate-devel@xxxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] ares doesn't send query to DNS 
> servers of other subnets
> 
> Are you sure we aren't just dealing with an issue around 
> which order servers are tried?

Yes we are. There are only 2 solutions that I'm aware of

1) solving it via software as I've proposed and what other applications that
I've mentioned do.

2) tell the customers of resip-based client softphone that if they use VPN
(or similar multi-NIC, private host setup) and VPN is not setup as the top
network, to follow the following steps:

Go to 'Control Panel | Network Connections | Advanced | Advanced Settings |
Adapters and Bindings'.
...

Somewhat ugly from a customer-care perspective. This is a recurring
complaint for us but your "proprietary behaviour" concern is duly noted
since this is a setup problem, most prevalent in a client invironment. It
will be implemented in our internal code base and a patch will be released
for whomever is interested.

> It violates the DNS specifications to ask another server once 
> you get a "no such name" answer.
> (split DNS is a underspecified hack of the DNS system. The 
> only sane resolver strategy in the
>   face of split DNS that I've seen so far is to make sure 
> your resolving servers are listed in the order
>   that's most important to you).
> 
> To go down the path you propose will take us into very 
> proprietary behavior, and we'd eventually have to argue about 
> what to do if the same name exists with different answers in 
> two different private DNS spaces (You have a vpn to A and to 
> B and they both answer queries for name N, but with different 
> results - what are you going to do?)

I've thought about that. In that case, they're asking for trouble since they
know they're connected to two different private network with the same
hostname, somehow. As such, best effort: first DNS answer comes, first
served, which is based on which of the private DNS server is first.

Regards,
Van.

> Before we go there, lets make sure we're honoring that most 
> important order already.
> 
> RjS
> 
> On Jul 13, 2007, at 8:14 PM, Van C. Nguyen wrote:
> 
> > 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.6/902 - Release Date: 7/15/2007
2:21 PM