Gandi DNS inconsistency with CNAME pointing to '@'

[julianfoad]

Gandi treats CNAME value '@' inconsistently. In DNS queries it's expanded, but in the API it's not.

In my Gandi DNS admin console I have some records like this:

pubsub 3600 IN CNAME @

In DNS queries, the '@' is expanded:

$ dig pubsub.example.net.
pubsub.example.net.     3575    IN  CNAME   example.net.

In Gandi's admin console, the "friendly" editor shows Your record will point to @.example.net.

This is inconsistent. Is the '@' supposed to be expanded or not? If so, the friendly editor display is wrong. If not, DNS queries are wrong.

Use of the '@' character is mentioned in RFC1035 - Domain Names - Implementation and Specification but this usage seems not sufficiently specified there.

OctoDNS error with Gandi DNS API: Exception when CNAME points to '@'

OctoDNS with its octodns-gandi module throws an exception when reading it:

$ octodns-dump --config-file=config/production.yaml --output-dir=tmp/ example.net. gandi
INFO  Manager __init__: config_file=config/production.yaml (octoDNS 0.9.21)
INFO  Manager __init__: provider=gandi (octodns_gandi 0.0.1)
...
octodns.record.ValidationError: Invalid record pubsub.example.net.
  - CNAME value "@.example.net." is not a valid FQDN

Should either Gandi's API or octodns-gandi expand the '@' in this case, I wonder? Or should this record have been disallowed in the first place?

---

[ This report is also posted on my blog: https://wrily.foad.me.uk/gandi-dns-inconsistency-with-cname-pointing-to-at ]

[ross]

Interesting. I haven't run across that usage of @ before. Definitely seen it in some providers to mean the APEX, e.g. domain=foo.com., name=@ means fqdn=foo.com.. My (quick) skim of the RFC makes me think it's referring to that case, but I could see it including including referring to the APEX as well.

I just tried using @ in a couple other providers I have easy access too:

Azure doesn't allow it:

NS1 does:

Since octoDNS disallows @ for names, https://github.com/octodns/octodns/blob/7b2a1d44296ce66e347ad81e4cce54fbc55c1230/octodns/record/base.py#L72-L73, preferring '', I'd lean towards disallowing it for values with a similar error message as well, preferring the target fqdn.

We could fairly easily translate them in both cases if others feel that's preferable, /cc @octodns/review for thoughts?

[julianfoad]

I filed an issue with Gandi. I'll report here when I get a case reference or reply. Seems to involve inconsistency on their side; not sure which parts of the behaviour should be deemed erroneous. Recommend waiting to see what they say before deciding anything.

[ross]

I suspect they'll say it works as expected using, though testing NS1, which allows the value, further it returns a literal @:

coho:octodns ross$ dig +short apex.exxampled.com. @dns4.p07.nsone.net
\@.

So that's definitely inconsistent behavior and with that we have one that translates, one that doesn't allow it, and one that returns the literal value. Pretty strongly leaning towards octoDNS's best path forward to be disallowing @ as a value, either just leaving things as-is and erroring out, or potentially with an improved error message that recommends replacing the @ with the FQDN.

[julianfoad]

Gandi case reference api-ote #16389785 .

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[julianfoad]

Nothing heard from Gandi so far. Nothing's changed yet, as far as I know, although I haven't tested it again recently.

[github-actions[bot]]

This issue is stale because it has been open 90 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[julianfoad]

Still open.