Mirror zones (was: Allow CNAME for apex domain)

[alehaa]

Is your feature request related to a problem? Please describe.
Some DNS providers like Cloudflare allow configuring a CNAME for the @ record. Although this is not supported by RFC, they will ensure the domain is resolved correctly.

When using this plugin as single source of truth for octoDNS, these records can't be managed. Trying to do so results in the error message:

There is already an active record for name @ in zone [external] example.com, CNAME is not allowed.

Describe the solution you'd like
The error message described above originates from models.Record.clean():

netbox-plugin-dns/netbox_dns/models/record.py

Lines 786 to 794 in 7e05a4a

	if self.type == RecordTypeChoices.CNAME:
	if records.exclude(type=RecordTypeChoices.NSEC).exists():
	raise ValidationError(
	{
	"type": _(
	"There is already an active record for name {name} in zone {zone}, CNAME is not allowed."
	).format(name=self.name, zone=self.zone)
	}
	)

I suggest adding a new configuration variable either in the PLUGIN_CONFIG or per-view to allow CNAME records as @ domain name. If set, the code mentioned above should exclude SOA and NS records when searching for existing records.

Describe alternatives you've considered
A and AAAA records can be added manually instead. However, this duplicates management overhead.

Additional context
If accepted, I can provide a PR for this feature.

[peteeckel]

Shudder :-)

I was afraid that sooner or later someone would come up with that requirement ... I know of this horrible practice by Cloudflare, which is not permitted for some very good reasons. But having it as a config option won't hurt (much), so it's fine.

Let me see if I can squeeze it in before today's release - if I can't you're very welcome to provide a PR.

[peteeckel]

OK, squeezing it in quickly failed.

It's more complicated than just allowing other record types in clean(), as the SOA record needs to be rewritten as well and that fails because of the unlucky CNAME. So if you want to have a go, you're welcome.

Remember to write positive and negative tests and some lines of documentation - nothing fancy, just so the reader knows that the feature is there and they will burn in hell if they ever use it :-)

[alainstucki]

Hi
Another enhancement in this direction would be also useful (which also is not convered by any RFC and is specific to PowerDNS): Record-Type ALIAS
https://doc.powerdns.com/authoritative/guides/alias.html

That is basically the same thing what Cloudlfare is doing (and it is very usful in some cases).

[peteeckel]

Hi Another enhancement in this direction would be also useful (which also is not convered by any RFC and is specific to PowerDNS): Record-Type ALIAS https://doc.powerdns.com/authoritative/guides/alias.html

That is basically the same thing what Cloudlfare is doing (and it is very usful in some cases).

I must admit that's where I would draw the line.

There is no record type ALIAS, period. Allowing it would mean diverging from any sensible standard, and, more seriously, abandoning the power of dnspython with regards to validating and formatting records, which NetBox DNS relies on heavily.

So if you really want ALIAS, I suggest you create a fork and see where you end up. I will definitely not do this, or accept any PR trying it.

[kirkkak]

Sorry for jumping in this way, but i'm struggling with same ANAME (ALIAS by Cloudflare definition) entry sync problem.

Ended up reading this draft about ANAME
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-aname-01

and longer story here
https://www.isc.org/blogs/cname-at-the-apex-of-a-zone/

could it be solved as ANAME entry? .. and octodns/middle layer tooling interpretation takes care the vendor specific "version" of it

[peteeckel]

Generally, no features specific to a particular DNS server implementation will be accepted. Views were an edge-case, because actually they are a BIND specific feature but can be implemented with other servers by running multiple instances.

If it's possible to implement specific features using a feature flag, that can be OK, too - the current issue is an example for that, as you can allow it without breaking general compatibility, leaving it up to the user to decide whether it's OK in their specific environment or not.

[alainstucki]

That makes totally sense and i completely agree with that statement. i imagined adding the record type ALIAS could be done in a similar way. Apparently that's a different, more complicated story.

[peteeckel]

