2

unbound.conf is used to configure Unbound, a caching DNS resolver. The documentation of version 1.6.8 says:

Server Options
    private-domain: <domain name>
        Allow this domain, and all its subdomains to contain private
        addresses. Give multiple times to allow multiple domain names
        to contain private addresses. Default is none.

We run unbound Version 1.6.0 with Debian Stretch (manpage and cited documentation do not differ here).

We have tested the following three variants separated by

  • editing /etc/unbound/unbound.conf
  • checking unbound-checkconf
  • restarting systemctl restart unbound.service
  • monitoring the unbound logfile.

Variant 1 (ending in a dot):

private-domain: domain.example.

Variant 2 (not ending in a dot):

private-domain: domain.example

Variant 3 (in given order):

private-domain: "domain.example. domain.example"

For all three variants unbound-checkconf returns:

unbound-checkconf: no errors in /etc/unbound/unbound.conf

At variant 3 we find in the logfile:

debug: ignoring duplicate private-domain: domain.example.

Makes sense, because one entry for the same domain name has to be sufficient and it seems to verify that unbound has an identical handling for both ways of writing the domain names (with/without dot).

Both ways are working, but what is the correct syntax to define private domain names in unbound? Should domain names end in a dot, or not? Is the dot at the end useful or meaningless? What implications could a needless or a missing dot have?

Fabian
  • 397
  • 3
  • 17

1 Answers1

1

This question is ancient, but it still came up for me as the first entry in a search, so IMO it's worth trying to answer.

Bottom line: In this context, and in most others, there is no practical difference between domain.example (with no trailing .) and domain.example. (with the training .). Both are therefore correct.

Now the long answer. :) This answer–and the only other comment now here, from 2018–proceeds from the what the specification says, as the 2018 comment to the OP also does. While there may be semantic differences between the RFC and the way Unbound uses domain names, this would be a deviation from the specification, and likely considered a bug.

RFC 1034 Section 3.1 defines the core syntax of domain names thusly:

When a user needs to type a domain name, the length of each label is omitted and the labels are separated by dots ("."). Since a complete domain name ends with the root label, this leads to a printed form which ends in a dot. We use this property to distinguish between:

  • a character string which represents a complete domain name (often called "absolute"). For example, "poneria.ISI.EDU."

  • a character string that represents the starting labels of a domain name which is incomplete, and should be completed by local software using knowledge of the local domain (often called "relative"). For example, "poneria" used in the ISI.EDU domain.

Relative names are either taken relative to a well known origin, or to a list of domains used as a search list.

Note the last sentence: Unless a "a list of domains used as a search list" is defined, names without a trailing dot are considered relative to a "well known origin"–i.e., the root of the name hierarchy. For public DNS, the DNS root corresponds to the root zone; private name hierarchies seldom deviate from this convention.

For practical purposes, this means that a fully qualified domain name (FQDN) without a trailing . should almost always be considered relative to the root of the name hierarchy, which is equivalent to the same "absolute" domain. Hence, domain.example == "domain.example relative to the root" == domain.example..

When might the different representations have implications? When you are dealing with fragments of a domain name instead of a FQDN. In that case, you should omit the period, and consider using the period on the FQDNs. If you run example.com. (note the period; the root server sends *.example.com traffic to you) and want to set up east.example.com. as a subdomain, east is the subdomain; east. is the top-level domain (TLD) .east.

Again: this is what the spec says. Check the docs for the tool that you're configuring, as always. There are also other areas of the spec, notably DNS compression, where some additional semantics are introduced. You can ignore those if you aren't literally parsing or generating messages in the DNS wire protocol.

Hopefully that answers the question fully. I hope this is helpful to someone.

pgroce
  • 26
  • 2