Route53 problem: Tried to create resource record set [name='_acme-challenge.host.domain.com.', type='TXT'] but it already exists

[sizgiyaev]

trafficstars

The issue log: An error occurred (InvalidChangeBatch) when calling the ChangeResourceRecordSets operation: Tried to create resource record set [name='_acme-challenge.host.domain.com.', type='TXT'] but it already exists

Isn't there a way to overwrite the record?

[AnalogJ]

You can use the update action to modify an existing record.

[sizgiyaev]

I'm using lexicon with acme.sh. So, how it looks like with this command: acme.sh --issue -d web.domain.com -dns dns_lexicon? I give it the provider and the credentials through env vars, like:

PROVIDER=route53
LEXICON_ROUTE53_ACCESS_KEY=*************
LEXICON_ROUTE53_ACCESS_SECRET=*************

Also, if the record doesn't exist, will it create if i use update action?

[alexzorin]

@AnalogJ this appears to be an example of #182

All usage of Lexicon the wild, including the example hooks for dehydrated and Certbot in this project, rely on the ability to lexicon {provider} create a TXT record. The inability to create a TXT record because another TXT record with the same label exists appears to be a misalignment between Route53's and Lexicon's interfaces.

I think the Lexicon Route53 provider should be using UPSERT or DELETE, I can't think of a scenario where CREATE makes sense.

[AnalogJ]

Yeah, adding support for record sets to Route53 (and a couple other providers) is still necessary.

From what I've seen regarding LetEncrypt clients (like dehydrated, Certbot, Acme.sh) they are usually pretty good about cleaning up after themselves on success (by calling lexicon delete).

Once we get the remaining lexicon providers updated to support record sets, this will be almost a non-issue, as failed ACME challenge dns records will not stop lexicon from creating new ACME challenge records.

However we'll still have a couple of providers that do not support record sets. They will have to be handled differently.

In general I favor explicit changes over implicit changes. I'm also a fan of internal consistency between providers.

I'd rather have a low level tool like lexicon do exactly what I tell it (and fail quickly if it cannot do what I want) instead of automatically deleting & recreating records in some cases but not others.

Just my thoughts, but yeah, getting the remaining providers working with record sets a priority right now. I think I'll create a github project for it, to track them all.

Sorry for the wall of text :)

[alexzorin]

That's great that RRSet support is coming.

My only note,

From what I've seen regarding LetEncrypt clients (like dehydrated, Certbot, Acme.sh) they are usually pretty good about cleaning up after themselves on success (by calling lexicon delete).

This relies on the order of operations to be successful. If you create delete create delete, it works fine, but create create delete delete is presently impossible (i.e. how Certbot invokes manual auth hooks ... which means the Certbot example hook I added in this repo is busted).

I strongly believe that the meaning of "lexicon create" should be "create an RR", not "create an RRSet with this one RR, fail if it exists". At least, that's the likely intent of the user. Does this fit with your vision?

[AnalogJ]

Hey @alexzorin Seems I never got around to responding to your question. Yeah the create operation should be idempotent, creating a record set (or reusing it if it already exists) and then populating it with a new record.

Unfortunately the route53 provider recordset support is a hot mess. I don't personally use route53 and I'm not very familiar with its API so I was hoping for some help from the community. Would either you or @sizgiyaev be interested in opening a PR to fix the route53 provider? The basic requirements are listed here https://github.com/AnalogJ/lexicon/issues/262 and in the CONTRIBUTING.md document.

[danoh]

Hi everyone, please check this patch, it works for me in the same situation:

#https://github.com/AnalogJ/lexicon/pull/309