| DNS server question Good morning folks.
I have a question about DNS that I've always wante to know just have never posted.
In my little network I have 2 inhouse DNS servers, and two Mikrotiks running my towers, and my gateway router.
Should I have my upstream providers DNS numbers in any of these machines, or just my own in each?
As always, thanks for your answers.
Jakkwb |
|
| your customers should use your dns servers and then your dns servers should have all of the root severs listed, ... |
|
| reply to jakkwb
I run a DNS server which is assigned to my customers. Above me, I use Google's DNS servers. |
|
| reply to jakkwb
I also use Google's. I would prefer to use openDNS as I can get some nice free stats, but I refuse to touch them again. About 2 years ago they had a problem where they were screwing with TTLs of records before handing them off to us and it was causing all kinds of problems with large sites like Google or Yahoo or Facebook or Ebay etc.
Only way around it was to completely bail from OpenDNS. So we did and will never look back. It was reported all over the place in their forums, and they denied denied denied. No idea if they finally got their shit together or not. |
|
| reply to jakkwb
Your DNS servers should get hints from the root servers and never your upstream's DNS servers. If you are getting hints from your upstream you have a single point of failure. You also avoid any DNS trickery that your upstream may add in the future. |
|
 DaDawgsPremium
join:2010-08-02
Deltaville, VA | reply to voxframe
said by voxframe:I also use Google's. I would prefer to use openDNS as I can get some nice free stats, but I refuse to touch them again. About 2 years ago they had a problem where they were screwing with TTLs of records before handing them off to us and it was causing all kinds of problems with large sites like Google or Yahoo or Facebook or Ebay etc.
Only way around it was to completely bail from OpenDNS. So we did and will never look back. It was reported all over the place in their forums, and they denied denied denied. No idea if they finally got their shit together or not.
You know you get what you PAY for...
--
Once we IPv6 enable every device on the Internet we will have toasters, baby monitors, and security cameras joining the bot nets which today are populated only by idiots that can not refrain from clicking, "Yes I would like to see those titties..."
|
|
|
|
| reply to jakkwb
Hehehe Yep |
|
| reply to dmburgess
This is how I do it with root servers. I have 2 recursive caching DNS and 2 authorative for my domains.
--
OptionsDSL Wireless Internet
»www.optionsdsl.ca |
|
 TomS_Git-r-donePremium,MVM
