Log in >>

knowledgebase

DNS and Nameserver

In combination with our professional Hosting and Email packages, you can use Cloudflare’s nameservers at no additional cost.

Cloudflare nameservers will be set up automatically by default if your domain was purchased or transferred through Komorebi Host.

With the CMS Hosting plan, you can also activate Cloudflare’s CDN by opening a support ticket request.

If you’re using a domain managed by another provider, you must configure the following nameservers:
jill.ns.cloudflare.com
eric.ns.cloudflare.com

Sometimes, if the above nameservers aren’t working, use:
aida.ns.cloudflare.com
owen.ns.cloudflare.com

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.

If you prefer using Komorebi Host nameservers, please open a support ticket request.

If you prefer to use any other nameserver service, please copy the DNS settings from the zone manager.

You can use this service in combination with all services provided by Komorebi Host, as well as with your domains registered with other providers and any other external services.

If you’re using a domain managed by another provider, you must configure the following nameservers:
ns1.komorebihost.eu
ns2.komorebihost.eu

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.

If you have any Hosting or Email service active, login to the Customer Area >> Services:

select “Hosting” under Product/Service >> Manage  >> Login to control panel, inside DirectAdmin control panel >> Account Manager >> DNS Management.

If you choose Komorebi Host nameservers or are using Free DNS select “DNS Hosting for” >> Manage >> DNS Record Management.

On both, you can manage the following types of DNS records:

A
AAAA
CNAME
MX + Priority
TXT/SRV
TTL

SOA and NS records are automatically managed by the system as needed.

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

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 86400 (24 hours), and not lower than 3600 (1 hour).

As deault we are using 3600.

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).

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.

Configuring your domain to use Shopify services is easy, safe, and quick.

If you have any Hosting or Email service active, login to the Customer Area >> Services:

select “Hosting” under Product/Service >> Manage >> Login to control panel, inside DirectAdmin control panel >> Account Manager >> DNS Management.

If you choose Komorebi Host nameservers or are using Free DNS select “DNS Hosting for” >> Manage >> DNS Record Management.

Remove these records:

A and AAAA records for mydomain.com

A and AAAA records for www.mydomain.com

Add these records:

mydomain.com A 23.227.38.32

www CNAME shops.myshopify.com

Depending on the domain extension, propagation requires from a few minutes up to 24 hours.

Note: “mydomain.com” become your actual domain name.

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:

Complete DNS

DNS History

SecurityTrails

Spyse

WhoISrequest

Whoxy

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.

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.

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.

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.

How to transfer your website and emails

Moving a website often involves migrating domain-related emails as well. Before proceeding with this operation you need to check some parameters.

First, before the transfer, you need to check if the mail is stored on the server, then configured in IMAP, or downloaded to your mail client, then configured in POP3. If the emails are configured in IMAP and then stored on the server, it will be necessary to configure them in POP3 and download them on your PC. If they are configured in POP3 it will not be necessary to proceed with further operations.

It will be possible to create the same identical previous e-mail accounts thanks to the preventive access to the control panel: before the domain is transferred, it will be possible to create the same accounts and therefore not lose any e-mails during the transfer.

Transferring your WordPress or some other website and associated emails from your old hosting providers is straightforward but requires careful steps to avoid downtime.
Note: Some website transfers aren’t always possible (e.g., due to custom configurations, licensing issues, or incompatible setups).
Contact us before for a free, non-binding pre-check before starting.

Prepare on the Old Provider (Export Data)

WordPress Site: Use plugins like Duplicator, All-in-One WP Migration, or UpdraftPlus to create a full backup (files + database).
Alternatively, download files via FTP and export the database via phpMyAdmin (better choice).

Emails: Export mailboxes using IMAP tools (e.g., Thunderbird or imapsync) or provider-specific export features. Note domain MX records for email routing.
Alternatively, provide the usernames and passwords for your existing email accounts so we can sync the messages.

Once you’re ready, opening a support ticket request to coordinate the timing of the intervention and prevent any service interruptions.