Correct DNS configuration is important when hosting websites, email, applications, or other internet services on a VDS server.
DNS allows domain names to resolve to IP addresses, enables subdomains such as www, and helps email traffic reach the correct mail servers.
In this guide, we explain the main DNS record types used with VDS servers, including A, AAAA, CNAME, MX, TXT, NS, and PTR records.
DNS stands for Domain Name System.
Its primary purpose is to translate human-readable domain names into IP addresses used by servers.
For example:
example.com → 192.0.2.10
When someone enters example.com into a browser, DNS helps determine which IP address should receive the connection.
A VDS can host multiple services.
For example:
example.com → Websitewww.example.com → Websitepanel.example.com → Control panelapi.example.com → API servicemail.example.com → Mail server
DNS determines where each hostname should resolve.
Incorrect DNS configuration can cause websites to become unavailable, email delivery to fail, or SSL validation to encounter problems.
DNS records are managed by the provider responsible for your domain's authoritative nameservers.
This may be:
The company where you purchased the domain does not necessarily manage its DNS.
A DNS zone contains the DNS records associated with a domain.
A typical zone may include:
AAAAACNAMEMXTXTNS
records.
Hosting panels may call this section DNS Management, DNS Zone, Zone Editor, or DNS Records.
An A record maps a hostname to an IPv4 address.
For example:
| Type | Host | Value |
|---|---|---|
| A | @ | 192.0.2.10 |
This results in:
example.com → 192.0.2.10
You can also create records for subdomains:
| Type | Host | Value |
|---|---|---|
| A | panel | 192.0.2.10 |
This allows panel.example.com to resolve to the same VDS.
An AAAA record performs a similar function to an A record but is used for IPv6 addresses.
Only configure an AAAA record when IPv6 is correctly configured on your VDS.
An incorrect IPv6 record may cause connectivity problems for visitors whose systems prefer IPv6.
A CNAME record aliases one hostname to another hostname.
For example:
| Type | Host | Value |
|---|---|---|
| CNAME | www | example.com |
This allows:
www.example.com
to follow the DNS resolution of the root domain.
A CNAME target should normally be a hostname rather than an IP address.
An MX (Mail Exchange) record determines which mail server should receive email for a domain.
For example:
| Type | Host | Value | Priority |
|---|---|---|---|
| MX | @ | mail.example.com | 10 |
The mail.example.com hostname must then resolve appropriately using an A or AAAA record.
MX targets should be hostnames rather than IP addresses.
When multiple mail servers are available, MX records can use priority values.
For example:
10 mail1.example.com20 mail2.example.com
A lower numerical value normally represents a higher preference.
TXT records publish text-based information through DNS.
They are frequently used for:
The exact value depends on the service you are configuring.
SPF helps specify which systems are authorized to send email on behalf of your domain.
SPF policies are published using DNS TXT records.
Incorrect SPF configuration can contribute to authentication failures or email deliverability problems.
Instead of publishing multiple independent SPF policies for the same domain, authorized sending services generally need to be represented within a valid SPF configuration.
DKIM allows outgoing email to be cryptographically signed.
Receiving mail servers can use a public key published in DNS to verify the DKIM signature.
DKIM information is commonly published under a hostname such as:
selector._domainkey.example.com
The required record and value are normally generated by your mail server or email provider.
DMARC provides domain-level policy and reporting related to SPF and DKIM authentication.
It is typically published as a TXT record under:
_dmarc.example.com
DMARC policies should be deployed carefully. Make sure SPF and DKIM are configured correctly before applying strict enforcement policies.
NS records identify the authoritative nameservers for a DNS zone.
For example:
ns1.example.comns2.example.com
Changing nameservers can effectively move DNS management to another DNS infrastructure, making it a broader change than simply modifying an A record.
A PTR record is used for reverse DNS (rDNS).
Normal DNS might resolve:
example.com → 192.0.2.10
Reverse DNS can resolve:
192.0.2.10 → server.example.com
PTR records are particularly important for mail servers because receiving systems may inspect the reverse DNS associated with a sending IP address.
PTR records are generally not managed through your normal domain DNS panel.
Reverse DNS for an IP address is usually controlled by the provider that owns or assigns the IP range.
PTR configuration may therefore be available through:
If your mail server is:
mail.example.com
and the IP is:
192.0.2.10
a consistent configuration may include:
mail.example.com → 192.0.2.10
and:
192.0.2.10 → mail.example.com
Other mail server settings, including its HELO/EHLO hostname, should also be configured consistently.
TTL specifies how long DNS resolvers may cache a DNS record.
TTL is expressed in seconds.
For example:
3600
represents one hour.
Lower TTL values may help cached records refresh more quickly during planned changes, although very low TTL values are not necessary for every configuration.
DNS relies heavily on caching.
After changing a DNS record, some resolvers may continue using the previous value until its cached TTL expires.
As a result, some visitors may temporarily reach the old server while others already reach the new one.
This should be considered when migrating services between servers.
A typical migration process is:
This can help reduce downtime during migration.
Yes.
Software such as BIND, PowerDNS, or DNS services included with hosting control panels can be used to run authoritative DNS.
For example, you could operate:
ns1.example.comns2.example.com
However, running authoritative DNS requires more than simply creating DNS records.
You must consider:
Creating two nameserver hostnames on the same VDS does not provide true infrastructure redundancy.
Glue records may be required when your nameservers are located under the same domain they serve.
For example:
ns1.example.com → 192.0.2.10
If example.com itself uses ns1.example.com as a nameserver, the registrar can publish the nameserver's IP information to avoid a circular DNS dependency.
Depending on the registrar, this feature may be called:
Glue Record
Child Nameserver
Register Nameserver
or:
Host Record
DNS commonly uses:
UDP 53
and, when required:
TCP 53
If you operate your own DNS server, the firewall must allow the necessary DNS traffic.
Do not assume that opening only UDP port 53 is sufficient for every DNS operation.
If your domain uses Cloudflare nameservers, your DNS records are managed through Cloudflare.
For a typical website, you may configure:
A → @ → VDS IP
and:
CNAME → www → example.com
When Cloudflare proxying is enabled, visitor traffic may pass through Cloudflare before reaching your VDS.
In this configuration, you usually do not need to operate your own authoritative DNS server on the VDS.
On Windows:
nslookup example.com
can be used to inspect basic DNS resolution.
On Linux or macOS systems where dig is available:
dig example.com
For MX records:
dig MX example.com
For nameservers:
dig NS example.com
Check whether:
If DNS is correct, the issue may be with the web server or application rather than DNS itself.
Common mistakes include:
You can access a VDS directly using its IP address. However, DNS records are required when you want to use domain names.
An A record maps a hostname to an IPv4 address. A CNAME aliases one hostname to another hostname.
MX targets should be hostnames. That hostname can then resolve to an IP address through A or AAAA records.
Usually not. PTR/reverse DNS is generally managed by the provider responsible for the IP address.
DNS commonly uses UDP 53, but TCP 53 is also part of DNS and is required for some operations.
No. You can use your registrar's DNS, your hosting provider, Cloudflare, or another DNS provider.
DNS configuration on a VDS involves more than simply pointing a domain to an IP address.
A and AAAA records are used for IP resolution, CNAME records create hostname aliases, MX records direct email, TXT records support verification and email authentication policies, and PTR records provide reverse DNS.
For many websites, using an existing DNS provider is sufficient. Operating your own authoritative DNS infrastructure requires additional security, redundancy, and administration.
When using İde Bilişim VDS services, properly planned DNS records help ensure that your websites, email services, and server applications remain accessible and correctly configured.