7

The hosts file allows us to configure the system to override the whole DNS servers system and resolve a particular DNS name into a prtcular IP address. But what if I just want it to use a particular DNS server for this?

Ivan
  • 17,708
  • You need to run a DNS server which will forward all DNS request but the one for that specific domain. In a .zone file you would add the records for that domain and then configure an upstream nameserver on the machine running the daemon. This is sketchy, sorry, no time to write a proper answer. – grochmal Sep 11 '16 at 03:32
  • It sounds like you're looking for dnsmasq; it can redirect DNS queries for specific domains to specific servers. I'll flesh this out into a proper answer later (if no one else does so first). – Stephen Kitt Sep 11 '16 at 07:52

2 Answers2

3

This is called split-horizon DNS service and there are four ways of doing it. For the sake of example let's suppose that you wish to configure split horizon for unix.stackexchange.com. (and of course for all parts of the domain name tree below that). How you do it depends from what you choose to run locally.

  1. You run a local forwarding proxy DNS server. This is a common case where you want local caching but local machines are firewalled off from the public Internet, or where query resolution from those machines is relatively expensive compared to doing it centrally from one place on the LAN.

    You tell it that for unix.stackexchange.com. it forwards to a different server. You have to set up a second (remote) proxy DNS server that knows how to resolve queries for unix.stackexchange.com. and its subdomains. You also have to set up a private content DNS server that serves up the actual alternative data for unix.stackexchange.com. and its subdomains, that the second proxy DNS server knows about and is configured to use.

    You likely already have both of the latter twain, especially if you are a large organization. You likely already have the resolving proxy DNS server as a central machine for performing the actual grunt work of query resolution. You likely already have a private content DNS server that is locally mirroring the public . content DNS servers in order to stop various kinds of internal traffic "leaking" outwith your organization, to which you can simply add your unix.stackexchange.com. data.

    The local forwarding proxy DNS server is configured:

    • For servers like Bernstein's dnscache (in FORWARDONLY mode) you configure the servers/unix.stackexchange.com file (in the server's root/working directory) with the IP addresses of the proxy DNS server(s) to forward queries to and restart the server.
    • For zoned DNS servers like Microsoft's DNS server and ISC's BIND, you configure a forwarding zone for unix.stackexchange.com. and reload/restart the server.

    The second (remote) proxy DNS server is configured as in choice #2 following here. Choice #2 also applies to the situation where machines' DNS client libraries are pointed (by /etc/resolv.conf for example) directly at a (local/remote) resolving proxy DNS server, rather than having a forwarding proxy DNS server as an intermediary.
  2. You run a local resolving proxy DNS server. Since the advent of the Domain Name System in the 1980s, multitasking operating systems like Unices and Linux have not shied away from running resolving proxy DNS servers on each machine as the usual case. But as pointed out in choice #1, "local" could be as local as on the LAN rather than on individual machines.

    You tell it that for unix.stackexchange.com. it must start query resolution at a different content DNS server to what is published in the public DNS database. You have to set up a private content DNS server that serves up the actual alternative data for unix.stackexchange.com. and its subdomains.

    The local resolving proxy DNS server is configured:

    • For servers like Bernstein's dnscache (in non-FORWARDONLY mode) you configure the servers/unix.stackexchange.com file (in the server's root/working directory) with the IP addresses of the content DNS server(s) to start query resolution at and restart the server.
    • For zoned DNS servers like Microsoft's DNS server and ISC's BIND, you configure a stub zone for unix.stackexchange.com. and reload/restart the server.
  3. Your public content DNS server is capable of serving up alternative data according to who sent the query. Few are, but if you have a software with this capability it is architecturally the simplest to set up.

    You do not fiddle with proxy DNS servers at all, or set up a second private content DNS server. You tell your public content DNS server which classes of client are which, and give it various labelled sets of data to serve for unix.stackexchange.com. and its subdomains. Everyone is already ending up at your public content DNS server anyway, via whatever route.

    • For servers like Bernstein's tinydns you use its location code feature and configure all of (the back-end client IP addresses of) "your" proxy DNS servers as one location code and the rest of the Internet as another. You tag all of the data in the database that are to be visible to your proxy DNS servers with the first location code, and all of the data that are to be visible to the rest of Internet as the other (or simply no location code at all).
      %si:10
      %si:192.168
      %lo:127
      …
      =unix.stackexchange.com:127.0.0.1:::lo
      =unix.stackexchange.com:192.168.72.3:::si
      =unix.stackexchange.com:151.101.1.69:::
    • For Microsoft's DNS server, you use its slightly more cumbersome zone scopes system. This operates by labelling the IP addresses of the server's own receiving interfaces, rather than by labelling the source IP addresses of DNS clients. Adapting Microsoft's PowerShell examples:
      Add-DnsServerQueryResolutionPolicy -Name "SplitHorizonZonePolicy" -Action ALLOW -ServerInterface "eq,10.0.0.56" -ZoneScope "internal,1" -ZoneName "stackexchange.com"
      Add-DnsServerResourceRecord -ZoneName "stackexchange.com" -A -Name "unix" -IPv4Address "151.101.1.69" 
      Add-DnsServerResourceRecord -ZoneName "stackexchange.com" -A -Name "unix" -IPv4Address "10.0.0.69” -ZoneScope "internal"
    • For ISC's BIND, you use its definitely more cumbersome views system.

    If you are relying upon an external company to serve your public DNS content, you are likely out of luck, even nowadays years after these ideas entered the mainstream. Few such companies yet provide this ability to customers, even though they may use one of these DNS server softwares.

    But if you are (say) publishing your own data with tinydns on your own public OpenBSD machine, split horizon DNS service this way is quite easy. ☺

  4. You employ complex DNS client softwares. Normally your DNS client is the code in the C library/libraries linked to applications softwares on your system. But sometimes it isn't.

    Applications softwares can use things like the Desktop Bus system that speaks to systemd's systemd-resolved. They don't speak the DNS protocol to a proxy DNS server. (The systemd people are encouraging applications software writers to stop doing this.) Instead, they speak an idiosyncratic and non-standardized Desktop Bus protocol to systemd-resolved. systemd-resolved has, in its turn, a complex system for determining, based upon current network configuration, what DNS server(s) to actually send a DNS protocol query to.

    Note that this local DNS service is not as fully featured as the libc NSS or systemd-resolved's [desktop] bus APIs. […] It is thus strongly recommended for all applications to use the libc NSS API or native systemd-resolved [desktop] bus API instead.
    Lennart Poettering, 2016-06-25

    Manpulating that is well beyond the scope of a general scope question and answer like this.

For vainly-wearing-all-the-hats-at-once DNS server softwares like Microsoft's DNS server, ISC's BIND, dnsmasq and so forth, there are complex scenarios that look like mixtures of choices #1, #2, and #3; or that look like a really complex version of choice #2. But vainly wearing all of the hats at once has been regarded as a bad idea in most of the DNS world for approaching two decades, now. (Even in the Microsoft DNS server world, for roughly one decade.) Your DNS servers should not be content DNS servers and proxy DNS servers all in one. (There are people such as The OpenResolver Project that actively go around poking people's public DNS servers in order to attempt to enforce this.) Properly separate the types of service into distinct servers, just like you very probably already do with SMTP and HTTP service, and the choices simplify into one of the aforementioned.

Further reading

JdeBP
  • 68,745
1

One solution would be to install bind (named) and setup a zone file for the domain you want to directly control.

There are plenty of simple tutorials to do it, but I particularly like the ones on https://www.digitalocean.com/ such as this one.