https://serverless-stack.com/ logo
#sst
Title
# sst
a

Adrián Mouly

10/08/2021, 5:04 PM
Looks like SST/CDK is creating a bunch of CName records on Route 53 for stage-subdomains, like, for each PR or developers’ stage. Is there a way to clean this from CDK/SST?
t

thdxr

10/08/2021, 5:04 PM
Those are created to verify the domain ownership for generating an SSL cert. I'm surprised it doesn't get deleted when the stack is deleted 😦
a

Adrián Mouly

10/08/2021, 5:05 PM
Yeah.
Are yours cleaned?
t

thdxr

10/08/2021, 5:06 PM
I'm not using custom domains anywhere but staging or prod but let me test this out
a

Adrián Mouly

10/08/2021, 5:07 PM
Ok cool, thank you for checking.
These cnames should be created and used only once right? once is verified, is never used again?
Once the custom domain is created I mean, no need to verify anything.
b

Blake E

10/08/2021, 5:50 PM
yeah, r53 verification records don’t really get cleaned up in my experience, my primary zone is just flooded with them. More recently I started created sub-domain zones, so at least it’s segregated and easier to audit by hand.
so like
<http://mycompany.com|mycompany.com>
<http://us-east-1.mycompany.com|us-east-1.mycompany.com>
or
<http://team-name.mycompany.com|team-name.mycompany.com>
a

Adrián Mouly

10/08/2021, 5:51 PM
Interesting.
b

Blake E

10/08/2021, 5:51 PM
(create a new zone with desired sub-domain, and then copy the NS record from sub-domain zone - and create a NS record in primary domain zone pointing to those name servers)
a

Adrián Mouly

10/08/2021, 5:52 PM
I have one zone for each “environment”, which is also a different account, so not much worry… but still I hate having all that crap.
b

Blake E

10/08/2021, 5:52 PM
yeah exactly, I don’t have a way to easily get rid of crap, but at least isolating makes me feel better lol
a

Adrián Mouly

10/08/2021, 5:52 PM
Yeah, is weird thought.
If this is intentional or just a bug.
b

Blake E

10/08/2021, 5:53 PM
I think that a) verification records can be re-used (so after deleting cert, and if it comes back, verification re-uses)
b) no idea if you can delete after it’s verified (I imagine yes, but haven’t tested)
a

Adrián Mouly

10/08/2021, 5:53 PM
Hum yeah, wish we can configure a policy somewhere.
b

Blake E

10/08/2021, 5:54 PM
given AWS CLI/SDK capabilities - I imagine you could programmatically clear out these records, they are pretty easily identified (which was my thought if I really wanted to clear them out)
a

Adrián Mouly

10/08/2021, 5:55 PM
Yeah, but I’m using high level constructs from SST, so not that easy, haha.
Well maybe I can do a cleanup function or something.
b

Blake E

10/08/2021, 5:59 PM
the newly offered Script construct would be good for this sort of thing
aws-sdk
inside, reads your zone, parses records, filters for verifications, and clears out what you want.
a

Adrián Mouly

10/08/2021, 5:59 PM
Interesting.
b

Blake E

10/08/2021, 6:00 PM
the Script construct might be the most underrated part of SST - it’s a very common issue/limitation of Cloudformation (as compared to Terraform). Cloudformation doesn’t easily let you interrogate deployed resources (let alone interact with them, like creating MySQL users/tables)
t

thdxr

10/08/2021, 6:02 PM
^ I'm realizing this too
can rig up all non-aws services with it
a

Adrián Mouly

10/08/2021, 6:02 PM
I didn’t realize this yet, but going to check it 😂 .
@Frank do you have any comment on this?
f

Frank

10/13/2021, 10:42 PM
Hmm yeah… might be doable i think. If we can get the DNS validation record name, set that as
Params
to the
Script
construct, and clean it up
onRemove
. 😁
a

Adrián Mouly

10/13/2021, 10:43 PM
Yeah maybe that’s the way.
f

Frank

10/13/2021, 10:43 PM
a

Adrián Mouly

10/13/2021, 10:43 PM
I mean, I was expecting to be removed automatically.
😮
😮 😮 😮
2019 🤦‍♂️