Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Distribution: Debian and Fedora Core in equal measure
Squid is an HTTP proxy working on port 80. It takes queries and passes them on to the target host's web server, and stores the response so that others downstream of the proxy can get the web page without having to request from the Internet.
DNS is not HTTP. It uses UDP port 53, and will make queries in a totally different protocol to that which a web proxy can understand, so unless you have some non-squid way of getting DNS queries through the system running the squid proxy, you will get exactly what you are seeing.
I guess you could set up some routing such that the proxy can proxy the HTTP, and simply redirect the DNS query, but to what end? The proxy won't do anything with the DNS messages, so I'd simply send your DNS queries to the right place in the first place.
I would like DNS queries to travel via 192.168.1.13.
Simple DNS forwarding via 192.168.1.13 to the ISP's DNS server.
But you don't explain why you would want to do this. Would you care to enlighten me?
Some reading around suggests I should setup BIND and configure it in FORWARDING mode.
While that would work, it doesn't seem to be the best solution (so, my suspicion is that you could but you shouldn't).
Bind is probably:
the most difficult to configure (you seem to be some way to finding that out)
history suggests its one of the candidates with the worst security record
it is probably the lowest performance solution
most of the above seems to be a consequence of the the fact that it is the most flexible, swiss army knife solution, but if you don't need that flexibility, does that make it a good solution for your situation?
Distribution: Debian and Fedora Core in equal measure
You say you are using 2 ISPs. How are you managing routing to them from within your network (preference of 1 ISP over another). I assume you are using iBGP to get the network to recognise the relative states of the two, and their suitability as a route to the Internet. It might help if we had had this information initially, it complicates your attempts somewhat
You will have DNS servers in both ISPs. You could set up a DNS cache server (using something like DJBDNS, or if you *must*, then BIND) and arrange that your DNS cache server collects information from one, the other or both ISPs, and have the clients in the network point at the DNS Cache server for resolution.
FWIW, I totally concurr with salasi's analysis of BIND, it's from a long time ago when there weren't bad people on the 'net and alternatives should be examined
Currently, I manually change the G/w IP in ifcfg-eth0 whenevr ISP-1 goes down.
so, you are only trying to cure half of the problem...
Can you suggest the simplest of options : DJBDNS or BIND or anything else ??
I am unsure what is in the centos repositories for this version (which is a factor, but one that you are in a better position to check than I am), but:
DNSMASQ and maradns are possibly as easy as they can be. Pdns is a possible too (but I've never installed it so I'm guessing).
As Dnsmasq can also act as a DHCP server, if you want both, probably that's the best choice. (Its still in the race, even if you only want DNS.)
DJBDNS is a good option, too, but, the last time I installed it (an old ubuntu) it wasn't a simple 'install from repos' but a somewhat involved local build. Not really difficult, but rather more stages than you'd like. If it is available from repos for your distro, this doesn't apply.
That said, having built it, the time to configure was just seconds.
Out of the list, DJBDNS is probably, judging by the historical record, the most secure. Even when Bind has vulns that are common to others, Bind is probably the one that gets the most hack attempts, as the hackers (& script kiddies, if that's a wortwhile distiction) try to go after the one that is most used in the Fortune-500-type (and, probably more to the point, three letter agencies and the like) sites.
So, if you do decide on Bind, someone in your organisation (and that may be one person) has got to realise that part of their job is to make frequent checks on whether new vulnerabilities have been found and taking the action to mitigate the threats in double quick time, and that has to happen good days and bad, high days and holidays. If your organisation isn't capable of doing this, you shouldn't be using Bind.