Bunny DNS provider tries to create NS records on the root of the domain

[flokli]

Describe the bug I'm using bunny DNS to create a shadow copy of my zone entries, similar as described here:

https://docs.dnscontrol.org/advanced-features/nameservers#shadow-nameservers

The main zone is hosted at Gandi. dnscontrol wants to modify the NS records in Bunny to point to Gandi, which fails:

#1: ± MODIFY flokli.io NS (coco.bunny.net. ttl=0) -> (ns-129-c.gandi.net. ttl=0)
FAILURE! BUNNY_DNS: cannot change implicit records
#2: ± MODIFY flokli.io NS (kiki.bunny.net. ttl=0) -> (ns-180-a.gandi.net. ttl=0)
FAILURE! BUNNY_DNS: cannot change implicit records
#3: + CREATE flokli.io NS ns-21-b.gandi.net. ttl=0
[BUNNY_DNS: Bad API response for PUT /dnszone/xxxxxxx/records: {"ErrorKey":"validation_error","Field":"Value","Message":"NS records are not supported on the root of the domain.\r"}]
FAILURE! bad status code from BUNNY_DNS: 400 not in [201]
[… other records created here]

Expected behavior If creating NS records is not supported, maybe the provider should skip these?

DNS Provider

• BUNNY

Additional context Add any other context about the problem here.

[tlimoncelli]

CC @ppmathis

[tlimoncelli]

Many DNS registrars do not permit changes to the apex NS records. There's not much the code can do to work around that.

If you want shadow nameservers, try this:

D("example.com", REG_BUNNYDNS, { no_ns: "true" },
   ...

If that works, please let me know and I'll update the shadow-nameservers doc.

[flokli]

D("example.com", REG_AUTODNS, DnsProvider(DNS_AUTODNS), DnsProvider(DNS_BUNNY, 0), {"no_ns": 'true'});

This doesn't seem to have an effect. DNS_BUNNY wants to add the NS records created by DNS_AUTODNS to the bunny zonefile (which fails), while it itself reports currently having set coco.bunny.net. and kiki.bunny.net. as NS records. And fails whenever you want to apply it. It's no big deal, it doesn't do the wrong thing it just creates a bit of noise.

Is there a way to configure dropping corrections relating to apex NS records as part of a specific DnsProvider(…) call? I think that's what'd be needed here, to describe we do not want to touch the apex NS records for that specific DNS Zone.

[tlimoncelli]

Sadly I can't think of a workaround.

Jus to confirm: Are the FAILURE! messages treated as warnings (don't stop the process) or errors (ends the "push")?

[flokli]

It proceeds with the rest of the changes (and other domains).

It however says at the bottom:

completed with errors

(not warnings)

[tlimoncelli]

"completed with errors" -- If you want to try to fix that, take a look at line https://github.com/StackExchange/dnscontrol/blob/7882326a8dad0dc8b04ff0f71ef4f7d79e1b5fa1/providers/bunnydns/records.go#L126

Instead of just returning the result of b.createRecord(), check if the error is cannot change implicit records and return nil instead. Otherwise return the original value.

[flokli]

createRecord never returns this error, these errors are emitted from the other callback function(s) so far.

I don't feel comfortable touching the provider, as I don't know how the API behaves.

Is there a way to configure dropping corrections relating to apex NS records as part of a specific DnsProvider(…) call? I think that's what'd be needed here, to describe we do not want to touch the apex NS records for that specific DNS Zone.

I think the proper way to fix this generally would be something like this. The Bunny provider shouldn't even need to see other NS records, if we have a way to configure it like this from the outside.

[SukkaW]

Not know if it is related, but I faced a similar behavior when implementing Vercel's provider: https://github.com/StackExchange/dnscontrol/pull/3542

Vercel doesn't allow you to create NS records on the apex root (which I limited in Auditrecord). They also maintain their root NS records for you, you can't view/edit/modify them via the web dashboard and API. This sounds exactly like what Bunny is restricting.

In Vercel's case, I simply make GetNameservers return an empty tuple; now DNSControl won't try to create/touch any root NS records.

Exoscale provider and Gandi V5 provider also return nil/empty tuple in their GetNameservers. Probably this is the right way to go?