DNS Forwarding

Configure your local DNS server as the DNS server for the local boxes on your LAN (and then serving up the local host names and the private IP addresses, and not the public IP addresses), and have your local DNS server then forward requests (for domains and hosts it is not authoritative for) to the external DNS servers and out to your ISP.

There's one wrinkle here around whether your firewall can reflect outbound IP traffic for your public static address; whether your outbound traffic to your public address will be routed back to your LAN and back in through your NAT and port forwarding. Some firewalls allow this, and some don't.

If your firewall does not provide this bounce-back or reflection or whatever you might call this, then you'll either end up swapping it, or you can test with your local DNS server serving up the local address to your host (and stepping in front of the public IP address) for your clients under the "public" host name. I'd tend toward the former approach here; a better and more capable firewall router.

I'd tend to serve up the local IP addresses as the example.net if you own both example.net and example.com, or as lan.example.com or such; with a zone and a domain or subdomain specific to your use. This to avoid having two different www.example.com translations (one public static IP from your external DNS and one private static IP from your internal server), depending on which network you're located upon. Using the separate domain or subdomain also avoids confusion over what's external and what's internal. example.net, in this example, is inside the firewall, and example.com outside same.

I've installed and am running exactly this configuration. The firewalls I install and operate specifically provide the ability to route the outbound IP traffic traffic back, too. And no, I don't like having two (and entirely unaffiliated) authoritative DNS servers for one public IP address.

Without reading all of MrHoffman's reply, it sounds like this one is answered, but figured I could add some background.

For me it looks like, that the client only uses the 1. entry (DNS1) if there is no website the client doesn't try the second DNS2.

That's how DNS works.

When your client queries the first DNS server it gets back a 'no such host' response. It takes this response and is done. There's no reason for it to doubt the server, so it's not going to try to query the second server just in case it gets a different response.

The only time the second server would be queried would be if there was no reply from the first server (e.g. it was down). Then it would failover the query to the second server. Since the first server responded, though (even with a 'no such host' response), the client doesn't see any need to try the second server.

When you query a DNS server for an address it doesn't know, there are two things it can do to try and find an answer before giving up (with a 'unknown host' response).

The first is to forward the request to some other server, to see if that server knows the answer.

The second is to try and resolve the hostname itself, by querying the authoritative server for the domain in question.

In the first case, the server DNS1 would need to have DNS2 listed as a forwarder, but you probably don't want to do this, especially if DNS1 is resolving many queries for other users since it will shift much of the load to DNS2

The second case is the norm and would happen automatically in most cases. However, in this case it sounds like you're running a private domain so DNS1 has no idea of how to resolve queries for that domain. This can only be solved by setting DNS1 as a slave of DNS2 for this specific domain. In that way DNS1 knows it can get data for the domain from DNS2 and will be able to resolve queries.

This, of course, requires that you have some control over DNS1

This shouldn't be necessary, though. I don't understand why clients are querying DNS1 when surely they should be querying DNS2? Am I missing something? Why not just configure the client to use DNS2 as its DNS server?

All of the referenced DNS servers are assumed to have duplicate contents.

The DNS servers listed in the client (or provided by DHCP) are not a sequence of DNS servers that the client will check. Rather, the list of servers is used when one of the DNS servers is not reachable.

All of your DNS servers must either (individually) need to know the address translations, or they will seek to obtain the translation for you; to directly query authoritative DNS servers or to forward to the next DNS servers upstream. If the first DNS server is reachable and (after processing the request fully) responds back to the client request with the DNS analog of "huh?", then full stop. There are typically no additional DNS requests or translations performed.

Here, the local DNS server (or for more critical applications with uptime, multiple parallel DNS servers) is usually configured to respond to local name addresses from the LAN, and then that local DNS server is configured to to ask the remote DNS server on behalf of the requesting client; to forward the request for non-authoritative requests.

The remote DNS server would not normally be explicitly listed and explicitly directly used here, save if the local DNS server is down (here ignoring indirect use from your local DNS server(s), via forwarding). That written, you might choose to have a network profile here, for instance, that bypasses your local DNS server and goes directly to the remote ISP DNS server. Or you might choose to have the local DHCP server (manually) switch over to a different profile and to provide a different DNS IP address when your local DNS server is down. But access to or references to the ISP DNS server(s) are not likely the default if and when you have a local DNS server running.

