Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upDyn: Sync issues when existing resource record names have capital letters #309
Comments
|
Thanks for the report. Things are normalized when they're pulled down from Dyn, but I guess it's client/API don't ignore case (as they should unless it allows you to create both Don't know what exactly we'll have to do here off-hand, but I'll queue it up to look into when I get a chance. Welcome others thoughts. |
|
If you try and create two A or AAAA records for Test and test at the same time Dyn seems to default to lower case. If one of these variants is preexisting and you add another record with either case the new record will default to the preexisting case. There's an RFC that talks about case insensitivity in DNS records here https://tools.ietf.org/html/rfc4343 |
|
There's another nuance to this unfortunately. If resource records have been created in Dyn with capital letters in their name, those capital letters persist even if the resource record is deleted and recreated with lower case only. The only way out seems to be to drop the zone from Dyn and transfer / load it in from scratch. To do this with no disruption at all could take several days depending on the TTL of the delegations from TLDs (assuming you also have a secondary service with enough capacity to cope with all your traffic)! |
|
Yeah. This is definitely a funky situation, but I think it can potentially be handled during the _mod_Delete method if I'm understanding things correctly now. Main problem I'm running into is trying to get reproducible cases to try out. Anyway. I plan to keep poking at it, but it make take a while before I get enough time together to sit down and focus on it. |
|
Given Oracle's recent announcement that the Dyn Service will be retired at the end of May 2020 perhaps we should close this issue and concentrate on platforms with a future! |
Doesn't seem to be exactly what's happening. They're sunsetting a few of the things that have been deprecated for years, but as far as I can tell the rest of what's happening will just be a rebranding of Dyn or Oracle. Afaik nothing that octoDNS makes use of will be changing, though I'd expect that some api hostnames and such will need to be adjusted, but time will tell. |
|
There's a new API for Oracle Cloud Infrastructure https://docs.cloud.oracle.com/iaas/api/#/en/dns/20180115/ |
I'm guessing/hoping that's a previous DNS service that predated Dyn as it doesn't seem to support any of the advanced traffic management stuff that Dyn does and they didn't call out as going away in the releases. |
|
So the advanced traffic management is now called Steering. https://docs.cloud.oracle.com/iaas/api/#/en/dns/20180115/SteeringPolicy/ I think unfortunately, the service they are offering right now on OCI is the best its going to get. I'll probably bail out as they aren't supporting external secondaries in the OCI service |
Dyn allows capital letters in the names of resource records - this feature has been used accidentally by our developer community and there are no technical controls in Dyn to prevent this.
If there is a prexisting record with a capital letter in Dyn that requires deletion based on the configuration in the yaml provider, octodns-sync claims to have deleted the record, but the record remains configured in Dyn.
Resource Record exists in Dyn Test.example.com (with a capital T)
octodns-sync --config-file=./config/prod.yaml --force --doit
2018-12-17T12:00:36 [139637141321536] INFO Manager init: config_file=./config/prod.yaml
2018-12-17T12:00:36 [139637141321536] INFO Manager init: max_workers=1
2018-12-17T12:00:36 [139637141321536] INFO Manager init: max_workers=False
2018-12-17T12:00:36 [139637141321536] INFO Manager sync: eligible_zones=[], eligible_targets=[], dry_run=False, force=True
2018-12-17T12:00:36 [139637141321536] INFO Manager sync: zone=example.com.
2018-12-17T12:00:36 [139637141321536] INFO Manager sync: sources=['config'] -> targets=['dyn']
2018-12-17T12:00:41 [139637141321536] INFO YamlProvider[config] populate: found 4742 records, exists=False
2018-12-17T12:00:41 [139637141321536] INFO DynProvider[dyn] plan: desired=example.com.
2018-12-17T12:01:04 [139637141321536] INFO DynProvider[dyn] populate: found 4744 records, exists=True
2018-12-17T12:01:04 [139637141321536] INFO DynProvider[dyn] plan: Creates=0, Updates=0, Deletes=1, Existing Records=4744
2018-12-17T12:01:04 [139637141321536] INFO Manager
2018-12-17T12:01:04 [139637141321536] INFO DynProvider[dyn] apply: making changes
2018-12-17T12:01:04 [139637141321536] INFO Manager sync: 1 total changes
However the resource record Test.example.com remains in the Dyn zone and is not actually deleted.
This can lead to further errors that look like this if yaml tries to change an A Record with capitalisation into a CNAME.
dyn.tm.errors.DynectCreateError: make: Cannot add a CNAME at a node with data. add: Record not added.
This is because the capitalised resource record hasn't been deleted so the CNAME can't be written over the top of it.