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

FAILURE! native OVH DMARC record requires subdomain to always be _dmarc, #3427

Closed
nathanaelhoun opened this issue Feb 10, 2025 · 6 comments · Fixed by #3440
Closed

FAILURE! native OVH DMARC record requires subdomain to always be _dmarc, #3427

nathanaelhoun opened this issue Feb 10, 2025 · 6 comments · Fixed by #3440

Comments

@nathanaelhoun
Copy link

Describe the bug
A clear and concise description of what the bug is.

Setting a DMARC record on a subdomain, using the OVH registrat, results in the following error message.
However, the DMARC type is (now?) accepted from the OVH web ui.

FAILURE! native OVH DMARC record requires subdomain to always be _dmarc,

To Reproduce
Steps to reproduce the behavior:

  1. Add a DMARC record on a subdomain, hosted by OVH

    TXT("_dmarc.listes", "v=DMARC1;p=quarantine;sp=quarantine;pct=100;adkim=r;aspf=r;fo=1;ri=86400;rua=mailto:postmaster@[REDACTED],mailto:dmarc-reports@[REDACTED];ruf=mailto:[REDACTED],mailto:[REDACTED];rf=afrf"),
  2. Push the zone: FAILURE!

Expected behavior
A clear and concise description of what you expected to happen.

I expected the record to be set.

DNS Provider

  • OVH

Additional context
Add any other context about the problem here.

  • The same zone when set from the OVH Web UI: it accepts DMARC records on the listes. subdomain.

    _dmarc.listes.[REDACTED]. 3600 IN TXT "v=DMARC1;p=quarantine;pct=100;rua=mailto:postmaster@[REDACTED],mailto:dmarc-reports@[REDACTED];sp=quarantine;aspf=r;"
  • The relevant code: https://github.com/StackExchange/dnscontrol/blob/main/providers/ovh/protocol.go#L189. I can submit a PR but I would know if there is a reason for that check that I haven't thought of.

@tlimoncelli
Copy link
Contributor

CC @masterzen

@masterzen
Copy link
Contributor

Thanks for the report!

It's very possible that OVH changed their backend verifications and now allow _dmarc in subdomains. I'm pretty sure it wasn't allowed in the past.

I'll have a look this week (not sure I'll have the time before this week-end though).

@tlimoncelli
Copy link
Contributor

That sounds reasonable. This is the kind of validation that is best left to the API. There's only so much pre-validation we can do.

@masterzen
Copy link
Contributor

Hi all,

I quickly tried to reproduce the problem, but it never triggered the failure.
I think it comes down to the fact that there needs to be DMARC record existing already in the zone (probably created before through the ovh Panel?).

I'll try again tomorrow doing more tests. Worst case, I remove the offending check and we call it a day :)

masterzen added a commit to masterzen/dnscontrol that referenced this issue Feb 15, 2025
Beforehand OVH refused to allow updating native DMARC records that
weren't exactly `_dmarc`. This prevents updating `_dmarc` subdomains
such as `_dmarc.something`.
This change makes that test less strict and allows to now update DMARC
records that are subdomains of the zone domain.
masterzen added a commit to masterzen/dnscontrol that referenced this issue Feb 15, 2025
Beforehand OVH refused to allow updating native DMARC records that
weren't exactly `_dmarc`. This prevents updating `_dmarc` subdomains
such as `_dmarc.something`. This change makes that test less strict and
allows to now update DMARC records that are subdomains of the zone
domain.
masterzen added a commit to masterzen/dnscontrol that referenced this issue Feb 15, 2025
Beforehand OVH refused to allow updating native DMARC records that
weren't exactly `_dmarc`. This prevents updating `_dmarc` subdomains
such as `_dmarc.something`. This change makes that test less strict and
allows to now update DMARC records that are subdomains of the zone
domain.
@masterzen
Copy link
Contributor

Hi,
I was able to reproduce it, it requires the record to exist in the OVH zone with a native DMARC record.

I'm proposing a fix in #3440.

This is the kind of validation that is best left to the API

I think the reason we added this validation was that the error message from OVH API was very cryptic :(

@nathanaelhoun
Copy link
Author

Thanks for the fix @masterzen!

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

Successfully merging a pull request may close this issue.

4 participants