Relative CNAME targets

[alehaa]

Using NetBox DNS I noticed that CNAME values can be relative, i.e. foo.example.com can point to bar and the details will list bar.example.com as the target. However, I can't find a reference to whether this is a valid RFC-compliant RR.

Looking at octodns/octodns#987 I see that RFC 1035 doesn't seem to be clear about this. However, another comment points out that this seems to be a BIND specific feature. So what's the deal with these record RRs?

[peteeckel]

Hi @alehaa, that's an interesting issue.

First of all, validation of names is surprisingly hard. Not only are the RFCs not very precise in some points, as a consequence the interpretation of the name server implementations varies even more widely. That's an area I'm still not completely satisfied with.

Second, if we talk about DNS names in RR values we not only have to talk about CNAMEs. There are a lot of other RR types that have names in their values, and if CNAME were an issue, that would be the case for all of them (DNAME, MX ... there are a lot more, and more obscure ones).

Third, in the RFCs a difference is made in the RFCs between the master file format and the wire format. While relative names in the master file format are quite common, they are forbidden in the wire format. RFC1034, Section 3.1 is a guideline:

Relative names are either taken relative to a well known origin, or to a list of domains used as a search list. Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation, and in master files, where they are relative to a single origin domain name. The most common interpretation uses the root "." as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing.

With NetBox DNS we clearly are on the "user interface/master file" end, not the "wire format" end. So using relative DNS names is fine here and covered by the RFCs. Another indicator are the examples in the RFCs themselves, see for instance RFC1912, Section 2.4:

           podunk.xx.      IN      NS      ns1
                           IN      NS      ns2
                           IN      CNAME   mary
           mary            IN      A       1.2.3.4

Bottom line: According to the RFCs there is no issue whatsoever with relative names in record values. If octodns-bind has an issue with them, it's probably an issue on their end.

Potentially it would make sense to add two options (default False):

1. Check for relative names in RR values and deny validation of records containing them
2. Automatically convert relative names to their absolute values when saving

and a management command that can be used to convert all existing relative values in record names to absolute ones.

On the other hand that can also be done by exporters for the name servers that - without any RFC requirement to do so - require absolute names. Usually I prefer to add options to loosen validation requirements (because they are required for NetBox DNS to work with certain non-standard implementations), not to add requirements that are not covered by RFCs, so I'd rather not invest work in that direction.

[peteeckel]

I conducted a little experiment with some authoritative name servers and the following zone file:

example.com.      86400  IN     SOA    ns1.example.com. postmaster.example.com. 2025012001 43200 7200 2419200 3600

test1                           IN   A       10.0.0.1
test2                           IN   CNAME   test1

Loading this zone file into a couple of open source authoritative DNS servers gave the following results:

Server	Result	Remarks
BIND9	OK
Knot	OK
PowerDNS	OK	Not via add-record, but via load-zone (see FR 636)
nsd	OK
YADIFA	OK

Of course I checked the resolution via dig, which always gave the expected result:

[root@vbox ~]# dig @localhost test2.example.com. A

; <<>> DiG 9.16.23-RH <<>> @localhost test2.example.com. A
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23701
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;test2.example.com.		IN	A

;; ANSWER SECTION:
test1.example.com.	86400	IN	A	10.0.0.1
test2.example.com.	86400	IN	CNAME	test1.example.com.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 20 13:55:23 UTC 2025
;; MSG SIZE  rcvd: 82

The only server that has an issue with a CNAME record pointing to a relative name is PowerDNS, but that's purely an issue of the CLI (and supposedly the GUI as well) as both always add the trailing dot when you enter a CNAME. which precludes entering a relative name. When the zone file is loaded into PowerDNS as a whole there is no problem either.

So the 'This is a BIND specific feature' argument is definitely void.

[peteeckel]

I just merged #511 which should help addressing the issue in OctoDNS and other consumers that have problems with relative names in record values.

The PR adds an absolute_value property to Record objects. That property contains derelativized names for all record types that can contain names in their values. For all records with absolute names and all other record types the value of the property is identical to value.

[peteeckel]

Just released 1.2.1 with the new feature.

[alehaa]

Thanks! I'll check on integrating this feature into octodns-netbox-dns.