DNS secondary zone transfers

If you ever configure a Windows based domain server as a secondary zone you can configure several sources for the domain.

If is important to remember that even if the first server in the list fails, but does not return a valid reply it will not continue down the list. An invalid reply might be "zone transfer failed", a common problem with source domain that are configured to accept dynamic updates. Read more about the zone transfer throttling mechanism here.

DNS directed lookups - pros and cons

When you have to do directed name lookups you have lots of options. Conditional forwarders, stub zones and secondary zones. What should I choose? It is not easy to choose, as the pros and cons are hard to find. But look no further, you are now reading the definitive source.

Before I go into the discussions about pros and cons bear in mind that not all environments are equal. For this discussion there exist only two types of connections (WAN) between sites. A network that is firewalled can in many circumstances look like a LAN-LAN VPN type of connection - the same restrictions applies.

Connection	Configuration
LAN-LAN VPN	In this configuration a remote site is connected to the main site using VPN over Internet. The remote site have only access to parts of your network based on the IPSec policy.
Leased line	The remote site shares the entire IP network with the main network and can access all internal resources.

Stub zones

Microsoft added support for stub zones a few years ago. With stub zones you configure from where to load the stub and then all queries are iterative from that point. More about stub zones here.

Why

Why not

Does not require zone transfers to work. Easy to integrate into an existing network as it can scale and change with the network. The stub zone can be placed in Active Directory and automatically loaded onto all domain controllers.

If stub zones fails to load (can not obtain NS and SOA) the zones can be loaded with information on the Internet. If a zone is part of a split DNS then the public information is cached instead of the private information. Queries are iterative; the DNS server will attempt to query all DNS servers by it self to get the answer. If the zone have delegated subzones then our DNS server needs to talk to all other DNS servers. Changes to information within DNS propagates slower as the server caches all answers. (Also negative answers.) You have to reconfigure the zone properties for most changes in the other DNS server.

Secondary zone

A secondary zone will at all times keep a copy of the entire zone on disc or in memory. Read more here.

Why

Why not

Faster updates (potentially) as your DNS server can be notified on any changes to the original zone. (If not, the zone is refreshed based on values inside the SOA record.) The server does not have to query any other server to get the answer. (Except when you have delegated subzones.) If the zone expires (it fails to update the zone within the configured time) the server will only send back negative answers. It will not ask other DNS servers for an answer. (No chance for cache poisoning.)

You need zone transfers, and that is usually blocked on DNS servers. If it is a zone with many records then you consume memory, disc and network resources. You have to reconfigure the zone properties for most changes in the other DNS server.

Conditional forwarders

A conditional forwarder sends (by default) a recursive query directly and returns the answer. Read more here.

Why	Why not
Queries are unconditionally forwarded to the forwarder(s). Answers are cached.  Reduces number of queries as they are recursive. (Good if you have a slow WAN.)	Have to be configured manually on all name servers. You have to reconfigure the zone properties for all changes in the other DNS server.

Sources

• DNS: Conditional Forwarders vs. Stub-Zones
• Contrasting stub zones and conditional forwarders
• DNS Conditional Forwarding in Windows Server 2003

DNS and directed lookups explained

With Microsoft DNS Server you roughly have three ways to force lookup to specific servers. They are:

• Stub zones
• Secondary zones
• Conditional forwarding

In any environment with split DNS, non-public zones or where you use .local domains you need to plan how to manage DNS lookups from third parties.

In this article you can read about the differences between these types.

 

Stub zones

When you configure a stub zone you only tell the DNS Server where to download the glue records for the zone. The glue records contains SOA, NS and if needed the corresponding A/AAAA records for that zone. Further resolving from the DNS server is done using these records. You have to type in one or more IP addresses of DNS servers to download the glue records from.

The local DNS server will use these records and continue recursion as normal, using these NS pointers as hints. You can not control what DNS Server that will be queried.

Secondary zones

A secondary zone contains a copy of the entire zone and can give authoritative answers. The entire content of the zone is downloaded from your DNS Servers (you have to specify where to download the zone from) and stored in a local file.

Conditional forwarders

This is also known as a forward delegation. When you configure a conditional forwarder you simply say that for all queries to a domain, ask this (or these) IP addresses.

All queries are recursive with a conditional forwarder.

bind9 multiple RRs of singleon type

On an issue I have been working on a zone did not load on the bind9 server. When debugging I ran across the message "multiple RRs of singleon type". To find this error message I had to run named as "named -g -u bind -d 9". According to an article I found on this matter it is related to duplicate CNAMEs or SOA records on a zone.

I started out by looking into the zone file (sort zone.db) and quickly found two almost identical SOA records.

I deleted one line and after a quick reload of named everything started working.

Sender Policy framework

In the war against forged emails we have a new contender that seems promising. The name of the new contender is Sender Policy Framework. The specifications are outlined in RFC4408.

SPF works like a charm - when configured properly. For my domain helge.net I have added the following TXT record:

helge.net. 3600 IN TXT "v=spf1 mx -all"

By doing this I say that emails from my domain helge.net is only allowed to originate from my incoming mailserver.

Given this information the received can check to see if the receiving email is forged or not.

Sender address forgery is a threat to users and companies alike, and it even undermines the e-mail medium as a whole because it erodes people's confidence in its reliability. That is why your bank never sends you information about your account by e-mail and keeps making a point of that fact.

For this to work you need to add a TXT record to your domain. At the project homepage you can find out for yourself how to do so.