# How to troubleshoot origin domain errors

From anywhere on the command line, check that the origin domain of the tenant has the right A record. Use the dig command:

  • with the -t A option, to filter for A records only,
  • with the origin domain of the tenant, origin.example.com by default.
 












 






$ dig origin.example.com
; <<>> DiG 9.10.6 <<>> origin.example.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12324
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;origin.example.com.		IN	A

;; ANSWER SECTION:
origin.example.com.	300	IN	A	54.208.95.238

;; Query time: 105 msec
;; SERVER: 212.231.6.7#53(212.231.6.7)
;; WHEN: Mon May 04 16:44:42 CEST 2020
;; MSG SIZE  rcvd: 62

The answer section must contain only one A record, pointing to an IP address specific to the tenant: their origin server.

Even with one A record set, different issues can arise. The rest of this article mentions different possible friction points.

# Check the origin IP address

You can check the origin IP address is the right one by pasting it directly in the browser URL bar:

  • If it opens the tenant's desktop site, it is correct.
  • If it results in an error, the tenant's servers are not working and they must be informed.

TIP

Once you know that the IP is the right one, you can access the tenant's desktop site directly through origin.domain.com: they are equivalent.

# Check the origin server protocol

The origin server must follow the same protocol as the one detected by Marfeel: if the website is available via HTTPS, the origin server must also be available via HTTPS.

From anywhere in the console, check it by sending 4 different requests:

  • 2 requests to the origin domain:
curl -I https://origin.example.com
curl -I http://origin.example.com
  • 2 requests to the normal domain:
curl -I https://www.example.com
curl -I http://www.example.com

The protocol is inconsitent and a fix is required if the HTTPS request fails for the origin domain, but succeeds for the normal domain.

In that case:

  • The tenant must make the protocol consistent between both domains.
  • Once it is, Marfeel must adapt the tenant's CDN configuration considering the new protocol. The Wizard cannot recover from this change, and the remaining steps must be done without its help. Follow the next steps with the CDN Wizard guide rather than the MarfeelStudio panel.

TIP

This issue typically arises when the tenant had a CDN providing a SSL certificate before activating MarfeelCDN.

All the activation steps for MarfeelCDN have been done with another CDN active, and the protocol suddenly changes when the previous CDN is deactivated.

# "Origin Down": is Fastly authorised

If the origin domain works in your browser, but MarfeelCDN doesn't detect it, Fastly cannot communicate with the tenant's server.

Use curl and one of Fastly's IP addresses Marfeel uses to learn more:

$ curl -I https://151.101.130.207 -H "Host:www.example.com" -k

Origin or normal domain?

This curl request here points to the actual tenant's domain on purpose. This request goes through Fastly, and Fastly is configured to connect to the origin directly when receiving such requests.

# Check for another CDN

MarfeelCDN doesn't work if a different CDN is in place. You can make sure the origin domain doesn't point to a CDN by inspecting the whois data.

From anywhere in the console, type whois followed by the IP address of the origin domain:

$ whois 54.208.95.238 | grep "OrgName"
...
OrgName:        Amazon Technologies Inc.
OrgName:        Amazon.com, Inc.

If the OrgName is a CDN provider like Cloudflare, the tenant must modify their origin record to poin to their "real" origin server instead of their CDN.