You need to add a TXT record to _railway-verify.tijuana.gob.mx. Also, you should be using CNAME records instead of A records.

Hello,

Thank you for the quick reply, but I believe there is a misunderstanding. I am NOT trying to configure the root domain tijuana.gob.mx. I am configuring specific subdomains (e.g., remutys.tijuana.gob.mx).

Also, I want to clarify that we are already using CNAME records, not A records, and the TXT records are correctly placed at the subdomain level.

Here is the current nslookup resolution for one of the subdomains (remutys), proving that the routing and verification setup on our end is correct:

Evidencia Técnica: Confirmación de Registros DNS

Servidor consultado: Google (8.8.8.8)

Herramienta: nslookup

Fecha de consulta: 10 de Julio de 2026

A continuación se presenta la salida íntegra de la consola que confirma cómo están configurados actualmente los registros en el sistema:

1. Mejora Regulatoria

> nslookup -type=cname mejoraregulatoria.tijuana.gob.mx 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
mejoraregulatoria.tijuana.gob.mx	canonical name = 541qu72j.up.railway.app.

> nslookup -type=txt _railway-verify.mejoraregulatoria.tijuana.gob.mx 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_railway-verify.mejoraregulatoria.tijuana.gob.mx	text = "railway-verify=fe797ec42f4ed7198c3351a7c536dd749c6b9a6af698738c9e8f1f0fead667e3"

✅ Resultado: CNAME correcto y TXT cuenta con el prefijo railway-verify=.

2. Mejora Regulatoria API

> nslookup -type=cname mejoraregulatoria-api.tijuana.gob.mx 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
mejoraregulatoria-api.tijuana.gob.mx	canonical name = 0g6cm2x6.up.railway.app.

> nslookup -type=txt _railway-verify.mejoraregulatoria-api.tijuana.gob.mx 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_railway-verify.mejoraregulatoria-api.tijuana.gob.mx	text = "railway-verify=7fc160e9215bacaa343fd46043e214cecbce6c4db35120e1c5a69d2f870866c8"

✅ Resultado: CNAME correcto y TXT cuenta con el prefijo railway-verify=.

3. Remutys

> nslookup -type=cname remutys.tijuana.gob.mx 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
remutys.tijuana.gob.mx	canonical name = 9n7edp4o.up.railway.app.

> nslookup -type=txt _railway-verify.remutys.tijuana.gob.mx 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_railway-verify.remutys.tijuana.gob.mx	text = "railway-verify=670367b55fa3d33d2fee944ef1543b1d542cc62972096a6d2800641a153b3649"

✅ Resultado: CNAME modificado y TXT cuenta con el prefijo railway-verify=.

4. Remutys API (tys-api)

> nslookup -type=cname tys-api.tijuana.gob.mx 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
tys-api.tijuana.gob.mx	canonical name = 27b0jcp5.up.railway.app.

> nslookup -type=txt _railway-verify.tys-api.tijuana.gob.mx 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_railway-verify.tys-api.tijuana.gob.mx	text = "railway-verify=c542e899c137c39033fca73a3f32c92adca46f9684135968ebab1457c1a1cebe"

✅ Resultado: CNAME corregido exitosamente y TXT cuenta con el prefijo railway-verify=.

5. Remutys ADMIN

> nslookup -type=cname remutys-admin.tijuana.gob.mx 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
remutys-admin.tijuana.gob.mx	canonical name = 99tru0ov.up.railway.app.

> nslookup -type=txt _railway-verify.remutys-admin.tijuana.gob.mx 8.8.8.8
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
_railway-verify.remutys-admin.tijuana.gob.mx	text = "railway-verify=951a3da277fdc46edf86900fae36eeeb32143ed54799f6e8413108a3625698af"

✅ Resultado: El CNAME fue corregido y el TXT ya tiene el prefijo railway-verify=.

I'd double-check your DNS configurations. I wasn't able to find any CNAME or TXT records on those 5 domains. Tried using both Cloudflare and Google's DNS servers to run nslookup.

Thank you for verifying. I just double-checked and you are absolutely right. The records were resolving successfully a few days ago, but it appears our IT department has since reverted the changes or broken the DNS zone, as the subdomains are now returning NXDOMAIN. I will escalate this internally with our government IT team to restore the CNAME and TXT records. I will update this thread once they are back online.

Hello again,

Quick update to my last message: Before escalating this to our IT department, I decided to run a few more deep DNS tests, and I discovered a very strange global propagation inconsistency. The records were not deleted, but there is a "split" in how they are resolving.

You were entirely correct that they return NXDOMAIN on some major resolvers (specifically Google DNS at 8.8.8.8, which explains what both of us were seeing).

However, if queried through Cloudflare (1.1.1.1), the records return NOERROR and are perfectly configured:

dig CNAME remutys.tijuana.gob.mx @1.1.1.1 returns 9n7edp4o.up.railway.app.

dig TXT _railway-verify.remutys.tijuana.gob.mx @1.1.1.1 returns the correct hash.

Since the records do exist and are actively propagating to Cloudflare's global network, could your engineering team verify if Railway's internal Let's Encrypt resolver is perhaps stuck on a cached NXDOMAIN from earlier?

Also, if your system is able to resolve them, I still need to know if there is a CAA block preventing the SSL generation, so I can pass all technical requirements to my IT team at once.

I am pasting the terminal output below for your reference. Thank you for your patience!

~

❯ dig CNAME remutys.tijuana.gob.mx @8.8.8.8