An easy way to find out the set of records that can be supported (that's actually a dynamic set, as it depends directly on the record types supported by dnspython) is to run the following commands:

from dns import rdatatype

print(llist(rdtype.name for rdtype in rdatatype.RdataType if not rdatatype.is_metatype(rdtype)))

This is dynamic because when (it happened a couple of times over the last years) dnspython starts supporting new record types, the RecordTypeChoices choice set automatically adopts them.

[peteeckel]

So I think I must correct myself on my absolute dismissal of ALIAS: You just need to convince the dnspython team of supporting it, and it will magically appear in NetBox DNS ...

[alainstucki]

Thanks Peter, i will try. Schöne Grüsse aus Bern

[alehaa]

Your discussion of feature compatibility and RFC compliance made me think about my FR. The feature I requested is easily solved by changing the validation of CNAME records. However, the managed records won't be compatible with DNS servers in general, only a few specific ones (Cloudflare in this case). This introduces a kind of vendor lock-in for the data managed in NetBox.

After thinking about it for a while, maybe my approach was wrong. Maybe the solution is not to change NetBox DNS to somehow work with my DNS service, but to allow it to easily manage RFC compliant data. So I came up with the idea to close this FR. Instead, I would like to propose some kind of new model to manage some kind of autocopy mechanism, where you could define a source record name and matching values will be copied into the destination name as a managed record. For example, A/AAAA foo.com could be copied as bar.com and the mechanism would ensure that bar.com values always follow foo.com.

What do you think about this? Of course I will formulate a proper FR for this change.

[peteeckel]

Hi @alehaa, I've converted your initial FR to a discussion as the issue is starting to get much broader than your original FR. I hope that's OK.

In some special cases a DNAME might already be a solution. The problem with DNAME is that it largely has the same restrictions as CNAME (specifically it can't be defined at the apex), so its usefulness is limited, but in some cases it will do the job. Let's say you have two zones zone1.example.com and zone2.example.com and want to map a sub-zone of zone1.example.com to names in zone2.example.com, you can create a DNAME sub.zone1.example.com and point it to zone2.example.com. That results in name1.sub.zone1.example.com being resolved as name1.zone2.example.com.

The obvious culprit is that you can't create a DNAME for zone1.example.com unless you also happen to control example.com, so it's usefulness is limited in many cases. Apart from that, DNAME is rarely seen in the wild and I suspect some resolvers will have trouble with it.

I like your idea of replicating records to a different zone though, even more so as it also addresses a problem with IPAM DNSsync raised by @phlpr that currently can't be solved in a satisfactory way: #340 (comment). The objective was to create DNS records for IP addresses in multiple zones, and at least for some special cases this could be achieved with "Mirror Zones" (working title, there may be a more suitable name for it).

Let me sketch out my first approach to implementing this and tell me if that fits your bill:

• Adding a reference that tells a zone to mirror the records of another zone makes it a mirror zone.
• Mirror zones can be in a different view from the zone they mirror (which solves another problem, by the way, allowing zones to be managed easily that have to be identical in multiple views).
• All unmanaged records and all managed records that were created by IPAM DNSsync are synchronized on create, modify, delete operations.
• A mirror zone cannot have its own unmanaged records.
• IPAM DNSsync ignores mirror zones and does not create records in them.
• Creating a mirror zone then mirrors all relevant records from the reference zone.
• Converting a normal zone to a mirror zone requires removing all unmanaged records from the zone manually first, and then mirrors all relevant records from the reference zone.
• Converting a mirror zone to a normal zone removes all mirrored records from the mirror zone, but leaves the zone as is otherwise.
• Deleting a mirror zone deletes all records and managed records in them.
• Deleting a zone referenced by a mirror zone deletes all mirrored records in the mirror zone and makes it a normal zone.

What do you think? It's not a small feature, but I think it could be of broader interest and usefulness.

[alehaa]

The objective was to create DNS records for IP addresses in multiple zones, and at least for some special cases this could be achieved with "Mirror Zones" (working title, there may be a more suitable name for it).

Interesting. I have a similar problem in my setup as well. I have a two views, one having all internal DNS records and another one just having the public ones (subset of internal). I solved this by asking for #401, but the problem of replicating CNAME records between zones remains. Right now I can't tell if mirror zones would solve this, as my setup has multiple internal zones (childs of a parent domain) while the external one is just a large single zone. Having this discrepancies could make mirroring difficult.

However, there's the second use case my intention was to solve with this FR: Mirroring just a single record. A typical example would be having webhosting.example.com and wanting to have customer.com to point to this webhosting record. The customer domain shouldn't get all example.com domains replicated.

So maybe these are two features which could build on top of each other?

1. Replicate a single domain name into another zone. If no filter is defined, all record types with same name will be replicated, otherwise just selected ones.
2. Replicate an entire zone by automatically creating previously mentioned replicas of all zone records. An optional filter could limit the records to replicate like Filter DNSsync entries for each view #401 defined a filter for IP addresses (e.g. just records with custom field "public" set to True).

[peteeckel]

Filtering is definitely on the list of things that should be added, and it's not a big deal, too - the same mechanism as for IPAM DNSsync filtering will do.

Your other use case looks less promising, I'm afraid. To achieve that, you'd need to mirror records from multiple zones to one zone, which introduces a lot of additional problems like collision handling. That would in turn require to validate the records in all target zones before accepting a change to a record in the mirrored zone, which in turn makes validating input a lot more complicated.

While this is possible, I must admit I don't see the benefit in a sane ratio to the cost. While your use case is valid, it seems to be a bit exotic (I stand corrected if there are wide-spread uses for it, so everyone please speak up if you disagree), and so I'd go for the other way that's always an option: Write a custom script for it and make it run via button or event hook. My favourite solution for everything too far off-standard.

[alehaa]

Okay, then I guess I need to invent some custom script magic to map multiple internal zones to a single external one. That's okay. :)

[alehaa]

When I formulated the feature request described in this discussion, I started working with this plugin and only had a few records to play with and test some scenarios. Now, a few weeks later, I am managing a lot more records and see some problems with my initial proposal.

It's all because I want to implement split DNS: we have a lot of internal services and some external ones, but both share the same domain. Now I have some data to check this scenario, let's be pragmatic: replicating the zone with a filter like "record has public flag set" should work fine. In fact, it would save a lot of headaches if we didn't have to think about how to put records in different zones, but just take what's there and select the public records in an external zone copy.

So I thought about how to implement this:

1. I would change the foreign key from Record to ipam.IPaddress to a GenericForeignKey as "related_object". This would allow us to keep track of mirrored records and e.g. delete the copy when the main record is removed. Perhaps this could also be useful for managing other relationships on managed records.
2. A signal should replicate the records whenever a record or the replication filter is added or changed. Deletion should work automatically with on_delete=CASCADE.

[alehaa]

@peteeckel If it‘s okay for you I‘d like to try working on a PR for this. The idea described might be rough, but I‘m positive testing on a POC might give some better insights on this.

[peteeckel]

Hi @alehaa, you're very welcome to provide a PR for the "Mirror Zone" feature!

Regarding your approach using GenericForeignKey:

• I don't see the point. The use case for GenericForeignKey is to be able to relate to objects of different types, and the ipam_ip_address field needs to link only to one. Extending it to general objects would require lots of object type-dependent code, which kind of makes it pointless.
• But the killer is that GenericForeignKey does not automatically create the reverse relation, which we need. You'd have to create a GenericRelation in ipam.IPAddress, and with that being a NetBox core model you can't.

On the other hand you usually get the best ideas while trying, so have a go!

[joshuadouch]

Just thought I'd chime in - I also have found myself in need of this configuration option.

I'm working to sync records from Cloudflare into Netbox, allowing management for both my Internal (PDNS) and External (Cloudflare) DNS from Netbox, using Webhooks + Ansible to call the appropriate APIs.

This unfortunately means inputting records that while they exist in Cloudflare, aren't compatible with DNS standards due to Cloudflare's CNAME flattening feature.