https://serverless-stack.com/ logo
#help
Title
# help
l

Louis Barclay

12/12/2021, 11:56 PM
I've always found my prod and dev
sst
APIs to work exactly the same way, except with an issue I just found. I can't figure out what's going on. One of my API paths checks CNAMEs for some domains. Code is in screenshot. It uses a resolver from the DNS tools shipped in Node.js by default (imported like this:
const { Resolver } = require("dns").promises; const resolver = new Resolver();
) The inconsistency is that everything works in the dev API (after running npx sst start), whereas in the prod API the first CNAME is successfully found (lines 59-69), but the second CNAME is not (lines 73-82). The error message that comes up in the prod API is as follows:
Copy code
2021-12-12T23:39:44.230Z 7826077a-0951-477b-84e6-c4b9358ce4df INFO No certificate_cname Error: queryCname EBADRESP <http://_17f3ff9be4f5c70a4e0.SOME-DOMAIN.com|_17f3ff9be4f5c70a4e0.SOME-DOMAIN.com> at QueryReqWrap.onresolve [as oncomplete] (internal/dns/promises.js:167:17) { errno: 'EBADRESP', code: 'EBADRESP', syscall: 'queryCname', hostname: '<http://_17f3ff9be4f5c70a4e0.SOME-DOMAIN.com|_17f3ff9be4f5c70a4e0.SOME-DOMAIN.com>' }
Any tips on how to fix this would be appreciated! AFAIK I have not done any particular config to make my prod and dev APIs work differently.
d

Dan Greaves

12/13/2021, 12:05 AM
Not sure on the specifics, but the “difference” you’re seeing will be because when running
sst start
, the actual logic in your function is firing from your local machine and local node environment. The remote lambda is just used for passing messages back and forth. Likely what’s happening here is that when the request is sent from your local machine, the SSL certificate is trusted as the cert is in your machines trust store. However, when running the exact same request from production (which will actually be from lambda), the cert isn’t trusted because the root cert isn’t in the store used by lambda. It could be a slightly different reason as not familiar with the resolver you’re using but would explain the differences.
You often find this when connecting to services which use LetsEncrypt certificates. Operating systems like Windows and Mac will have them trusted (the root certificate is added to their trust store), but older software usually running remote servers won’t have it added. Same is true for self-signed certificates which have been manually trusted on your machine, but won’t have been trusted on the remote.
I could be completely wrong that it’s a certificate verification problem, but the difference will definitely be your local machine vs remote lambda, so hopefully that sets you on the right track!
l

Louis Barclay

12/13/2021, 10:21 AM
Thank you!
OK great - will look into it bearing this in mind