DNS and Domain Management: A, MX, TXT & NAT

Where should you change the record?

Check the nameservers configured at the domain registrar first. If DNS is hosted by the registrar or another provider, edit the web record there. Windows DNS managed through AdaPanel serves as the public source only when it is authoritative for that domain.

The DNS area provides Windows DNS role installation, zone and record management. When changing nameservers, transfer mail, verification and subdomain records as well. Copying only the main A record can leave other working services behind.

What does each record do?

What does each record do?
Record	Purpose	Check
A / AAAA	IPv4 / IPv6 destination	Does that address serve this site?
CNAME	Alias pointing to another name	Does the target resolve? It is not an HTTP redirect.
MX	Inbound mail server	Does the destination have A/AAAA records?
TXT	Verification and policies such as SPF	Does it conflict with existing records?
NS	Authoritative nameservers	Is it consistent with registrar delegation?

Private addresses, public addresses and IPv6

Behind NAT, an IIS binding may use a private address while the public A record points to the external IPv4 address. The router must forward required traffic to the correct server. Publishing a private address in public DNS does not make a site reachable over the internet.

Publish AAAA only when the site also works over IPv6. A wrong IPv6 destination can break access for some visitors while IPv4 tests pass. Public addressing, CGNAT and provider port policies are separate from panel settings.

A practical domain transition sequence

Record the existing authoritative zone and its TTL values.
Prepare the new IIS hostname binding and certificate.
Allow advance TTL changes to reach existing caches before switching traffic.
Update A/AAAA to the intended destination; preserve unrelated MX and TXT records.
Query authoritative and independent resolvers, then test the application over HTTPS at the new destination.
Keep the previous server until caches and active user operations have completed the transition.

Why can the site fail when DNS is correct?

DNS identifies the destination. IIS site selection, the TLS handshake and application execution happen afterwards. For a wrong page, inspect hostname bindings; for timeouts, inspect the network path; for certificate warnings, inspect the certificate served. Clearing one computer’s cache does not refresh the whole internet.