14 Replies Latest reply: Feb 15, 2006 5:29 PM by David Leip
Burk Roberts Level 2 Level 2 (280 points)
Xserve running Tiger Server behind a NAT router provides DNS to our LAN (i.e.: it's not a public DNS server) with a FQDN of "xserve.ourdomain.com." We run our website off the Xserve, too, and since we have a dynamic internet IP address we use dyndns.org's custom domain service.

The problem is that the Xserve purports to be authoritative for the entire "ourdomain.com" so when a LAN machine tries to load our website it can't find the server. I can create a "www" Machine in Server Admin with our current public IP address and it works, but I don't want to have to manually update the record everytime our public IP changes.

Can someone explain how to set up our internal DNS so that when the Xserve receives a LAN query for "www.ourdomain.com" it forwards the query on to an appropriate public nameserver for response?

Xserve, Mac OS X (10.4.3)
  • Gerrit DeWitt Level 4 Level 4 (3,900 points)
    Can someone explain how to set up our internal DNS so that when the Xserve receives a LAN query for "www.ourdomain.com" it forwards the query on to an appropriate public nameserver for response?

    Yes. You can do this rather simply, but it will require a change in your server's DNS configuration.

    First off, when you configured your Xserve to host a DNS zone, you had to let each of your client computers know that it was a DNS name server. You may have manually added the Xserve's local IP address to the DNS Servers field in the Network pane of System Preferences on each client, or you may have provided the name server information via the DHCP service.

    In addition to your local DNS name server, your ISP provides one or more name servers, which you may have manually or dynamically configured on each client. If you don't know these numbers, the local IP address of your router would be the external name server, since it has access to the external network (and forwards name server requests outside of your network).

    With that said, if you're actually using a local DNS name like xserve.mycompany.com, any client computers that are configured to use your Xserve as a local DNS name server will use it as the first available resolver for any services at mycompany.com, not contacting your external DNS name server. You could try switching the order of the name servers in your DHCP configuration (or manually on each client) such that the external one is listed first. This may or may not work, and you'll likely have varying results, especially if your external IP configuration is dynamic.

    It is for this reason that DNS configuration guides and experts highly recommend not using a top-level domain suffix (such as .com, .biz, or .net) for internal DNS. As you've seen, this can cause problems for internal clients when attempting to contact a legitimate external service.

    Since Apple uses .local for multicast DNS (mDNS - also known as Bonjour/Rendezvous), using that suffix would require some extra configuration on client computers using Mac OS X 10.2 through 10.3.9. For this reason, I use .private since it is an acceptable local DNS suffix: xserve.mycompany.private. You could also make up your own, so long as it doesn't (or won't) conflict with a present (or future) top-level domain DNS suffix.

    --Gerrit
  • Burk Roberts Level 2 Level 2 (280 points)
    Yes. You can do this rather simply, but it will
    require a change in your server's DNS configuration.


    Gerrit, this is a helpful suggestion and I very much appreciate your taking the time to answer.

    I had already tried changing the order of the DNS servers on the LAN computers. Setting it up this way gives them access to the website, but breaks name resolution within the LAN. (For example, I can no longer access "xserve.ourdomain.com" in WorkGroup Manager; I have to do it by IP address.)

    I was hoping not to have to go back and change my config with a different internal domain, but will certainly give this a try if I can't find any better alternative.

    I guess what I'm having trouble accepting is that the entire internet can find our server whenever its public IP changes, but the machines on my own network can't. Is there really no way to accomplish this?

    Thanks again for the help.
  • Gerrit DeWitt Level 4 Level 4 (3,900 points)
    I guess what I'm having trouble accepting is that the entire internet can find our server whenever its public IP changes, but the machines on my own network can't. Is there really no way to accomplish this?

    Don't think of it as a matter of size - the entire Internet is actually not "finding" your server all at once.

    When someone accesses your web site from elsewhere, his or her computer on a remote network sends a request to its nearest DNS name server, and that name server forwards the request on up to another name server until it has an authoritative response for your domain. In your case, that authoritative response would come from your dynamic DNS service, which keeps a record of your computer's external IP address. (Your software or router periodically informs the dynamic DNS service about your server's present IP address.)

    In a similar way, when someone accesses your web site from within your network, his/her computer forwards the request to the nearest DNS name server. The forwarding process would continue on to the next level DNS name server until an authoritative response had been acquired, except that your local name server simply returns an incorrect authoritative response!

    In such a way, any network can block access to your web site by putting a fake authoritative DNS response for your domain within their network.

    Bear in mind, changing your local DNS configuration is not the only way; however, I do believe that it's the best, as these alternatives have side effects that you may not want.

    Essentially you'd need to resolve the two authoritative answers problem. You could take your domain name away from your dynamic DNS service, get a static external IP address, and use your server as the name server for your domain. It would forward its contact information up to higher-level DNS name servers so that anyone inside or outside your network would be able to access your server by name. (Of course, you may not want this level of access.)

    In your local DNS service setup, you should be able to add a www machine that points to your server's local IP address (not the dynamic external one), but this still doesn't solve the two different name servers that users inside and outside your network would get for your domain. This generally isn't recommended because it unnecessarily complicates your situation for email and other services if you use them down the road, but it may be sufficient for your needs.

    --Gerrit
  • Burk Roberts Level 2 Level 2 (280 points)
    Thanks, Gerrit. You convinced me and I bit the bullet this afternoon. I demoted the server back to Standalone, deleted the old .com Zone and created a new .private one, promoted the server back to OD Master, re-created my Users, moved their data into the new home directories, corrected the permissions, and then re-bound the clients. I really hated to have to do it, but it's done now and everything seems to work.

    Two quick follow-up questions if it's not too much trouble:

    1. When I originally promoted the sever to OD Master with the .com domain, Server Admin automatically pre-filled the Kerberos fields in the sheet that drops down for you to enter your directory administrator password. Using the .private domain today, though, that didn't happen. I went ahead and entered the information manually. I don't really plan on using Kerberos, but I wonder whether something is messed up or if it just doesn't work with a non-standard domain like .private?

    2. The DHCP server in the router is set up to feed out the Xserve's internal (10.0.1.X) address first, followed by the IP addresses of our ISP's servers. When browsing the web there is a slightly longer delay which I assume is caused by the client first querying the Xserve before moving on to the ISP's servers for a response. It's a small thing but I wonder if there's anything more I can do to reduce/eliminate the delay?

    Thanks again for your help.
  • Leif Carlsson Level 5 Level 5 (4,950 points)
    I would use only the internal DNS as the ISP ones doesn't know about your private network.

    Instead setup DNS forwarders in /etc/named.conf to speed up lookups.

    // query-source address * port 53;

    // new stuff:

    forwarders; {
    isp.dns.ip.1;
    isp.dns.ip.2;
    };
    forward first;

    // end new stuff

    };


    And frankly I don't know why you had to change your Internal domain since the server is compleatly behind a NAT router? As the access to it
    via the public IP is forwarded from the router and you can have static private IPs setup in the internal DNS there should be no problem if only using the internal DNS on your LAN?

    If the public server was another machine placed directly (especially when using a dynamic IP) on Internet, having a different domainname on the private LAN would be the best choice.

    Well I don't know where your domain's mail are hosted so that might be a reason to have different domains too (or not). Having different domains internally/externally might even mess stuff up in your WEB and DNS config (need to setup both).

    The internal DNS needs to have the reverse domain setup too for Kerberos and other stuff to work correctly.
  • Burk Roberts Level 2 Level 2 (280 points)
    And frankly I don't know why you had to change your
    Internal domain since the server is compleatly behind
    a NAT router? As the access to it
    via the public IP is forwarded from the router and
    you can have static private IPs setup in the internal
    DNS there should be no problem if only using the
    internal DNS on your LAN?


    I think Gerrit explained it pretty succinctly in his first response in this thread: "With that said, if you're actually using a local DNS name like xserve.mycompany.com, any client computers that are configured to use your Xserve as a local DNS name server will use it as the first available resolver for any services at mycompany.com, not contacting your external DNS name server."

    I host my website on our Xserve, but we have a dynamic IP address. When a LAN client queried the DNS server on the Xserve for the IP of our website, it would get a response that the Xserve was authoritative for the "mycompany.com" domain, but that the Xserve didn't have a clue what the IP address of the website is. End result: our website wouldn't load from within the LAN.

    If I had the LAN clients query the ISP instead, they'd find that dyndns.org's nameservers had authoritative records for "mycompany.com" and hence the website would load just fine, but as you remarked those nameservers had no idea about the LAN address for our Xserve behind the NAT router so our private DNS became useless.

    Supplying both the Xserve's IP address and the ISP's IP address via DHCP didn't help because I'd get the same results as outlined above, depending on which IP address was listed first.

    I could have set up a Machine record for "www" in Server Admin and assigned our current public IP address to it, but that would have required me to manually change the Machine record everytime our public IP address changes. (Admittedly that doesn't happen very often, but I've got enough other things to worry about without adding that to the list.)

    I tried setting up a Machine record for "www" in Server admin and pointing it to the Xserve's LAN IP address, but Server Admin won't let you point a Machine record to the same IP address as the IP address of the server whose zone you are editing.

    Moving the website to an external server with a static IP (or buying a static IP for ourselves) would have worked, but simply as a matter of personal preference I didn't want to do that.

    In my heart of hearts I still feel like BIND is flexible enough for the Xserve to be able to say to the LAN client: "I'm authoritative for xserve.mycompany.com, but if you're looking for www.mycompany.com you need to ask the ISP nameserver instead." I just never could figure out how to do it and after wasting a whole week's worth of free time on it I was just ready to have it over with. So, now the now the router provides IP addresses for both our internal and pubic DNS servers to the LAN clients via DHCP. The Xserve gets to be authoritative for xserve.mycompany.private, which covers all our LAN DNS needs, and the ISP's nameservers take care of everything else.

    It may be a bit of a kludge but I think everything is OK now. Running the host command in terminal shows that xserve.mycompany.com resolves to the correct LAN IP address, and running the same command on the Xserve's LAN IP returns xserve.mycompany.com. I just couldn't figure out why the Kerberos fields didn't pre-fill, and of course want the name lookups to be as speedy as possible.

    Having said all that, would adding the forwarders be of any benefit?
  • Gerrit DeWitt Level 4 Level 4 (3,900 points)
    Here is a follow-up - no problem to ask - that's why we have these boards!

    1. Kerberos Configuration - Server Admin automatically pre-filled the Kerberos fields in the sheet that drops down for you to enter your directory administrator password.

    The Kerberos information that slapconfig requests (or that Server Admin requests for slapconfig) is the realm name. The realm name can technically be any string that you'd like, but convention makes it DNS name of the server in capital letters. For example: XSERVE.MYCOMPANY.PRIVATE

    Chances are, your Kerberos configuration is OK. To check, open Server Admin and click Open Directory. Look to see if Kerberos is running (as indicated in the status section).

    Since the Kerberos realm name depends on the server's DNS name, I recommend doing two things while you're configuring local DNS services but before creating the Open Directory master:

    a. Verify that the HOSTNAME entry in /etc/hostconfig is set to the server's hostname, not the -AUTOMATIC- variable.

    b. Use the hostconfig command to verify (and set, if required) the server's cached hostname.

    (More details and instructions at: http://discussions.apple.com/thread.jspa?messageID=661415&#661415)

    2. Tying in your server with external DNS servers - . When browsing the web there is a slightly longer delay

    As Mr. Carlsson mentions, you could add a forwarders entry to your local DNS server's (your server's) configuration by editing the /etc/named.conf file. This would allow your server to pass other DNS requests to higher-level DNS name servers, which may reduce the delay when finding external web sites from your local network.

    If you make the change to the /etc/named.conf file, you won't have to inform your clients of the external DNS servers. Your local one will be sufficient; however, I recommend leaving a the external DNS servers in your client configurations so that clients don't lose web browsing capability while you're working on your server (rebooting, etc.).

    Having said all that, would adding the forwarders be of any benefit?

    On a small, fast network, you may not even notice a difference. If you forward all DNS traffic through your local DNS server, you may even notice a speed decrease, as a lot of DNS activity may actually slow down your server entirely.

    3. Adding "www" machine when it's the nameserver - I tried setting up a Machine record for "www" in Server admin and pointing it to the Xserve's LAN IP address, but Server Admin won't let you point a Machine record to the same IP address as the IP address of the server whose zone you are editing.

    Worth a try. You could probably do this by editing the named.conf file, but it's best practice to have a dedicated nameserver (as explained in 2).

    --Gerrit
  • hyerstay Level 1 Level 1 (0 points)
    You could connect to your local server by using the address, "xserve.local".

    jason
  • Gerrit DeWitt Level 4 Level 4 (3,900 points)
    That's absolutely correct: xserve.local is an mDNS name, provided by Bonjour. It is formed by the server's local host name followed by the .local suffix. Multicast DNS provides name resolution by broadcasting the server's name on the local subnet. Clients do not need a name server to find the server, but they do need a client-side mDNS process. Both Mac OS X and Mac OS X Server run a process called mDNSResponder, which handles the client/server (and client/client) name resolution process.

    Multicast DNS (Bonjour) works for basic services. However, to fully take advantage of Open Directory, you need to configure Kerberos, which requires properly configured DNS services. If your server is configured as an Open Directory Master with just a Bonjour name, you'll notice that Kerberos is stopped. (You can still use most Open Directory features for users with passwords of type "Open Directory," since one authentication authority, Password Server, is still running.)

    Further, mDNS name resolution is specific to Mac OS X unless you've installed the Bonjour software for Windows.

    My preceeding post explains how to configure your local server as both a local nameserver and Open Directory Master with Kerberos support.

    --Gerrit
  • David Leip Level 1 Level 1 (10 points)
    Hi,
    Very good information that I have been using.

    Question: I edited my named.conf file to add the forwarders as shown. However, after saving the file, the Server Admin GUI no longer has any information in the DNS bullet. (if I re-edit the file to remove the forwarders, I can once again see the DNS zone, machines, etc.). Is there a way to keep the accessibility through Server Admin and add the forwarding lines?
    Thanks,
    Dave
  • Burk Roberts Level 2 Level 2 (280 points)
    The concensus around here seems to be that you can't have it both ways: you either need to stick with Server Admin's GUI or do it all manually. Trying to switch back and forth apparently causes no end of trouble.
  • Leif Carlsson Level 5 Level 5 (4,950 points)
    OK, this is an old post but I'd like to answer it anyway.

    2. I would NOT have both local and public nameservers in the local machines nameserver lists (and I would use DHCP for clients) because you don't know what DNS in the list will be asked to resolve a lookup.

    I know most people think the first/top one will always get the request if it's available, but it seems other factors will come into play. Maybe it's works like the BIND (DNS) server that asks all "forwarders" at once and then use the first answer that arrives (if the data isn't already cached of course).

    If a public DNS gets a lookup request for a local name/domain it woun't know the answer. This will happen often if you mix local (private) and public nameservers in the list.

    To ensure DNS availability I would prefer using a second "backup"/slave DNS locally. All machines running OS X is a potential DNS server (BIND is installed) and it's not very hard to configure.

    And the load from serving DNS to clients is usually very low.


    My reason for not bothering with changeing the setup (domainname) earlier
    was if you run a (web)server with a local/private (NATed) IP and "reuse" (maybe not neat but works) the public domainname, the webserver would get the same "namerequest" from the public LAN and the Internet.

    (If I had totally separate Intranet and Internet servers I would of course use different domainnames internally/for Internet.)

    As this "site" was using a dynamic IP for the public IP it tells me it probably is a rather small "setup" so the domainname is probably not used for too many other public servers: mail, ftp and such hosted elsewhere.

    I have once or twice been using the same domainname for public and private use and one or two public IPs setup in a private IP DNS — maybe ugly but works. This way the LAN users could find the public (DMZ) mailserver and remotely hosted webservers and all local stuff by name.

    Reverse lookup for these public IPs is (should be) handled by public nameservers.

    For best DNS lookup speed: turn off IPv6 on all local machines and use forwarders. Forwarders also reduce local DNS server load as the ISP servers does most of the public IP lookup work.
  • Leif Carlsson Level 5 Level 5 (4,950 points)
    Sorry, I put in a ";" to much (directly after "forwarders") and maybe a closing "};" at the end too many too. This usually show up in the logs though

    enter after this line: // query-source address * port 53;


    forwarders {
    <your isp.dns.ip.1>;
    <your isp.dns.ip.2>;
    };
    forward first;


    Works for me in 10.4.4 (but don't enter the "<"forwarders {"

    Sorry again.
  • David Leip Level 1 Level 1 (10 points)
    Thank you very much. This appears to have worked. I keep the GUI interface to manage machines and I get fast DNS forwarding.
    Thanks,
    Dave