Importance of Proper DNS Setup
For your Commerce website to work properly, NetSuite needs to establish and retain control over your domain's DNS.
This is especially important for domains secured with automatic certificates. Setting the DNS verification (ACME challenge) CNAME to point to a NetSuite domain lets NetSuite prove domain ownership to the Certification Authority (CA) for you. It also lets NetSuite obtain new domain certificates or renew the existing one.
NetSuite servers and databases store your data and serve the web content on your domain. Using a CNAME that points to a NetSuite hosting DNS record lets NetSuite host your domain and deliver web content to your customers.
NetSuite uses its own state-of-the-art content delivery network (CDN) and, with the right DNS setup, you can fully benefit from all of its features, including, but not limited to:
-
Enhanced caching to improve your web store’s performance..
-
Security features to protect your web store, customers, and users from threats like DDoS attacks, aggressive bots, and fraud.
-
On-demand cache clearing.
-
SuiteCommerce-specific protections like rate limiting, bot management, web application firewall, IP reputation management, and geo-blocking based on Oracle policy.
A team of network and security engineers monitors and updates these measures 24/7.
If your DNS isn’t set up right, or you use a third-party CDN, you could run into issues like:
-
Reliability – NetSuite can’t guarantee reliable service if your DNS isn’t set up correctly. Problems caused by a improper DNS setup are hard to investigate because NetSuite has limited visibility and control.
-
Disaster recovery – If there’s a disaster, NetSuite will move customer accounts and domains to safe regions. If your DNS isn’t set up right, or a third-party CDN is used, your domain might not be moved because the change happens at the DNS level. Third-party CDNs and reverse proxies often use hardcoded hostnames or IPs and don't respect DNS changes.
-
Cache control – NetSuite uses caching to improve performance. If you use a third-party CDN, NetSuite can’t control what gets cached or for how long. SuiteCommerce, SuiteCommerce Advanced, and SuiteCommerce MyAccount have built-in automated cache clearing, but this won’t work properly with a third-party CDN because there’s another caching layer involved NetSuite that can’t control. This can slow down your site and cause problems with stale content.
-
Automatic SSL certificates – If your DNS isn’t set up right, NetSuite might not be able to issue SSL certificates automatically. If NetSuite can’t verify domain ownership, it won’t be able to issue or renew your certificate. Without a valid certificate, your domain won’t be secure and might not be able to process transactions.
Note:You should use automatic SSL certificates to keep your domain secure. See Automatic and Manual Certificates.
-
Security – When a proxy or CDN handles SSL traffic, NetSuite can’t control the SSL version or cipher profile, and third-party CDNs might not meet NetSuite’s security standards.
-
Traffic – If your DNS isn’t set up right, or you use a third-party CDN, your website traffic could be blocked or the wrong traffic could get through.
-
If you use a third-party CDN, your NetSuite account might not be able to forward traffic to another data center when load balancing is needed.
-
Third-party CDNs might not use the same filtering methods to block malicious traffic.
-
Using DNS Query Tools
To check that your DNS is set up properly, you can use online dig or server lookup tools to query DNS servers. If you're using Windows, it comes with a nslookup tool that can also be used to query DNS servers.
The following example shows the response from a dig command run on www.correct-netsuite-dns.com for web hosting. You can see the CNAME being translated and the hits to Akamai, so we know the CNAME for web hosting is set up correctly.
$ dig www.correct-netsuite-dns.com
; <<>> DiG 9.10.6 <<>> www.correct-netsuite-dns.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42979
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;www.correct-netsuite-dns.com. IN A
;; ANSWER SECTION:
www.correct-netsuite-dns.com. 3600 IN CNAME www.correct-netsuite-dns.com.hosting.netsuite.com.
www.correct-netsuite-dns.com.hosting.netsuite.com. 300 IN CNAME www.correct-netsuite-dns.com.e99999.c12345567.hosting.netsuite.com.edgekey.net.
www.correct-netsuite-dns.com.e99999.c12345567.hosting.netsuite.com.edgekey.net. 10800 IN CNAME e123456.x.akamaiedge.net.
e123456.x.akamaiedge.net. 20 IN A 2.16.153.216
e123456.x.akamaiedge.net. 20 IN A 2.16.153.214
;; Query time: 70 msec
The following example shows the response from a dig command run on www.correct-netsuite-dns.com for DNS verification. You can see the CNAME being translated and the hits to the ACME challenge, so we know the CNAME for DNS verification is set up correctly.
$ dig _acme-challenge.www.correct-netsuite-dns.com
; <<>> DiG 9.10.6 <<>> _acme-challenge.www.correct-netsuite-dns.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 39090
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;_acme-challenge.www.correct-netsuite-dns.com. IN A
;; ANSWER SECTION:
_acme-challenge.www.correct-netsuite-dns.com. 3600 IN CNAME www.correct-netsuite-dns.com.hosting-verify.netsuite.com.
;; AUTHORITY SECTION:
hosting-verify.netsuite.com. 300 IN SOA a1-124.akam.net. dnsadmin.nsgbu.internal. 76 3600 1800 604800 1800
;; Query time: 72 msec
;; SERVER: 2606:b400:300:d:feed::1#53(2606:b400:300:d:feed::1)
;; WHEN: Mon Sep 30 10:44:16 CEST 2024
;; MSG SIZE rcvd: 226