Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

HetznerDNS Provider / NS Records

See original GitHub issue

Hello!

I am trying to add the NS Records in my octoDNS configuration too.

I have an interesting behavior at the moment:

'':
  - type: NS
    values:
      - hydrogen.ns.hetzner.com.
      - oxygen.ns.hetzner.com.
      - helium.ns.hetzner.de.

This option makes nothing, no changes.

If I use this option:

'@':
  - type: NS
    values:
      - hydrogen.ns.hetzner.com.
      - oxygen.ns.hetzner.com.
      - helium.ns.hetzner.de.

This options generates new entries with every run.

My question is if I configured it correctly or if I missed anything? Additionally if the coding is correct or if I made an issue.

Additionally A, MX and TXT records are in the ‘’ field for the domain.

Yours faithfully, Mathias

Issue Analytics

State:
Created 2 years ago
Comments:5 (4 by maintainers)

Top GitHub Comments

1reaction

rosscommented, Dec 30, 2021

I am trying to add the NS Records in my octoDNS configuration too.

I could have sworn it was in the README/docs somewhere, but apparently not, but octoDNS doesn’t support managing apex NS records due to messes around how various providers deal with them. Some providers allow you to manage them completely, some allow you to add or remove extra values but won’t let you touch their own NS values, and others won’t let you do anything with them.

I think it’d probably make sense to add a validation to the NS record type similar to the one on CNAMEs that throws an error if you try to do it (unless lenient is included.)

The @ is probably a ~bug in the Hetzner provider. I’m not familiar with it, but a quick glance at it seems like the provider under the hood expects @ for apex records so the code is adding that as needed and removing it when things come back from the provider with @. I don’t know that the provider really needs to handle that case. I suppose octoDNS could throw an error when the name is @ as that’s otherwise not a legal name. I’ll think about that.

See https://github.com/octodns/octodns/issues/38 for more info on the apex NS stuff and that issue tracks the maybe someday managing of them. This issue can stay open to record the one/two changes mentioned above.

0reactions

rosscommented, Dec 31, 2021

@ symbol validation is added in https://github.com/octodns/octodns/pull/827.