And yes, when the referenced "peer" DNS servers do have skewed contents, "weird stuff" can happen.

the only way is no dns and the local website will be surfed by server.local. unfortunately no subdomains will be possible 😟

FWIW, I'm running exactly this configuration at a customer site. With a local DNS server running on a Mac OS X Server running on a Mac Mini.

Or yes, you can use mDNS and the .local stuff, yes.

How? Well, see the earlier responses. Basically, a DNS server was configured and enabled to respond as the authoritative server for the hosts in the target domain, and the clients are configured to use that DNS server on that LAN. That DNS server responds authoritatively for the domain it is configured for, but it's not accessible from outside and not set up to respond authoritatively to any hosts outside of the local LAN. Either that local DNS server responds, or it forwards the request; it's basically insinuated into the DNS translation network path pretty much the way you might think.

I prefer to use example.com and example.net for this sort of thing, where .net is the internal domain and .com is the external domain. The sequence is basically the same with a subdomain; larger networks with internal DNS configurations tend to use subdomains. With a larger and more complex network and DNS construction, a network manager will usually have subdomains structured for host.site.example.com or host.dept.example.com host.geography.example.com or similar such. And larger sites will have groups of DNS servers for buildings or sites or domains; for these domains or subdomains, and (often) the associated IP subnets.

We're apparently talking past each other here. Go read Cricket Liu's DNS and Bind book, if you really want to know how this stuff works. A large chunk of that book won't be relevant here, but the basics and the details around this sort of configuration will help with understanding DNS.

How can i configure the openDNS on Mac OS Server to forward a request to an other DNS?
so they way is like
client------dns2->------>dns1.

Correct.

Local DNS host translations don't get past dns2; those translations where dns2 is authoritative aren't shipped up to dns1. But (and as DNS works in general) any translations that dns2 doesn't know about will get handed off to another DNS server.

For smaller network configurations, I don't see a particular difference in the number of translations that hit the ISP servers here between the multiple hits from clients configured to hit the ISP DNS directly (which is what you'd have if you're not running DNS locally), and clients configured via a local DNS server. If any difference resulted, the configuration with the local DNS server (due to its shared cache) will probably have a slightly lower aggregate load on the ISP DNS server(s).

the configuration of the client network settings looks like:
1.Static DNS: dns2
2.Static DNS: dns1

I'd expect this configuration if dns2 and dns1 are replicated, and we've already established that the contents of dns1 and dns2 are entirely different.

I'd expect the setting (provided by DHCP or static) looks like this:

1: Static DNS: dns2

so when dns2 is down.... the client uses automatically dns1.

Constructs such as DNS and OpenDirectory assume replication. They're either not down often enough to warrant replication or the costs of outages don't cover replication, or they're replicated.

I tried exactly your proposed configuration last week (by accident, as I was bringing the server on-line), and (for whatever reason) it didn't work as I needed. But go try it. I'd not want to predict which server would be used by a particular box.

With a small LAN such as this, if dns2 is down, then DNS is down until a replicated dns3 server (which is what most anybody with a big or critical network does; this is why all of the DNS materials suggest multiple DNS servers) can take over, or you need to flip over via one of the manual (or locally scripted approaches mentioned earlier. DHCP, or otherwise. (Within smaller networks, if your core server is down, pretty much anything else you care about is down, too.)

When operating on Tiger Server and Leopard Server DNS, I've preferred to use a US$20 tool known as DNS Enabler. It's generally better than the Server Admin DNS tool on those releases.

For low-end higher-uptime requirements (is that an oxymoron?), I might look at a pair of Mac Mini boxes with Leopard Server or (when it rolls out in September) Snow Leopard Server, and probably with external RAID storage (preferably via FW800 on the new Mac Mini), and park OpenDirectory and LDAP and DNS on these boxes. The higher-end Apple solution here is racked and replicated Xserve boxes.