knowledgebase
DNS and Nameserver
Recommended DNS TTL values 0
When specifying TTL (Time To Live) values in DNS records, please be aware of the following important factors:
The higher the TTL, the less frequently caching name servers need to query authoritative name servers.
A higher TTL reduces the perceived latency of a site and decreases the dependency on the authoritative name servers.
Beside this, a higher TTL makes harder a TTL Poisoning attack, so higher TTL is more secure too.
The lower the TTL, the more frequently updates are propagated to other name servers.
A slower TTL can make significantly slower your site.
As standard, we recommend a TTL of 86,400 (24 hours), and not lower than 3,600 (1 hour).
As deault we are using 3,600.
If you are planning to make DNS changes, we recommend lowering the TTL at least 36 hours before making the changes.
So you should lower the TTL to 300 (5 minutes) at least 36 hours in advance of making the changes.
After the changes are made, increase the TTL back to 24 hours.
Minimum admitted TTL value is 300 (5 minutes).
Why can't I create a CNAME record for the root record?
A CNAME record can’t be defined as root record of a domain name: root record need to be an A record.
It’s so because of RFC1034 section 3.6.2:
If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.
Since the root must zone necessarily must have also a set of NS records, it follows that the root record can not be a CNAME.
The issue is insidious because subsequent errors can be discontinuous and erratic over time.
Just create required record as CNAME, live “www” and use our redirect option for root record.
DNS History Tools
An accurate and complete and comprehensive service to recover DNS history data for some domains not exist: there’s no global repository of this data anywhere in the Internet, and almost always neither providers o registries record this historical data.
There’re however a number of tools available that may be useful for this task; every single service relies on its own archives, so it’s no granted you’ll recover the data you’re querying for or they are accurate. here it is some:
DNS and Name Server propagation and setting check tools
After any change to Nameserver or DNS zone settings, it may usefull made a check, there are online several tool, here it is some:
DNS Health by Pingdom
A comprehensive test for global DNS configuration. Can be used for undelegated DNS servers
Zonemaster
Another comprehensive test, complete and fully configurable.
Into DNS
Very easy for a quick check.
DNS Propagation
An inutitive webtool for check DNS and IP propagation.
What’s my DNS
Another easy global DNS propagation checker.
Dig Web Interface
Extensive and very professional web interface to dig for doing online dns / nameserver query.
Remember, every single time you make a change to the DNS servers of your domain, or you modify any DNS record, you have to wait for the propagation of this data to be effective.
Propagation is the time it takes for each of the internet backbones to be updated with your new DNS information.
It’s not linear: these data travel from one DNS server to another, and is influenced by the policy of every single server. So it may happen that a user see new DNS data in few minutes, while another user (with different connectivity and DNS server) take many hours or up to 5 days.
How to set up an SPF record
SPF (Sender Policy Framework) is a kind of DNS record, very important and mandatory in order to fight spam and increase the deliverability of your email messages.
It’s a TXT record, which specify a list of authorized SMTP servers which are allowed to send messages from your domain.
SMTP servers can be specified with their hostnames or by ipv4 and ipv6 numbers.
This is an example of our default SPF record:
“v=spf1 a mx ip4:89.38.98.235 ip6:2a00:7c80:0:1e0:0:0:0:235 ~all”
There are also free tools and resources to help you, here it is some:
SPF check: https://mxtoolbox.com/spf.aspx
SPF Record Syntax: http://www.openspf.org/SPF_Record_Syntax
SPF Wizard: http://www.spfwizard.net/
Common mistakes when creating a SPF record: http://www.openspf.org/FAQ/Common_mistakes
SPF Record testing Tools: http://www.kitterman.com/spf/validate.html
s
Komorebihost's Cloudflare DNS servers how to use
If a domain is specified to use Komorebihost’s Cloudflare DNS nameservers service at the time of registration or transfer, activation and basic configuration are completely automatic. The DNS zone will be created, and a basic record set will be configured, potentially based on user-defined customizations.
Our default nameservers are:
jill.ns.cloudflare.com
eric.ns.cloudflare.com
Sometimes, if the above nameservers are not working, use:
aida.ns.cloudflare.com
owen.ns.cloudflare.com
If a domain was registered or transferred to us without initially requesting the use of our DNS servers, and the user wants to activate our DNS service later, they will need to create the corresponding “DNS zone” beforehand. To do this:
1. Inside the standard Control Panel area, select the menu option Domains → Manage DNS.
2. Locate the DNS service row for the domain you want to activate with our DNS servers and click on Add New Zone.
*(Note: DNS services are listed alphabetically, so you may need to scroll through the list to find the relevant domain.)*
The system will prompt you for the following details:
Zone Name: Enter the domain name without “www”.
IP Address: Leave this field blank.
Select Record Set: If you have multiple Record Sets, choose which one to apply; otherwise, the default will be applied.
To conclude, click on Add Zone.
At this point, the basic zone will have been created. You can access it and modify it as necessary after logging into the DirectAdmin control panel:
1. Select Account Manager → DNS Management.
After creating the DNS zone, you can go to the domain management page and set up our default nameservers. This can be done immediately after creating the zone or at a later time, depending on your needs. Keep in mind that modifying authoritative nameservers is never an operation with immediate effect. Depending on the domain extension, propagation times vary due to technical registry processes and internet propagation delays (from a few minutes up to 24 hours). Examples include:
Registry nic.it (.it domains): Updates parent nameservers every 2 hours; adopting new nameservers may take up to two hours from the request, followed by propagation times. If nameserver checks fail, nic.it will retry for 7 days before declaring failure.
Registry register.si (.si domains): Updates parent nameservers once a day.
Registry Verisign (.com, .net, .org, .us domains): Updates parent nameservers every 5 minutes and does not perform checks.
Point to Shopify Service
At Komorebi Host configuring use Shopify services is easy, safe and quick.
Please login into DirectAdmin control panel.
Select Account Manager >> DNS Management
Remove A and AAA records:
mydomain.com
www.mydomain.com.
Add these A records:
mydomain.com A 23.227.38.32
www CNAME shops.myshopify.com.
Depending on the domain extension propagation require from a few minutes up to 24 hours.
Note: “mydomain.com” should be replaced with the name desired of your domain.
Recommended DNS TTL values
When specifying TTL (Time To Live) values in DNS records, please be aware of the following important factors:
The higher the TTL, the less frequently caching name servers need to query authoritative name servers.
A higher TTL reduces the perceived latency of a site and decreases the dependency on the authoritative name servers.
Beside this, a higher TTL makes harder a TTL Poisoning attack, so higher TTL is more secure too.
The lower the TTL, the more frequently updates are propagated to other name servers.
A slower TTL can make significantly slower your site.
As standard, we recommend a TTL of 86,400 (24 hours), and not lower than 3,600 (1 hour).
As deault we are using 3,600.
If you are planning to make DNS changes, we recommend lowering the TTL at least 36 hours before making the changes.
So you should lower the TTL to 300 (5 minutes) at least 36 hours in advance of making the changes.
After the changes are made, increase the TTL back to 24 hours.
Minimum admitted TTL value is 300 (5 minutes).
What kind of DNS records can be managed?
To ensure a high-profile service for the nameservers, we rely on a top-tier external partner, Cloudflare.
Our default namservers are:
jill.ns.cloudflare.com
eric.ns.cloudflare.com
After login into DirectAdmin control panel
Select Account Manager >> DNS Management
You can manage following kinds od DNS records:
A
AAAA
CNAME
MX
TXT/SRV
RP records are not manageable.
SOA and NS records are authomatically managed by the system as necessary.
WordPress
Brute force attack trought XML-RPC
XML-RPC in WordPress is commonly exploited for brute-force attacks.
Although the code has been improved over time and the likelihood of a successful brute-force attack via XML-RPC has been significantly reduced, XML-RPC remains a prime target. If a bot targets your blog, it can send tens of thousands of XML-RPC requests in an attempt to compromise your site.
Even if these attacks are unsuccessful, the volume of requests can consume server resources (RAM, CPU), negatively impacting your site’s performance[5][7].
Given this, the best solution is to completely disable the XML-RPC service in WordPress. In fact, on all our hosting packages, direct access to the XML-RPC service is disabled by default.
Secure WordPress from common attacks
At KomorebiHost, we apply these security rewrite rules by default in our custom OpenLiteSpeed templates to protect WordPress sites at the server level:
RewriteRule ^/wp-content/debug.log$ - [R=403,L,NC]
RewriteRule ^/.*\.env$ - [R=403,L,NC]
RewriteCond %{REMOTE_ADDR} !^(127.0.0.1|::1)$
RewriteCond %{QUERY_STRING} rest_route=/wp/v2/users [NC,OR]
RewriteCond %{REQUEST_URI} /wp-json/wp/v2/users [NC]
RewriteRule ^ - [R=403,L]
These rules block access to sensitive debug logs and .env files (preventing credential leaks), while stopping user enumeration via WP REST API (except localhost)—reducing attack surfaces automatically across all sites without manual .htaccess edits.
How to set SMTP sending in WordPress
WordPress by default uses PHP mail (php_mail) to send emails, but this method has significant limitations, especially regarding email deliverability.
Emails sent via PHP mail are often marked as spam or may not be delivered at all because they lack proper authentication and security checks required by modern email systems.
This is why PHP mail is not recommended for production environments where reliable email delivery is crucial.
SMTP (Simple Mail Transfer Protocol) authenticates emails with a username and password, improving deliverability, security, and ensuring emails are less likely to be flagged as spam
SMTP supports security protocols like SPF, DKIM, and DMARC, which help verify the legitimacy of emails and further boost deliverability.
Most reputable SMTP services provide detailed feedback on email delivery status, making it easier to troubleshoot issues.
To switch from PHP mail to SMTP, you need to configure your WordPress site to use an SMTP server. This can be done using plugins such as WP Mail SMTP, or SMTP2GO for WordPress which allows you to connect your site to any SMTP service.
SMTP services can be included with your hosting provider or purchased separately.
Several SMTP options are available in our email packages or included with hosting packages, all tested and fully compatible with WordPress.
Alternatively, you can use external SMTP providers like Brevo, SendGrid, SMTP2GO, or others. Many of these services offer free plans suitable for small to medium websites.
If you are using any hosting packages with Komorebihost, we can assist you in configuring any of the supported SMTP services to ensure your WordPress emails are delivered reliably.