2

I have bind9 on a local gateway system which is currently configured as a recursive resolving nameserver for our LAN. I would also like to also make it authoritative for the RFC 1918 addresses on our LAN, but fall through to a remote name server for names in the same domain not found in the zone file for these. (Both the local hosts with RFC 1918 addresses and public names resolved through the remote server use the same sld.tld.) I've tried putting NS records for the remote server in the zone table, but this doesn't work. Is there any way to do this?

I have the local names in /etc/hosts, but some services require that they be resolvable through DNS lookups, and won't resolve them from the hosts file.

1
  • To clarify, this question does not appear to be talking about reverse DNS for RFC 1918. My brain locked up for a moment.
    – Andrew B
    Oct 4, 2016 at 18:42

1 Answer 1

2

I would also like to also make it authoritative for the RFC 1918 addresses on our LAN, but fall through to a remote name server for names in the same domain not found in the zone file for these.

The problem you run into here is that authority doesn't work that way. There is no concept of fallthrough. When the server claims authority for a zone, it is authoritative for all data within it, barring two scenarios:

  1. A referral (NS record) delegates authority away from it. NS records at the top of zones do not define referrals.
  2. An overlapping zone with a more specific name is defined on the same server.

Unfortunately for this problem, referrals that are not received from the internet are not very useful. This is because referrals only serve a purpose when encountered along the path of recursion, which internally managed DNS does not follow.

There are a few different approaches you can take here to accomplish a similar end result.


Solution 1: Create a subdomain for internal DNS records.

This is what most companies do, and is by far the most easy to manage.

The simplest solution is to create a new, exclusively "internal" subdomain for RFC1918 devices to live in. This works so long as you aren't trying to create conflicting DNS definitions for a DNS entry. (i.e. www.example.com having both a public and private IP`)

Recursive DNS servers which need access to this internal domain must be configured with forwarders that point at the authoritative servers. In BIND, these would be zones of type forward.

Advantages:

  • No conflicting namespace. Very clear and well defined ownership of DNS zones.

Disadvantages:

  • Must use separate names for devices that have both private and public addresses.
  • Owner of the internet facing namespace must not create DNS records that conflict with yours. (you must both agree to this policy)

Solution 2: Intercept specific DNS records with a response policy.

If solution 1 doesn't work, we need to take a step back and be honest with ourselves for a moment. Your server does not own authority for the namespace that you are trying to create DNS records in. You are attempting to hijack namespace that you are not operationally responsible for. Instead of trying to create an authoritative zone for data that you are not authoritative for, why not use the feature designed for this purpose?

In recent years, BIND has received a new feature called Response Policy Zones (RPZ). This allows you to define a zone file of queries that you want to intercept, along with the answers that your server should provide when they are seen. This allows you to manage a list of records that you would like to intercept, with all others resolving as they would normally.

Advantages:

  • Ability to intercept specific queries without attempting to claim authority for entire zones.

Disadvantages:

  • Additional CPU overhead. I would not be concerned with this unless we're talking carrier grade, customer facing scenarios.
  • User confusion. It will not be very obvious to them why queries going through your server will behave differently.

Solution 3: Split DNS hell.

The final method is one where multiple versions of the zone exist. One faces the internet, and one or more face your private networks.

There are two common approaches.

  1. A view based approach. Both versions of the authoritative zone live on the same servers. Multiple views based on source IP are defined, which determine the file that is used to serve the answer from.

  2. A server based approach. One server owns the internet facing version of the zone, and another server owns a privately facing version of the zone. Similar to Solution 1, the privately facing version of the zone is only visible to recursive servers that have defined forwarders that point authority at the alternate DNS servers.

The server based approach tends to be ugly, as any records which must be visible to both environments have to be added separately. This becomes even more complicated if the servers have different operational owners, as it becomes necessary to engage two or more teams for DNS records that need to be visible in more than one environment. Your users have no way of knowing that multiple teams are involved in their "simple" request to add a record, and balls will be dropped frequently barring good team communication.

Advantages:

  • A DNS record can have a value that changes depending on where the request is coming from.

Disadvantages:

  • User confusion. It will not be very obvious to them why queries going through your server will behave differently. If more than one team operates the servers, they will not know that they need to submit requests to both groups.
  • Design complexity.
    • If a record must be visible to multiple environments, it must be added to all of them. It does not matter whether they are returning different values or the same value. If someone forgets to add the record to an environment, it simply doesn't exist there.
    • Risk of a record being changed in one environment but not others.
  • You will make me cry. :'(

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .