Trailing dots in config but not in dns provider (route53)?

[jmreicha]

Looking at https://github.com/octodns/octodns/pull/1147 how does this work if e.g. route53 does not contain the trailing dots but the corresponding source config has them?

I ran into a case where records were changed manually without a trailing dot but the config has them and route53 tries to revert the changes every time. It looks like I have the opposite issue?

[ross]

Moved to octodns-route53 since it's likely something going on specific to it.

octoDNS always uses trailing dots in config as that's the technically correct/cononical way to specify a FQDN. Without it searching for something like does.not.exist.com would result in queirying for that value, as well as things like does.not.exist.com.yourdomain.com. based on whatever is in your resolve.conf (or similar) search config, see https://superuser.com/questions/570082/in-etc-resolv-conf-what-exactly-does-the-search-configuration-option-do.

Some DNS providers work with trailing .s and some don't, others still will silently add or remove it. It's up to each provider to deal with the translation between octoDNS's standard and the specific provider's. This is an example of the main purpose of octoDNS, providing a consistent interface to wildly varying DNS providers.

Looking at octodns/octodns#1147 how does this work if e.g. route53 does not contain the trailing dots but the corresponding source config has them?

I'm not 100% clear on what the question is here, assuming the above didn't answer it. If the source of data has . and the target doesn't the provider for that target should deal with removing them before sending the data and remove them when pulling data out of the provider.

[jmreicha]

This one basically describes what’s going on https://github.com/octodns/octodns-route53/issues/84. That said, all of what I am trying to do are workarounds for fixing the root of the problem, so I think I just need to bite the bullet here. Unfortunately at this point in time route53 it requires records to be deleted and recreated.

[ross]

Not sure I follow. If there are targeted records in Route53 w/o trailing ., e.g. a CNAME -> foo.bar.com and locally in a config file foo.bar.com. I would expect the provider to do an update (UPSERT):

********************************************************************************
* exxampled.com.
********************************************************************************
* route53 (Route53Provider)
*   Update
*     <CnameRecord CNAME 300, foo.exxampled.com., exxampled.com> ->
*     <CnameRecord CNAME 3600, foo.exxampled.com., exxampled.com.> (config)
*   Summary: Creates=0, Updates=1, Deletes=0, Existing Records=2
********************************************************************************

I manually created the record in the console w/o a . and then configured it locally with one.

That should update the records in place and bring them into best practices. Not sure how that would result in a delete and create so if that's what you're seeing something else is up and we'll need an actually issue with details on the situation and steps to reproduce if it's going to be debugged.

[jmreicha]

Yep I agree, that's the behavior I was expecting to see as well but it never actually upserts. I will check a few more things on my side to make sure I'm not missing something silly and get some more details together early next week if you'd like to debug.

I appreciate the help.