o1.ingest.domain.tld is not created

[nodomain]

Hi,

awesome project. I had to try it immediately.

Unfortunately, the DNS entry for oi1.ingest.domain.tld is missing in Route53. How to fix it?

Thanks Fabian

[mariusmitrofan]

Hi.

2 things you can do for now as a workaround: 1) create that subdomain manually and point it to a sentry relay :) 2) just ignore that completely and modify the Client DSN to simply point directly to sentry relay

What I will do as a fix for this:

• ensure that domain gets created in route53

Further note: In case you missed this, the sentry relay LB is "internal", just fyi.

[nodomain]

But if the relay LB is internal how should it then receive traffic from the internet? Or am I mixing things up?

[mariusmitrofan]

For security reasons, it was set that why with the downside of being only able to capture data from "inside your network" (aka add a VPC peering from another VPC in which your app resides).

HOWEVER, I guess it would be nice to leave the choice for that to the user :).

I'll make a PR which will fix both:

• create that DNS record
• allow the possibility to select internal or internet-facing ALB relay system (with default to "internet-facing")

What do you think ?

[nodomain]

Awesome. This would fit exactly into our use case where we want to ingest react and vue errors from our users.

[mariusmitrofan]

Cool. Should be fixed by tomorrow. It's late here. Will update the thread when done.

Cheers!

[mariusmitrofan]

The PR fixed the following issues @nodomain:

• the ingest route53 record is properly created
• the ingest record is externally reachable (didn't find any reason why not to make it that way after all)

Please pay attention to the added README nodes though: ->

Important note about stack

The Client DSN record that is created by Sentry each and every time you create a new project looks something like this:

https://some_random_public_key_string_here@o1.ingest.${the_sentry_dns_record}/2

So if the parameter value of SentryDnsRecord is sentry.rungutan.com then the DSN would be:

https://some_random_public_key_string_here@o1.ingest.sentry.rungutan.com/2

Why is this important?

Because you need to make sure that your SSL certificate can handle that specific ingest domain as well

The workaround for this (if it's not possible to use the default ingest record) is to relay on the parameter value that you set up for SentryRelayAlternativeDnsRecord.

This means that if for example the value for SentryRelayAlternativeDnsRecord is sentry-relay.rungutan.com, then you would instead use this specific DSN:

https://some_random_public_key_string_here@sentry-relay.rungutan.com/2

[nodomain]

You are awesome.