Red Hat

We are using internal DNS server to relove for internal systems, and the same DNS server resolves any external domains for example yahoo.com

I would like to use openddns to resolve the external domains and put some control.

I looked at the resolve.conf file and it is as follows

search myinternaldomain.com
nameserver 127.0.0.1


My first question is why the nameserver is pointing to 127.0.0.1,
How is it resolving the external domains.

should I just add the opendns entry here in the resolv.conf


TIA

Well, 127.0.0.1 is ok for resolv.conf on the name server, very portable unless you want to see it from the outside. Any client app will use resolv.conf to find a name server, so that name server must be an ip or in /etc/hosts to give the ip.

The server side of having a domain is to have a parent list you as its child. Then, even if hosts point to other initial name servers, they get the answers from you.

DNS is a bit insecure, so it is nice to use it with dnssec, which in turn requires that you get a certificate trusted by someone trusted.

You can put some convenient lies in DNS, but I am not sure what sort of "control" you get. I once set up a DNS that said aol was the firewall, where there was a forwarding proxy to the real aol. Since all external DNS inquiry went through the firewall DNS server, it intercepted all such requests.

You do not need roots to get DNS going, you use your ISPs DNS as your roots, and they redirect you to the real ones so you do not have to know when they change.

The question that come to mind is why? What do you expect to gain by doing this?
What controls are you looking for here?

Because it doesn't need to look anywhere else to resolve requests as it knows how to do this itself.

Because it knows how to ask the ROOT servers where to find the information it is looking for.

You could but it would not help you. resolv.conf is used by programs on that system only not others requesting DNS information.

I can think of one great reason why you should not mess with this server. You don't understand how DNS works or configured. Your best bet is to learn how to configure DNS servers, on another test system, before you mess with this server so you don't bring all connections to a stand still because DNS is not working.

Yes, resolv.conf or equivalent information is at the client end of DNS, so when apps call gethostbyname() they know where to go besides the hosts file or such. Being dumb clients, they call the first working DNS server in there to resolve the name, selecting randomly, possibly with their domain tacked on the right end. Names ending in '.' do not get domains tried on the right end.

The first DNS server probably does not know the answer, unless he serves that domain, so as the poor client asked for recursion, he will keep asking dns servers (without recursion, so he can build his cache) until he has an answer. Then, he will cache it for its lifetime. For ftp.boulder.ibm.com, knowing nothing, he would call his root server for the "com" domain (top level), which should be his ISP, but if you are the ISP, you need to keep your list of real roots up to date. The "com" server will say go bother the name servers for "ibm.com" and give a list, the nameservers for "ibm.com" may say go ask "boulder.ibm.com" DNS nameservers, and give a list. One of them will answer you. You will cache all of these answers for their lifetime. The real root servers are a pile of computers in two tiers, with the first tier host forwarding to a right choice on the second tier based on database segmentation, and the second sending answers directly, a triangular circuit, since UDP is connectionless!

That was DNS server life on the client side.

The DNS server side involves a parent that says you control some subtree of the world's namespace and knows your master and your slaves's names and IPs, zone transfers from your master to your slaves, domain and host information for the domains you control. BIND puts this in simple text files, but some implementations use RDBMS, LDAP, or even the Windows name server thing that I forget already! Any domain can have many servers, but only one should be master and be updated.

DNS is very simple for the query, UDP packets on one unconnected socket port 53, and one packet in drives one packet out, generally. Lost packets are not a big deal, as the end client will time out and resend his query. DNS Server internal state involves remembering recursion requests not filled, so when answers final or partial arrive, the answer or next question, respectively, can be sent. Zone transfers move the domain info from master to slave on the same socket number but TCP port 53 (slaves pull, as I recall). Security gets hacked when unsolicited bogus packets arrive, and are trustingly accepted, poisoning the cache. DNSSEC ensures the packets are from the real sending server, who is trusted by chain, using encryption and signatures.

Firewall DNS is common, so the hosts internally, either end clients or internal DNS servers supporting the end clients while protecting the firewall from that load, and possibly on unroutable addresses like 10.*, are not exposed as they seek IP addresses on the Internet. Your hosts accessible from the Internet can be name-hosted there, although you need an outside visible backup server or so for reliability if not bandwidth. Internal DNS can tell lies to send internal apps to a firewall for proxy access to real hosts on the outside. Since firewall tasks involve a lot of reverse DNS, having a server handy speeds things up and reduces network load.

DNS can provide failover reliability, if each app server is a DNS server for itself. Clients skip over dead DNS servers looking for live DNS servers, and the live DNS server says it is the app server. DNS server choice is random, spreading the load on all live servers somewhat evenly.

See, DNS is beautiful, elegant and not so hard. Did I miss anything Google and man cannot fill in?

If you look at opendns.com, opendns service allows to block dns queries to sites , like I want to block radio sites, phishing sites, porn and more.
This is management requirement.

The current DNS was built by my pre-decessor, I just want to resolve external sites using the opendns name server 208.67.222.222 and 208.67.220.220

I havent worked with bind, that is why I am asking the gurus, after reading I think I need to change the root hints to point to opendns

Well, even if there was no blocking built in as such, you can define any domain name server or host as localhost 127.0.0.1, just like Spybot S&D Immunize, or whatever target you desire to give a graceful denial response. It falls under "lies you can tell"!

Too bad http GET is not as elegant as DNS query. No connection delay and bandwidth use, one server socket for all, one in for one out, different hosts can answer and you can even use broadcast IPs with UDP to hit redundant hosts on the same subnet!

Then instead of changing the root hints file just make your dns server a forward only system that forwards everything to opendns.

Make a backup copy of named.conf before editing anything so you can back out if there is a problem.
Look at the config file for options and change it like so:

Code:

options {
        forward only;
        forwarders {
            <first ip of opendns>;
            <second ip of opendns>;
        };
    };