forwarding & query-source (was Re: name caching and forwarding)

[Shawn Bakhtiar]

A better solution may be (if feasible) to register and get an internet AS number and enable BGP on both links. If one fails the upstream routers (even if from desperate providers) will detect a fail and re-rout via the active link.

http://en.wikipedia.org/wiki/Border_Gateway_Protocol

This is NOT a load balancing solution, you will still have one active route at any given time, but you can setup your servers on the same IP segment if you choose, and let the routers deal with where the traffic is coming from or going to. You can use egress ACLs to sudo balance the outgoing too, but that's very hackish.


> Date: Sat, 2 Mar 2013 16:16:28 +0100
> From: uhlar at fantomas.sk
> To: bind-users at lists.isc.org
> Subject: Re: forwarding & query-source (was Re: name caching and forwarding)
> 
> On 01.03.13 17:23, Lawrence K. Chen, P.Eng. wrote:
> > I thought I had read somewhere the query-source default is to try making
> > queries from all the IPs on my system.
> 
> No, the default is to use special IP "0.0.0.0" that causes the system (not
> the BIND) to select source IP address.
> 
> > And, my DNS servers have two IPs on them....using policy based routing,
> > the first IP routes out on my fast though less reliable internet
> > connection and the second IP routes out on my slower but reliable (though
> > the router is acting up on this link now) internet connection.
> 
> You are apparently aware that source IP address has nothing to do with the
> link the packets are out by default - this is why you've had to configure
> policy routing.
> 
> > Problem I found was that when my fast internet connection goes
> > down....queries stop working.  Had to explicitly set query-source to use
> > the second IP.
> 
> When your link is down, the packets sent through the link will not be
> delivered.
> 
> The whole solution about using multiple links requires provider-independent
> IP Addresses, both ISP's cooperation or much of playing with routing, NAT
> and other servers' configuration - not only DNS, if you want e.g.  your mail
> to get delivered.
> 
> > So, I thought I could trick my caching servers to handle the dual routing
> > that I wanted, by setting the two prod servers to 'forward first' to my
> > dev server, which sends its queries out on fast connection and assume that
> > they would query out over the slow connection if the 'forward first'
> > doesn't yield an answer.
> 
> you can do this by using server {} bind statement for the forwarders, with
> different IP in query-source and possibly other *-source options.
> 
> > And, then I was surprised by a flood of email.  My mailservers weren't
> > able to resolve addresses because the forwarder wasn't responding....  I
> > suppose its because its udp it isn't quick about deciding that there's no
> > service to answer.
> 
> This has nothing to do with UDP. The bind tries to forward and has own
> timeouts (3 to 12 seconds iirc) when forwarder in unreachable.
> 
> >  Does this timeout problem also impact "forward only"
> > and a list of forwarders?  I have a set of servers with 10.x.x.x IPs with
> > local caching DNS servers configured to forward only to a pair of caching
> > DNS servers with public IPs.
> 
> Yes, with the difference that "forward only" will only try forwarders, and
> when they fail, it will fail too. "forward first" will do the resolution by
> itself when all forwarders fail, thus it should be more reliable.
> 
> > So, how would I make forwarding not prevent resolution?  Or can I get bind
> > to try both IPs in trying to do queries?
> 
> BIND always wants to be responsive, so it will repeatedly try all forwarders
> (it will prefer servers that respond but time to time it re-tries those
> unresponsive too).
> 
> 
> I'm not sure whether you are solving the problem with multiple links at
> right level.  Your router(s) could possibly detect the link outage sooner
> and switch to another link, maybe with NATting to other IP.  However, your
> DNS problem chould be solved by BIND configuration.
> -- 
> Matus UHLAR - fantomas, uhlar at fantomas.sk ; http://www.fantomas.sk/
> Warning: I wish NOT to receive e-mail advertising to this address.
> Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
> Chernobyl was an Windows 95 beta test site.
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20130304/a81afa71/attachment.html>