Hi, @MoTeske. @coelmay is very good at this DNS troubleshooting. The only reason I’ve found something he has not is because I am part of Netlify and have access to internal information that he does not.
This is what I see when I lookup the DNS information for this domain:
Name server records (type = NS):
mo-teaching.nl. 21600 IN NS anastasia.ns.cloudflare.com.
mo-teaching.nl. 21600 IN NS john.ns.cloudflare.com.
Records for the apex domain (type = A):
mo-teaching.nl. 300 IN A 54.241.246.27
mo-teaching.nl. 300 IN A 138.68.234.180
Records for www subdomain:
www.mo-teaching.nl. 300 IN A 184.72.37.151
www.mo-teaching.nl. 300 IN A 138.68.7.48
What @colemay cannot have examined (not without breaking into our systems first) but which I can is this:
- the list of IP address which Netlify uses for our Standard Edge Network
That list is always changing which is why it isn’t published publicly. However, if you ask our support team we can always verify if an IP address is one we control or not. What I have learned is this.
These two IP addresses are Netlify controlled and the site works for them:
- 54.241.246.27
- 184.72.37.151
Here is an example below (where the -resolve www.mo-teaching.nl:443:184.72.37.151 option controls what IP address curl will make the HTTP request to):
$ curl -k --compressed -svo /dev/null --resolve www.mo-teaching.nl:443:184.72.37.151 https://www.mo-teaching.nl/ 2>&1 | egrep '^(<|>)'
> GET / HTTP/2
> Host: www.mo-teaching.nl
> user-agent: curl/7.79.1
> accept: */*
> accept-encoding: deflate, gzip
>
< HTTP/2 200
< age: 109156
< cache-control: public, max-age=0, must-revalidate
< content-encoding: gzip
< content-type: text/html; charset=UTF-8
< date: Sun, 21 Aug 2022 21:51:46 GMT
< etag: "043a7847b5ad8f19a67bc070e8d5c1d5-ssl-df"
< server: Netlify
< strict-transport-security: max-age=31536000
< vary: Accept-Encoding
< x-nf-request-id: 01GB4EB2BQWT97AR0MQHAF9GAG
< content-length: 2961
<
Note, I’ve used the -k option above to ignore SSL errors. The SSL isn’t working because of the DNS configuration is unsupported. Once the DNS is configured to match these instructions, the SSL can be provisioned.
The other two IP addresses are not ones that Netlify controls:
- 138.68.234.180
- 138.68.7.48
When I make the HTTP request to one of those IP address, it is then that the 403 occurs:
$ curl -k --compressed -svo /dev/null --resolve www.mo-teaching.nl:443:138.68.7.48 https://www.mo-teaching.nl/ 2>&1 | egrep '^(<|>)'
> GET / HTTP/2
> Host: www.mo-teaching.nl
> user-agent: curl/7.79.1
> accept: */*
> accept-encoding: deflate, gzip
>
< HTTP/2 403
< audit-id: 64d1ccfa-5072-4b74-ad72-a65e937057ea
< cache-control: no-cache, private
< content-type: application/json
< x-content-type-options: nosniff
< x-kubernetes-pf-flowschema-uid: a9177ce7-9873-4003-839a-feb9d2bb4cfc
< x-kubernetes-pf-prioritylevel-uid: 25e07a67-f68d-4c3d-a864-529b0299929d
< content-length: 233
< date: Tue, 23 Aug 2022 04:06:12 GMT
<
To summarize, 403s are not coming from Netlify. For some reason the DNS for this site points sometimes to IP address that Netlify does control and sometimes to IP addresses we do not. I cannot see the DNS configuration at Cloudflare so I don’t know what the reason is for this. However, if you modify the DNS configuration to match the instructions above to it directs only to Netlify, the 403s will stop happening.