dig CNAME remutys.tijuana.gob.mx @1.1.1.1

; <<>> DiG 9.10.6 <<>> CNAME remutys.tijuana.gob.mx @8.8.8.8

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 33076

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;remutys.tijuana.gob.mx. IN CNAME

;; AUTHORITY SECTION:

tijuana.gob.mx. 300 IN SOA ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

;; Query time: 96 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Tue Jul 14 07:56:38 CST 2026

;; MSG SIZE rcvd: 144

; <<>> DiG 9.10.6 <<>> CNAME remutys.tijuana.gob.mx @1.1.1.1

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46525

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;remutys.tijuana.gob.mx. IN CNAME

;; ANSWER SECTION:

remutys.tijuana.gob.mx. 3600 IN CNAME 9n7edp4o.up.railway.app.

;; Query time: 132 msec

;; SERVER: 1.1.1.1#53(1.1.1.1)

;; WHEN: Tue Jul 14 07:56:39 CST 2026

;; MSG SIZE rcvd: 88

~

❯ dig TXT _railway-verify.remutys.tijuana.gob.mx @8.8.8.8

dig TXT _railway-verify.remutys.tijuana.gob.mx @1.1.1.1

; <<>> DiG 9.10.6 <<>> TXT _railway-verify.remutys.tijuana.gob.mx @8.8.8.8

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 27791

;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 512

;; QUESTION SECTION:

;_railway-verify.remutys.tijuana.gob.mx. IN TXT

;; AUTHORITY SECTION:

tijuana.gob.mx. 300 IN SOA ns-cloud-e1.googledomains.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

;; Query time: 99 msec

;; SERVER: 8.8.8.8#53(8.8.8.8)

;; WHEN: Tue Jul 14 07:56:45 CST 2026

;; MSG SIZE rcvd: 160

; <<>> DiG 9.10.6 <<>> TXT _railway-verify.remutys.tijuana.gob.mx @1.1.1.1

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9719

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 1232

;; QUESTION SECTION:

;_railway-verify.remutys.tijuana.gob.mx. IN TXT

;; ANSWER SECTION:

_railway-verify.remutys.tijuana.gob.mx. 3600 IN TXT "railway-verify=670367b55fa3d33d2fee944ef1543b1d542cc62972096a6d2800641a153b3649"

;; Query time: 175 msec

;; SERVER: 1.1.1.1#53(1.1.1.1)

;; WHEN: Tue Jul 14 07:56:45 CST 2026

;; MSG SIZE rcvd: 159

➜ nslookup -type=CNAME remutys.tijuana.gob.mx 1.1.1.1

Server:         1.1.1.1

Address:        1.1.1.1#53

** server can't find remutys.tijuana.gob.mx: NXDOMAIN

Could just be DNS caching. DNS sometimes may take up to 48 hours to fully propagate.

Thanks for checking from your end. The records were originally configured last Thursday, so if they are showing NXDOMAIN globally now, it is definitely not a propagation delay. Our government IT department must have reverted the DNS zone over the weekend. I will escalate this internally to have the records restored. You can pause this ticket for now, and I will update you once the DNS is actually stable. Thank you!

Hi there! Thank you so much for looking into this.

I completely understand that DNS propagation can sometimes take up to 48 hours. However, we actually configured the DNS for all our subdomains last Thursday July 9, so the global

propagation should be fully completed by now.

The NXDOMAIN result from nslookup on remutys seems to have been a false negative caused by a residual Anycast cache on that specific node. As shown in the same screenshot,

the dig command successfully returned the correct CNAME when querying the exact same IP (1.1.1.1).

The reason I'm reaching out for help is that we are experiencing this exact same verification issue across several other domains, not just remutys.tijuana.gob.mx. We set up

the following domains at the exact same time, and they seem to be stuck as well:

• mejoraregulatoria.tijuana.gob.mx

• mejoraregulatoria-api.tijuana.gob.mx

• tys-api.tijuana.gob.mx

• remutys-admin.tijuana.gob.mx

You can double-check that their CNAME and _railway-verify TXT records are all correct and responding instantly by querying our authoritative nameserver directly: dig CNAME

[domain] @ns0.tjservices.lat

Since all of these records have been globally available for several days now, could you kindly help me investigate why the platform isn't picking them up? Is there any way we

could manually trigger the verification and SSL issuance for these domains from your side?

I'd really appreciate your guidance on this!

I'm still unable to find records attached to any of those domains.

$ nslookup -type=CNAME mejoraregulatoria.tijuana.gob.mx 1.1.1.1

Server:         1.1.1.1

Address:        1.1.1.1#53

** server can't find mejoraregulatoria.tijuana.gob.mx: NXDOMAIN

Thank you for the screenshot. It is clear that the DNS is failing in multiple regions.

We want to send the right information to our internal IT team so they can fix this. Could you help us verify a technical detail on your end?

We suspect there is a conflict with an old DNS provider. While our new nameserver (ns0.tjservices.lat) is returning the correct CNAMEs, it looks like some queries are still

hitting an old Google Domains server (ns-cloud-e1.googledomains.com) which is returning an NXDOMAIN.

Could the engineering team review this and confirm if this is the root cause? I just need a brief confirmation from your side explaining the technical issue (for example, if

this is a split-brain DNS problem caused by the Google servers) and the steps you recommend to fix it.

With that confirmation and your suggested solution, I can provide it to our IT department as proof so they know exactly what they need to do on their end.

Thank you again for your time.