What happens when two DNS zones intersect on the same server?

Question

I have a DNS zone of example.com with a record of type A defined for foo.example.com. On that same server, I have another zone named foo.example.com with and no A record defined at the top of the zone. If my server receives a query for foo.example.com, will it return the record defined in the example.com zone? (Or would the search algorithm stop once it gets to the more specific zone, then answer "not found"?)

A similar question:

If I have all of the above, if I then set up an A record at the top of the foo.example.com zone (@) pointing to a different IP address, which address would be returned?

example.com

foo.example.com. 3600 IN A <location A>

foo.example.com

@               3600 IN A <location B>

Obviously you don't need both - I am teasing out the behavior of DNS. But is there a standard way to approach this - a standard place to put it?

I am using BIND.

Answer 1

When overlapping zones are defined on an authoritative nameserver, the most specific zone is used to provide the answer.

• A query of example.com. IN A? hits the example.com zone.
• A query of foo.example.com. IN A? hits the foo.example.com zone. If foo.example.com is defined in the example.com zone, it will be ignored.
• A query of sub.foo.example.com. IN A? hits the foo.example.com zone, because it is more specific for the request than example.com.

In your specific example, the returned value for the query would be NXDOMAIN because the foo.example.com zone does not provide an A record definition for itself.

To use DNS terminology, there is effectively a zone cut at the boundary between the parent zone and the more specific zone. RFC2181 §6.1 describes the proper behavior for your scenario:

Such a server is authoritative for all resource records in a zone that are not in another zone. The NS records that indicate a zone cut are the property of the child zone created, as are any other records for the origin of that child zone, or any sub-domains of it. A server for a zone should not return authoritative answers for queries related to names in another zone, which includes the NS, and perhaps A, records at a zone cut, unless it also happens to be a server for the other zone.

Other than the DNSSEC cases mentioned immediately below, servers should ignore data other than NS records, and necessary A records to locate the servers listed in the NS records, that may happen to be configured in a zone at a zone cut.

As for which is a best practice, that's completely up to you. You can put all of your records in a single zone, or break out separate zone files for your subdomains if it would be more convenient. (say, due to them containing hundreds of records each) The one thing I would caution, which isn't very obvious, is that validation tools like named-checkzone typically have no awareness of subzones living on the same server and may generate incorrect warnings if the parent zone includes references to records inside the child zone. (say, CNAME aliases)