join:2002-07-19
Ireland
kudos:1 | reply to battleop
said by battleop:Your DNS servers should get hints from the root servers Actually, hints are a local database on your resolvers that tell them where the roots are. 
The most up to date hints file can be obtained here (and its a good idea to keep it updated, sometimes things change and this could introduce latency when resolving, and also reduce your potential to resolve at all): »www.internic.net/zones/named.root
If you have a *nix box with Bind installed, or perhaps just the "dig" utility on its own, try the following:
dig +trace <hostname>
and watch it spell it out for you. 
DNS is a hierarchical system, so say for example you want to resolve www.dslreports.com, first your resolver will ask a root "where is .com", which will return the authoritative servers for the .com TLD as NS records, and it will ask one of those servers "where is dslreports.com", which will probably return the authoritative servers for this website as NS records, and if you ask one of them "where is www.dslreports.com" it will probably return an A record with the web servers IP - this is the authoritative answer, and the result is returned to the client that requested it and is probably cached for the period indicated by the TTL field (which indicates the number of seconds the cache should retain that record so that it can expire and be refreshed). Quite a simple but none the less cool little system.
dig can tell you what an individual resolver currently has TTL wise for any given record, from which you can determine whether the record has already been resolved, how long ago, and when it will need to be resolved again.
It is a good idea to keep your resolvers separate from your authoritatives. Resolvers cache information received from authoritative servers, so you dont necessarily want someone to be able to resolve a domain through your resolver, then use it as an authoritative source of information about that domain... which is a kind of "DNS injection" attack.
A good practice is to locate at least 1 authoritative server off your network incase of local issues, people will still be able to resolve things like your MX records which means they shouldnt get really ugly bounces because youve fallen off the face of the 'net. At worst delivery of messages will be delayed because your mail server isnt responding (still bad, but a lot better). Host it on a cheapie VPS somewhere across the country.
This means you probably need to run 4 servers (or instances), but in theory you could do it with 2-3 physical/virtual servers, just give them a couple of IPs, and run multiple DNS server instances, each configured to operate on a different IP. Perhaps one server each for your primary resolver and master authoritative, and one box combined for the secondary resolver/slave authoritative?
If you want to go deeper, you can also operate a phantom master authoritative. This holds all of your zone files, and you have multiple slave servers that you delegate domains to, so your master never gets touched by the outside world. |
|
| reply to jakkwb
It seems like most small companies are outsourcing their authoritative DNS these days - especially WISPs who don't have to manage lots of domains. Makes sense. DNS can be complicated, but it doesn't really have to be for most smaller ISPs.
Regarding resolving/recursive servers:
I would operate two recursive servers (BIND, PowerDNS, whatever you are most comfortable with) in two locations on your network (if possible). I would hand out both of these DNS servers to customers (via DHCP, PPPoE, etc). The customer's primary DNS server would be the one closest to them on the network. These DNS servers would use hints to query the root servers and recurse to answer queries from there - no need to forward on to Google or anybody else. This just complicates the configuration and introduces another point of failure in your network.
As these servers are recursing to nameservers out on the internet to resolve hostnames, they are also building a cache which makes resolution for local clients faster as they no longer have to go out to the Internet to get an answer for the query. It's not uncommon to throw a local cache at a tower/remote site that customers at that site use - especially if the tower's link isn't exceptional. Slow DNS can make a user's browsing experience horrible - and obviously generate a ton of calls.
On another note, if you do operate a BIND recursive server you should patch it ASAP for this vulnerability which surfaced earlier this week:
»www.isc.org/software/bind/adviso···011-4313
Josh |
|
| I am re-visiting this post again. I need to understand how to set up my network correctly for DNS.
Here is my current network:
Cisco gateway router
Cable modem
both of these are connected to the WAN ports of a Peplink (in drop-in mode for the Cisco on WAN1).
On the LAN side of the Peplink these are attached:
DNS1, DNS2, Mikrotik, Mail.
All the above are on my public IPs from my upstream provider on WAN1.
The Mikrotik is handling 2 different networks, #1 pool - using DHCP to hand out private IPs to my wireless customers, and #2 pool - using DHCP to hand out private IPs to my business PCs.
What DNS server IP do I put in my Gateway router and the cable modem? My own or my upstream providers or Googles...etc?
What DNS servers IPs do I put in everything else?
My Mikrotik is currently set to perform DNS caching. The Peplink also has this ability, from what I understand.
The only way I can get the Peplink to work correctly is to put public DNS IPs in it. When I put my own in it, I am not able to ping them from the Peplink.
Can someone out there clue me in on this? |
|
| reply to pacmanfan
Why? Use the root servers. That's what they are for. If you just use Google you have a single point of failure. |
|
| reply to jakkwb
"What DNS server IP do I put in my Gateway router and the cable modem? My own or my upstream providers or Googles...etc?"
Your DNS Servers.
"What DNS servers IPs do I put in everything else?"
Your DNS Servers.
"My Mikrotik is currently set to perform DNS cachingMy Mikrotik is currently set to perform DNS caching"
Let your routers route and DNS servers act like DNS servers.
I can't answer the peplink question. If your DNS servers are on public IPs they should be pingable from the peplink. You may have to get with peplink support on that one. |
|
| reply to jakkwb
I can only get to some web sites if I have my own DNS server numbers in my PC. The rest will say page cannot be displayed. If I change it to Google, all web sites come up.
That is why I asked all the questions about it. |
|
| reply to jakkwb
I have two seperate upstream ISP's and use a DNS caching relay, rather than a proper dns server.
The DNS relay sends it upstream to the ISP, and if that fails, it goes to opendns.
If i just use opendns or google dns servers, we dont get the access to the high speed (bursting) local caches from our upstream.
The reason for this is because one of our ISP's caches youtube and alot of other content, and so I like their dns servers to direct the traffic properly to their http / video caches, which I in turn cache the http and video as well. |
|
| reply to jakkwb
On one of the domains that is not working with your DNS servers run an nslookup and see what the dns server returns. |
|
| Just a note that DNS caching relay server in mikrotik often crashes under load. I had to scrap it because it kept dying.
--
OptionsDSL Wireless Internet
»www.optionsdsl.ca |
|
