Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Netcup Error - TXT and MX record #1103

Open
mustermann2021 opened this issue Jan 30, 2022 · 6 comments
Open

Netcup Error - TXT and MX record #1103

mustermann2021 opened this issue Jan 30, 2022 · 6 comments

Comments

@mustermann2021
Copy link
Contributor

I tried the pullrequest for "Netcup" and it works most of the way but it giving some errors at the end.
The examples are these once:

ERROR - create für Eintrag MX/nitter.maindomain.tld fehlgeschlagen: MX record destination is incorrect. An example of a correct entry: mail.nitter. (4013)

ERROR - create für Eintrag TXT/_dmarc.nitter.maindomain.tld fehlgeschlagen: Please put quotation marks in front of a backspash. The name server automatically sets quotation marks at the beginning and end. (4013)

Can i somehow help so solve the problem? I use lexicon within yunohost and the full errorlog is here.

Thanks you a lot!

@adferrand
Copy link
Collaborator

adferrand commented Feb 21, 2022

From what I see in the logs, it seems that the MX records should be inserted with a trailing dot in the content, and the TXT record content should be enclosed with quotes.

It seems also that the values of the records are passed verbatim from the command line flag --content to Netcup API. Could you retry the calls with content of kind mail.domain.tld. for the MX records and '"My content"' for the TXT records ?

@mustermann2021
Copy link
Contributor Author

Hey there,
thanks for the suggestion. ill try my best and test it. Hopefully this weekend.

@alexAubin
Copy link

Hey there,

I'm one of the Yunohost folks who worked on the integration of Lexicon

After chatting a bit with @mustermann2021, here are some additional info that may help:

  • From what I understand, the issue being discussed here is triggered when calling the Lexicon lib with, for example, type='MX' and name='foobar'
  • From what I understand of the API's answer, it's complaining either because it expects a fqdn (e.g. foobar.domain.tld.) - or because it wants the name to be prefixed with mail. maybe ? (I hope it's not the later)
  • The thing is that our code works for other registrars, such as OVH and Gandi ... but not with some registrars, because some registars API expect records to be formatted in a certain way. Yet we format our query the same way for all registrars. This is cumbersome because the expectation was that Lexicon would handle the registrar-specific formatting and just provide a uniform, registrar-agnostic interface ... Or maybe there's already some good care that went into this and Yunohost is just misusing the library
  • I had a quick look a few months ago and noticed that Lexicon does not integrate unit tests for MX and SRV records (maybe TXT too ? i don't remember) which is where we noticed that some registrars would return errors because of their API specificities compared to others

So bottom line is : maybe sending mail.foobar.domain.tld. as name works for Netcup API ... but we know that sending foobar for OVH and Gandi does work, so why wouldn't it work for Netcut too 😛

@alexAubin
Copy link

(Aaaand after writing this I realize that I was focused on the name but not the value/content ... which our error message doesn't display ... though still, the current formatting of queries work for OVH/Gandi but not for some other APIs)

@adferrand
Copy link
Collaborator

Indeed, the problem here is for the value of the record, not its content. For the name, yes Lexicon is taking care of standardizing the inputs/outputs so that the commands are always the same. Basically it is always acceptable to put the relative name for a given domain.

But for content, there is no specific control, because it is really depends on each DNS API and even each kind of record.

@mustermann2021
Copy link
Contributor Author

@adferrand Thanks for the clarification.
@alexAubin So there is nothing we can do right?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants