CresignSys Learn

CresignSys Learn — Lesson 075

Written by

cresignsys

in

Build hosting-dns-check

We now have the domain layer. The next step is to verify whether domains actually point to the CresignSys server.

Target command:

sudo hosting-dns-check example.com

The important distinction is:

Registering a domain in CHP does not mean its DNS is correctly configured.

1. DNS Architecture

The complete request path is now:

USER
  │
  ▼
DOMAIN
  │
  ▼
DNS
  │
  ▼
SERVER IP
  │
  ▼
NGINX
  │
  ▼
HTTPS
  │
  ▼
PHP-FPM
  │
  ▼
WORDPRESS

If DNS is wrong, everything after DNS can be perfectly configured and the website will still not work.

2. What hosting-dns-check Must Answer

For:

sudo hosting-dns-check example.com

we want to know:

Domain:
example.com

A:
203.0.113.10

AAAA:
None

Expected IPv4:
203.0.113.10

Result:
DNS CORRECT

3. DNS States

Use explicit states:

CORRECT
PENDING
WRONG
MULTIPLE
ERROR

CORRECT

DNS points to the expected server.

PENDING

DNS doesn’t exist yet.

WRONG

DNS exists but points somewhere else.

MULTIPLE

Multiple records exist and at least one isn’t expected.

ERROR

DNS query failed.

4. Why Multiple Matters

Suppose:

example.com

has:

A → 203.0.113.10
A → 198.51.100.20

Your server is:

203.0.113.10

Some users may reach your server while others reach the other server.

Therefore:

DNS = MULTIPLE

may be more accurate than simply:

DNS = CORRECT

5. Read Expected Server IP

Don’t hard-code:

SERVER_IP=...

into every domain.

Put server identity in centralized configuration:

/etc/cresignsys/hosting.conf

For example:

SERVER_IPV4="YOUR_SERVER_IPV4"
SERVER_IPV6="YOUR_SERVER_IPV6"

Only define IPv6 if the server actually supports it.

6. Why IPv6 Matters

A domain might have:

A     → IPv4
AAAA  → IPv6

A browser may prefer IPv6.

If:

AAAA → wrong server

while:

A → correct server

some users can still see the wrong website.

Therefore checking only the A record is incomplete.

7. Query A Record

Use:

dig +short A example.com

Example:

203.0.113.10

Store:

DNS_IPV4="203.0.113.10"

8. Query AAAA

dig +short AAAA example.com

If there is no result:

AAAA:
NONE

That isn’t necessarily an error.

It simply means IPv6 isn’t configured for that hostname.

9. Query CNAME

dig +short CNAME www.example.com

For:

www.example.com

you might see:

example.com.

This means:

www.example.com
       ↓
CNAME
       ↓
example.com
       ↓
A
       ↓
server

10. Don’t Treat CNAME as an Error

For:

www.example.com

the correct configuration could be:

CNAME www → example.com

instead of:

A www → server

Both architectures can be valid.

Therefore the DNS checker must understand record relationships.

11. DNS Resolution

Example:

www.example.com
       │
       ▼
CNAME example.com
       │
       ▼
A 203.0.113.10

The final resolved address is:

203.0.113.10

So the checker should distinguish:

record type

from:

final destination

12. Use a Resolver

A DNS answer depends on the resolver.

For troubleshooting, you can compare:

dig example.com

with:

dig @1.1.1.1 example.com

and:

dig @8.8.8.8 example.com

This can reveal resolver-specific differences or propagation issues.

13. Don’t Assume DNS Changes Are Instant

Suppose the user changes:

A example.com

from:

OLD_IP

to:

NEW_IP

Different recursive resolvers may continue returning the old record until the previous TTL expires.

Therefore:

DNS changed

does not necessarily mean:

everyone sees new DNS immediately

14. DNS TTL

Query:

dig example.com

You’ll see a TTL field in the response.

Conceptually:

TTL = 300

means recursive resolvers may cache the answer for approximately 300 seconds.

The actual propagation behavior can be more complex because of caching layers.

15. hosting-dns-check Should Report TTL

Example:

A Record:
203.0.113.10

TTL:
300 seconds

This helps administrators understand why a recent DNS change may still be propagating.

16. Create the Script

Create:

sudo nano /usr/local/bin/hosting-dns-check

Start:

#!/usr/bin/env bash

set -Eeuo pipefail

17. Require Root

if [[ "$EUID" -ne 0 ]]; then
    echo "ERROR: Run with sudo."
    exit 1
fi

18. Require Domain

if [[ $# -ne 1 ]]; then
    echo "Usage: hosting-dns-check DOMAIN"
    exit 1
fi

DOMAIN="$1"

19. Validate Domain

Reuse the same hostname-validation function from:

hosting-domain-add

Don’t implement five different domain validators.

Eventually create:

/etc/cresignsys/lib/domain.sh

with reusable functions.

20. Load Configuration

source /etc/cresignsys/hosting.conf

Then:

EXPECTED_IPV4="${SERVER_IPV4:-}"
EXPECTED_IPV6="${SERVER_IPV6:-}"

21. Query IPv4

mapfile -t IPV4_RECORDS < <(
    dig +short A "$DOMAIN"
)

Now you may have:

203.0.113.10

or:

203.0.113.10
198.51.100.20

22. Compare IPv4

If:

EXPECTED_IPV4=203.0.113.10

and:

IPV4_RECORDS:
203.0.113.10

then:

IPv4:
CORRECT

If:

IPV4_RECORDS:
198.51.100.20

then:

IPv4:
WRONG

23. Multiple IPv4 Records

If:

203.0.113.10
198.51.100.20

then:

IPv4:
MULTIPLE

unless your platform intentionally supports multiple origin IPs.

24. Multi-Server Hosting

Later CHP may support:

Server A
Server B
Server C

Then multiple A records might be intentional.

For now, if CHP has one origin server:

multiple unexpected A records

should generate a warning.

25. IPv6 Check

Run:

mapfile -t IPV6_RECORDS < <(
    dig +short AAAA "$DOMAIN"
)

Then compare against:

SERVER_IPV6

If IPv6 isn’t configured on the server:

AAAA:
UNEXPECTED

if the domain points somewhere else.

26. Important IPv6 Scenario

Suppose:

A:
YOUR_SERVER

AAAA:
OTHER_SERVER

Then:

DNS Status:
WRONG

even though:

A:
CORRECT

because IPv6 clients may reach the wrong machine.

27. CNAME Handling

For an alias:

www.example.com

check:

dig +short CNAME www.example.com

If:

example.com.

then recursively inspect:

example.com

to determine the final IP.

28. DNS Checker Output

A useful result:

CresignSys DNS Check
====================

Domain:
www.example.com

CNAME:
www.example.com → example.com

A:
203.0.113.10

Expected:
203.0.113.10

AAAA:
None

TTL:
300

Result:
DNS CORRECT

29. Wrong DNS Output

CresignSys DNS Check
====================

Domain:
example.com

A:
198.51.100.20

Expected:
203.0.113.10

Result:
DNS WRONG

30. Pending DNS

If:

dig +short A example.com

returns nothing:

A:
NONE

show:

Result:
DNS PENDING

31. Multiple Records

A:
203.0.113.10
198.51.100.20

Expected:
203.0.113.10

Result:
DNS MULTIPLE

32. DNS Error

If the resolver cannot be reached:

Result:
DNS ERROR

This is different from:

DNS PENDING

because:

PENDING

means there is no record.

ERROR

means the check itself failed.

33. Domain-Specific Expected DNS

Instead of assuming every hostname should point directly to:

SERVER_IPV4

your domain registry can eventually contain:

DNS_MODE=A

or:

DNS_MODE=CNAME

For example:

www.example.com
DNS_MODE=CNAME
DNS_TARGET=example.com

34. DNS Requirements

hosting-domain-list can eventually show:

DOMAIN                 DNS
---------------------------------
example.com             CORRECT
www.example.com         CORRECT
old-example.com         PENDING

35. hosting-domain-add Integration

After:

sudo hosting-domain-add www.example.com --alias example.com

the system can output:

DNS:
PENDING

Required:
CNAME www → example.com

Then:

sudo hosting-dns-check www.example.com

will tell you when the DNS is ready.

36. Don’t Automatically Modify DNS

Unless CHP is actually operating the authoritative DNS service for the domain, don’t try to change DNS records from the hosting server.

The hosting server can:

CHECK DNS

but may not be able to:

CHANGE DNS

37. DNS Provider Integration

Later, CHP can support integrations such as:

DNS Provider
     │
     ├── Create A
     ├── Create AAAA
     ├── Create CNAME
     └── Create TXT

But that requires provider-specific API credentials and configuration.

Keep the base DNS checker provider-independent.

38. DNS vs Domain Registrar

Another important distinction:

Domain Registrar
        │
        ▼
Domain ownership
        │
        ▼
Nameservers
        │
        ▼
DNS Provider
        │
        ▼
A / AAAA / CNAME

Your hosting platform normally doesn’t need to be the registrar.

39. Nameserver Check

You can inspect:

dig +short NS example.com

Example:

ns1.provider.com.
ns2.provider.com.

This tells you which DNS infrastructure is authoritative.

40. Why Check Nameservers?

Suppose the customer says:

I added the DNS record.

But the domain uses:

ns1.oldprovider.com

while they modified records at another provider.

The changes won’t affect the authoritative DNS.

Therefore:

NS

is useful diagnostic information.

41. DNS Delegation

The full hierarchy:

Root
 ↓
.com
 ↓
example.com
 ↓
Authoritative nameservers
 ↓
A / AAAA / CNAME

If delegation is wrong:

DNS configuration at the expected provider

may never be seen by users.

42. hosting-dns-check --verbose

Eventually support:

sudo hosting-dns-check example.com --verbose

Output:

Domain:
example.com

Nameservers:
ns1.provider.com
ns2.provider.com

A:
203.0.113.10

AAAA:
None

TTL:
300

Expected IPv4:
203.0.113.10

Result:
CORRECT

43. Resolver Comparison

For troubleshooting:

dig @1.1.1.1 example.com
dig @8.8.8.8 example.com

You may see:

Resolver 1:
NEW IP

Resolver 2:
OLD IP

This suggests caching/propagation differences rather than necessarily a server problem.

44. DNS Health State

Add to domain metadata:

DNS_STATE=CORRECT

Possible values:

PENDING
CORRECT
WRONG
MULTIPLE
ERROR

45. Domain Health Matrix

Now each domain can have:

DNS
SSL
HTTP
HTTPS

For example:

example.com

DNS:
CORRECT

HTTP:
OK

HTTPS:
OK

SSL:
ACTIVE

46. Combined Domain Check

Eventually:

sudo hosting-domain-health example.com

can perform:

DNS
 ↓
HTTP
 ↓
HTTPS
 ↓
SSL

This will complement:

hosting-health

which checks the whole application stack.

47. Difference Between DNS Health and Site Health

DNS health

Is the hostname pointing to the right place?

Site health

Is the application working after reaching the server?

Example:

DNS ✓
HTTP ✓
PHP ✗

The domain is correctly configured, but the application is broken.

48. Complete Diagnostic Chain

DNS
 │
 ├── FAIL → DNS problem
 │
 ▼
Nginx
 │
 ├── FAIL → web server problem
 │
 ▼
PHP-FPM
 │
 ├── FAIL → PHP problem
 │
 ▼
WordPress
 │
 ├── FAIL → application problem
 │
 ▼
Database
 │
 ├── FAIL → database problem
 │
 ▼
HEALTHY

This is the foundation for automatic diagnostics.

49. DNS + SSL

The SSL command should eventually call:

hosting-dns-check

before requesting a certificate.

So:

hosting-ssl example.com

becomes:

DNS check
   ↓
HTTP check
   ↓
certificate

This reduces failed ACME requests.

50. DNS + Provisioning

The full provisioning process can become:

hosting-create
      ↓
site created
      ↓
domain registered
      ↓
DNS instructions
      ↓
hosting-dns-check
      ↓
DNS correct
      ↓
hosting-ssl
      ↓
HTTPS
      ↓
health
      ↓
ACTIVE

51. Pending Provisioning

This suggests a useful state:

SITE_STATUS=WAITING_DNS

Instead of:

SITE_STATUS=ERROR

because DNS may simply not have been configured yet.

52. Example

After:

sudo hosting-create example.com

the system may show:

Site:
CREATED

DNS:
PENDING

Required:
A example.com → SERVER_IP

SSL:
PENDING DNS

Application:
READY

This is much clearer than saying:

ERROR

53. DNS Instructions

The platform can automatically display:

DNS Records
===========

A
Name: @
Value: YOUR_SERVER_IP

A
Name: www
Value: YOUR_SERVER_IP

Or if using CNAME:

CNAME
Name: www
Target: example.com

54. Avoid Requiring Both A and CNAME for Same Host

A hostname cannot normally have both:

CNAME www → example.com

and:

A www → server

at the same time.

Your DNS instruction generator must choose one valid configuration.

55. Apex Domain

For:

example.com

the root/apex domain usually uses:

A

or an appropriate provider-specific alias/flattening mechanism.

A standard CNAME at the zone apex is generally not supported in traditional DNS.

This is why your DNS instruction generator should distinguish:

apex

from:

subdomain

56. www Recommendation

A simple architecture:

example.com
   A → SERVER

www.example.com
   CNAME → example.com

Then your Nginx configuration handles both.

57. But CDN/Proxy Changes Things

If the domain uses a CDN or reverse proxy:

Browser
 ↓
CDN
 ↓
Server

DNS may intentionally point to the CDN rather than directly to your server.

Therefore:

DNS != SERVER_IP

does not automatically mean:

wrong

for every architecture.

58. Add DNS Mode

Eventually site metadata can contain:

DNS_MODE=DIRECT

or:

DNS_MODE=PROXY

or:

DNS_MODE=EXTERNAL

For the current CHP server:

DNS_MODE=DIRECT

can be the default.

59. Direct Mode

example.com
     ↓
server IP

The DNS checker expects:

A → CHP server

60. External/Proxy Mode

example.com
     ↓
CDN
     ↓
CHP server

The DNS checker should instead verify the appropriate expected configuration.

This can be added later.

61. Don’t Overcomplicate Version 1

For the current platform, implement:

DIRECT DNS

with:

A
AAAA
CNAME
NS
TTL

Then add provider/CDN support later.

62. DNS Check Output — Full Example

CresignSys DNS Check
====================

Domain:
example.com

Nameservers:
ns1.provider.com
ns2.provider.com

A Records:
203.0.113.10

Expected IPv4:
203.0.113.10

AAAA Records:
None

CNAME:
None

TTL:
300

DNS State:
CORRECT

63. Pending Example

CresignSys DNS Check
====================

Domain:
example.com

A Records:
None

AAAA Records:
None

DNS State:
PENDING

Required:
A @ → YOUR_SERVER_IP

64. Wrong Example

CresignSys DNS Check
====================

Domain:
example.com

A Records:
198.51.100.20

Expected:
203.0.113.10

DNS State:
WRONG

65. Multiple Example

CresignSys DNS Check
====================

Domain:
example.com

A Records:
203.0.113.10
198.51.100.20

Expected:
203.0.113.10

DNS State:
MULTIPLE

66. DNS Error Example

CresignSys DNS Check
====================

Domain:
example.com

DNS resolver:
ERROR

DNS State:
ERROR

No changes made.

67. Integration With hosting-health

Now:

sudo hosting-health example.com

can start with:

[OK] DNS

and then:

[OK] Nginx
[OK] PHP-FPM
[OK] PHP socket
[OK] Database
[OK] WordPress
[OK] HTTPS

68. Integration With hosting-ssl

The SSL workflow becomes:

hosting-ssl
     │
     ▼
hosting-dns-check
     │
 ┌───┴────┐
 ▼        ▼
CORRECT   FAIL
 │         │
 ▼         ▼
ACME      STOP

This is much safer.

69. Integration With Domain Management

Now:

hosting-domain-add
        ↓
DNS=PENDING
        ↓
hosting-dns-check
        ↓
DNS=CORRECT
        ↓
hosting-ssl
        ↓
SSL=ACTIVE

This gives the platform a clean provisioning pipeline.

70. Lesson 075 — Core Principle

DNS is the bridge between:

DOMAIN

and:

SERVER

Therefore the hosting platform should never simply assume:

domain added = DNS ready

Instead:

DOMAIN
   ↓
DNS CHECK
   ↓
CORRECT
   ↓
HTTP
   ↓
SSL
   ↓
HTTPS

71. Updated CHP Architecture

                         CHP
                          │
          ┌───────────────┼────────────────┐
          ▼               ▼                ▼
        SITE            DOMAIN             DNS
          │               │                │
          │               ├── Primary      │
          │               ├── Alias        │
          │               └── Redirect     │
          │                                │
          │                                ▼
          │                           DNS CHECK
          │                                │
          └────────────────────────────────┘
                           │
                           ▼
                         NGINX
                           │
                           ▼
                          SSL
                           │
                           ▼
                       PHP-FPM
                           │
                           ▼
                       WordPress

72. Current Command Set

hosting-create DOMAIN

hosting-list
hosting-info DOMAIN
hosting-health DOMAIN

hosting-repair DOMAIN --php
hosting-repair DOMAIN --nginx
hosting-repair DOMAIN --permissions
hosting-repair DOMAIN --wordpress

hosting-ssl DOMAIN

hosting-backup DOMAIN
hosting-backup-list DOMAIN
hosting-backup-verify DOMAIN BACKUP_ID
hosting-backup-prune DOMAIN --dry-run
hosting-backup-prune DOMAIN --execute
hosting-restore DOMAIN BACKUP_ID

hosting-suspend DOMAIN
hosting-unsuspend DOMAIN

hosting-domain-add DOMAIN
hosting-domain-add DOMAIN --alias TARGET
hosting-domain-add DOMAIN --redirect TARGET
hosting-domain-list DOMAIN
hosting-domain-remove DOMAIN

hosting-dns-check DOMAIN

Next Lesson — 076

Build hosting-site-status

We now have enough components to build a single unified status engine.

Instead of checking:

hosting-dns-check example.com
hosting-health example.com
hosting-info example.com

separately, we can create:

sudo hosting-site-status example.com

that produces one complete diagnostic:

DOMAIN
 ├── Ownership
 ├── DNS
 ├── Nginx
 ├── HTTP
 ├── HTTPS
 ├── SSL
 ├── PHP-FPM
 ├── Database
 ├── WordPress
 ├── Filesystem
 ├── Backup
 ├── Service State
 └── Overall Health

The result will allow CHP to classify a site as:

HEALTHY
DEGRADED
SUSPENDED
WAITING_DNS
SSL_ERROR
APPLICATION_ERROR
DATABASE_ERROR
SERVER_ERROR

That unified status layer will become the foundation for the future CresignSys Hosting control panel.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

More posts