OVH DNS Provider (#143)#175
Conversation
masterzen
force-pushed
the
feature/ovh-provider
branch
from
337c2ef to
301e0b1
Compare
masterzen
force-pushed
the
feature/ovh-provider
branch
from
5b17774 to
891455e
Compare
masterzen
force-pushed
the
feature/ovh-provider
branch
from
891455e to
172225e
Compare
|
I've rebased to the latest master. |
|
Sorry for the delay. Could you rebase and re-run the integration tests? I'd be glad to merge this. |
|
@tlimoncelli I'll do that this week-end. Thanks! |
masterzen
force-pushed
the
feature/ovh-provider
branch
2 times, most recently
from
d99752c to
4d26587
Compare
|
I've rebased and made sure documentation is generated (I also implemented the I've also enabled support for TLSA, but that required a modification of the integration test because OVH doesn't allow TLSA records for a sha256 matching type with a checksum that doesn't have exactly 64 characters (this makes sense). I couldn't test the other providers with this integration test change, so I hope I haven't introduced any test regressions. Thanks! |
| } | ||
| actual = append(actual, rec) | ||
| } | ||
|
|
There was a problem hiding this comment.
Insert this (all providers now must do this; though if you were passing the integration tests it might be a no-op):
// Normalize
models.Downcase(actual)
There was a problem hiding this comment.
Oh, I missed this change, I'll do that.
integrationTest/providers.json
Outdated
| "domain": "$VULTR_DOMAIN" | ||
| }, | ||
| "OVH": { | ||
| "COMMENT": "47-48 OVH doesn't support TLSA records with matching type 0 (full certificate)", |
There was a problem hiding this comment.
Is there a matchingtype other than 0 that the tests could use so that the tests can run? (I don't know much about TLSA)
There was a problem hiding this comment.
Yes, matching type 2 is for sha512, but since they check the length of the checksum we'd have to have a string of 128 hex characters.
Do you want me to modify the integration test to check changing matching type to 2 instead of 0 ?
There was a problem hiding this comment.
Sure! The extra 128 bytes won't fill my hard disk :-) . (but seriously... I'd rather have working tests than not)
This adds the OVH Provider along with its documentation. Unfortunately we can't set this DNS provider to support `CanUsePTR`, because OVH only supports setting PTR target on the Arpa zone.
This implements OVH as a registrar provider. Note that NS modifications are done in a "best effort" mode, as the provider doesn't wait for the modifications to be fully applied (the operation that can take a long time).
Since OVH released their APIv6, it is now possible to update zone apex NS records, opening the door to complete dual providers scenarii. This change implements apex NS management in an OVH zone.
masterzen
force-pushed
the
feature/ovh-provider
branch
from
4d26587 to
9addcb0
Compare
|
@tlimoncelli I've pushed the fixes you asked for. Let me know if there's anything I should do. |
|
Thank you for your contribution! |
* OVH DNS Provider (StackExchange#143) This adds the OVH Provider along with its documentation. Unfortunately we can't set this DNS provider to support `CanUsePTR`, because OVH only supports setting PTR target on the Arpa zone. * OVH Registrar provider (StackExchange#143) This implements OVH as a registrar provider. Note that NS modifications are done in a "best effort" mode, as the provider doesn't wait for the modifications to be fully applied (the operation that can take a long time). * Allow support for dual providers scenarios Since OVH released their APIv6, it is now possible to update zone apex NS records, opening the door to complete dual providers scenarii. This change implements apex NS management in an OVH zone.
* OVH DNS Provider (StackExchange#143) This adds the OVH Provider along with its documentation. Unfortunately we can't set this DNS provider to support `CanUsePTR`, because OVH only supports setting PTR target on the Arpa zone. * OVH Registrar provider (StackExchange#143) This implements OVH as a registrar provider. Note that NS modifications are done in a "best effort" mode, as the provider doesn't wait for the modifications to be fully applied (the operation that can take a long time). * Allow support for dual providers scenarios Since OVH released their APIv6, it is now possible to update zone apex NS records, opening the door to complete dual providers scenarii. This change implements apex NS management in an OVH zone.
* OVH DNS Provider (StackExchange#143) This adds the OVH Provider along with its documentation. Unfortunately we can't set this DNS provider to support `CanUsePTR`, because OVH only supports setting PTR target on the Arpa zone. * OVH Registrar provider (StackExchange#143) This implements OVH as a registrar provider. Note that NS modifications are done in a "best effort" mode, as the provider doesn't wait for the modifications to be fully applied (the operation that can take a long time). * Allow support for dual providers scenarios Since OVH released their APIv6, it is now possible to update zone apex NS records, opening the door to complete dual providers scenarii. This change implements apex NS management in an OVH zone.
4 participants
This adds the OVH provider along with its documentation:
A few comments:
CanUsePTRbecause OVH supports only setting PTR with a target in the arpa zone. This makes the integration tests 31 and 32 fail horribly (can we make those use the arpa zone?)