inwx: domain entries for apex stopped working

[wararjey]

I recently got a new domain and discovered that my dnscontrol setups stopped working. Here are a few examples:

D("example.net", REG_NONE, DnsProvider(DNS_INWX), 
MX( "@", 10, "nameofmx.example.com."),
TXT("@", "v=spf1 +mx -all"),
TXT("@", "v=DMARC1;p=reject;pct=100;sp=none;aspf=s;adkim=r;"),
CNAME("openpgpkey", "wkd.keys.openpgp.org."),
TXT("dkim._domainkey", "v=DKIM1; dkim_pubkey_data_strings")
):

dnscontrol check says everything fine dnscontrol preview says everthing is fine for unchanged data for existing domains, dnscontrol push is fine for new domains, all the entries with the "@" key give me errors like this one

#1: CREATE MX example.net 10 nameofmx.example.com. ttl=86400
FAILURE! (2005) Parameter value syntax error

I guess there has been a change to the inwx api, so that entries for the apex ("@") stopped working. The other entries, like fo the wkd and dkim key get pushed without errors, but the "@" entries do not.

Using an additional dummy BIND provider creates zone files that look ok to me.

I cannot really figure out what is behind this and would appreciate any help.

Regards,

[tlimoncelli]

CC @svenpeter42

[svenpeter42]

It looks like INWX has decided that they no longer accept "@" but want an empty string instead.

[inwx-mba]

Hello Together and greetings from INWX!

I would like to apologize briefly, unfortunately an error has led to this problem. We unintentionally disabled the @ customization in the origin of the domain name. Unfortunately there was a problem in the communication to our developers.

Yesterday we were informed by a customer about this issue and my colleagues were able to fix it.

The @ is now accepted correctly again!

Thanks a lot for your quick efforts to change it in your software, too!

Best regards Montgomery

[patschi]

Thanks Montgomery for your very fast reply to my ticket and in this GitHub issue here!

@tlimoncelli @svenpeter42 I think it might be worth reverting the commit to stick with the @? @ is very common practice and is working again, so I think it might make sense.

[svenpeter42]

Yeah, agreed. We should be able to just revert this commit now.

[tlimoncelli]

Sure! Submit a revert PR. (I defer to your expertise. I'm fine either way.)

[tlimoncelli]

I would like to apologize briefly, unfortunately an error has led to this problem. We unintentionally disabled the @ customization in the origin of the domain name. Unfortunately there was a problem in the communication to our developers.

FYI: I'm reverting the change as suggested.

Also FYI: The DNSControl integration tests are 51% to test the project and 49% to alert us when SaaS providers change their API in unexpected and often unintentional ways. If INWX needs a test framework to detect API changes and prevent regressions, please consider using our framework or stealing the good parts. Our automated tests run weekly and that helps us "shift left" these kind of problems (i.e. make it more likely that we'll notice a change in the test area, not in production.)

Tom