```
├── .gitattributes (omitted)
├── .github/
├── FUNDING.yml
├── PULL_REQUEST_TEMPLATE.md (100 tokens)
├── CODE_OF_CONDUCT.md (1000 tokens)
├── CONTRIBUTING.md (300 tokens)
├── LEARN.md (1300 tokens)
├── LICENSE (omitted)
├── README.md (800 tokens)
├── SECURITY.md (200 tokens)
├── assets/
├── logo.jpg
├── documents/
├── domains/
├── announcement.md
├── faq.md (200 tokens)
├── tutorial/
├── BOOK_PLAN.md (600 tokens)
├── advanced/
├── 6.1-api-automation.md (600 tokens)
├── 6.2-self-hosted-dns.md (600 tokens)
├── 6.3-command-reference.md (500 tokens)
├── 6.4-architecture-patterns.md (800 tokens)
├── 6.5-reliability-and-capacity.md (800 tokens)
├── glossary.md (600 tokens)
├── index.md (200 tokens)
├── references.md (300 tokens)
├── appendices/
├── answers.md (1100 tokens)
├── checklists-and-templates.md (800 tokens)
├── index.md (100 tokens)
├── troubleshooting-trees.md (1000 tokens)
├── workbook.md (1200 tokens)
├── capstone/
├── 7.1-project-brief.md (800 tokens)
├── 7.2-build-and-test.md (1100 tokens)
├── 7.3-register-and-deploy.md (800 tokens)
├── 7.4-secure-and-operate.md (800 tokens)
├── 7.5-final-acceptance.md (900 tokens)
├── index.md (200 tokens)
├── dns/
├── 2.0-delegation.md (400 tokens)
├── 2.1-record-types.md (700 tokens)
├── 2.2-subdomains.md (500 tokens)
├── 2.3-ttl-and-propagation.md (500 tokens)
├── 2.4-troubleshooting.md (500 tokens)
├── index.md (200 tokens)
├── email/
├── 4.1-email-dns.md (600 tokens)
├── 4.2-service-records.md (400 tokens)
├── index.md (100 tokens)
├── foundations/
├── 0.1-how-to-use-this-book.md (800 tokens)
├── 0.2-internet-foundations.md (800 tokens)
├── 0.3-terminal-basics.md (800 tokens)
├── 0.4-practice-environment.md (700 tokens)
├── 0.5-plan-your-site.md (700 tokens)
├── 0.6-domain-and-dns.md (700 tokens)
├── index.md (200 tokens)
├── index.md (1400 tokens)
├── operations/
├── 5.1-domain-management.md (500 tokens)
├── 5.2-renewal-and-expiration.md (500 tokens)
├── 5.3-migrate-nameservers.md (400 tokens)
├── 5.4-registration-data.md (400 tokens)
├── 5.5-security.md (500 tokens)
├── 5.6-acceptable-use.md (400 tokens)
├── 5.7-backups-and-restoration.md (900 tokens)
├── 5.8-monitoring-and-incidents.md (900 tokens)
├── 5.9-server-hardening.md (900 tokens)
├── index.md (200 tokens)
├── platform/
├── 1.0-product-boundaries.md (700 tokens)
├── 1.1-account-registration.md (400 tokens)
├── 1.2-domain-registration.md (400 tokens)
├── 1.3-connect-nameservers.md (500 tokens)
├── 1.4-status-and-renewal.md (400 tokens)
├── 1.5-account-and-policies.md (400 tokens)
├── 1.6-api-overview.md (300 tokens)
├── dashboard-tour.md (600 tokens)
├── imgs/
├── cloudflare-account-register.png
├── cloudflare-add-domain.png
├── cloudflare-add-record.png
├── cloudflare-choose-plan.png
├── cloudflare-setns.png
├── digitalplat-account-registration.jpg
├── digitalplat-domain-registration.jpg
├── digitalplat-register-setns.png
├── index.md (300 tokens)
├── project-overview.md (500 tokens)
├── website/
├── 3.0-html-css-foundations.md (1000 tokens)
├── 3.1-how-websites-work.md (400 tokens)
├── 3.2-build-static-site.md (500 tokens)
├── 3.3-test-locally.md (300 tokens)
├── 3.4-prepare-server.md (500 tokens)
├── 3.5-deploy-and-connect.md (400 tokens)
├── 3.6-https.md (700 tokens)
├── 3.7-dynamic-applications.md (900 tokens)
├── 3.8-accessibility-and-search.md (800 tokens)
├── 3.9-performance-and-caching.md (800 tokens)
├── index.md (300 tokens)
```
## /.github/FUNDING.yml
```yml path="/.github/FUNDING.yml"
# These are supported funding model platforms
custom: ['https://hcb.hackclub.com/donations/start/digitalplat']
```
## /.github/PULL_REQUEST_TEMPLATE.md
## Summary
Describe what this pull request changes and why.
## Validation
- [ ] I verified the technical claims and commands I changed.
- [ ] I checked relative links and image paths.
- [ ] I removed credentials, personal information, and other sensitive data.
- [ ] I kept this pull request focused on one subject.
## Related Context
Link any related discussion, service report, or source material.
## /CODE_OF_CONDUCT.md
# Contributor Covenant Code of Conduct
## Our Pledge
We as members, contributors, and leaders pledge to make participation in our
community a harassment-free experience for everyone, regardless of age, body
size, visible or invisible disability, ethnicity, sex characteristics, gender
identity and expression, level of experience, education, socio-economic status,
nationality, personal appearance, race, religion, or sexual identity
and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming,
diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our
community include:
- Demonstrating empathy and kindness toward other people
- Being respectful of differing opinions, viewpoints, and experiences
- Giving and gracefully accepting constructive feedback
- Accepting responsibility and apologizing to those affected by our mistakes,
and learning from the experience
- Focusing on what is best not just for us as individuals, but for the
overall community
Examples of unacceptable behavior include:
- The use of sexualized language or imagery, and sexual attention or
advances of any kind
- Trolling, insulting or derogatory comments, and personal or political attacks
- Public or private harassment
- Publishing others' private information, such as a physical or email
address, without their explicit permission
- Other conduct which could reasonably be considered inappropriate in a
professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of
acceptable behavior and will take appropriate and fair corrective action in
response to any behavior that they deem inappropriate, threatening, offensive,
or harmful.
Community leaders have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, discussions, and other contributions that
are not aligned to this Code of Conduct, and will communicate reasons for
moderation decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when
an individual is officially representing the community in public spaces.
Examples of representing our community include using an official email address,
posting via an official social media account, or acting as an appointed
representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported to the community leaders responsible for enforcement at
`contact@digitalplat.org`.
All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the
reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining
the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact**: Use of inappropriate language or other behavior deemed
unprofessional or unwelcome in the community.
**Consequence**: A private, written warning from community leaders, providing
clarity around the nature of the violation and an explanation of why the
behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact**: A violation through a single incident or series
of actions.
**Consequence**: A warning with consequences for continued behavior. No
interaction with the people involved, including unsolicited interaction with
those enforcing the Code of Conduct, for a specified period of time. This
includes avoiding interactions in community spaces as well as external channels
like social media. Violating these terms may lead to a temporary or permanent
ban.
### 3. Temporary Ban
**Community Impact**: A serious violation of community standards, including
sustained inappropriate behavior.
**Consequence**: A temporary ban from any sort of interaction or public
communication with the community for a specified period of time. No public or
private interaction with the people involved, including unsolicited interaction
with those enforcing the Code of Conduct, is allowed during this period.
Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact**: Demonstrating a pattern of violation of community
standards, including sustained inappropriate behavior, harassment of an
individual, or aggression toward or disparagement of classes of individuals.
**Consequence**: A permanent ban from any sort of public interaction within
the community.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 2.0, available at
https://www.contributor-covenant.org/version/2/0/code_of_conduct.html.
Community Impact Guidelines were inspired by [Mozilla's code of conduct
enforcement ladder](https://github.com/mozilla/diversity).
[homepage]: https://www.contributor-covenant.org
For answers to common questions about this code of conduct, see the FAQ at
https://www.contributor-covenant.org/faq. Translations are available at
https://www.contributor-covenant.org/translations.
## /CONTRIBUTING.md
# Contributing
Thank you for helping improve DigitalPlat FreeDomain.
## What Belongs in This Repository
This repository contains public project information, announcements, and learning resources. The application source code is maintained in [DigitalPlatDev/Domain-OSS](https://github.com/DigitalPlatDev/Domain-OSS).
Good contributions include:
- Correcting inaccurate or outdated documentation.
- Improving explanations, examples, and troubleshooting steps.
- Fixing broken links, formatting, or accessibility problems.
- Adding useful documentation for domain, DNS, website, email, security, or operations workflows.
## Before Opening a Pull Request
1. Search existing pull requests and discussions to avoid duplicate work.
2. Keep each pull request focused on one subject.
3. Verify commands and technical claims before documenting them.
4. Do not include credentials, personal information, private domain data, or screenshots containing sensitive information.
5. Use clear English for repository content. Translation packs may use their target language.
6. Check that all relative links and image paths work from their Markdown file.
## Where to Ask for Help
- Use [GitHub Discussions](https://github.com/DigitalPlatDev/FreeDomain/discussions) for questions and ideas.
- Use [DigitalPlatDev/FreeDomain-Issues](https://github.com/DigitalPlatDev/FreeDomain-Issues) for service problems and bug reports.
- Email `abusereport@digitalplat.org` for domain abuse reports.
- Follow [SECURITY.md](./SECURITY.md) for security vulnerabilities.
By participating in this project, you agree to follow the [Code of Conduct](./CODE_OF_CONDUCT.md).
## /LEARN.md
# Learn Domains from Registration to Website
This repository includes a book-length learning path. Product instructions and general education are separated so DigitalPlat capabilities are not confused with external DNS or hosting features.
## Category A: DigitalPlat FreeDomain
1. [About the FreeDomain Project](./documents/tutorial/platform/project-overview.md)
2. [Dashboard Tour](./documents/tutorial/platform/dashboard-tour.md)
3. [What DigitalPlat Does](./documents/tutorial/platform/1.0-product-boundaries.md)
4. [Create a DigitalPlat Account](./documents/tutorial/platform/1.1-account-registration.md)
5. [Register a FreeDomain Name](./documents/tutorial/platform/1.2-domain-registration.md)
6. [Connect External Nameservers](./documents/tutorial/platform/1.3-connect-nameservers.md)
7. [Check Status and Renew](./documents/tutorial/platform/1.4-status-and-renewal.md)
8. [Manage Account Data and Policies](./documents/tutorial/platform/1.5-account-and-policies.md)
9. [Use the API Safely](./documents/tutorial/platform/1.6-api-overview.md)
DigitalPlat registers domains and delegates them to external authoritative nameservers. Ordinary DNS records are managed outside DigitalPlat.
## Category B: General Textbook
- [Part 0: Beginner Foundations](./documents/tutorial/foundations/index.md)
- [Part 2: External DNS](./documents/tutorial/dns/index.md)
- [Part 3: Website Building and Deployment](./documents/tutorial/website/index.md)
- [Part 4: Email and Service Records](./documents/tutorial/email/index.md)
- [Part 5: Operations and Security](./documents/tutorial/operations/index.md)
- [Part 6: Advanced Architecture and Reference](./documents/tutorial/advanced/index.md)
<details>
<summary>View every general textbook chapter</summary>
### Part 0: Beginner Foundations
1. [How to Use This Book](./documents/tutorial/foundations/0.1-how-to-use-this-book.md)
2. [How the Internet Moves Data](./documents/tutorial/foundations/0.2-internet-foundations.md)
3. [Terminal and File Basics](./documents/tutorial/foundations/0.3-terminal-basics.md)
4. [Build a Safe Practice Environment](./documents/tutorial/foundations/0.4-practice-environment.md)
5. [Plan Your First Website](./documents/tutorial/foundations/0.5-plan-your-site.md)
6. [Domain and DNS Fundamentals](./documents/tutorial/foundations/0.6-domain-and-dns.md)
### Part 2: External DNS
1. [Delegation and External Nameservers](./documents/tutorial/dns/2.0-delegation.md)
2. [DNS Record Types](./documents/tutorial/dns/2.1-record-types.md)
3. [Root Domains and Subdomains](./documents/tutorial/dns/2.2-subdomains.md)
4. [TTL, Caching, and Propagation](./documents/tutorial/dns/2.3-ttl-and-propagation.md)
5. [DNS Troubleshooting](./documents/tutorial/dns/2.4-troubleshooting.md)
### Part 3: Website Building and Deployment
1. [HTML and CSS Foundations](./documents/tutorial/website/3.0-html-css-foundations.md)
2. [How a Website Request Works](./documents/tutorial/website/3.1-how-websites-work.md)
3. [Build a Static Website](./documents/tutorial/website/3.2-build-static-site.md)
4. [Test the Website Locally](./documents/tutorial/website/3.3-test-locally.md)
5. [Prepare a Linux Web Server](./documents/tutorial/website/3.4-prepare-server.md)
6. [Deploy and Connect the Domain](./documents/tutorial/website/3.5-deploy-and-connect.md)
7. [Enable and Verify HTTPS](./documents/tutorial/website/3.6-https.md)
8. [Dynamic Applications and Reverse Proxies](./documents/tutorial/website/3.7-dynamic-applications.md)
9. [Accessibility and Search Basics](./documents/tutorial/website/3.8-accessibility-and-search.md)
10. [Performance and Caching](./documents/tutorial/website/3.9-performance-and-caching.md)
### Part 4: Email and Service Records
1. [Email DNS: MX, SPF, DKIM, and DMARC](./documents/tutorial/email/4.1-email-dns.md)
2. [Verification and Service Records](./documents/tutorial/email/4.2-service-records.md)
### Part 5: Operations and Security
1. [Infrastructure Inventory and Change Management](./documents/tutorial/operations/5.1-domain-management.md)
2. [Renewal and Expiration](./documents/tutorial/operations/5.2-renewal-and-expiration.md)
3. [Migrate Nameservers Safely](./documents/tutorial/operations/5.3-migrate-nameservers.md)
4. [Registration Data and Privacy](./documents/tutorial/operations/5.4-registration-data.md)
5. [Account and API Security](./documents/tutorial/operations/5.5-security.md)
6. [Acceptable Use and Abuse Response](./documents/tutorial/operations/5.6-acceptable-use.md)
7. [Backups and Restoration](./documents/tutorial/operations/5.7-backups-and-restoration.md)
8. [Monitoring and Incident Response](./documents/tutorial/operations/5.8-monitoring-and-incidents.md)
9. [Server Hardening and Maintenance](./documents/tutorial/operations/5.9-server-hardening.md)
### Part 6: Advanced Architecture and Reference
1. [API Automation Safety](./documents/tutorial/advanced/6.1-api-automation.md)
2. [Self-Hosted Authoritative DNS](./documents/tutorial/advanced/6.2-self-hosted-dns.md)
3. [Command Reference](./documents/tutorial/advanced/6.3-command-reference.md)
4. [Website Architecture Patterns](./documents/tutorial/advanced/6.4-architecture-patterns.md)
5. [Reliability and Capacity Planning](./documents/tutorial/advanced/6.5-reliability-and-capacity.md)
6. [Glossary](./documents/tutorial/advanced/glossary.md)
7. [Standards and Further Reading](./documents/tutorial/advanced/references.md)
</details>
## Practice and Assessment
- [Integrated Capstone Project](./documents/tutorial/capstone/index.md)
1. [Project Brief and Architecture](./documents/tutorial/capstone/7.1-project-brief.md)
2. [Build and Test the Site](./documents/tutorial/capstone/7.2-build-and-test.md)
3. [Register, Deploy, and Connect](./documents/tutorial/capstone/7.3-register-and-deploy.md)
4. [Secure, Monitor, and Back Up](./documents/tutorial/capstone/7.4-secure-and-operate.md)
5. [Final Acceptance and Handover](./documents/tutorial/capstone/7.5-final-acceptance.md)
- [Workbook and Practice Exercises](./documents/tutorial/appendices/workbook.md)
- [Suggested Answers](./documents/tutorial/appendices/answers.md)
- [Troubleshooting Decision Trees](./documents/tutorial/appendices/troubleshooting-trees.md)
- [Checklists and Templates](./documents/tutorial/appendices/checklists-and-templates.md)
Continue with the [complete learning guide](./documents/tutorial/index.md).
## /README.md
# DigitalPlat FreeDomain
<div align="center">
<img src="assets/logo.jpg" alt="DigitalPlat FreeDomain logo" width="240">
</div>
Free domain registration and practical DNS learning resources for everyone.
Register a domain, connect your preferred DNS provider through custom nameservers, and use the included learning guide to take a project from registration to deployment.
[Register a domain](https://dash.domain.digitalplat.org/) · [Read the tutorial](./documents/tutorial/index.md) · [Browse the learning guide](./LEARN.md) · [View the application source](https://github.com/DigitalPlatDev/Domain-OSS)
> This repository contains the public information and learning resources for DigitalPlat FreeDomain. The application source code is maintained separately in [DigitalPlatDev/Domain-OSS](https://github.com/DigitalPlatDev/Domain-OSS).
### ✔️ Why Free Domains?
At **DigitalPlat FreeDomain**, we’re on a mission to make the web more accessible. We believe that the cost of a domain shouldn’t hold anyone back from creating a website. Our goal is to make the internet an open space where everyone can have their own place online, regardless of budget.
> DigitalPlat FreeDomain is independently designed and maintained by [**Edward Hsing**](https://github.com/EdwardLab), founder of the DigitalPlat Foundation.
---
### 🌍 Available Domain Extensions
- **.DPDNS.ORG**
- **.US.KG**
- **.QZZ.IO**
- **.XX.KG**
- **.QD.JE**
_(More extensions coming soon!)_
---
### 🌍 Ready to Claim Your Free Domain?
Jump in and register your domain by visiting our site:
➡️ [DigitalPlat FreeDomain Dashboard](https://dash.domain.digitalplat.org/)
📝 [Read our tutorial](./documents/tutorial/index.md)
---
### 📚 Learning Guide
Follow the complete book-style learning path in [LEARN.md](./LEARN.md), from DigitalPlat FreeDomain setup to general DNS, website, email, operations, and advanced topics.
---
### 🌟 Trusted by Thousands
With over 500,000 domains already registered, DigitalPlat FreeDomain is a trusted choice for individuals and organizations alike. Join our growing community and claim your own free domain today!
---
### ❔ FAQ
Read the [FAQ](./documents/domains/faq.md).
---
### 🤝 Join Our Community!
Join our official [DigitalPlat FreeDomain Discord server](https://discord.gg/ma4RZzMmVW) for updates, support, and project discussions. You can also use [GitHub Discussions](https://github.com/DigitalPlatDev/FreeDomain/discussions) for public questions and ideas.
⚠️ **Security Notice**
Our previous Telegram account and group were compromised and are no longer under our control.
Please **do not trust any messages, links, or announcements** from Telegram, especially anything related to bonuses, earnings, or external sites.
We are no longer using Telegram as an official communication channel.
---
### ⏭️ What's Next?
We might introduce more domain options and free hosting in the future to help as many people as possible!
**We can’t wait to see what you build!**
---
### 🚨 Abuse Reporting
We take domain name abuse seriously and are committed to maintaining a safer and more open internet. Every report is carefully reviewed, and response times may vary from a few hours to several days, depending on the complexity of the case.
Email: abusereport@digitalplat.org
---
## 🧠 Story
This started as a small DNS experiment when I was 15, letting a few friends use subdomains.
Over time, it grew into something people actually rely on, and running it turned out to be much harder than building it.
I wrote a bit about how it evolved here:
https://dev.to/edwardhsing/i-bought-a-domain-at-15-now-it-powers-400000-users-7ol
---
## Source Code
The DigitalPlat Domain application is open source at [DigitalPlatDev/Domain-OSS](https://github.com/DigitalPlatDev/Domain-OSS).
Documentation improvements to this repository are welcome. See [CONTRIBUTING.md](./CONTRIBUTING.md) before opening a pull request.
## /SECURITY.md
# Security Policy
## Reporting a Vulnerability
Do not disclose security vulnerabilities in public discussions, pull requests, or the service issue tracker.
Email `contact@digitalplat.org` with:
- A description of the vulnerability and its potential impact.
- The affected page, endpoint, or workflow.
- Reproduction steps or a proof of concept.
- Any suggested mitigation, if available.
Please allow the maintainers time to investigate before publishing details. Do not access, modify, retain, or share data that does not belong to you.
## Domain Abuse
Security vulnerabilities and domain abuse are handled separately. Report phishing, malware, spam, or other abuse involving a registered domain to `abusereport@digitalplat.org`.
## Scope
This repository contains documentation and public project information. Vulnerabilities in the DigitalPlat Domain application may involve code maintained in [DigitalPlatDev/Domain-OSS](https://github.com/DigitalPlatDev/Domain-OSS), but they should still be reported privately using the contact above.
## /assets/logo.jpg
Binary file available at https://raw.githubusercontent.com/DigitalPlatDev/FreeDomain/refs/heads/main/assets/logo.jpg
## /documents/domains/announcement.md
## /documents/domains/faq.md
### ❔ FAQ
#### How many free domain names can be registered? 🚀
Currently, the default limit is **1 domain per user account**.
This policy was updated due to increased domain abuse and to ensure fair usage across the platform. Additional capacity may be introduced in the future through expansion programs or specific use cases, but is not generally available at this time.
You can still create subdomains under your assigned domain via your DNS provider (e.g., `example.foo.us.kg`).
------
#### Which DNS services can I use this domain with?
You can use a DNS service that provides authoritative nameservers for your domain. Enter the assigned NS records in the DigitalPlat FreeDomain panel.
You can also run your own DNS infrastructure if preferred.
DigitalPlat does not endorse or guarantee any third-party DNS service. Review a service's features, security practices, availability, terms, and pricing before using it.
------
#### Do I need to star this project?
It’s not required, but it’s always appreciated 😊
Stars help more people discover the project and support its growth.
## /documents/tutorial/BOOK_PLAN.md
# FreeDomain Learning Guide Plan
## Goal
Create a book-length English learning path that begins with the DigitalPlat FreeDomain product, then clearly transitions to general domain, DNS, website, email, security, and operations education.
## Category Boundary
### Category A: DigitalPlat FreeDomain
Product-specific chapters cover:
- Account registration
- FreeDomain registration
- Submission of external authoritative nameservers
- Domain status and renewal
- Registration data and policies
- Currently documented account and API areas
DigitalPlat delegates domains to external authoritative nameservers. It does not provide an ordinary DNS record editor. Product chapters must never instruct a reader to create `A`, `AAAA`, `CNAME`, `MX`, `TXT`, or other zone records in DigitalPlat.
### Category B: General Domain and Website Textbook
General chapters cover:
- Internet, terminal, and domain foundations
- External authoritative DNS records and troubleshooting
- HTML, CSS, accessibility, and performance
- Static and dynamic website deployment
- HTTP, HTTPS, reverse proxies, and certificates
- Email-related DNS records
- Backups, monitoring, incidents, and server hardening
- Architecture, automation, and capacity planning
All ordinary DNS record examples belong to the external authoritative DNS service.
### Integrated Capstone
The capstone connects both categories: DigitalPlat registers and delegates the name; external DNS publishes zone records; the web server hosts the site and HTTPS.
## Editorial Principles
- Assume no previous DNS, terminal, server, or web development experience.
- Progress from mental models to local labs, public deployment, and advanced operations.
- Explain the reason before the procedure.
- Use fictional names and documentation IP ranges.
- Keep third-party guidance neutral and avoid guarantees.
- Treat current Dashboard notices, policies, prices, suffixes, limits, and capabilities as authoritative.
- Never expose passwords, keys, contact data, private domains, balances, or unrelated content in screenshots.
- Provide observable verification and rollback for operational changes.
- Include exercises, suggested answers, decision trees, and reusable checklists.
## Book Structure
1. Category A: DigitalPlat FreeDomain Guide
2. Category B, Part 0: Beginner Foundations
3. Part 2: External DNS
4. Part 3: Website Building and Deployment
5. Part 4: Email and Service Records
6. Part 5: Operations and Security
7. Part 6: Advanced Architecture and Reference
8. Part 7: Integrated Capstone Project
9. Appendices: Workbook, Answers, Decision Trees, and Templates
## Completion Standard
The book is complete when a new reader can identify the product boundary, register a domain, delegate it to external nameservers, manage records at the external DNS service, build and deploy an accessible HTTPS site, operate it safely, complete the capstone, and navigate every chapter through README and the book index.
## /documents/tutorial/advanced/6.1-api-automation.md
# API Automation Safety
This general chapter applies when a registration, DNS, hosting, or monitoring service exposes an API. Treat that service's current documentation as authoritative for endpoint paths, request formats, permissions, rate limits, and errors.
## Choose a Suitable Task
Good automation tasks are repeatable, observable, and reversible, such as:
- Reading a domain inventory
- Checking expiration dates
- Comparing configured nameservers with expected values
- Alerting on state changes
Registration, renewal, deletion, nameserver updates, purchases, and bulk mutations need stronger safeguards because a retry or wrong variable can create external effects.
## Create a Dedicated Key
- Use the narrowest scope available.
- Create one key per application and environment.
- Give the key a name that identifies its owner and purpose.
- Record a rotation and deletion date.
- Keep the secret outside source control.
## Load Secrets Safely
```bash
read -r -s DIGITALPLAT_API_TOKEN
export SERVICE_API_TOKEN
```
This avoids writing the token visibly while typing, but the environment and running process still need protection. A managed secret store is preferable for production automation.
## Build Read-Only First
Before enabling mutations:
1. Fetch a single known resource.
2. Validate response status and schema.
3. Add timeouts.
4. Handle pagination explicitly.
5. Redact authorization headers and personal data from logs.
6. Test rate-limit and server-error handling.
## Mutation Safety Pattern
For every external change:
```text
Read current state
-> Compare with desired state
-> Display exact change
-> Require approval when appropriate
-> Send one idempotent request
-> Read state again
-> Record the verified result
```
Do not retry an ambiguous registration, payment, renewal, or deletion response automatically. Read the authoritative state before deciding whether another request is safe.
## Example Skeleton
This example intentionally omits a real endpoint. Copy the current base URL and resource path from the Dashboard API documentation.
```bash
curl --fail-with-body \
--connect-timeout 10 \
--max-time 30 \
--header "Authorization: Bearer $SERVICE_API_TOKEN" \
--header "Accept: application/json" \
"https://api-address-from-current-documentation.example/resource"
```
Do not use verbose HTTP logging in production when it may print authorization headers.
## Monitor Automation
Alert on:
- Authentication failure
- Permission changes
- Rate limits
- Unexpected resource counts
- Domain status or nameserver changes
- Repeated retries
- Partial batch completion
Keep a manual recovery procedure that does not depend on the automation being healthy.
Continue to [Self-Hosted Authoritative DNS](./6.2-self-hosted-dns.md).
## /documents/tutorial/advanced/6.2-self-hosted-dns.md
# Self-Hosted Authoritative DNS
Running authoritative DNS gives direct control of zone data but also makes you responsible for availability, correctness, security, monitoring, updates, and incident response.
## Do Not Confuse Server Roles
An authoritative server publishes zones it controls. A recursive resolver performs lookups for clients. Do not expose an unrestricted recursive resolver to the public internet as part of an authoritative deployment.
## Minimum Design Questions
Before self-hosting, decide:
- How many authoritative servers will serve the zone
- Whether they are on independent networks and failure domains
- How zone data is replicated
- Who can edit zones and sign changes
- How updates are reviewed and rolled back
- How software and operating systems are patched
- How UDP and TCP DNS on port 53 are monitored
- How logs, configuration, and keys are backed up
- How an outage will be detected from outside the network
## Parent Delegation and Glue
The registration service delegates the domain to nameserver hostnames. If a nameserver hostname is inside the domain it serves, the parent may need glue address records to avoid a circular lookup.
Example circular dependency:
```text
Zone: example.dpdns.org
Nameserver: ns1.example.dpdns.org
```
Do not choose in-zone nameserver names unless the registration layer supports the required glue workflow and you understand how to maintain it.
## Zone Essentials
An authoritative zone normally includes:
- One SOA record
- The authoritative NS record set
- Address or alias records for services
- Mail and verification records when used
All authoritative servers must publish consistent data. Validate zone files before loading them and increment the SOA serial according to the DNS software's update model.
## Network Requirements
Authoritative DNS must answer both UDP and TCP on port 53. TCP is not an optional fallback to ignore; larger responses, transfers, and protocol behavior can require it.
Do not place all authoritative servers behind one machine, router, power supply, or network path and call that redundancy.
## Pre-Delegation Test
Before changing registration-level nameservers:
```bash
dig @192.0.2.53 SOA example.dpdns.org
dig @192.0.2.53 NS example.dpdns.org
dig @192.0.2.53 A www.example.dpdns.org
dig +tcp @192.0.2.53 SOA example.dpdns.org
```
The documentation address must be replaced with the real server address.
## Operational Standard
Do not delegate production domains until external monitoring can detect failures, a second authoritative server has been verified, backups have been restored in a test, and an operator other than the original builder can follow the recovery documentation.
Continue to [Command Reference](./6.3-command-reference.md).
## /documents/tutorial/advanced/6.3-command-reference.md
# Command Reference
Replace example names and documentation addresses before using these commands.
## Registration and Delegation
```bash
dig NS example.dpdns.org
dig +trace NS example.dpdns.org
dig SOA example.dpdns.org
```
## Direct Authoritative Queries
```bash
dig @ns1.dns-service.example SOA example.dpdns.org
dig @ns1.dns-service.example A example.dpdns.org
dig +tcp @ns1.dns-service.example SOA example.dpdns.org
```
## Website Records
```bash
dig A example.dpdns.org
dig AAAA example.dpdns.org
dig CNAME www.example.dpdns.org
dig CAA example.dpdns.org
```
## Email Records
```bash
dig MX example.dpdns.org
dig TXT example.dpdns.org
dig TXT selector1._domainkey.example.dpdns.org
dig TXT _dmarc.example.dpdns.org
```
## Short Answers
```bash
dig +short A example.dpdns.org
dig +short NS example.dpdns.org
```
Short output is convenient for scripts but removes useful flags, authority, and TTL context. Use normal output during diagnosis.
## HTTP and Redirects
```bash
curl -I http://example.dpdns.org
curl -I https://example.dpdns.org
curl -L -o /dev/null -s -w '%{http_code} %{url_effective}\n' http://www.example.dpdns.org
```
## Test a Virtual Host Before DNS
```bash
curl -I -H 'Host: example.dpdns.org' http://192.0.2.10
curl --resolve example.dpdns.org:443:192.0.2.10 -I https://example.dpdns.org
```
The HTTPS command validates the certificate for the hostname while connecting to the selected address.
## TLS Certificate
```bash
openssl s_client -connect example.dpdns.org:443 -servername example.dpdns.org </dev/null
```
Summarize certificate fields:
```bash
openssl s_client -connect example.dpdns.org:443 -servername example.dpdns.org </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
```
## Local Listening Ports
Linux:
```bash
sudo ss -lntup
```
macOS:
```bash
lsof -nP -iTCP -sTCP:LISTEN
```
## Web Server Checks
```bash
sudo nginx -t
systemctl status nginx --no-pager
journalctl -u nginx --since '30 minutes ago' --no-pager
```
## Connectivity
```bash
nc -vz example.dpdns.org 80
nc -vz example.dpdns.org 443
```
A successful TCP connection does not prove that HTTP, TLS, or the application is correct.
## Save Diagnostic Output
```bash
{
date -u
dig NS example.dpdns.org
dig A example.dpdns.org
curl -I --max-time 15 https://example.dpdns.org
} > domain-diagnostic.txt 2>&1
```
Review the file and remove personal data, internal hostnames, tokens, cookies, and unrelated output before sharing it.
Continue to [Website Architecture Patterns](./6.4-architecture-patterns.md).
## /documents/tutorial/advanced/6.4-architecture-patterns.md
# Website Architecture Patterns
Architecture is the set of components, responsibilities, data flows, and failure boundaries that deliver the website. Choose the simplest pattern that meets the real goal.
## Pattern 1: One Static Server
```text
DNS -> Nginx -> Static files
```
### Strengths
- Few components
- Easy to understand
- Small application attack surface
- Straightforward backup and rollback
### Limits
- One server is one failure boundary.
- Content changes require deployment.
- Dynamic features need another component.
This pattern is suitable for learning, documentation, portfolios, and small informational sites when the availability requirement permits it.
## Pattern 2: Reverse Proxy and Application
```text
DNS -> Nginx -> Application -> Database
```
### Strengths
- Supports accounts, forms, and dynamic data.
- Separates public TLS from the application listener.
- Can route static and dynamic paths differently.
### Limits
- More credentials and updates
- Database backup and migration requirements
- More failure modes
- Application security responsibility
## Pattern 3: Separate Static Frontend and API
```text
www.example.dpdns.org -> Static frontend
api.example.dpdns.org -> API -> Database
```
This can separate deployment lifecycles, but browser security, cross-origin policy, cookies, tokens, and API availability become explicit design concerns.
Do not expose a privileged API merely because the frontend is static.
## Pattern 4: Multiple Application Servers
```text
DNS -> Load balancer -> App A
-> App B
```
Multiple servers improve availability only when state, health checks, deployments, certificates, dependencies, and failover are designed accordingly.
Two application servers behind one unmonitored database and one load balancer are not complete redundancy.
## Stateful and Stateless Components
A stateless application can handle a request without relying on local session or uploaded data from a previous request. State may live in a database, object store, or shared cache.
Stateless design can make horizontal scaling easier, but the external state systems become critical dependencies.
## Failure Domains
Ask what happens if each component fails:
- Registration account unavailable
- Authoritative DNS unavailable
- One network unavailable
- Server lost
- Certificate renewal fails
- Database corrupts
- Deployment publishes broken files
- Monitoring provider fails
- Operator loses credentials
Components are not independent when they share the same account, network, physical host, billing method, or recovery email.
## Data Flow Diagram
For every dynamic site, draw:
```text
User data
-> Browser
-> Public proxy
-> Application
-> Database
-> Logs
-> Backups
```
Label:
- Encryption boundaries
- Authentication decisions
- Personal data
- Retention
- Third-party transfers
- Administrative access
## Choose with a Decision Record
Use a short architecture decision record:
```markdown
# Decision: Static site on one server
## Context
The site publishes documentation and has no accounts.
## Decision
Serve version-controlled static files with Nginx.
## Consequences
- Simple deployment and backup
- No server-side forms
- One-server availability boundary
## Revisit When
The site needs authenticated or database-backed features.
```
## Migration Without a Rewrite
Start simple but preserve boundaries:
- Keep domain and DNS ownership documented.
- Keep source in version control.
- Use stable public URLs.
- Separate content from secrets.
- Automate reproducible builds.
- Make backups independent of the server.
- Monitor user-visible outcomes.
These practices make a future architecture change safer without requiring premature complexity.
## Architecture Exercise
Draw the architecture for:
1. A personal static portfolio.
2. A community event site with a contact form.
3. An authenticated dashboard with uploads.
For each, identify the smallest design, sensitive data, backup scope, and single largest failure risk.
Continue to [Reliability and Capacity Planning](./6.5-reliability-and-capacity.md).
## /documents/tutorial/advanced/6.5-reliability-and-capacity.md
# Reliability and Capacity Planning
Reliability is the ability to deliver the intended service over time. Capacity is the amount of traffic, storage, and work the system can handle while meeting that goal.
## Define a Service Objective
Avoid saying only “the site should always work.” Define measurable outcomes:
```text
99.9% of homepage requests succeed each calendar month.
95% of successful responses begin within 800 milliseconds.
Certificate expiration is detected at least 21 days in advance.
Website restoration completes within four hours.
```
Choose targets appropriate to user impact and available operations. A target creates monitoring and staffing obligations.
## Availability Arithmetic
Approximate monthly downtime budgets:
| Availability | Downtime in a 30-day month |
| ---: | ---: |
| 99% | About 7 hours 12 minutes |
| 99.9% | About 43 minutes |
| 99.99% | About 4 minutes 19 seconds |
The calculation alone does not prove the user experience. Scheduled maintenance, measurement scope, partial failures, and dependency outages must be defined.
## Error Budgets
An error budget is the permitted unreliability implied by a service objective. It helps balance feature changes against stability work.
If the service has already consumed its monthly budget, reduce risky changes and focus on causes of failure instead of declaring the target met by changing the measurement.
## Estimate Capacity
For a static site, begin with:
```text
Requests per second
Average and peak response size
Concurrent connections
Network transfer
Disk space
Log growth
Backup size
```
For a dynamic site, also measure:
```text
Application latency
Database queries per request
Database connections
Queue depth
Cache hit rate
CPU and memory per process
External API limits
```
## Average Is Not Peak
A site averaging one request per second may receive hundreds after an announcement. Plan for realistic bursts and define how the system fails when limits are reached.
Prefer controlled degradation:
- Return a clear temporary response.
- Limit expensive endpoints.
- Queue work with bounded capacity.
- Preserve administrative access.
- Protect the database from unlimited concurrency.
## Load Testing Safety
Load test only systems you own or are explicitly authorized to test. Begin in a nonproduction environment with small request rates.
Define:
- Maximum request rate
- Duration
- Test source
- Abort threshold
- Expected server behavior
- Person monitoring the test
An uncontrolled test can become a denial-of-service event.
## Dependency Budgets
The website can be no more available than critical dependencies unless it can continue without them.
Classify each dependency:
- Required for every request
- Required only for a feature
- Required only during deployment
- Required only for administration
Cache or degrade optional features so one analytics, font, or external API failure does not blank the whole page.
## Change Risk
Reliability problems often arrive through changes rather than raw traffic.
Safer deployment controls include:
- Configuration validation
- Automated tests
- Small releases
- Health checks
- Observable rollout
- Fast rollback
- Database migration planning
- Change windows for high-risk work
## Capacity Review Worksheet
Record:
```text
Normal requests/second:
Peak requests/second:
Largest response:
Monthly transfer:
Current disk usage:
Daily log growth:
Backup duration:
Restore duration:
Database size:
Largest dependency risk:
Next capacity threshold:
```
## Reliability Exercise
For your first website:
1. Write one availability objective.
2. Define an external HTTP check.
3. Define a certificate-expiration alert.
4. Estimate a peak traffic event.
5. Identify the first likely resource limit.
6. Write a rollback for the next deployment.
Continue to [Part 7: Capstone Project](../capstone/index.md).
## /documents/tutorial/advanced/glossary.md
# Glossary
## A record
A DNS record that maps a name to an IPv4 address.
## AAAA record
A DNS record that maps a name to an IPv6 address.
## ACME
A protocol for automating certificate issuance, validation, and renewal.
## Authoritative nameserver
A DNS server that publishes official data for a zone.
## CAA
A DNS record that restricts certificate authority issuance for a name.
## CNAME
A DNS record that aliases one hostname to another canonical hostname.
## Delegation
The parent-zone records that identify the authoritative nameservers for a child zone.
## DKIM
An email authentication method that uses a domain-published public key to validate message signatures.
## DMARC
An email policy and reporting mechanism based on SPF or DKIM authentication alignment with the visible From domain.
## DNS
The distributed naming system that connects domain names to typed resource records.
## Domain
A name in the DNS hierarchy. In this book, it often means a registered name that has been delegated to external authoritative nameservers.
## Glue record
An address record supplied by a parent zone when it is needed to reach an in-zone nameserver.
## HTTP
The application protocol used to request and deliver web resources.
## HTTPS
HTTP carried over TLS, providing transport encryption and server authentication.
## MX record
A DNS record that identifies mail exchangers for a domain.
## Namespace
A managed naming area or suffix under which names may be registered.
## NS record
A DNS record that identifies an authoritative nameserver.
## Proxy
A system that receives traffic and forwards it to another service. It changes the network path and can affect logging, certificates, security, and policy.
## RDAP
A structured protocol for accessing registration data.
## Recursive resolver
A DNS server that follows referrals and caches answers for clients.
## Registrant
The person or organization that registers and is responsible for a domain.
## Registrar or registration service
The system through which a registrant creates and manages a domain registration.
## SOA record
The DNS record containing core authority and timing information for a zone.
## SPF
An email authorization policy describing which systems may send using a domain in the SMTP envelope.
## SRV record
A DNS record that identifies the hostname and port for a named service.
## Subdomain
A name below another domain, such as `www.example.dpdns.org`.
## TLS
The protocol that protects HTTPS and other network connections with encryption and authentication.
## TTL
Time to Live, the maximum caching lifetime advertised with a DNS record.
## TXT record
A DNS record containing text, commonly used for verification and email policy.
## Virtual host
A web server configuration that selects a site based on the requested hostname.
## WHOIS
A legacy registration data lookup protocol and a general term still used for domain registration information.
## Zone
The portion of the DNS namespace published as one administrative unit by authoritative nameservers.
Continue to [Standards and Further Reading](./references.md).
## /documents/tutorial/advanced/index.md
# Part 6: Advanced Reference
These chapters cover automation, authoritative DNS operation, repeatable diagnostics, terminology, and primary technical references.
## Chapters
1. [API Automation Safety](./6.1-api-automation.md)
2. [Self-Hosted Authoritative DNS](./6.2-self-hosted-dns.md)
3. [Command Reference](./6.3-command-reference.md)
4. [Website Architecture Patterns](./6.4-architecture-patterns.md)
5. [Reliability and Capacity Planning](./6.5-reliability-and-capacity.md)
6. [Glossary](./glossary.md)
7. [Standards and Further Reading](./references.md)
Advanced features increase operational responsibility. Build monitoring, rollback, access control, and documentation before adding automation or self-hosted infrastructure.
Continue to [API Automation Safety](./6.1-api-automation.md).
## /documents/tutorial/advanced/references.md
# Standards and Further Reading
The primary references below define the protocols and registration concepts summarized in this guide.
## DNS
- [RFC 1034: Domain Names — Concepts and Facilities](https://www.rfc-editor.org/rfc/rfc1034.html)
- [RFC 1035: Domain Names — Implementation and Specification](https://www.rfc-editor.org/rfc/rfc1035.html)
- [RFC 8499: DNS Terminology](https://www.rfc-editor.org/rfc/rfc8499.html)
## HTTP, TLS, and Certificates
- [RFC 9110: HTTP Semantics](https://www.rfc-editor.org/rfc/rfc9110.html)
- [RFC 8446: The Transport Layer Security Protocol Version 1.3](https://www.rfc-editor.org/rfc/rfc8446.html)
- [RFC 8555: Automatic Certificate Management Environment](https://www.rfc-editor.org/rfc/rfc8555.html)
## Email Authentication
- [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208.html)
- [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html)
- [RFC 7489: Domain-based Message Authentication, Reporting, and Conformance](https://www.rfc-editor.org/rfc/rfc7489.html)
## Registration Data
- [ICANN Information for Domain Name Registrants](https://www.icann.org/registrants)
- [ICANN Lookup FAQ](https://lookup.icann.org/en/faq)
## Using Standards
RFCs define protocol behavior, not a particular product interface. Use current registration and namespace policies for product-specific requirements, then use protocol standards to understand and verify the resulting DNS, HTTP, TLS, and email behavior.
## /documents/tutorial/appendices/answers.md
# Suggested Answers
These are reasoning guides, not the only acceptable wording.
## Category A
### A1
1. DigitalPlat
2. DigitalPlat
3. External DNS
4. External DNS
5. Web server
6. DigitalPlat
7. Web server
### A2
Enter `ns1.dns-service.example` and `ns2.dns-service.example`. The fields require authoritative nameserver hostnames. The server IP belongs in an external DNS address record, and the resolver IP belongs in client network configuration.
### A3
Stop before submission, return to the name and suffix review, read current pricing or slot information, and continue only after the intended final values are clear.
## Part 0
### B1
The registration layer delegates the domain. A recursive resolver follows delegation to the external authoritative server. DNS returns an address. The browser reaches the server over the network, negotiates transport and TLS, sends an HTTP request containing the hostname and path, and receives HTML.
### B2
`192.168.1.25` is a private IPv4 address. Routers on the public internet do not route it to the owner's private device. Public home hosting requires an intentional public reachability design.
### B3
- Does the Nginx configuration test succeed, and will reload affect production?
- Are both source and destination exact, and should remote-only files really be deleted?
- Is the current directory correct, and is the target backed up?
### B4
Good conditions include verified NS delegation, correct DNS answers, successful canonical HTTPS response, valid certificate names, working page links, successful restoration, and active monitoring.
## DNS
### C1
1. `A`
2. `CNAME`
3. `TXT`
4. `MX`
5. `AAAA`
### C2
The parent delegation still exposes the old nameserver. The registration change may not have been applied or cached delegation has not expired.
### C3
Investigate the external authoritative DNS zone. Delegation and zone authority work, but the requested ordinary record is missing or named incorrectly.
### C4
Resolvers that cached the old answer before the TTL reduction may retain it for the original 86400 seconds. Lowering the TTL does not rewrite existing caches.
### C5
A CNAME owner generally cannot also contain other data. Move verification to the name specified by the service or choose a non-CNAME design.
## Website
### D1
Use `<button type="submit">Submit</button>`. It participates in forms, exposes button semantics, and has native keyboard behavior.
### D2
All three resources should return successful status. HTML pages should return an HTML content type and the stylesheet a CSS content type.
### D3
The HTTP Host header and TLS server name identify the requested hostname. The web server selects the matching virtual host.
### D4
Check routing, listening port, firewalls, web server process, and virtual host configuration. Correct DNS proves only the address lookup.
### D5
DNS proves the hostname reached an address. The certificate failure proves the TLS endpoint is not presenting a certificate valid for that hostname.
### D6
Acceptable answers identify real findings and specific fixes, such as restoring visible focus, correcting heading order, or allowing layout reflow.
### D7
The answer should identify the largest measured phase, propose one cause, change one controlled variable, and repeat comparable measurements.
## Email
### E1
Preference 10 is normally attempted before 20 because lower MX preference values are preferred.
### E2
A name must not publish multiple independent SPF policies. Inventory all legitimate senders and construct one reviewed policy within protocol limits.
### E3
The public key is published in DNS. The private signing key remains protected in the sending mail system.
### E4
Monitoring identifies real senders and alignment failures before an enforcement policy rejects legitimate mail.
## Operations
### F1
It does not protect against disk failure, server deletion, ransomware with the same access, account compromise, physical loss, or many configuration mistakes.
### F2
Evidence includes archive integrity, successful extraction in isolation, correct files and permissions, a working local or test server, application checks, and measured restoration time.
### F3
Confirm independently, record timestamps, secure registration and recovery accounts, preserve current delegation and account evidence, contain unauthorized access, then restore approved nameservers and verify the user path.
### F4
An alert without an owner can be seen by everyone and acted on by no one. Assign a primary and backup responsible person.
### F5
Record the process owner, bind address, port and protocol, purpose, public-access requirement, and update responsibility. Any five that cover identity, exposure, purpose, and ownership are acceptable.
## Advanced
### G1
A static site may need DNS, a web server, files, TLS, and backups. An authenticated dashboard adds application processes, credentials, sessions, database state, migrations, authorization, personal data, and more monitoring.
### G2
Read current state, compare desired state, show the exact change, approve, send one request, read authoritative state again, and record the verified result. Do not retry ambiguity blindly.
### G3
Average traffic hides bursts. Observe concurrent connections, CPU, memory, network, application latency, database capacity, and external limits.
### G4
Both processes share one machine, power source, network path, operating system, and administrative failure boundary. A single failure removes both.
Return to [Troubleshooting Decision Trees](./troubleshooting-trees.md).
## /documents/tutorial/appendices/checklists-and-templates.md
# Checklists and Templates
Copy these into a private project notebook and adapt them. A checklist supports judgment; it does not replace understanding.
## Domain Registration Checklist
```markdown
- [ ] Current Dashboard notices read
- [ ] Exact label reviewed
- [ ] Exact suffix reviewed
- [ ] External DNS zone created
- [ ] Complete assigned nameserver set copied
- [ ] Applicable policies read
- [ ] Slot or charge reviewed
- [ ] Registration data accurate
- [ ] Final complete domain reviewed
- [ ] Result confirmed in Domain List
- [ ] Expiration date recorded
```
## External Nameserver Checklist
```markdown
- [ ] Zone spelling matches the registered domain
- [ ] All assigned NS hostnames recorded
- [ ] No server IP entered as an NS hostname
- [ ] Registration-level nameservers saved
- [ ] dig NS returns intended values
- [ ] Every external authoritative server answers SOA
- [ ] Ordinary DNS records are managed only in the external zone
```
## DNS Change Template
```markdown
# DNS Change
- Date and time in UTC:
- Operator:
- Domain and record name:
- Record type:
- Current value:
- Current TTL:
- Intended value:
- Reason:
- Authoritative verification command:
- Recursive verification command:
- Rollback value:
- Rollback decision time:
- Result:
```
## Website Deployment Checklist
```markdown
- [ ] Local tests pass
- [ ] Staged files reviewed
- [ ] Backup created and readable
- [ ] Destination path verified
- [ ] Private notes and secrets excluded
- [ ] Server configuration test passes
- [ ] Health check passes before DNS change
- [ ] Deployment revision recorded
- [ ] HTTP status verified
- [ ] HTTPS status verified
- [ ] Monitoring observes the new version
- [ ] Rollback window closed intentionally
```
## Certificate Checklist
```markdown
- [ ] DNS reaches intended server
- [ ] IPv4 tested
- [ ] IPv6 tested or absent
- [ ] Required validation path reachable
- [ ] Requested hostname list reviewed
- [ ] CAA compatibility reviewed when CAA is used
- [ ] Private key protected
- [ ] Certificate names verified
- [ ] Validity dates verified
- [ ] HTTP redirect tested
- [ ] Renewal dry run succeeds
- [ ] Independent expiration alert exists
```
## Monthly Operations Checklist
```markdown
- [ ] Domain expiration and renewal owner checked
- [ ] Delegated nameservers unchanged or approved
- [ ] Important DNS records unchanged or approved
- [ ] Website monitor healthy
- [ ] Certificate renewal healthy
- [ ] Backup jobs healthy
- [ ] Restoration drill current
- [ ] Disk space acceptable
- [ ] Security updates reviewed
- [ ] Listening ports reviewed
- [ ] Old accounts and API keys removed
- [ ] Abandoned DNS records removed after ownership review
- [ ] Runbook and contacts current
```
## Incident Timeline Template
```markdown
# Incident
## Summary
## User Impact
## Detection
## Timeline in UTC
- 00:00 - Event
## Evidence Preserved
## Containment
## Recovery
## Verification
## Root Cause
## Contributing Conditions
## Corrective Actions
| Action | Owner | Due date | Verification |
| --- | --- | --- | --- |
```
## Architecture Decision Template
```markdown
# Decision Title
## Status
Proposed / Accepted / Superseded
## Context
## Options Considered
## Decision
## Consequences
## Security and Privacy Impact
## Operational Impact
## Revisit When
```
## Service Inventory Template
```markdown
# Service Inventory
| Component | Account owner | Technical owner | Recovery owner | Renewal or update date |
| --- | --- | --- | --- | --- |
| Registration | | | | |
| External DNS | | | | |
| Web server | | | | |
| Certificate | | | | |
| Email | | | | |
| Monitoring | | | | |
| Backups | | | | |
```
## Handover Acceptance
```markdown
- [ ] Another authorized operator can find the expiration date
- [ ] Another operator can identify expected nameservers
- [ ] Deployment and rollback are documented
- [ ] Certificate renewal is documented
- [ ] Backup restoration has evidence
- [ ] Alerts have primary and backup owners
- [ ] Incident contacts are current
- [ ] Credentials are stored outside the runbook
```
## /documents/tutorial/appendices/index.md
# Appendices and Workbook
The appendices turn the textbook into a course that can be practiced, assessed, and operated repeatedly.
## Contents
1. [Workbook and Practice Exercises](./workbook.md)
2. [Suggested Answers](./answers.md)
3. [Troubleshooting Decision Trees](./troubleshooting-trees.md)
4. [Checklists and Templates](./checklists-and-templates.md)
Use the workbook before reading the suggested answers. Operational checklists should be copied into a private project notebook and adapted to the actual service.
## /documents/tutorial/appendices/troubleshooting-trees.md
# Troubleshooting Decision Trees
Use one tree at a time. Record observations before changing configuration.
## Domain Does Not Resolve
```text
Does Domain List show the expected active registration?
|-- No -> Fix registration status first.
`-- Yes
|
Does dig NS show the intended external nameservers?
|-- No -> Check registration-level NS values and cached delegation.
`-- Yes
|
Does each authoritative server answer SOA?
|-- No -> Fix the external DNS zone or service availability.
`-- Yes
|
Does the requested record exist on the authoritative server?
|-- No -> Add or correct it in the external DNS zone.
`-- Yes -> Compare recursive cache and TTL.
```
## DNS Resolves but Website Times Out
```text
Does the hostname return the intended address?
|-- No -> Fix external DNS.
`-- Yes
|
Is the server reachable on the network?
|-- No -> Check routing and server availability.
`-- Yes
|
Is port 80 or 443 listening?
|-- No -> Start or configure the web server.
`-- Yes
|
Do network and host firewalls allow the connection?
|-- No -> Apply the reviewed firewall rule.
`-- Yes -> Check virtual host, TLS, and application logs.
```
## Wrong Website Appears
```text
Does DNS return the intended server?
|-- No -> Correct the external DNS record.
`-- Yes
|
Does curl with the Host header return the intended virtual host?
|-- No -> Fix server_name or virtual-host ordering.
`-- Yes
|
Is a proxy or browser cache serving old content?
|-- Yes -> Inspect cache headers and purge only the correct cache.
`-- No -> Check deployment directory and current revision.
```
## HTTPS Fails
```text
Does HTTP reach the intended server?
|-- No -> Fix DNS, routing, firewall, or web server first.
`-- Yes
|
Is port 443 listening?
|-- No -> Configure the HTTPS virtual host.
`-- Yes
|
Does the certificate cover the requested hostname?
|-- No -> Issue or select the correct certificate.
`-- Yes
|
Is the certificate current and chain trusted?
|-- No -> Repair renewal or chain configuration.
`-- Yes -> Check redirect loops, application errors, and mixed content.
```
## `www` Works but Root Fails
```text
Does the root have the intended A or AAAA record in external DNS?
|-- No -> Create the required external DNS record.
`-- Yes
|
Does the web server accept the root hostname?
|-- No -> Add it to the virtual host.
`-- Yes
|
Does the certificate cover the root hostname?
|-- No -> Include it in certificate issuance.
`-- Yes -> Check canonical redirect configuration.
```
## Only Some Users Fail
```text
Do failing users receive a different DNS answer?
|-- Yes -> Compare TTL, resolver cache, IPv4, and IPv6.
`-- No
|
Do they use a different protocol path or network?
|-- Yes -> Test IPv6, proxy, firewall, and regional routing.
`-- No
|
Do they receive different HTTP cache or application content?
|-- Yes -> Inspect cache keys and headers.
`-- No -> Collect exact client error and timestamp.
```
## Email Does Not Arrive
```text
Does dig MX return the issued mail exchangers?
|-- No -> Fix MX records in external DNS.
`-- Yes
|
Do MX target hostnames resolve?
|-- No -> Fix mail-host address records.
`-- Yes
|
Does the mail system accept the recipient and domain?
|-- No -> Fix mail-system configuration.
`-- Yes -> Inspect delivery logs, rejection response, and spam handling.
```
## Deployment Fails
```text
Did configuration validation pass?
|-- No -> Do not reload; fix or restore configuration.
`-- Yes
|
Does the local application or static directory work?
|-- No -> Fix deployment files or application process.
`-- Yes
|
Does the public virtual host work?
|-- No -> Check proxy, permissions, firewall, and logs.
`-- Yes -> Verify DNS, TLS, and external monitoring.
```
## When to Roll Back
Prefer rollback when:
- User impact is significant.
- A known-good previous state exists.
- Diagnosis will take longer than the acceptable outage.
- The change is the likely cause.
- Rollback does not destroy required evidence or data.
Continue to [Checklists and Templates](./checklists-and-templates.md).
## /documents/tutorial/appendices/workbook.md
# Workbook and Practice Exercises
Write answers in a separate notebook. Use fictional values unless an exercise explicitly belongs to your authorized project.
## Progress Tracker
```markdown
- [ ] Category A: DigitalPlat FreeDomain Guide
- [ ] Part 0: Prepare to Learn
- [ ] Part 2: Learn DNS
- [ ] Part 3: Build and Publish a Website
- [ ] Part 4: Email and Service Records
- [ ] Part 5: Operate the Domain
- [ ] Part 6: Advanced Reference
- [ ] Part 7: Capstone Project
```
## Category A Exercises
### A1: Product boundary
Classify each task:
1. Register `example.dpdns.org`.
2. Submit external nameserver hostnames.
3. Create an `A` record.
4. Add an MX record.
5. Upload website files.
6. Renew the domain.
7. Redirect HTTP to HTTPS.
Use these categories: DigitalPlat, external DNS, web server.
### A2: Nameserver validation
Given:
```text
Assigned NS: ns1.dns-service.example
Assigned NS: ns2.dns-service.example
Server IP: 192.0.2.10
Resolver IP: 203.0.113.53
```
Which values belong in the DigitalPlat nameserver fields, and why?
### A3: Registration stop condition
The Dashboard shows a different suffix and an unexpected charge immediately before submission. Write the safe next action.
## Part 0 Exercises
### B1: Map a request
Draw the path from a browser entering `https://www.example.dpdns.org/about.html` to the HTML response. Label registration, recursive DNS, authoritative DNS, TCP or QUIC, TLS, HTTP, and the web server.
### B2: Public and private addresses
Explain why `192.168.1.25` normally should not be published as the public website `A` record.
### B3: Terminal safety
For each command, write the question you should answer before running it:
```bash
sudo systemctl reload nginx
rsync -av --delete ./site/ user@server:/var/www/site/
rm -r backups
```
### B4: Definition of done
Write five observable conditions that prove a website is ready. Avoid conditions such as “configuration looks correct.”
## DNS Exercises
### C1: Choose the record type
Select `A`, `AAAA`, `CNAME`, `MX`, or `TXT`:
1. Point the root hostname to an IPv4 address.
2. Alias `www` to the root hostname.
3. Publish a service-verification token.
4. Route inbound email.
5. Publish an IPv6 destination.
### C2: Diagnose delegation
The registration interface lists `ns1.new.example`, but `dig NS` returns `ns1.old.example`. Which layer has not changed for resolvers yet?
### C3: Diagnose an empty answer
`dig NS` works and the authoritative SOA query succeeds, but `dig A www.example.dpdns.org` returns an empty answer. Where should the next investigation occur?
### C4: TTL migration
A record has TTL 86400. An operator lowers it to 300 and changes the IP two minutes later. Explain why many users can still see the old IP for almost a day.
### C5: CNAME conflict
Explain why the following design is invalid or unsafe:
```text
www CNAME example.dpdns.org
www TXT verification=value
```
## Website Exercises
### D1: HTML semantics
Rewrite a clickable `<div>` used for form submission as an appropriate native element. Explain the keyboard and semantic benefit.
### D2: Local test
Run the static site on `127.0.0.1:8000`. Record the status and content type for Home, About, and CSS.
### D3: Virtual host
DNS points two domains to one IP. Explain how the web server decides which site to return.
### D4: Correct DNS, broken site
The `A` record returns the correct IP, but `curl` times out. List the next four layers or components to test.
### D5: HTTPS
HTTP works. HTTPS presents a certificate for another hostname. Identify what DNS proves and what the certificate failure proves.
### D6: Accessibility
Audit a page using only the keyboard, 200 percent zoom, and a narrow viewport. Record three findings and fixes.
### D7: Performance
Measure a page with `curl`. Identify whether DNS, connection, TLS, first-byte, or transfer time is the largest part. Write one hypothesis and one controlled experiment.
## Email Exercises
### E1: MX preference
Given MX preferences 10 and 20, which is normally attempted first?
### E2: SPF duplication
Two services each tell the user to add a separate `v=spf1` TXT record at the root. Explain the problem and the required planning step.
### E3: DKIM key roles
Which key belongs in DNS, and where must the other key remain?
### E4: DMARC rollout
Why is monitoring legitimate sending sources useful before enforcing rejection?
## Operations Exercises
### F1: Backup quality
A nightly job copies files into another directory on the same server. Identify at least three failures it does not protect against.
### F2: Restore evidence
List the evidence that proves a website backup can actually be restored.
### F3: Incident response
The nameservers change unexpectedly. Write the first five actions in order.
### F4: Renewal ownership
The calendar has an expiration reminder, but no person owns it. Explain why this is incomplete.
### F5: Server hardening
For every listening port, what five facts should be documented?
## Advanced Exercises
### G1: Architecture
Choose a static architecture for a documentation site and a dynamic architecture for an authenticated dashboard. List the additional state and failure boundaries in the dashboard.
### G2: API mutation
Write the safe state sequence around a nameserver-change API request.
### G3: Capacity
A site averages one request per second but receives 500 requests per second after a launch announcement. Explain why average capacity is insufficient and name three resources to observe.
### G4: Self-hosted DNS
Explain why two nameserver processes on the same machine do not provide meaningful infrastructure redundancy.
## Capstone Assessment
Demonstrate without notes:
1. Which product controls delegation.
2. Where ordinary DNS records are edited.
3. How to query parent delegation.
4. How to ask an authoritative server directly.
5. How to test a virtual host before DNS.
6. How to inspect a certificate's hostname and dates.
7. How to verify a backup restoration.
8. How to decide between continued investigation and rollback.
Continue to [Suggested Answers](./answers.md) only after completing the exercises.
## /documents/tutorial/capstone/7.1-project-brief.md
# Capstone: Project Brief and Architecture
The capstone website will publish a small project or organization profile with a home page and an About page.
## Learning Outcomes
You will demonstrate that you can:
- Translate a user goal into a small site scope.
- Separate registration, DNS, hosting, and HTTPS responsibilities.
- Plan ownership and recovery before opening accounts or servers.
- Define evidence for completion.
- Identify risks and rollback actions.
## Step 1: Write the Project Statement
Complete:
```text
The website helps [audience] learn [information] and take [action].
```
Example:
```text
The website helps local volunteers learn what the project does and find a monitored contact address.
```
## Step 2: Define the Pages
Home page:
- Project name
- One-sentence purpose
- Main call to action
- Link to About
About page:
- Project background
- What it provides
- Responsible contact method
- Link back to Home
Do not add login, payment, analytics, user uploads, or a database to the capstone. The goal is to master the complete infrastructure path before adding application risk.
## Step 3: Select Names
Use fictional planning values first:
```text
Registered domain: example.dpdns.org
Canonical site: https://example.dpdns.org/
Alias: https://www.example.dpdns.org/
Practice server: 192.0.2.10
```
The canonical name is the public identity. The alias will redirect to it.
When selecting the real domain, check:
- Spelling when read aloud
- Risk of impersonation or confusion
- Policy and trademark concerns
- Available suffix and current registration requirements
- Long-term usefulness
## Step 4: Assign Owners
Create `notes/ownership.md`:
```markdown
# Ownership
- Registration account owner:
- Recovery email owner:
- Renewal primary:
- Renewal backup:
- DNS operator:
- Server operator:
- Content owner:
- Security contact:
- Backup owner:
```
One person may fill several roles for a small project, but every role still needs an explicit name and recovery plan.
## Step 5: Draw the Architecture
```text
Visitor browser
|
| DNS query
v
Authoritative DNS service
|
| A / AAAA answer
v
Linux server
|
| TLS on 443
v
Nginx
|
v
/var/www/example.dpdns.org
|
+-- index.html
+-- about.html
+-- styles.css
```
Label the registration account outside the request path. It controls delegation but does not serve each page request.
## Step 6: Define Public Data
Public:
- Domain name
- Website content
- DNS records
- TLS certificate metadata
- Intended contact address
Private:
- Account password
- Recovery codes
- API keys
- SSH private key
- Certificate private key
- Full personal address unless publication is explicitly required and understood
- Server backup credentials
## Step 7: Define Completion Evidence
Create `notes/acceptance.md`:
```markdown
# Acceptance Evidence
- [ ] Domain appears active in Domain List
- [ ] Delegated NS records match the intended authoritative service
- [ ] Root A/AAAA records match the server
- [ ] www resolves intentionally
- [ ] HTTP redirects to canonical HTTPS
- [ ] HTTPS returns 200
- [ ] Certificate covers root and www
- [ ] Home and About links work
- [ ] Keyboard navigation works
- [ ] External monitor checks the canonical URL
- [ ] Renewal reminders exist
- [ ] Backup restoration is tested
```
## Step 8: Write the Rollback Plan
Before deployment:
```markdown
# Rollback
- DNS previous values:
- Old server availability period:
- Website backup location:
- Nginx configuration backup:
- Command to validate configuration:
- Command to restore files:
- Person authorized to decide rollback:
```
## Architecture Review
Do not continue until you can explain:
1. Which component registers the name.
2. Which component answers DNS queries.
3. Which component serves HTML.
4. Which component terminates HTTPS.
5. Which account loss would threaten domain control.
6. Which backup restores the website after server loss.
Continue to [Build and Test the Site](./7.2-build-and-test.md).
## /documents/tutorial/capstone/7.2-build-and-test.md
# Capstone: Build and Test the Site
Build the complete website locally before making a public DNS or server change.
## Step 1: Create the Project
```bash
mkdir -p capstone-site/assets capstone-site/notes
cd capstone-site
```
Create `.gitignore`:
```gitignore
.DS_Store
.env
*.log
notes/private-*
```
Initialize version control:
```bash
git init
git status
```
## Step 2: Create the Home Page
Create `index.html`:
```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="A short description of the project and its purpose.">
<title>Example Project</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<a class="skip-link" href="#content">Skip to content</a>
<header class="site-header">
<nav class="nav" aria-label="Primary navigation">
<a class="brand" href="index.html">Example Project</a>
<a href="about.html">About</a>
</nav>
</header>
<main id="content" class="page">
<p class="eyebrow">Open and useful</p>
<h1>A clear statement of what the project does.</h1>
<p class="lede">Explain who the project serves and why it exists in two short sentences.</p>
<a class="button" href="about.html">Learn about the project</a>
</main>
<footer class="site-footer">
<p>Contact: <a href="mailto:contact@example.dpdns.org">contact@example.dpdns.org</a></p>
</footer>
</body>
</html>
```
Replace the fictional contact address only when a monitored mailbox exists and publishing it is intentional.
## Step 3: Create the About Page
Create `about.html`:
```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="Background, purpose, and contact information for Example Project.">
<title>About | Example Project</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<a class="skip-link" href="#content">Skip to content</a>
<header class="site-header">
<nav class="nav" aria-label="Primary navigation">
<a class="brand" href="index.html">Example Project</a>
<a aria-current="page" href="about.html">About</a>
</nav>
</header>
<main id="content" class="page prose">
<h1>About the project</h1>
<p>Describe the problem that led to the project.</p>
<h2>What we provide</h2>
<p>Describe the useful information or service available here.</p>
<h2>Contact</h2>
<p>Explain how a visitor can reach the responsible team.</p>
</main>
<footer class="site-footer">
<p><a href="index.html">Return home</a></p>
</footer>
</body>
</html>
```
## Step 4: Create the Stylesheet
Create `styles.css`:
```css
*,
*::before,
*::after {
box-sizing: border-box;
}
:root {
color-scheme: light;
font-family: system-ui, sans-serif;
line-height: 1.6;
background: #f8fafc;
color: #0f172a;
}
body {
min-height: 100vh;
margin: 0;
}
a {
color: #075985;
}
a:focus-visible {
outline: 3px solid #0ea5e9;
outline-offset: 3px;
}
.skip-link {
position: absolute;
left: 1rem;
top: -5rem;
padding: 0.75rem 1rem;
background: #ffffff;
}
.skip-link:focus {
top: 1rem;
}
.site-header,
.site-footer {
border-block: 1px solid #cbd5e1;
background: #ffffff;
}
.nav,
.page,
.site-footer p {
width: min(68rem, calc(100% - 2rem));
margin-inline: auto;
}
.nav {
display: flex;
align-items: center;
justify-content: space-between;
min-height: 4rem;
}
.brand {
font-weight: 750;
text-decoration: none;
}
.page {
padding-block: clamp(4rem, 10vw, 8rem);
}
.page h1 {
max-width: 18ch;
font-size: clamp(2.25rem, 6vw, 4.75rem);
line-height: 1.05;
}
.eyebrow {
color: #0369a1;
font-weight: 700;
letter-spacing: 0.12em;
text-transform: uppercase;
}
.lede,
.prose {
max-width: 44rem;
}
.button {
display: inline-block;
margin-top: 1rem;
padding: 0.8rem 1rem;
border-radius: 0.5rem;
background: #075985;
color: #ffffff;
font-weight: 700;
text-decoration: none;
}
.site-footer {
padding-block: 1rem;
}
@media (prefers-reduced-motion: no-preference) {
a {
transition: color 150ms ease, background-color 150ms ease;
}
}
```
## Step 5: Run the Local Server
```bash
python3 -m http.server 8000 --bind 127.0.0.1
```
Open `http://127.0.0.1:8000/`.
## Step 6: Functional Tests
In another terminal:
```bash
curl -I http://127.0.0.1:8000/
curl -I http://127.0.0.1:8000/about.html
curl -I http://127.0.0.1:8000/styles.css
```
Expected:
- Both pages return `200`.
- The stylesheet returns `200` with a CSS content type.
- Home links to About.
- About links to Home.
## Step 7: Accessibility Tests
- Navigate with `Tab` and `Enter`.
- Confirm the skip link appears on focus.
- Confirm focus remains visible.
- Zoom to 200 percent.
- Test a narrow viewport.
- Confirm heading order.
- Confirm every link describes its destination.
## Step 8: Content and Privacy Review
Search the project:
```bash
rg -n -i 'password|token|secret|api[_-]?key|192\.168\.' .
```
Review every match. Confirm that the public contact data is intentional and no private notes are inside the site directory.
## Step 9: Save the Baseline
```bash
git add index.html about.html styles.css .gitignore
git diff --cached
git commit -m "Create capstone static site"
```
Only commit after reviewing the staged content.
## Gate Before Public Work
Do not continue until all local tests pass and the source can rebuild the site on another machine.
Continue to [Register, Deploy, and Connect](./7.3-register-and-deploy.md).
## /documents/tutorial/capstone/7.3-register-and-deploy.md
# Capstone: Register, Deploy, and Connect
This stage creates external state. Read every current policy, hostname, slot, charge, and nameserver value before submission.
## Step 1: Prepare the DNS Zone
In the authoritative DNS service, create a zone for the exact domain you intend to register. Record every assigned nameserver in the project notebook.
Verify that the service recognizes the zone before using the nameservers for registration.
## Step 2: Register the Domain
In the DigitalPlat Dashboard:
1. Read current notices.
2. Open **Register**.
3. Read the policies for the selected suffix.
4. Check the intended label.
5. Review availability, slot use, and any price.
6. Enter assigned authoritative nameservers when requested.
7. Verify the final complete domain.
8. Submit only when every value matches the plan.
Record the registration result and displayed expiration date. Do not copy private account data into public project documentation.
## Step 3: Verify Delegation
```bash
dig NS example.dpdns.org
dig +trace NS example.dpdns.org
```
Replace the fictional name. The delegated nameservers must match the intended service.
Ask an authoritative server directly:
```bash
dig @ns1.dns-service.example SOA example.dpdns.org
```
Do not proceed if the authoritative server does not publish the zone.
## Step 4: Prepare the Server
On the authorized Linux server:
```bash
sudo apt update
sudo apt upgrade
sudo apt install nginx
sudo mkdir -p /var/www/example.dpdns.org
sudo chown -R "$USER":"$USER" /var/www/example.dpdns.org
```
Confirm listeners and firewall intent:
```bash
sudo ss -lntp
```
## Step 5: Deploy Files
From the local project parent directory:
```bash
rsync -av ./capstone-site/ user@192.0.2.10:/var/www/example.dpdns.org/ \
--exclude '.git/' \
--exclude 'notes/' \
--exclude '.env'
```
Do not use `--delete` for the first deployment. Replace the server address and user.
On the server:
```bash
find /var/www/example.dpdns.org -maxdepth 2 -type f -print
```
Confirm that only intended public files were copied.
## Step 6: Configure Nginx
Create `/etc/nginx/sites-available/example.dpdns.org`:
```nginx
server {
listen 80;
listen [::]:80;
server_name example.dpdns.org www.example.dpdns.org;
root /var/www/example.dpdns.org;
index index.html;
location / {
try_files $uri $uri/ =404;
}
access_log /var/log/nginx/example.dpdns.org.access.log;
error_log /var/log/nginx/example.dpdns.org.error.log;
}
```
Enable and validate:
```bash
sudo ln -s /etc/nginx/sites-available/example.dpdns.org /etc/nginx/sites-enabled/example.dpdns.org
sudo nginx -t
sudo systemctl reload nginx
```
Never reload after a failed configuration test.
## Step 7: Test Before DNS
```bash
curl -I -H 'Host: example.dpdns.org' http://192.0.2.10
curl -I -H 'Host: www.example.dpdns.org' http://192.0.2.10
```
Both requests should reach the intended virtual host.
## Step 8: Add DNS Records
Open the external authoritative DNS service used in Step 1. Create the following records there, not in DigitalPlat.
Root IPv4:
```text
Name: @
Type: A
Value: real-server-ipv4
TTL: 3600
```
Root IPv6 only when tested:
```text
Name: @
Type: AAAA
Value: real-server-ipv6
TTL: 3600
```
`www` alias:
```text
Name: www
Type: CNAME
Value: example.dpdns.org
TTL: 3600
```
## Step 9: Verify Public HTTP
```bash
dig A example.dpdns.org
dig AAAA example.dpdns.org
dig CNAME www.example.dpdns.org
curl -I http://example.dpdns.org
curl -I http://www.example.dpdns.org
```
If IPv6 is published, test it independently. Remove an incorrect `AAAA` rather than leaving some visitors on an unreachable path.
## Step 10: Record the Change
Document:
- Domain and registration date
- Expiration date
- Nameservers
- DNS records and TTLs
- Server address
- Deployment revision
- Nginx test result
- HTTP verification result
- Rollback values
Continue to [Secure, Monitor, and Back Up](./7.4-secure-and-operate.md).
## /documents/tutorial/capstone/7.4-secure-and-operate.md
# Capstone: Secure, Monitor, and Back Up
The public HTTP site works. This stage turns it into an operable HTTPS service.
## Step 1: Issue a Certificate
Before issuance, confirm:
```bash
dig A example.dpdns.org
dig AAAA example.dpdns.org
dig A www.example.dpdns.org
curl -I http://example.dpdns.org
```
Use a maintained ACME client supported by the server environment. Request names only after both reach the intended server.
Do not copy private keys into notes or screenshots.
## Step 2: Verify HTTPS Directly
```bash
curl -I https://example.dpdns.org
curl -I https://www.example.dpdns.org
```
Inspect the certificate:
```bash
openssl s_client -connect example.dpdns.org:443 -servername example.dpdns.org </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
```
Expected:
- Current validity dates
- Root and `www` in the subject alternative names
- A chain trusted by the intended clients
## Step 3: Configure Canonical Redirects
Choose the root domain as canonical for this project.
HTTP redirect:
```nginx
server {
listen 80;
listen [::]:80;
server_name example.dpdns.org www.example.dpdns.org;
return 308 https://example.dpdns.org$request_uri;
}
```
Add an HTTPS redirect virtual host for `www` using the certificate configuration produced by the reviewed ACME workflow, then serve the content from the root hostname.
Validate and reload:
```bash
sudo nginx -t
sudo systemctl reload nginx
```
## Step 4: Verify the Redirect Path
```bash
curl -IL http://www.example.dpdns.org/about.html
```
The response should reach the canonical HTTPS URL without loops or unnecessary chains.
## Step 5: Test Certificate Renewal
Run the documented dry-run or test-renewal command for the installed ACME client. Verify the scheduled timer or task and review its latest status.
Create an independent expiration alert. The same client that fails renewal should not be the only system expected to report the failure.
## Step 6: Apply Server Baseline
- Confirm only required public ports are open.
- Confirm website files are not broadly writable.
- Confirm Nginx and the operating system are updated.
- Confirm SSH recovery access before tightening authentication.
- Confirm logs rotate.
- Confirm time synchronization.
- Remove default pages and unused services.
Re-run:
```bash
sudo ss -lntup
sudo nginx -t
```
## Step 7: Create a Website Backup
```bash
sudo tar -C /var/www -czf /tmp/example-site-backup.tar.gz example.dpdns.org
tar -tzf /tmp/example-site-backup.tar.gz | sed -n '1,80p'
```
Copy the verified archive to a protected system separate from the server. Back up the Nginx site configuration and the source repository as separate recovery inputs.
## Step 8: Restore in Isolation
On a safe test system or isolated directory:
```bash
mkdir restore-test
tar -xzf example-site-backup.tar.gz -C restore-test
find restore-test -maxdepth 3 -type f -print
```
Serve the restored files on `127.0.0.1` and verify Home, About, and CSS. Record the restore duration.
## Step 9: Create Monitors
At minimum:
- Domain expiration reminder
- Canonical HTTPS status and content check
- TLS expiration check
- Backup job result
- Server disk-space alert
- Unexpected nameserver or address change check
Every alert needs an owner and a first-response instruction.
## Step 10: Run a Failure Drill
Temporarily use a safe test environment to simulate one failure, such as a missing static file or stopped local test server. Confirm that:
- Monitoring detects it.
- The operator follows the runbook.
- Recovery restores the expected page.
- The incident is recorded.
Do not intentionally break public DNS or production certificates for a learning drill.
Continue to [Final Acceptance and Handover](./7.5-final-acceptance.md).
## /documents/tutorial/capstone/7.5-final-acceptance.md
# Capstone: Final Acceptance and Handover
Completion is a set of verified outcomes, not a feeling that the configuration looks correct.
## Registration Acceptance
- [ ] The exact domain appears in Domain List.
- [ ] The registration status is ready for use.
- [ ] The expiration date is recorded.
- [ ] Renewal reminders have named owners.
- [ ] Registrant and recovery data are current.
- [ ] Current namespace policies have been reviewed.
Evidence:
```text
Dashboard status and expiration date recorded in the private notebook
```
## DNS Acceptance
- [ ] Parent delegation matches the intended nameservers.
- [ ] Every authoritative server answers for the zone.
- [ ] Root `A` points to the intended server.
- [ ] Root `AAAA` is correct or intentionally absent.
- [ ] `www` resolves intentionally.
- [ ] No obsolete address or verification record remains.
Commands:
```bash
dig +trace NS example.dpdns.org
dig NS example.dpdns.org
dig @ns1.dns-service.example SOA example.dpdns.org
dig A example.dpdns.org
dig AAAA example.dpdns.org
dig CNAME www.example.dpdns.org
```
## HTTP and HTTPS Acceptance
- [ ] HTTP redirects to the canonical HTTPS URL.
- [ ] The redirect chain has no loop.
- [ ] The canonical page returns `200`.
- [ ] The About page returns `200`.
- [ ] The certificate is valid and covers every public name.
- [ ] Renewal was tested.
- [ ] No mixed HTTP content appears.
Commands:
```bash
curl -IL http://www.example.dpdns.org/
curl -I https://example.dpdns.org/
curl -I https://example.dpdns.org/about.html
```
## Content Acceptance
- [ ] The home page states the audience and purpose.
- [ ] The About page contains accurate information.
- [ ] Contact information is monitored and intentionally public.
- [ ] Navigation works with a keyboard.
- [ ] Focus is visible.
- [ ] Headings follow a logical order.
- [ ] The layout works on narrow and wide screens.
- [ ] No secret, private note, or local path is public.
## Operations Acceptance
- [ ] Account ownership and recovery are documented.
- [ ] DNS ownership is documented.
- [ ] Server access is assigned and recoverable.
- [ ] Required ports are known.
- [ ] Updates have an owner and schedule.
- [ ] Logs rotate and disk space is monitored.
- [ ] An external website check exists.
- [ ] Certificate expiration is monitored.
- [ ] A backup exists outside the server.
- [ ] A restoration drill succeeded.
- [ ] The rollback procedure was reviewed.
## Handover Runbook
Create a private runbook with:
```markdown
# Website Operations Runbook
## Service Purpose
## Public URLs
## Registration Owner
## DNS Owner
## Server Owner
## Renewal Procedure
## Deployment Procedure
## Rollback Procedure
## Certificate Renewal
## Backup and Restore
## Monitoring and Alerts
## Incident Contacts
## Known Risks
```
The runbook should tell an authorized operator where credentials are managed without copying the credentials into the document.
## Independent Operator Test
Ask another authorized person to use the runbook to answer:
1. When does the domain expire?
2. Which nameservers are expected?
3. How is the site deployed?
4. How is a failed deployment rolled back?
5. How is the certificate renewed?
6. Where is the latest backup?
7. How is restoration verified?
8. Who responds to an abuse or security report?
If the original builder must explain every answer, the handover is not complete.
## Final Practical Examination
Without copying commands blindly, demonstrate:
1. A trace of the nameserver delegation.
2. A direct query to an authoritative server.
3. Separate IPv4 and IPv6 reasoning.
4. The HTTP-to-HTTPS redirect.
5. Certificate hostname and date inspection.
6. A local restoration of the website files.
7. A rollback decision based on an unexpected result.
## Reflection
Write one paragraph for each question:
- Which layer was hardest to understand?
- Which verification prevented the largest possible mistake?
- Which part of the design is still a single failure boundary?
- What would change if the site accepted user accounts or payments?
- What maintenance action must happen next month?
## Completion
You have completed the capstone when every applicable item has evidence, not merely a checked box. Keep the runbook, inventory, change log, and recovery procedure current as the website evolves.
Continue to the [Workbook and Practice Exercises](../appendices/workbook.md).
## /documents/tutorial/capstone/index.md
# Part 7: Capstone Project
The capstone turns the book into one complete project: plan, register, build, deploy, secure, verify, and operate a small public website.
## Chapters
1. [Project Brief and Architecture](./7.1-project-brief.md)
2. [Build and Test the Site](./7.2-build-and-test.md)
3. [Register, Deploy, and Connect](./7.3-register-and-deploy.md)
4. [Secure, Monitor, and Back Up](./7.4-secure-and-operate.md)
5. [Final Acceptance and Handover](./7.5-final-acceptance.md)
## Final Deliverables
The project produces:
- A written architecture and ownership plan
- A registered domain with verified delegation
- A two-page accessible static website
- A tested server configuration
- Correct root and `www` DNS records
- A canonical HTTPS URL
- A renewal and certificate-monitoring plan
- A restorable backup
- A change log and operations runbook
Use fictional values until a step explicitly requires the real account, domain, or server. Registration, payment, renewal, deletion, and nameserver changes can create external effects; review the final values before submission.
Continue to [Project Brief and Architecture](./7.1-project-brief.md).
## /documents/tutorial/dns/2.0-delegation.md
# Delegation and External Nameservers
This is a general DNS chapter. It assumes the registration platform has already been given the external authoritative nameserver hostnames.
## Three Views of the Same Domain
### Registration view
Stores the intended authoritative nameserver hostnames.
### Parent DNS view
Publishes the delegation that resolvers actually follow.
### Child authoritative view
Publishes the zone's SOA, NS, and ordinary resource records.
All three must be consistent enough for resolution to work.
## Check the Delegation
```bash
dig NS example.dpdns.org
```
The returned nameservers should match the external DNS service's assigned set.
Trace the path:
```bash
dig +trace NS example.dpdns.org
```
The trace helps distinguish a parent delegation problem from a child-zone problem.
## Check the Child Zone Directly
```bash
dig @ns1.dns-service.example SOA example.dpdns.org
dig @ns1.dns-service.example NS example.dpdns.org
```
An authoritative server must publish the zone before waiting for caching can help.
## Delegation Failure Patterns
| Result | Likely layer |
| --- | --- |
| Parent points to old NS hostnames | Registration or parent delegation |
| NS hostnames are correct but time out | External authoritative service or network |
| One nameserver answers and another does not | External DNS synchronization or availability |
| SOA says the zone does not exist | Zone missing at external DNS service |
| NS works but A record is empty | Ordinary record missing from external DNS zone |
## Do Not Mix Fields
```text
Nameserver field: ns1.dns-service.example
A record value: 192.0.2.10
CNAME value: another-host.example
Resolver address: an IP configured on a client
```
Each belongs to a different context.
## Evidence Worksheet
Record:
```text
Expected external nameservers:
Observed delegated nameservers:
SOA answer from nameserver 1:
SOA answer from nameserver 2:
Time checked in UTC:
Next action:
```
Continue to [DNS Record Types](./2.1-record-types.md).
## /documents/tutorial/dns/2.1-record-types.md
# DNS Record Types
A DNS record has a name, type, value, and TTL. Some record types also include a priority or other parameters.
Create the records in the external authoritative DNS service that hosts the zone. A domain registration platform that only accepts nameserver hostnames is not the record editor.
## A Record
Maps a hostname to an IPv4 address.
```text
Name: @
Type: A
Value: 192.0.2.10
TTL: 3600
```
Use the actual public IPv4 address of the server. Do not use a private address such as `192.168.1.10` for a public website.
Verify:
```bash
dig A example.dpdns.org
```
## AAAA Record
Maps a hostname to an IPv6 address.
```text
Name: @
Type: AAAA
Value: 2001:db8::10
TTL: 3600
```
Only publish `AAAA` when the server is reachable over IPv6. A broken IPv6 path can make the site appear unreliable to clients that prefer IPv6.
Verify:
```bash
dig AAAA example.dpdns.org
```
## CNAME Record
Makes one hostname an alias of another hostname.
```text
Name: www
Type: CNAME
Value: example.dpdns.org
TTL: 3600
```
Do not point a `CNAME` to an IP address. A name with a `CNAME` generally must not also have other record types.
Verify:
```bash
dig CNAME www.example.dpdns.org
```
## MX Record
Routes email for a domain to a mail server.
```text
Name: @
Type: MX
Priority: 10
Value: mail.example.dpdns.org
TTL: 3600
```
Lower numbers have higher preference. The MX target must be a hostname with address records, not a `CNAME` or an IP address written directly in the MX value.
Verify:
```bash
dig MX example.dpdns.org
```
## TXT Record
Stores text used for ownership verification, email policy, and service configuration.
```text
Name: @
Type: TXT
Value: service-verification=replace-with-issued-value
TTL: 3600
```
Copy verification values exactly. Do not combine separate TXT records unless the service documentation specifically requires it.
Verify:
```bash
dig TXT example.dpdns.org
```
## CAA Record
Restricts which certificate authorities may issue certificates for a domain.
```text
Name: @
Type: CAA
Flag: 0
Tag: issue
Value: ca.example
TTL: 3600
```
An incorrect CAA record can prevent certificate issuance. Add it only after identifying the exact certificate authority used by your HTTPS setup.
Verify:
```bash
dig CAA example.dpdns.org
```
## NS and SOA Records
`NS` records identify authoritative nameservers. `SOA` describes zone authority and timing parameters. A hosted DNS service normally manages the zone-apex NS and SOA records.
Changing NS records only inside the child zone does not necessarily change the parent delegation. Nameserver changes for the registered domain must be made through its registration service.
## PTR Record
Maps an IP address back to a hostname. The IP network owner controls reverse DNS, so a normal forward DNS zone cannot set the public PTR record for a server address.
## Safe Record Checklist
Before saving a record, check:
- The name is relative to the intended zone.
- The value uses the correct format for the type.
- The TTL is appropriate for the planned change.
- No conflicting `CNAME` exists at the same name.
- Documentation IP addresses have been replaced with real server addresses.
- The record does not expose a secret. Verification tokens are intended to be public unless their issuer says otherwise.
## Next Step
Continue to [Root Domains and Subdomains](./2.2-subdomains.md).
## /documents/tutorial/dns/2.2-subdomains.md
# Root Domains and Subdomains
A single registered domain can organize many services without registering another domain.
## The Zone Apex
For `example.dpdns.org`, the zone apex is the registered name itself. DNS interfaces often represent it as one of these values:
```text
@
example.dpdns.org
blank name field
```
Follow the interface's own convention. Do not type the full domain into a field that automatically appends the zone, or you may create a name such as `example.dpdns.org.example.dpdns.org`.
## Common Subdomains
| Hostname | Typical purpose |
| --- | --- |
| `www.example.dpdns.org` | Public website |
| `api.example.dpdns.org` | Application API |
| `status.example.dpdns.org` | Status page |
| `mail.example.dpdns.org` | Mail server hostname |
| `dev.example.dpdns.org` | Development environment |
The purpose is only a naming convention. DNS does not know that `www` is a website or `mail` is a mail server.
## Root and `www`
A common website arrangement is:
```text
example.dpdns.org A 192.0.2.10
www.example.dpdns.org CNAME example.dpdns.org
```
The web server must still be configured to accept both hostnames. DNS alone does not create an HTTP redirect between them.
Choose one canonical public hostname and redirect the other at the web server. This keeps links and analytics consistent.
## Wildcard Records
A wildcard such as `*.example.dpdns.org` can answer for names that do not otherwise exist.
```text
Name: *
Type: A
Value: 192.0.2.10
```
Wildcards can hide typing mistakes and unintentionally route unknown names to a service. Prefer explicit records unless the application genuinely creates subdomains dynamically.
## Delegating a Subdomain
A subdomain can become its own DNS zone by adding NS records at the parent:
```text
Name: team
Type: NS
Value: ns1.team-dns.example
```
After delegation, the child nameservers control records below `team.example.dpdns.org`. Do not keep conflicting records for the delegated name in the parent zone.
## Naming Guidelines
- Use lowercase letters when documenting hostnames.
- Keep names short and descriptive.
- Avoid exposing internal project codenames.
- Do not encode credentials, customer data, or secrets in hostnames.
- Separate production and test services clearly.
## Verify Each Name
```bash
dig A example.dpdns.org
dig CNAME www.example.dpdns.org
dig NS team.example.dpdns.org
```
Continue to [TTL, Caching, and Propagation](./2.3-ttl-and-propagation.md).
## /documents/tutorial/dns/2.3-ttl-and-propagation.md
# TTL, Caching, and Propagation
DNS changes are not copied instantly to every device. Recursive resolvers cache answers for the record's TTL.
## How Caching Works
If a resolver receives this record:
```text
example.dpdns.org. 3600 IN A 192.0.2.10
```
it may reuse the answer for up to 3,600 seconds. Updating the authoritative record does not erase answers that were already cached.
Negative answers can also be cached. Creating a record immediately after someone queried a nonexistent name may still produce `NXDOMAIN` at some resolvers for a while.
## Choose a TTL
| Situation | Example TTL | Trade-off |
| --- | ---: | --- |
| Stable production record | 3600 to 86400 | Fewer queries, slower emergency changes |
| Planned migration | 300 to 600 | Faster transition, more DNS queries |
| Temporary test | 60 to 300 | Quick iteration, higher query volume |
These are operational examples, not universal requirements. A DNS service may enforce its own minimum or automatic TTL.
## Plan a DNS Migration
1. At least one old TTL period before the change, lower the TTL on records that will move.
2. Confirm the lower TTL is visible from the authoritative nameservers.
3. Make the address or target change.
4. Keep the old service available during the overlap.
5. Verify the new answer from authoritative and recursive resolvers.
6. Raise the TTL again after the migration is stable.
Lowering the TTL immediately before the main change does not affect copies already cached with the old, longer TTL.
## Separate Authoritative State from Cached State
Ask an authoritative server directly:
```bash
dig @ns1.dns-service.example A example.dpdns.org
```
Ask the resolver configured on your machine:
```bash
dig A example.dpdns.org
```
If the authoritative answer is new but the recursive answer is old, the zone is correct and a cache is still valid. Waiting is safer than repeatedly editing the record.
## Inspect TTL Values
```bash
dig A example.dpdns.org +noall +answer
```
The number before `IN` is the remaining TTL in seconds. It often decreases between queries when the answer is cached.
## Browser and Operating System Caches
Even after a resolver updates, an application or operating system may retain connection or DNS state. Test with command-line DNS tools first. Restarting a browser does not fix an incorrect authoritative record.
## Next Step
Continue to [DNS Troubleshooting](./2.4-troubleshooting.md).
## /documents/tutorial/dns/2.4-troubleshooting.md
# DNS Troubleshooting
Troubleshoot from delegation toward the final service. Do not change multiple layers at once.
## Step 1: Confirm the Exact Name and Type
```bash
dig A www.example.dpdns.org
```
Check for spelling mistakes, an unintended duplicated suffix, and the wrong record type.
## Step 2: Check Parent Delegation
```bash
dig +trace NS example.dpdns.org
```
The delegation should lead to the authoritative nameservers configured at the registration service.
## Step 3: Check Every Authoritative Server
```bash
dig @ns1.dns-service.example SOA example.dpdns.org
dig @ns2.dns-service.example SOA example.dpdns.org
```
All authoritative servers should answer for the zone. If they return different serials or values for too long, the DNS service may not have synchronized the zone.
## Step 4: Query the Record Directly
```bash
dig @ns1.dns-service.example A www.example.dpdns.org
```
If the direct answer is wrong, edit the authoritative zone. Waiting for propagation will not fix a wrong authoritative answer.
## Step 5: Compare Recursive Answers
Query the normal resolver and, if needed, a second resolver chosen by the user or network administrator. Different cached values can be normal during a TTL transition.
## Common Problems
### `NXDOMAIN`
- The hostname is misspelled.
- The record was created in the wrong zone.
- The DNS interface appended the zone twice.
- A negative answer is still cached.
### `SERVFAIL`
- Delegated nameservers do not answer.
- The zone is missing from an authoritative server.
- A network path or firewall is blocking DNS.
### Correct DNS, but the website does not open
DNS only locates the server. Check:
```bash
curl -I http://example.dpdns.org
curl -I https://example.dpdns.org
```
Then check the server process, firewall, virtual host, certificate, and application logs.
### Only some users see the new website
- Old DNS answers may still be cached.
- IPv4 and IPv6 may point to different servers.
- A proxy or application cache may hold old content.
- The client may be using a different hostname.
### `www` works but the root does not
Check the root `A` or `AAAA` record and the web server's accepted hostnames. A `www` CNAME does not automatically configure the root.
## Collect Evidence Before Asking for Help
Include:
- The exact hostname and record type
- `dig NS` output
- A direct authoritative query
- The expected and actual value
- The time of the change and previous TTL
- HTTP status from `curl -I`, when relevant
Remove tokens, cookies, account IDs, private addresses, and unrelated personal data before sharing logs or screenshots.
Continue to [Part 3: Build and Publish a Website](../website/index.md).
## /documents/tutorial/dns/index.md
# Part 2: Learn DNS
DNS records connect the domain to websites, email systems, verification services, and other network resources.
## Chapters
1. [Delegation and External Nameservers](./2.0-delegation.md)
2. [DNS Record Types](./2.1-record-types.md)
3. [Root Domains and Subdomains](./2.2-subdomains.md)
4. [TTL, Caching, and Propagation](./2.3-ttl-and-propagation.md)
5. [DNS Troubleshooting](./2.4-troubleshooting.md)
## Working Rule
Make one DNS change at a time, record the previous value, wait for the authoritative answer to update, and verify the result before changing another layer.
All record-editing examples in this category are performed at the external authoritative DNS service, not at the registration platform.
Continue to [Delegation and External Nameservers](./2.0-delegation.md).
## /documents/tutorial/email/4.1-email-dns.md
# Email DNS: MX, SPF, DKIM, and DMARC
Receiving and sending email are separate functions. MX records route incoming mail, while SPF, DKIM, and DMARC help receiving systems evaluate outgoing mail.
## MX: Route Incoming Mail
A mail system may provide records similar to:
```text
example.dpdns.org. 3600 MX 10 mx1.mail-system.example.
example.dpdns.org. 3600 MX 20 mx2.mail-system.example.
```
Lower preference numbers are tried first. Use every required record and do not replace the target hostname with an IP address.
Verify:
```bash
dig MX example.dpdns.org
```
## SPF: Authorize Sending Sources
SPF is published as a TXT record at the domain used for envelope sending.
```text
Name: @
Type: TXT
Value: v=spf1 include:_spf.mail-system.example -all
```
This value is only an illustration. Use the exact mechanisms required by every legitimate sender for the domain.
Important rules:
- Publish one SPF policy per name, not several separate `v=spf1` records.
- Combine authorized sources carefully.
- Understand the difference between `-all`, `~all`, `?all`, and `+all` before changing the final qualifier.
- Remove sources that no longer send mail.
- Keep the SPF DNS-lookup limit in mind when adding nested includes.
Verify:
```bash
dig TXT example.dpdns.org
```
## DKIM: Sign Outgoing Messages
DKIM publishes a public key under a selector chosen by the mail system:
```text
Name: selector1._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=public-key-material-issued-by-the-mail-system
```
The private key remains in the sending mail system. Never place the private key in DNS.
Verify:
```bash
dig TXT selector1._domainkey.example.dpdns.org
```
## DMARC: Define Alignment and Reporting Policy
DMARC is published at `_dmarc`:
```text
Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.dpdns.org
```
Begin with monitoring when you do not yet understand every legitimate sending source. Move toward quarantine or rejection only after reviewing authentication results and alignment.
Addresses in `rua` can receive large XML aggregate reports. Use a mailbox designed to process them and confirm that the destination accepts reports for the domain.
Verify:
```bash
dig TXT _dmarc.example.dpdns.org
```
## Authentication Alignment
DMARC evaluates whether the visible From domain aligns with a successful SPF or DKIM domain. A message can show SPF pass or DKIM pass and still fail DMARC if alignment is wrong.
## Safe Rollout
1. Inventory every system that sends mail for the domain.
2. Publish the required MX records for incoming mail.
3. Configure SPF for legitimate envelope senders.
4. Enable DKIM signing and verify the selector.
5. Publish a monitoring DMARC policy.
6. Review reports and message headers.
7. Tighten the policy only after legitimate mail consistently aligns.
## Troubleshooting Evidence
Collect the complete authentication results from a test message header, the exact DNS answers, and the selector used. Remove message bodies, recipients, internal IDs, and other personal data before sharing evidence.
Continue to [Verification and Service Records](./4.2-service-records.md).
## /documents/tutorial/email/4.2-service-records.md
# Verification and Service Records
External services often ask you to prove control of a domain by adding a DNS record.
Add verification and service records to the external authoritative DNS zone. Do not look for these record types in DigitalPlat.
## TXT Verification
Example format:
```text
Name: @
Type: TXT
Value: service-verification=issued-token
```
The token is normally intended to be publicly readable in DNS, but it should still be copied only to the exact name specified by the service.
Verify:
```bash
dig TXT example.dpdns.org
```
## CNAME Verification
Example format:
```text
Name: issued-label
Type: CNAME
Value: issued-target.service.example
```
Do not create other records at the same hostname as the CNAME.
Verify:
```bash
dig CNAME issued-label.example.dpdns.org
```
## SRV Records
Some network applications discover a service through an SRV record:
```text
Name: _service._tcp
Type: SRV
Priority: 10
Weight: 5
Port: 443
Target: host.example.dpdns.org
```
Priority selects preferred targets, weight distributes traffic among targets with the same priority, and port identifies the service port. The target must resolve to an address.
## Safe Verification Workflow
1. Confirm you are signed in to the intended external service account.
2. Read the exact record name, type, and value.
3. Check whether the DNS interface automatically appends your zone name.
4. Save the record.
5. Query the authoritative nameserver directly.
6. Ask the service to verify only after DNS returns the expected value.
7. Record whether the verification record must remain permanently.
## Remove Old Records Carefully
Verification records can outlive the account or integration that created them. Review the zone periodically, but do not delete an unfamiliar record until its owner and purpose are identified.
For each service record, document:
- Service owner
- Record purpose
- Creation date
- Whether it may be removed after verification
- Expected impact of removal
Never add a record received through an untrusted message without independently confirming it in the intended service's authenticated interface.
Continue to [Part 5: Operate the Domain](../operations/index.md).
## /documents/tutorial/email/index.md
# Part 4: Email and Service Records
Email uses DNS for routing, sender authorization, signatures, and policy. Incorrect records can reject legitimate mail or allow confusing authentication results.
All records in this part are created at the external authoritative DNS service that hosts the zone, not in DigitalPlat.
## Chapters
1. [Email DNS: MX, SPF, DKIM, and DMARC](./4.1-email-dns.md)
2. [Verification and Service Records](./4.2-service-records.md)
Do not copy sample mail records into a live zone. Use the exact values issued by the mail system you selected and evaluate that service independently.
Continue to [Email DNS](./4.1-email-dns.md).
## /documents/tutorial/foundations/0.1-how-to-use-this-book.md
# How to Use This Book
This book is both a course and an operational reference. The course path teaches one concept at a time; the reference sections help diagnose a real domain later.
## Who This Book Is For
You can begin with no previous experience in:
- Domain registration
- DNS administration
- HTML or CSS
- Linux servers
- TLS certificates
- Command-line tools
The only required skills are reading instructions carefully, keeping access to your account email, and stopping when a result differs from the expected result.
## The Learning Method
Each major topic follows the same cycle:
```text
Understand -> Plan -> Change -> Observe -> Verify -> Record -> Continue
```
### Understand
Learn what the component does and what it does not do. For example, DNS locates a server but does not upload a website.
### Plan
Write the intended value, current value, expected effect, and rollback before changing anything public.
### Change
Make one controlled change. Avoid editing DNS, server configuration, and certificates simultaneously.
### Observe
Read the interface response, command output, service log, or HTTP status.
### Verify
Use an independent check. A successful Save button is weaker evidence than a DNS query that returns the intended record.
### Record
Write what changed, when it changed, who changed it, and how it was verified.
## Three Types of Text
### Explanation
Explanations build a mental model. Read them even when you can copy the command without them.
### Procedure
Procedures are numbered actions. Complete them in order and compare your result with the described signal.
### Reference
Reference chapters contain commands, record formats, glossary definitions, and decision trees. You do not need to memorize them.
## Example Values
This book uses fictional values:
```text
Domain: example.dpdns.org
Web hostname: www.example.dpdns.org
IPv4: 192.0.2.10
IPv6: 2001:db8::10
Nameserver: ns1.dns-service.example
Server user: user
```
Documentation addresses and `.example` names are not production destinations. Replace them only when a procedure explicitly tells you to use your real value.
## Your Project Notebook
Create a private Markdown file outside the public website directory. Use this structure:
```markdown
# Website Project Notebook
## Goal
## Domain
## Account Owner
## Authoritative Nameservers
## DNS Records
## Server
## Renewal Date
## Changes
## Rollback Notes
```
Do not place passwords, API keys, recovery codes, cookies, or private certificate keys in the notebook.
## Stop Conditions
Stop and investigate when:
- The domain shown before submission is not the domain you intended.
- A charge, slot use, or policy differs from what you expected.
- A command requires administrator access without a clear reason.
- A DNS result points to an unfamiliar address.
- A certificate contains the wrong hostname.
- A deletion, payment, registration, or renewal result is ambiguous.
- Instructions from a page ask you to expose credentials or bypass security controls.
Stopping is part of the workflow, not a failure.
## Suggested Study Schedule
| Pace | Schedule |
| --- | --- |
| Weekend overview | Read concepts and complete local labs only |
| Two-week course | One part each two or three days |
| Four-week course | One or two chapters per day with exercises |
| Project-driven | Follow Parts 0–3, then return to reference chapters as needed |
## First Exercise
In your notebook, answer:
1. What do you want the website to accomplish?
2. Who is responsible for the domain renewal?
3. What information must never appear in public screenshots?
4. What will make you stop before a public change?
Continue to [How the Internet Moves Data](./0.2-internet-foundations.md).
## /documents/tutorial/foundations/0.2-internet-foundations.md
# How the Internet Moves Data
Domains are easier to understand when you can separate names, addresses, connections, and application requests.
## A Postal Analogy with Limits
A domain name resembles a contact name, an IP address resembles a routable address, a port resembles a department, and HTTP resembles the format of a request. The analogy is useful, but the internet is not one central postal system. Many independent networks exchange traffic using shared protocols.
## The Main Layers
```text
Application: HTTP, DNS, SMTP
Transport: TCP, UDP, QUIC
Network: IPv4, IPv6
Link: Ethernet, Wi-Fi, mobile network
```
You do not need to memorize a complete networking model. You do need to identify which layer is failing.
## IP Addresses
An IP address identifies a network interface or routing destination.
IPv4 example:
```text
192.0.2.10
```
IPv6 example:
```text
2001:db8::10
```
The examples are documentation addresses. Public websites require publicly routable addresses or an intentionally configured proxy or tunnel architecture.
### Public and private addresses
Common private IPv4 ranges include:
```text
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
```
A DNS record pointing public users to a private address normally cannot reach a home or office server across the internet.
## Ports
A server can provide multiple services at one address because each connection targets a port.
| Port | Common use |
| ---: | --- |
| 22 | SSH administration |
| 53 | DNS |
| 80 | HTTP |
| 443 | HTTPS |
A listening application, host firewall, network firewall, and upstream network policy can each affect whether a port is reachable.
## TCP and UDP
TCP provides an ordered connection and is commonly used by HTTP/1.1, HTTP/2, SSH, and DNS when needed. UDP carries independent datagrams and is commonly used for many DNS queries and QUIC-based HTTP/3.
DNS must not be described as UDP-only. Authoritative DNS needs correct TCP behavior as well.
## Clients and Servers
A client begins a request. A server listens and responds.
When you run:
```bash
curl https://example.dpdns.org
```
`curl` is the client. The machine accepting the HTTPS connection is the server. A reverse proxy may accept the public connection and then become a client of an application behind it.
## Routing and Latency
Routers forward packets between networks. The number of network steps and the quality of the path influence latency, but geographic distance is not the only factor.
Test reachability without assuming that an ICMP response proves the website works:
```bash
ping -c 4 192.0.2.10
```
Some networks block ping while permitting web traffic. Use protocol-specific checks for a final conclusion.
## Network Address Translation
Home routers often translate many private devices to one public address. Hosting a public service behind such a router may require port forwarding, stable addressing, firewall rules, and an internet connection that permits inbound traffic.
Carrier-grade NAT can prevent ordinary inbound forwarding even when the router shows an address. Confirm the actual network design before choosing home hosting.
## A Website Request, Layer by Layer
```text
User enters URL
-> DNS returns an address
-> Routing reaches the network
-> TCP or QUIC reaches a port
-> TLS authenticates and encrypts
-> HTTP requests a hostname and path
-> Web server returns content
```
## Guided Observation Lab
Run these commands against a public site you are permitted to query:
```bash
dig A example.com
curl -I https://example.com
```
Record:
- The returned IP address
- The HTTP status
- Whether a redirect occurred
- The final protocol shown by the client
Do not scan ports or test systems beyond ordinary public DNS and HTTP requests without authorization.
## Review Questions
1. Why can correct DNS still lead to a connection timeout?
2. Why does a public `A` record usually not point to `192.168.1.10`?
3. Which layer decides what `/about.html` means?
4. Why is port 443 not sufficient proof that a valid HTTPS site exists?
Continue to [Terminal and File Basics](./0.3-terminal-basics.md).
## /documents/tutorial/foundations/0.3-terminal-basics.md
# Terminal and File Basics
The terminal gives precise, repeatable evidence about DNS, files, network listeners, certificates, and HTTP responses.
## The Prompt and Working Directory
The shell waits at a prompt for a command. Check your current directory before creating, copying, or deleting files:
```bash
pwd
```
List files, including hidden files:
```bash
ls -la
```
Change directory:
```bash
cd my-first-site
```
Return to the parent directory:
```bash
cd ..
```
## Paths
An absolute path begins from the filesystem root:
```text
/var/www/example.dpdns.org/index.html
```
A relative path begins from the current directory:
```text
./index.html
```
Before running a command with `--delete`, `rm`, administrator privileges, or recursive behavior, resolve both source and destination paths.
## Create and Inspect Files
Create directories:
```bash
mkdir -p my-first-site/assets
```
Display a text file:
```bash
sed -n '1,120p' index.html
```
Search text recursively:
```bash
rg -n 'example.dpdns.org' .
```
Show file type:
```bash
file index.html
```
## Standard Output and Errors
Commands can write normal output and error output. A command that prints nothing is not automatically successful.
Check the previous exit status in a POSIX-like shell:
```bash
echo $?
```
Zero normally indicates success. Scripts should verify status rather than search only for reassuring words.
Redirect output to a file:
```bash
dig NS example.dpdns.org > ns-check.txt
```
Redirect normal and error output:
```bash
curl -I https://example.dpdns.org > http-check.txt 2>&1
```
Review the file before sharing it.
## Pipes
A pipe sends one command's output to another command:
```bash
dig A example.dpdns.org +short | sort -u
```
Pipelines can hide an earlier command failure unless the shell is configured to detect it. Use simple commands while learning and inspect the complete output during troubleshooting.
## Quoting
Single quotes preserve text literally in common shells:
```bash
curl -I -H 'Host: example.dpdns.org' http://192.0.2.10
```
Double quotes allow variable expansion:
```bash
domain='example.dpdns.org'
dig A "$domain"
```
Never paste a command containing an unfamiliar variable, substitution, redirection, or encoded payload without understanding it.
## Administrator Privileges
`sudo` runs a command with elevated privileges. Use it only for tasks that genuinely require system configuration, such as installing a package or changing a web server configuration.
Do not run an entire shell as root for convenience. Check a configuration before reloading a service.
## Processes and Listening Ports
On Linux:
```bash
ps aux
sudo ss -lntup
```
On macOS:
```bash
ps aux
lsof -nP -iTCP -sTCP:LISTEN
```
Identify the program, address, and port before deciding whether a service is reachable.
## Command History and Secrets
Shell history can retain commands. Avoid typing tokens and passwords directly in commands. Prefer a secret manager, protected prompt, or tool-specific credential store.
Do not include a secret in a URL. URLs may appear in history, logs, referrer data, and screenshots.
## Practice Lab
```bash
mkdir -p domain-book-lab/site
cd domain-book-lab
pwd
printf '%s\n' 'example.dpdns.org' > planned-domain.txt
sed -n '1,20p' planned-domain.txt
find . -maxdepth 2 -type f -print
```
Expected result: one `planned-domain.txt` file containing the fictional domain. Remove the lab only after confirming the path:
```bash
cd ..
rm -r domain-book-lab
```
## Review Questions
1. What command confirms your current directory?
2. Why should you inspect paths before `rsync --delete`?
3. What is the difference between output and exit status?
4. Why should an API token not appear directly in a shell command?
Continue to [Build a Safe Practice Environment](./0.4-practice-environment.md).
## /documents/tutorial/foundations/0.4-practice-environment.md
# Build a Safe Practice Environment
Learning is faster when experiments cannot damage a live domain or expose private data.
## Separate Four Environments
```text
Notebook -> Local files -> Local web server -> Public production server
```
Each step should work before the next one begins.
### Notebook
Contains plans, expected values, change records, and rollback notes. It stays private.
### Local files
Contains the website source. It can be version controlled and reviewed without running a server.
### Local web server
Serves the files on `127.0.0.1` so only the local machine can connect.
### Public production server
Receives internet traffic. It requires updates, a firewall, backups, monitoring, and incident ownership.
## Create the Workspace
```bash
mkdir -p domain-book-project/{site,notes,backups}
cd domain-book-project
```
Recommended layout:
```text
domain-book-project/
├── backups/
├── notes/
│ ├── changes.md
│ └── inventory.md
└── site/
├── assets/
└── index.html
```
The `backups` directory here is only a staging location. A real backup must also exist on another system or storage boundary.
## Initialize Version Control
```bash
git init
git status
```
Create `.gitignore`:
```gitignore
.DS_Store
.env
*.log
backups/
notes/private-*
```
Ignored files are not encrypted. Anyone with filesystem access may still read them.
## Use a Fictional Configuration First
Create `notes/inventory.md`:
```markdown
# Infrastructure Inventory
- Domain: example.dpdns.org
- IPv4: 192.0.2.10
- IPv6: 2001:db8::10
- Nameserver: ns1.dns-service.example
- Environment: practice only
```
This prevents accidental instructions from targeting a real system during early experiments.
## Define a Change Record
Create `notes/changes.md`:
```markdown
# Change Log
## Template
- Date and time:
- Operator:
- Goal:
- Current value:
- Intended value:
- Verification:
- Rollback:
- Result:
```
## Local Safety Checks
Before running a local server:
```bash
pwd
find site -maxdepth 2 -type f -print
```
Before publishing source:
```bash
git status --short
git diff --cached
rg -n -i 'password|secret|token|api[_-]?key' .
```
Search results are prompts for review, not proof that every matching line is a secret or that every secret was found.
## Use a Test Hostname
If you later need a public test, create an explicit subdomain such as `lab.example.dpdns.org`. Do not point the main public hostname at an unfinished environment.
Protect test environments. A hostname containing `test` is still publicly reachable when DNS and firewall rules expose it.
## Snapshot Before Risky Work
Before changing a server or zone:
- Export DNS records.
- Copy web server configuration.
- Record package versions.
- Back up website files and application data.
- Test that the backup can be read.
- Write the exact rollback commands.
## Exit Criteria
You are ready for Part 1 when:
- You have a private notebook.
- You can identify the current directory in a terminal.
- You know which files are public website files.
- You can distinguish fictional examples from real values.
- You have written at least one change record without making a public change.
Continue to [Plan Your First Website](./0.5-plan-your-site.md).
## /documents/tutorial/foundations/0.5-plan-your-site.md
# Plan Your First Website
A small written plan prevents domain, DNS, and server choices from becoming disconnected.
## Define the Audience and Goal
Complete this sentence:
```text
This website helps [audience] accomplish [specific result].
```
Examples:
- This website helps community members find event dates and contact information.
- This website helps users read project documentation and release notes.
- This website gives a small organization a stable public identity.
Avoid beginning with technology. A framework, server, or DNS record is not the user goal.
## Choose the First Version
For a first project, use a static website with:
- A home page
- An About page
- A contact method that does not expose unnecessary personal data
- Accessible navigation
- No database or user login
You can add application features after the domain, deployment, and HTTPS workflow is reliable.
## Choose Hostnames
Plan a canonical name and aliases:
```text
Canonical: example.dpdns.org
Alias: www.example.dpdns.org
Test: lab.example.dpdns.org
```
Decide whether visitors should see the root name or `www`. The web server will later redirect the other name.
## Assign Ownership
| Responsibility | Owner |
| --- | --- |
| Registration account | Named person or organization role |
| Renewal | Named operator and backup |
| DNS | Named operator |
| Server updates | Named operator |
| Website content | Named editor |
| Security reports | Monitored contact |
| Backups | Named operator |
Writing “the team” is not enough when no individual is accountable for the next action.
## Define Availability Needs
Ask:
- Is the site informational or operationally critical?
- How much downtime is acceptable?
- How quickly must content be restored?
- Is email tied to the same domain?
- Does the site collect personal data?
- Are there legal or contractual requirements?
The answers influence server redundancy, monitoring, backup frequency, and incident response.
## Draw the Initial Architecture
```text
Visitor
|
v
Recursive DNS
|
v
Authoritative DNS
|
v
Web server on ports 80 and 443
|
v
Static website files
```
Keep the first architecture understandable. Every added component creates another configuration, credential, failure mode, and renewal lifecycle.
## Write the Definition of Done
The first version is complete when:
- The domain is registered and active.
- Nameserver delegation is correct.
- Root and `www` DNS records resolve intentionally.
- HTTP redirects to one canonical HTTPS URL.
- The certificate is valid for every public hostname.
- The home and About pages work on desktop and mobile.
- A backup can restore the site.
- Expiration and certificate renewal are monitored.
- No secrets or private registration data are published.
## Risk Register
Create a small table:
| Risk | Likelihood | Impact | Mitigation |
| --- | --- | --- | --- |
| Account email lost | Medium | High | Protected recovery account and documented owner |
| DNS typo | Medium | High | Export, one change at a time, direct verification |
| Server update failure | Low | High | Backup and tested rollback |
| Certificate renewal failure | Medium | High | Renewal dry run and expiration alert |
## Planning Exercise
Write one page containing:
1. Audience and goal
2. First-version pages
3. Canonical hostname
4. Responsible owners
5. Definition of done
6. Three major risks
Continue to [Domain and DNS Fundamentals](./0.6-domain-and-dns.md).
## /documents/tutorial/foundations/0.6-domain-and-dns.md
# Domain and DNS Fundamentals
This chapter begins the general textbook. It applies to domains regardless of which registration service delegates them.
## The Main Systems
A working website normally uses four separate layers:
| Layer | Purpose |
| --- | --- |
| Registration | Gives a registrant control of a domain name |
| Authoritative DNS | Publishes records for that domain |
| Web hosting | Stores or runs website content |
| Certificate workflow | Creates and renews HTTPS certificates |
One company may offer several layers, but the technical responsibilities remain separate.
## Domain Name Structure
In this example:
```text
www.example.dpdns.org
```
the labels are:
```text
www -> example -> dpdns -> org -> DNS root
```
DNS reads the hierarchy from the root toward the most specific name even though humans normally write the most specific label first.
## Registered Domain and Zone Apex
In this book, `example.dpdns.org` is the registered name and the apex of the zone managed at the external DNS service.
DNS editors may represent the apex as:
```text
@
blank field
example.dpdns.org
```
Follow the external DNS editor's convention. Typing a full domain into a field that automatically appends the zone can create a duplicated name.
## Delegation
The registration layer delegates a child domain to authoritative nameservers using NS records in the parent hierarchy.
```text
Parent zone
|
| NS records
v
External authoritative nameservers
|
| zone records
v
Website and email destinations
```
Delegation identifies which servers are authoritative. It does not create the website address record.
## Authoritative Server and Recursive Resolver
An authoritative server publishes official data for zones it hosts.
A recursive resolver performs lookups for clients, follows delegation, and caches answers.
The DNS address configured on a laptop or router is usually a recursive resolver. It is not a nameserver hostname to submit during registration.
## Resource Records
Common record types include:
- `A` for IPv4
- `AAAA` for IPv6
- `CNAME` for aliases
- `MX` for mail routing
- `TXT` for verification and email policy
- `CAA` for certificate authority policy
- `SRV` for service discovery
- `NS` for authoritative nameservers
- `SOA` for zone authority information
These ordinary zone records are managed in the external authoritative DNS service used by the domain.
## TTL
Time to Live tells recursive resolvers how long an answer may remain cached. TTL is measured in seconds.
Changing an authoritative record does not erase already cached answers. This is why old and new values can coexist temporarily after a planned change.
## First DNS Observation
```bash
dig NS example.dpdns.org
dig SOA example.dpdns.org
```
Read:
- Answer type
- Returned hostname
- TTL
- Whether the query succeeded
The fictional domain may not return useful live data. Repeat the observation with a public domain you are permitted to query.
## Review Questions
1. What is the difference between registration and DNS hosting?
2. What does delegation select?
3. Why is a recursive resolver not entered as an authoritative NS value?
4. Where are ordinary DNS records managed?
5. What does a TTL affect?
Continue to [Part 2: Learn DNS](../dns/index.md).
## /documents/tutorial/foundations/index.md
# Category B, Part 0: Prepare to Learn
This part is for readers who have never managed a domain, used a terminal, or run a web server. It establishes the vocabulary and working habits used by every later chapter.
## Chapters
1. [How to Use This Book](./0.1-how-to-use-this-book.md)
2. [How the Internet Moves Data](./0.2-internet-foundations.md)
3. [Terminal and File Basics](./0.3-terminal-basics.md)
4. [Build a Safe Practice Environment](./0.4-practice-environment.md)
5. [Plan Your First Website](./0.5-plan-your-site.md)
6. [Domain and DNS Fundamentals](./0.6-domain-and-dns.md)
## Part Project
By the end of Part 0, you will have:
- A project notebook
- A safe example domain and IP convention
- A local project directory
- A working terminal checklist
- A one-page website plan
No public DNS, server, or account changes are required in this part. Product-specific DigitalPlat instructions remain in [Category A](../platform/index.md).
Continue to [How to Use This Book](./0.1-how-to-use-this-book.md).
## /documents/tutorial/index.md
# The FreeDomain Learning Guide
This book is organized into two clearly separated categories:
1. **DigitalPlat FreeDomain Guide** — product-specific account, registration, external nameserver delegation, status, renewal, and policy instructions.
2. **General Domain and Website Textbook** — internet foundations, external DNS records, web development, deployment, HTTPS, email, operations, and advanced engineering.
DigitalPlat delegates registered domains to external authoritative nameservers. It does not provide an ordinary DNS record editor. All `A`, `AAAA`, `CNAME`, `MX`, `TXT`, and other zone-record tutorials belong to the external DNS category.
Read the [Book Plan](./BOOK_PLAN.md) for scope and editorial rules.
## Category A: DigitalPlat FreeDomain Guide
1. [About the FreeDomain Project](./platform/project-overview.md)
2. [Dashboard Tour](./platform/dashboard-tour.md)
3. [What DigitalPlat Does](./platform/1.0-product-boundaries.md)
4. [Create a DigitalPlat Account](./platform/1.1-account-registration.md)
5. [Register a FreeDomain Name](./platform/1.2-domain-registration.md)
6. [Connect External Nameservers](./platform/1.3-connect-nameservers.md)
7. [Check Status and Renew](./platform/1.4-status-and-renewal.md)
8. [Manage Account Data and Policies](./platform/1.5-account-and-policies.md)
9. [Use the API Safely](./platform/1.6-api-overview.md)
[Category A overview](./platform/index.md)
## Category B: General Domain and Website Textbook
### Part 0: Prepare to Learn
1. [How to Use This Book](./foundations/0.1-how-to-use-this-book.md)
2. [How the Internet Moves Data](./foundations/0.2-internet-foundations.md)
3. [Terminal and File Basics](./foundations/0.3-terminal-basics.md)
4. [Build a Safe Practice Environment](./foundations/0.4-practice-environment.md)
5. [Plan Your First Website](./foundations/0.5-plan-your-site.md)
6. [Domain and DNS Fundamentals](./foundations/0.6-domain-and-dns.md)
[Part 0 overview](./foundations/index.md)
### Part 2: Learn External DNS
1. [Delegation and External Nameservers](./dns/2.0-delegation.md)
2. [DNS Record Types](./dns/2.1-record-types.md)
3. [Root Domains and Subdomains](./dns/2.2-subdomains.md)
4. [TTL, Caching, and Propagation](./dns/2.3-ttl-and-propagation.md)
5. [DNS Troubleshooting](./dns/2.4-troubleshooting.md)
[Part 2 overview](./dns/index.md)
### Part 3: Build and Publish a Website
1. [HTML and CSS Foundations](./website/3.0-html-css-foundations.md)
2. [How a Website Request Works](./website/3.1-how-websites-work.md)
3. [Build a Static Website](./website/3.2-build-static-site.md)
4. [Test the Website Locally](./website/3.3-test-locally.md)
5. [Prepare a Linux Web Server](./website/3.4-prepare-server.md)
6. [Deploy and Connect the Domain](./website/3.5-deploy-and-connect.md)
7. [Enable and Verify HTTPS](./website/3.6-https.md)
8. [Dynamic Applications and Reverse Proxies](./website/3.7-dynamic-applications.md)
9. [Accessibility and Search Basics](./website/3.8-accessibility-and-search.md)
10. [Performance and Caching](./website/3.9-performance-and-caching.md)
[Part 3 overview](./website/index.md)
### Part 4: Email and Service Records
1. [Email DNS: MX, SPF, DKIM, and DMARC](./email/4.1-email-dns.md)
2. [Verification and Service Records](./email/4.2-service-records.md)
[Part 4 overview](./email/index.md)
### Part 5: Operate and Protect the Domain
1. [Infrastructure Inventory and Change Management](./operations/5.1-domain-management.md)
2. [Renewal and Expiration](./operations/5.2-renewal-and-expiration.md)
3. [Migrate Nameservers Safely](./operations/5.3-migrate-nameservers.md)
4. [Registration Data and Privacy](./operations/5.4-registration-data.md)
5. [Account and API Security](./operations/5.5-security.md)
6. [Acceptable Use and Abuse Response](./operations/5.6-acceptable-use.md)
7. [Backups and Restoration](./operations/5.7-backups-and-restoration.md)
8. [Monitoring and Incident Response](./operations/5.8-monitoring-and-incidents.md)
9. [Server Hardening and Maintenance](./operations/5.9-server-hardening.md)
[Part 5 overview](./operations/index.md)
### Part 6: Advanced Architecture and Reference
1. [API Automation Safety](./advanced/6.1-api-automation.md)
2. [Self-Hosted Authoritative DNS](./advanced/6.2-self-hosted-dns.md)
3. [Command Reference](./advanced/6.3-command-reference.md)
4. [Website Architecture Patterns](./advanced/6.4-architecture-patterns.md)
5. [Reliability and Capacity Planning](./advanced/6.5-reliability-and-capacity.md)
6. [Glossary](./advanced/glossary.md)
7. [Standards and Further Reading](./advanced/references.md)
[Part 6 overview](./advanced/index.md)
## Part 7: Integrated Capstone Project
1. [Project Brief and Architecture](./capstone/7.1-project-brief.md)
2. [Build and Test the Site](./capstone/7.2-build-and-test.md)
3. [Register, Deploy, and Connect](./capstone/7.3-register-and-deploy.md)
4. [Secure, Monitor, and Back Up](./capstone/7.4-secure-and-operate.md)
5. [Final Acceptance and Handover](./capstone/7.5-final-acceptance.md)
[Part 7 overview](./capstone/index.md)
The capstone is the only integrated section: DigitalPlat handles registration and external NS delegation, the external DNS service handles zone records, and the web server handles HTTP and HTTPS.
## Appendices and Workbook
1. [Workbook and Practice Exercises](./appendices/workbook.md)
2. [Suggested Answers](./appendices/answers.md)
3. [Troubleshooting Decision Trees](./appendices/troubleshooting-trees.md)
4. [Checklists and Templates](./appendices/checklists-and-templates.md)
[Appendices overview](./appendices/index.md)
## Quick Paths
### I only need to connect a DigitalPlat domain to external DNS
1. [What DigitalPlat Does](./platform/1.0-product-boundaries.md)
2. [Connect External Nameservers](./platform/1.3-connect-nameservers.md)
3. [Delegation and External Nameservers](./dns/2.0-delegation.md)
### My delegated domain has no website record
1. [DNS Record Types](./dns/2.1-record-types.md)
2. [DNS Troubleshooting](./dns/2.4-troubleshooting.md)
3. [Troubleshooting Decision Trees](./appendices/troubleshooting-trees.md)
### I want to publish my first website
1. [Plan Your First Website](./foundations/0.5-plan-your-site.md)
2. [Build a Static Website](./website/3.2-build-static-site.md)
3. [Deploy and Connect the Domain](./website/3.5-deploy-and-connect.md)
4. [Enable and Verify HTTPS](./website/3.6-https.md)
### I want the complete course
Start with [Category A](./platform/index.md), continue through [Part 0](./foundations/index.md), and finish the [Capstone](./capstone/index.md) and [Workbook](./appendices/workbook.md).
## Safety Rules
- Replace fictional domains and documentation IP addresses before real deployment.
- Never publish passwords, tokens, private keys, cookies, recovery codes, or personal registration data.
- Read current product notices and policies before registration, renewal, payment, or account changes.
- Manage ordinary DNS records only in the external authoritative DNS service.
- Back up current values and define rollback before DNS, server, or nameserver changes.
- Evaluate third-party DNS, hosting, email, and certificate services independently.
## /documents/tutorial/operations/5.1-domain-management.md
# Infrastructure Inventory and Change Management
Reliable operation begins with a current inventory and a controlled change process. Registration, authoritative DNS, website hosting, email, and monitoring may be owned by different systems.
## Control Areas
Record where each responsibility is managed:
- Registration account for domain status, renewal, and delegated nameservers
- External authoritative DNS account for zone records
- Server or hosting account for the website
- Certificate automation on the server or hosting system
- Email system for mailboxes and sending configuration
- Monitoring system for public checks and alerts
Account interfaces and service capabilities can change. Keep the inventory based on current observed state rather than old screenshots.
## Domain Inventory
Maintain a private inventory with:
| Field | Purpose |
| --- | --- |
| Domain | Exact registered name |
| Project owner | Person responsible for content and renewal |
| Account owner | Person or organization controlling registration |
| Authoritative DNS | Nameserver hostnames and DNS account owner |
| Web host | Server or deployment owner |
| Renewal date | Calendar deadline and reminder dates |
| Certificate | Hostnames and renewal method |
| Email use | Whether the domain sends or receives mail |
| Recovery contact | Internal escalation contact |
Do not place passwords, session cookies, API secrets, or private certificate keys in the inventory.
## Before Any Change
1. Check registration notices and domain status.
2. Export or record existing DNS records.
3. Record current nameservers and TTL values.
4. Identify the owner of every affected service.
5. Define a rollback value and decision point.
## After Any Change
Verify:
```bash
dig NS example.dpdns.org
dig A example.dpdns.org
curl -I https://example.dpdns.org
```
Add mail and application-specific checks when those services are affected.
## Separate Roles Where Practical
For an organization, avoid making one personal account the undocumented owner of registration, DNS, hosting, certificates, and email. Record access ownership and recovery procedures so the domain survives staff changes and device loss.
Continue to [Renewal and Expiration](./5.2-renewal-and-expiration.md).
## /documents/tutorial/operations/5.2-renewal-and-expiration.md
# Renewal and Expiration
Expiration can interrupt DNS delegation, websites, email, certificates, and account recovery at the same time. Treat renewal as an operational process, not a last-day task.
## Use the Registration Service as the Source of Truth
Renewal windows, fees, grace behavior, limits, and namespace policies can change. Check the current domain detail page and notices for each domain.
Do not assume that a rule for one suffix applies to another.
## Create Reminders
Record the displayed expiration date and create several reminders, for example:
- 90 days before expiration
- 60 days before expiration
- 30 days before expiration
- 7 days before expiration
Choose dates that fall inside the current renewal window. Assign every reminder to a responsible person, not merely a shared calendar with no owner.
## Renewal Checklist
1. Sign in through the official registration interface.
2. Read current notices and policy changes.
3. Confirm the exact domain and account.
4. Confirm registrant contact information is current.
5. Review the displayed renewal outcome, slot usage, and any charge.
6. Complete the renewal.
7. Confirm the new expiration date in the domain list.
8. Save a non-sensitive record of the action.
## If Renewal Fails
Capture:
- Domain name
- Current status
- Expiration date
- Exact error message
- Time of the attempt
- Whether a slot or payment was required
Do not repeatedly submit payment or registration actions after an ambiguous result. First confirm whether the previous action succeeded.
## If a Domain Expires
Stop making unrelated DNS or server changes. Check the registration status and current recovery instructions. A technically correct DNS zone cannot restore a parent delegation that has been removed due to expiration.
## Offboarding a Domain
Before intentionally allowing a domain to expire:
- Remove sensitive services and stale DNS records.
- Migrate email addresses and recovery accounts.
- Redirect users when policy and time permit.
- Revoke certificates and API credentials tied to the name when appropriate.
- Notify project owners.
- Archive the final DNS and service inventory.
An abandoned domain can later be registered by someone else, so remove it from login recovery, OAuth callbacks, package metadata, documentation, and trusted allowlists.
Continue to [Migrate Nameservers Safely](./5.3-migrate-nameservers.md).
## /documents/tutorial/operations/5.3-migrate-nameservers.md
# Migrate Nameservers Safely
A nameserver migration changes the authoritative source for the entire zone. Missing one record can interrupt a service even when the website still works.
## Inventory the Old Zone
Collect every record and identify its owner:
- `A` and `AAAA`
- `CNAME`
- `MX`
- `TXT`, including SPF and verification records
- DKIM selectors
- DMARC policy
- `CAA`
- `SRV`
- Delegated subdomain `NS` records
An `ANY` query is not a reliable zone export. Use the old DNS service's supported export or management interface.
## Build the New Zone First
1. Create the new zone without changing the registration-level nameservers.
2. Copy records and TTL values.
3. Check automatically generated SOA and NS records.
4. Query each new authoritative server directly.
Example:
```bash
dig @new-ns1.dns-service.example A example.dpdns.org
dig @new-ns1.dns-service.example MX example.dpdns.org
dig @new-ns1.dns-service.example TXT _dmarc.example.dpdns.org
```
## Change the Delegation
In the domain registration interface, replace the old authoritative nameservers with the complete new set. Review spelling before saving.
## Keep Both Services Running
Old delegation answers can remain cached. Keep the old zone online and consistent during the transition. Do not delete it immediately after the Dashboard shows new nameservers.
## Verify
```bash
dig +trace NS example.dpdns.org
dig NS example.dpdns.org
dig A example.dpdns.org
dig MX example.dpdns.org
curl -I https://example.dpdns.org
```
Test website, email, API, certificate renewal, and important subdomains.
## Rollback
If the new authoritative service is incomplete or unavailable, restore the previous nameservers at the registration service and keep both zones intact until the delegation stabilizes.
Continue to [Registration Data and Privacy](./5.4-registration-data.md).
## /documents/tutorial/operations/5.4-registration-data.md
# Registration Data and Privacy
Registration data identifies the person or organization responsible for a domain. Required fields and public visibility depend on the namespace, registry policy, and privacy controls.
## Keep Data Accurate
Use the registration account's contact-data area to review:
- Registrant name or organization
- Email address
- Phone number
- Postal address
- Billing address when applicable
Do not enter fictional data to avoid visibility. Inaccurate data can break recovery, notices, renewal, or policy compliance.
## Understand Lookup Systems
Registration data may be available through WHOIS, RDAP, or a namespace-specific lookup system. Some fields may be redacted while operational data such as nameservers, registration dates, or status remains public.
The current registration interface and namespace policies determine which controls are available.
## Privacy Practices
- Use an organization-controlled contact address for organizational domains.
- Use a monitored role email address when policy permits.
- Keep recovery access separate from a single employee's device.
- Do not publish Dashboard screenshots containing full contact data.
- Review privacy settings after account updates.
- Assume DNS record values are public.
## Change Management
After updating registration data:
1. Confirm the Dashboard shows the intended value.
2. Verify that important notices reach the new email address.
3. Review public registration data where applicable.
4. Record the change date and responsible owner.
## Staff or Organization Changes
Before a responsible person leaves:
- Move the domain to an organization-controlled account if supported and appropriate.
- Update contact and recovery addresses.
- Rotate passwords and API keys.
- Revoke old sessions and device access.
- Transfer internal documentation and renewal ownership.
Continue to [Account and API Security](./5.5-security.md).
## /documents/tutorial/operations/5.5-security.md
# Account and API Security
Control of the registration account can redirect every service under the domain. Protect it as production infrastructure.
## Account Controls
- Use a unique password generated and stored by a password manager.
- Enable the strongest multi-factor authentication available in the current Dashboard.
- Protect the email account used for recovery with separate multi-factor authentication.
- Review active sessions and connected accounts when those controls are available.
- Sign in only through the official Dashboard address.
- Treat urgent domain-expiration or suspension messages as untrusted until verified in the Dashboard.
## Recovery Plan
Document:
- Account owner
- Recovery email owner
- Approved administrators
- Where recovery codes are stored
- Renewal responsibility
- Incident contact
Do not store recovery codes in the same unencrypted file as the password.
## API Keys
Create an API key only for a defined automation task.
- Prefer the smallest available scope.
- Use a separate key for each application or environment.
- Store keys in a secret manager or protected environment variable.
- Never put keys in URLs, screenshots, issue reports, frontend JavaScript, or Git commits.
- Rotate a key after staff changes, suspected exposure, or unexplained activity.
- Delete unused keys.
Example shell pattern:
```bash
export REGISTRATION_API_TOKEN='load-this-from-a-secret-store'
```
Do not place the real value directly in shell history or a committed script.
## Check a Repository for Accidental Secrets
Before publishing code:
```bash
git status --short
git diff --cached
git grep -n -i 'api[_-]*key\|token\|secret\|password'
```
These checks can miss encoded or unusual secrets. Use a dedicated secret scanner in the development workflow and review its findings.
If a secret is committed, removing the visible line is not enough. Revoke or rotate the credential immediately, then handle repository history according to the project's incident procedure.
## Nameserver Change Alerts
Where monitoring is available, alert on:
- Nameserver changes
- Unexpected address changes
- Certificate issuance
- Domain expiration approaching
- New API keys or login events
- Website content or TLS failures
Continue to [Acceptable Use and Abuse Response](./5.6-acceptable-use.md).
## /documents/tutorial/operations/5.6-acceptable-use.md
# Acceptable Use and Abuse Response
The registrant is responsible for understanding the current policies that apply to the account, namespace, domain, and hosted content.
## Before Publishing
Review the current:
- Terms of Service
- Acceptable Use Policy
- Privacy Policy
- Namespace-specific rules
- Hosting and DNS service terms
- Laws applicable to the project and its users
This guide does not replace those documents or legal advice.
## Common High-Risk Uses
Do not use a domain for phishing, malware, credential theft, spam, impersonation, unauthorized proxying, deceptive redirects, illegal content, or activity that violates current policy.
Protect forms, file uploads, redirects, user-generated content, and abandoned subdomains. A legitimate project can still be abused through an unpatched application or forgotten DNS record.
## Monitor for Abuse
- Review web and authentication logs.
- Patch public applications and dependencies.
- Remove unused DNS records and services.
- Scan for exposed secrets.
- Monitor certificates and DNS changes.
- Provide a working security or abuse contact.
- Rate-limit sensitive endpoints where appropriate.
## Respond to a Report
1. Preserve the report and relevant timestamps.
2. Confirm the affected hostname and content.
3. Contain active harm without destroying evidence.
4. Rotate compromised credentials.
5. Remove malicious content or configuration.
6. Patch the root cause.
7. Reply through the official reporting channel with concise facts.
8. Document the incident and preventive action.
Do not publish complainant data, access tokens, full logs, or unrelated user information.
## If a Domain Is Suspended
Read the current status and official notice first. Gather evidence of ownership, remediation, and current configuration. Use the official appeal or support channel and avoid creating duplicate requests that obscure the timeline.
## Responsible Shutdown
When ending a project, remove user data, disable vulnerable applications, revoke credentials, archive necessary records securely, update public documentation, and follow the domain offboarding checklist before allowing registration to expire.
Continue to [Backups and Restoration](./5.7-backups-and-restoration.md).
## /documents/tutorial/operations/5.7-backups-and-restoration.md
# Backups and Restoration
A backup is useful only when it contains the required data, survives the original failure, and can be restored within the project's recovery goal.
## Define What Must Be Rebuilt
Inventory each layer:
| Layer | Backup or reconstruction source |
| --- | --- |
| Domain registration | Account ownership and renewal records |
| DNS | Zone export and nameserver inventory |
| Website source | Version control repository |
| Built website | Reproducible build or artifact archive |
| Web server | Reviewed configuration backup |
| Certificates | Normally reissued; protect private keys if backed up |
| Application data | Database-aware backup |
| Uploaded files | File backup with ownership and metadata |
| Secrets | Secret manager and recovery process |
| Operations | Runbooks, contacts, and monitoring configuration |
Do not assume a server snapshot replaces application-consistent database backups or independent source control.
## Recovery Objectives
### Recovery Point Objective
The maximum acceptable amount of recent data loss. A daily backup implies that almost a day of changes could be lost.
### Recovery Time Objective
The target time to restore service. A backup on slow offline media may satisfy retention but not a short recovery time.
Write both objectives before selecting backup frequency and storage.
## The 3-2-1 Pattern
A common baseline is:
- Three copies of important data
- On two different storage types or systems
- With one copy separated from the primary environment
The exact architecture depends on risk, but a copy in another directory on the same server is not protection from server loss.
## Back Up a Static Site
Source control is the primary history for text files, but create a deployable archive when the build depends on tools or generated assets:
```bash
tar -C /var/www -czf example-site-$(date -u +%Y%m%dT%H%M%SZ).tar.gz example.dpdns.org
```
Check the archive without extracting over production:
```bash
tar -tzf example-site-20260716T120000Z.tar.gz | sed -n '1,80p'
```
Use the actual generated filename. Store the archive on a separate protected system.
## Back Up Configuration
Important configuration may include:
```text
/etc/nginx/
/etc/systemd/system/
/etc/ssh/
firewall rules
scheduled tasks
application environment definitions
```
Configuration backups can contain internal paths, hostnames, usernames, and secrets. Encrypt and restrict them appropriately.
## Database-Aware Backups
Copying live database files can produce an inconsistent backup. Use the database's supported dump, snapshot, or replication procedure and record the server version required for restoration.
Test:
- Schema restoration
- Data row counts or checksums where appropriate
- Required extensions
- User and permission reconstruction
- Application migration compatibility
## Encrypt and Protect Backups
Backups often contain more sensitive data than production views because they combine historical records.
- Encrypt in transit and at rest.
- Limit operators and service accounts.
- Separate backup deletion permission from normal application permission when possible.
- Monitor backup failures and unexpected deletion.
- Define retention and secure disposal.
Do not place the only decryption key inside the system being backed up.
## Restoration Drill
At a scheduled interval:
1. Select a known backup.
2. Create an isolated restore environment.
3. Verify archive integrity.
4. Restore configuration and data without overwriting production.
5. Start the service on a private address or alternate port.
6. Run HTTP and application checks.
7. Measure restoration time.
8. Record missing steps and update the runbook.
9. Destroy the isolated copy securely when finished.
A successful drill is stronger evidence than a green backup job.
## DNS and Domain Recovery Packet
Keep a protected, current record of:
- Registration account owner
- Recovery contact
- Domain expiration date
- Authoritative nameservers
- Exported DNS zone
- Web server addresses
- Certificate hostnames
- Mail providers and DKIM selectors
- Incident contacts
Do not include raw passwords or API tokens in a printable recovery packet.
## Backup Failure Exercise
Assume the production server is permanently lost. Write the exact sequence required to:
1. Obtain a replacement server.
2. Restore website files.
3. Restore web server configuration.
4. Reissue HTTPS certificates.
5. Change DNS safely.
6. Validate the website.
7. Communicate the incident.
Any step that depends on memory or the missing server is a documentation gap.
Continue to [Monitoring and Incident Response](./5.8-monitoring-and-incidents.md).
## /documents/tutorial/operations/5.8-monitoring-and-incidents.md
# Monitoring and Incident Response
Monitoring answers whether the system is behaving as expected. Incident response defines what to do when it is not.
## Monitor the User Path
The most useful external check follows the public path:
```text
DNS resolves
-> TCP connects
-> TLS validates
-> HTTP returns expected status
-> Page contains expected identity
```
A process can be running while users still see an expired certificate, wrong DNS address, or error page.
## Essential Checks
### Domain expiration
Alert well before the current renewal window closes. Assign the alert to a responsible owner and a backup.
### Nameserver delegation
Compare current parent delegation with the approved nameserver set.
### DNS records
Monitor important `A`, `AAAA`, `CNAME`, `MX`, and policy records for unexpected changes.
### TLS certificate
Alert on expiration, hostname mismatch, invalid chain, and unexpected issuer when the project maintains an issuer expectation.
### HTTP
Check the canonical HTTPS URL, expected status, redirect path, response time, and a small content marker.
### Server health
Monitor disk space, memory pressure, CPU saturation, process restarts, time synchronization, backup results, and security updates.
## Avoid Noisy Alerts
An alert that fires constantly without action trains operators to ignore it.
Every alert should answer:
- What user impact does this indicate?
- Who receives it?
- How urgent is it?
- What first diagnostic should be run?
- When should it escalate?
- How is recovery verified?
## Establish a Baseline
Record normal values:
- Typical HTTP latency
- Normal response size
- Expected redirect count
- Expected DNS answers
- Normal disk growth
- Normal application error rate
Thresholds without a baseline can miss slow degradation or create false alarms.
## Incident Severity
Example levels:
| Severity | Example | Response |
| --- | --- | --- |
| SEV-1 | Domain hijack, widespread phishing, total critical outage | Immediate coordinated response |
| SEV-2 | Website unavailable, certificate expired, major feature broken | Urgent owner response |
| SEV-3 | Partial degradation or noncritical failure | Scheduled prompt investigation |
| SEV-4 | Cosmetic or documentation issue | Normal maintenance |
Define severity for the actual project. A personal portfolio and a public safety service do not have the same impact.
## First Response Checklist
1. Record the detection time and reporter.
2. Confirm the issue from an independent path.
3. Define affected hostnames, users, and services.
4. Preserve relevant logs and current configuration.
5. Contain harm with the smallest reversible action.
6. Assign an incident lead.
7. Communicate a factual status and next update time.
8. Diagnose from registration and DNS toward the application.
9. Apply and verify recovery.
10. Monitor for recurrence.
Do not erase logs, rotate every system, or redeploy unrelated components before preserving evidence and understanding the scope.
## Domain Hijack Signals
- Nameservers changed unexpectedly.
- DNS records point to unfamiliar infrastructure.
- Account recovery email changed.
- A certificate was issued unexpectedly.
- Website content changed while the server remained untouched.
Response may require securing the email account, revoking sessions and API keys, restoring registration settings, contacting official support, and warning users. Preserve exact timestamps and account notices.
## Certificate Incident
If a private key may be exposed:
1. Remove unauthorized access.
2. Revoke or replace the affected certificate according to the certificate workflow.
3. Generate a new private key.
4. Deploy the new certificate and chain.
5. Confirm every server uses the replacement.
6. Investigate how the key was exposed.
Merely deleting a copied key from a public location does not make it secret again.
## Post-Incident Review
Write a blameless technical review containing:
- Impact
- Timeline
- Detection method
- Root cause and contributing conditions
- What reduced impact
- What delayed recovery
- Corrective actions with owners and dates
- Verification that actions were completed
Avoid vague actions such as “be more careful.” Improve a system, review gate, alert, backup, permission, or runbook.
## Tabletop Exercise
Scenario: the canonical domain suddenly resolves to an unknown IP while the production server remains healthy.
Write:
1. The first three commands you run.
2. Which accounts you secure.
3. Which evidence you preserve.
4. How you restore service.
5. How you notify users.
6. How you verify the incident is over.
Continue to [Server Hardening and Maintenance](./5.9-server-hardening.md).
## /documents/tutorial/operations/5.9-server-hardening.md
# Server Hardening and Maintenance
Hardening reduces unnecessary access and limits the damage of a mistake or compromise. It is an ongoing process, not a one-time checklist.
## Begin with a Minimal System
Install only required packages and services. Every listening process creates maintenance and attack surface.
Inventory listeners:
```bash
sudo ss -lntup
```
For each listener, record:
- Process owner
- Bind address
- Port and protocol
- Business purpose
- Whether it must be public
- Update responsibility
Disable or remove services with no owner or purpose after confirming dependencies.
## Administrative Access
- Use individual non-root accounts.
- Use `sudo` for reviewed administrative commands.
- Prefer cryptographic SSH keys protected by passphrases.
- Restrict SSH network access where practical.
- Disable obsolete authentication only after verifying a working recovery path.
- Remove accounts promptly during offboarding.
Do not lock out the only recovery path while changing authentication.
## File Permissions
Website files should be writable only by the deployment identity or controlled process that needs to update them. The web server normally needs read access, not ownership of every source and configuration file.
Find unusually broad permissions:
```bash
find /var/www/example.dpdns.org -xdev -type f -perm -0002 -print
```
Review results before changing permissions. Some collaborative workflows intentionally use group write access.
## Patch Management
Create a routine for:
- Operating system security updates
- Web server updates
- Application runtime updates
- Dependency updates
- Reboots required by kernel or core library changes
- Verification after updates
- Rollback when compatibility fails
Test major version changes in a nonproduction environment. Do not postpone critical updates indefinitely because no maintenance window was assigned.
## Firewall Design
Default to denying unsolicited inbound traffic, then permit required services.
For a simple web server, public inbound access may be limited to:
```text
TCP 80 HTTP and certificate validation workflow
TCP 443 HTTPS
```
Administrative access should be restricted according to the actual recovery and network design. Confirm IPv4 and IPv6 firewall policy separately.
## Application Isolation
Run applications as dedicated service users with access only to required files and sockets. Keep database, cache, and internal application ports on private or local interfaces unless remote access is explicitly designed and protected.
Use operating system service controls for resource limits, restart policy, working directory, and environment loading.
## Logs
Logs should support diagnosis without becoming a second sensitive database.
- Rotate logs before they fill the disk.
- Restrict access.
- Avoid request bodies and credentials.
- Redact tokens and cookies.
- Keep synchronized system time.
- Define retention based on operational and legal needs.
- Monitor repeated authentication and application errors.
## Security Headers and Application Controls
Server headers supplement application security. They do not repair SQL injection, broken authentication, or unsafe file uploads.
Deploy strict controls incrementally and observe their effect. In particular, test Content Security Policy and HTTP Strict Transport Security before long enforcement periods.
## Vulnerability Reduction
- Remove default pages and sample applications.
- Disable directory listing unless intentionally required.
- Keep management interfaces off public paths when possible.
- Use secure cookie attributes for authenticated applications.
- Protect state-changing requests against cross-site request forgery.
- Apply rate limits based on endpoint risk and user impact.
- Validate server-side input and output encoding.
## Monthly Maintenance Checklist
1. Review pending security updates.
2. Review listening ports and service owners.
3. Confirm backup and restoration tests.
4. Check disk space and log rotation.
5. Review account and SSH access.
6. Check certificate renewal.
7. Review DNS and nameserver changes.
8. Remove abandoned files, records, and integrations.
9. Test the public user path.
10. Record completion and unresolved risks.
## Hardening Lab
On a practice server you are authorized to administer:
1. Capture the current listener list.
2. Identify every public port.
3. Confirm the owning process and package.
4. Check whether the application runs as root.
5. Review website directory permissions.
6. Confirm update status.
7. Confirm a backup exists before changes.
8. Make one safe improvement and verify the service afterward.
Continue to [Part 6: Advanced Reference](../advanced/index.md).
## /documents/tutorial/operations/index.md
# Part 5: Operate the Domain
A domain requires ongoing ownership, renewal, security, documentation, and incident-response work after the website is online.
## Chapters
1. [Infrastructure Inventory and Change Management](./5.1-domain-management.md)
2. [Renewal and Expiration](./5.2-renewal-and-expiration.md)
3. [Migrate Nameservers Safely](./5.3-migrate-nameservers.md)
4. [Registration Data and Privacy](./5.4-registration-data.md)
5. [Account and API Security](./5.5-security.md)
6. [Acceptable Use and Abuse Response](./5.6-acceptable-use.md)
7. [Backups and Restoration](./5.7-backups-and-restoration.md)
8. [Monitoring and Incident Response](./5.8-monitoring-and-incidents.md)
9. [Server Hardening and Maintenance](./5.9-server-hardening.md)
Continue to [Infrastructure Inventory and Change Management](./5.1-domain-management.md).
## /documents/tutorial/platform/1.0-product-boundaries.md
# What DigitalPlat Does
Understanding the product boundary prevents the most common setup mistake: looking for website or mail records inside the registration Dashboard.
## DigitalPlat Responsibilities
DigitalPlat provides the registration control layer for supported names. Depending on the current interface and account, it can include:
- Account registration and sign-in
- Domain availability and registration
- Namespace-specific policy acknowledgement
- External authoritative nameserver submission
- Domain status and expiration information
- Renewal workflows
- Registration contact data management
- Product notices and supported account features
Current Dashboard notices and linked policies are authoritative because availability, limits, prices, pauses, and requirements can change.
## External DNS Responsibilities
An external authoritative DNS service hosts the zone and provides nameservers. Its interface is where the user manages records such as:
```text
A IPv4 address
AAAA IPv6 address
CNAME Hostname alias
MX Mail routing
TXT Verification and email policy
CAA Certificate authority policy
SRV Service discovery
```
DigitalPlat stores the external nameserver hostnames for delegation. It does not replace the external DNS service's record editor.
## Web Hosting Responsibilities
A web host or server stores or runs the website. It accepts HTTP and HTTPS connections after DNS points a hostname to it.
DigitalPlat registration does not:
- Upload HTML or application code
- Create a web server
- Open firewall ports
- Configure a reverse proxy
- Issue an HTTPS certificate
- Create a mailbox
Those are separate general website tasks covered later in the book.
## The Complete Relationship
```text
DigitalPlat registration
|
| delegates the domain to external NS hostnames
v
External authoritative DNS
|
| publishes A, CNAME, MX, TXT, and other records
v
Website, email, and other services
```
## Example
For `example.dpdns.org`:
1. DigitalPlat records that the domain uses `ns1.dns-service.example` and `ns2.dns-service.example`.
2. The external DNS service publishes the zone for `example.dpdns.org`.
3. The user creates an `A` record in that external service.
4. A browser resolves the record and connects to the web server.
If the record is missing, changing the DigitalPlat nameserver fields repeatedly will not create it.
## Diagnose the Correct Layer
| Symptom | First place to check |
| --- | --- |
| Domain absent from account | DigitalPlat Domain List |
| Wrong delegated nameservers | DigitalPlat domain nameserver settings |
| Correct NS but missing `A` record | External DNS zone |
| Correct DNS but connection timeout | Server and firewall |
| HTTP works but HTTPS fails | Web server and certificate workflow |
| Mail does not route | External DNS MX records and mail system |
## Reader Exercise
For each task, write either **DigitalPlat**, **external DNS**, or **web server**:
1. Renew the domain.
2. Add `www` as a CNAME.
3. Upload `index.html`.
4. Replace authoritative nameservers.
5. Add an MX record.
6. Configure an HTTP redirect.
Answers: DigitalPlat, external DNS, web server, DigitalPlat, external DNS, web server.
Continue to [Create a DigitalPlat Account](./1.1-account-registration.md).
## /documents/tutorial/platform/1.1-account-registration.md
# Create a DigitalPlat Account
An account stores registration contact data and provides access to the domain Dashboard.
## Prepare Before Registration
- An email address you can continue to access
- Your accurate name or organization name
- A valid phone number in the format requested by the form
- A complete contact address
- A unique password stored in a password manager
Do not use fictional textbook values as real registration data.
## Open the Registration Form
Open the account registration page from the official DigitalPlat Dashboard.
## Complete the Account Fields
- Use a monitored email address because it may receive recovery and policy notices.
- Enter accurate registration contact data.
- Use a unique password that is not shared with the email account.
- Enter a referral code only when you intentionally have one.
## WHOIS and Billing Addresses
The form separates domain contact information from billing information. If the interface offers a same-address option, review the copied result before submission.
Public visibility and required registration data depend on current namespace and privacy policy. Read the information presented by the Dashboard.
## Review Policies
Read the current:
- Terms of Service
- Privacy Policy
- Acceptable Use Policy
- Additional namespace or account policies shown by the product
Only submit accurate data after agreeing to the applicable terms.
## Verify the Account
1. Confirm the Dashboard opens.
2. Confirm the account email is correct.
3. Save recovery information securely.
4. Sign out and sign in once.
5. Record the responsible account owner privately.
Never publish a screenshot containing a password, full address, account ID, recovery code, or active session information.
Continue to [Register a FreeDomain Name](./1.2-domain-registration.md).
## /documents/tutorial/platform/1.2-domain-registration.md
# Register a FreeDomain Name
This chapter covers the DigitalPlat registration workflow. Ordinary DNS records will be configured later at an external DNS service.
## Read Current Notices First
Open the Dashboard notice board. Supported suffixes, registration pauses, slot requirements, prices, limits, renewal windows, and policies may change.
Do not treat an old screenshot as proof of current availability or cost.
## Prepare External Nameservers
The registration workflow may require authoritative nameserver hostnames. Create the intended zone at an external DNS service and copy every assigned nameserver.
Example format:
```text
ns1.dns-service.example
ns2.dns-service.example
```
These are hostnames, not DNS resolver addresses and not website IP addresses.
## Open Registration
Choose **Register** in the Dashboard.
Read the policies associated with the suffix you intend to select.
## Check the Name
1. Enter the requested label.
2. Choose a suffix.
3. Select **Check availability**.
4. Review the complete resulting name.
5. Review the displayed slot or payment requirement.
Avoid names that impersonate others, infringe rights, mislead users, or violate current policies.
## Submit Carefully
Before final submission, check:
- Complete domain spelling
- Selected suffix
- External nameserver hostnames
- Registrant information
- Policy acknowledgement
- Slot or charge displayed by the Dashboard
Registration can create external state and may consume a slot or create a charge. Stop when any value is unexpected.
## Confirm the Result
Open **Domain List** and locate the exact name. Record its status and expiration date privately.
A pending or rejected result should be investigated from the displayed reason. Possible causes include unavailable names, invalid external nameservers, incomplete registration data, or a current namespace restriction.
Continue to [Connect External Nameservers](./1.3-connect-nameservers.md).
## /documents/tutorial/platform/1.3-connect-nameservers.md
# Connect External Nameservers
DigitalPlat delegates the registered domain to an external authoritative DNS service. It does not provide the editor for ordinary DNS records.
DigitalPlat does not endorse or guarantee any third-party DNS service. The screenshots below use Cloudflare only as a short interface example.
## Create the External Zone
Create an account with the external DNS service and add the complete domain.
Choose an external service plan that meets your own requirements.
## Copy Assigned Nameservers
The external service assigns authoritative nameserver hostnames.
Copy every hostname exactly. Do not enter an IP address, public resolver address, or DNS record value in the DigitalPlat nameserver fields.
## Save Nameservers in DigitalPlat
Enter the assigned external nameserver hostnames during registration or in the available domain management workflow.
DigitalPlat's responsibility ends at delegation. After delegation, open the external DNS service to create website, email, or verification records.
## Verify Delegation
```bash
dig NS example.dpdns.org
```
The answer must contain the same external nameservers entered in DigitalPlat.
Trace the parent path when needed:
```bash
dig +trace NS example.dpdns.org
```
Ask an external authoritative server directly:
```bash
dig @ns1.dns-service.example SOA example.dpdns.org
```
## Common Mistakes
| Mistake | Correct action |
| --- | --- |
| Entering a server IP as an NS value | Enter the assigned authoritative nameserver hostname |
| Looking for an A-record editor in DigitalPlat | Open the external DNS zone |
| Creating a zone with the wrong domain spelling | Recreate or correct the external zone before delegation |
| Entering only one of several assigned nameservers | Enter the complete assigned set |
| Waiting when the external authoritative server has no zone | Fix the external zone first |
Continue to [Check Status and Renew](./1.4-status-and-renewal.md).
## /documents/tutorial/platform/1.4-status-and-renewal.md
# Check Status and Renew
The DigitalPlat Dashboard is the source of truth for the registration status and expiration date of a FreeDomain name.
## Domain Status
Open **Domain List** and confirm:
- Exact spelling
- Current registration state
- Expiration date
- Nameserver values when displayed
- Current notices affecting the namespace
If the domain is active but an `A`, `CNAME`, or `MX` record is missing, troubleshoot the external DNS service rather than the registration status.
## Renewal Planning
Renewal windows, fees, slot rules, and grace behavior can change. Follow the current Dashboard and policies for each suffix.
Create reminders assigned to named owners. Example schedule:
- 90 days before expiration
- 60 days before expiration
- 30 days before expiration
- 7 days before expiration
Adjust reminders to the actual renewal window shown by the product.
## Renewal Checklist
1. Sign in through the official Dashboard.
2. Read current notices.
3. Confirm the exact domain.
4. Confirm contact information is current.
5. Review the displayed renewal result, slot use, and charge.
6. Submit once.
7. Confirm the new expiration date.
8. Record the verified result.
Do not repeatedly submit after an ambiguous response. Read Domain List first to determine whether the earlier action succeeded.
## Expiration and Recovery
If the domain expires or becomes suspended, read the official status and instructions. Correct external DNS records cannot restore a registration-level delegation that is no longer active.
Before intentionally abandoning a domain, remove it from account recovery, email addresses, OAuth callbacks, package metadata, documentation, and trusted allowlists.
Continue to [Manage Account Data and Policies](./1.5-account-and-policies.md).
## /documents/tutorial/platform/1.5-account-and-policies.md
# Manage Account Data and Policies
Registration data and product policy belong to the DigitalPlat category because they affect ownership and eligibility, not the contents of the external DNS zone.
## Keep Contact Data Accurate
Review available account settings for:
- Name or organization
- Email address
- Phone number
- Postal address
- Billing address when applicable
Inaccurate data can interfere with notices, recovery, renewal, or compliance.
## Privacy
Public registration data and privacy controls depend on the namespace and current policy. Do not use fictional data to avoid visibility. Read the product's current privacy information before submitting or updating contact data.
Do not publish Dashboard screenshots containing full contact information, account IDs, balances, private domains, or session data.
## Current Policies
Review:
- Terms of Service
- Acceptable Use Policy
- Privacy Policy
- Suffix-specific rules
- Dashboard notices
The repository tutorial is educational and cannot override current policies shown by the service.
## Account Security
- Use a unique password.
- Protect the recovery email separately.
- Enable available multi-factor authentication.
- Review sessions and connected accounts when the interface provides those controls.
- Verify urgent suspension or expiration messages inside the official Dashboard.
- Remove old administrators during staff changes.
## Support Evidence
When contacting the official support or issue channel, include only the necessary:
- Domain name
- Current status
- Exact error message
- Time of the attempt
- Non-sensitive reproduction steps
Remove passwords, tokens, cookies, complete personal addresses, and unrelated account information.
Continue to [Use the API Safely](./1.6-api-overview.md).
## /documents/tutorial/platform/1.6-api-overview.md
# Use the API Safely
The Dashboard currently exposes API key and API documentation areas. The current documentation defines the actual endpoints, permissions, request formats, and limits.
Do not assume the API can manage external DNS records. DigitalPlat nameserver delegation and an external DNS provider's record API are separate systems.
## Start Read-Only
Good first tasks include inventory and status checks supported by the current documentation.
Before any mutation:
1. Read the current state.
2. Compare it with the intended state.
3. Display the exact proposed change.
4. Require approval when external effects are significant.
5. Send one request.
6. Read the authoritative state again.
Do not automatically retry ambiguous registration, renewal, deletion, purchase, or nameserver operations.
## Key Safety
- Create a key for one purpose.
- Use the narrowest available permission.
- Store it in a protected secret system.
- Never place it in frontend JavaScript, screenshots, URLs, or Git commits.
- Rotate it after exposure or staff changes.
- Delete unused keys.
## Documentation Placeholder
This skeleton intentionally omits a real endpoint:
```bash
curl --fail-with-body \
--connect-timeout 10 \
--max-time 30 \
--header "Authorization: Bearer $DIGITALPLAT_API_TOKEN" \
--header "Accept: application/json" \
"https://address-from-current-api-documentation.example/resource"
```
Copy current endpoint details only from the authenticated official API documentation.
## Category Transition
You have completed the DigitalPlat-specific category. Continue to [Category B: General Domain and Website Textbook](../foundations/index.md).
## /documents/tutorial/platform/dashboard-tour.md
# Dashboard Tour
The Dashboard organizes registration and account tasks. Exact labels and available areas may change with the account and current product version.
## Dashboard Overview
The overview can contain:
- Platform and namespace notices
- Account and slot summaries
- Domains approaching expiration
- Registration contact data
- Links to important actions
Read notices before registering or renewing. A notice can change the safe next step even when an older tutorial describes a different workflow.
## Domain List
Use Domain List to verify:
- The complete registered name
- Current registration status
- Expiration date
- Available management actions
Domain List proves the registration account's state. It does not prove that an external DNS record exists.
## Register
The registration area can include:
- Current policy links
- Name and suffix selection
- Availability checking
- Slot or charge information
- Policy acknowledgement
- External nameserver submission
Review the complete domain and current conditions before the final action.
## WHOIS Lookup and Account Data
Lookup and account settings can help review registration data and contact information. Public visibility and editable fields depend on current policy and namespace behavior.
Never publish a screenshot of the account section without removing personal data.
## API Areas
When API Keys and API Documentation are available, use the current documentation. The DigitalPlat API and an external DNS provider's API are separate. A DigitalPlat key must not be assumed to edit external zone records.
## Search and Navigation
Dashboard search can help locate product actions. Search results do not grant additional capability; the resulting page and current documentation define what the feature actually supports.
## A Safe Dashboard Routine
Before a state-changing action:
1. Confirm the signed-in account.
2. Read the notice board.
3. Open the exact domain.
4. Record the current state.
5. Review the intended state.
6. Check policy, slot, and charge information.
7. Submit once.
8. Return to the authoritative page and verify the result.
## Screenshot Safety
Crop screenshots to the smallest interface area needed to explain the action. Exclude:
- Browser address bar
- Full name and address
- Email and phone number
- Account ID
- Balances and unrelated subscription data
- Private domains
- API keys, cookies, and session values
- Unrelated tabs or applications
## Dashboard Exercise
Without changing anything, locate:
1. Current notices
2. Domain List
3. Registration
4. Account settings
5. API documentation, when available
For each area, write whether it controls registration state, account data, nameserver delegation, or documentation.
Continue to [What DigitalPlat Does](./1.0-product-boundaries.md).
## /documents/tutorial/platform/imgs/cloudflare-account-register.png
Binary file available at https://raw.githubusercontent.com/DigitalPlatDev/FreeDomain/refs/heads/main/documents/tutorial/platform/imgs/cloudflare-account-register.png
## /documents/tutorial/platform/imgs/cloudflare-add-domain.png
Binary file available at https://raw.githubusercontent.com/DigitalPlatDev/FreeDomain/refs/heads/main/documents/tutorial/platform/imgs/cloudflare-add-domain.png
## /documents/tutorial/platform/imgs/cloudflare-add-record.png
Binary file available at https://raw.githubusercontent.com/DigitalPlatDev/FreeDomain/refs/heads/main/documents/tutorial/platform/imgs/cloudflare-add-record.png
## /documents/tutorial/platform/imgs/cloudflare-choose-plan.png
Binary file available at https://raw.githubusercontent.com/DigitalPlatDev/FreeDomain/refs/heads/main/documents/tutorial/platform/imgs/cloudflare-choose-plan.png
## /documents/tutorial/platform/imgs/cloudflare-setns.png
Binary file available at https://raw.githubusercontent.com/DigitalPlatDev/FreeDomain/refs/heads/main/documents/tutorial/platform/imgs/cloudflare-setns.png
## /documents/tutorial/platform/imgs/digitalplat-account-registration.jpg
Binary file available at https://raw.githubusercontent.com/DigitalPlatDev/FreeDomain/refs/heads/main/documents/tutorial/platform/imgs/digitalplat-account-registration.jpg
## /documents/tutorial/platform/imgs/digitalplat-domain-registration.jpg
Binary file available at https://raw.githubusercontent.com/DigitalPlatDev/FreeDomain/refs/heads/main/documents/tutorial/platform/imgs/digitalplat-domain-registration.jpg
## /documents/tutorial/platform/imgs/digitalplat-register-setns.png
Binary file available at https://raw.githubusercontent.com/DigitalPlatDev/FreeDomain/refs/heads/main/documents/tutorial/platform/imgs/digitalplat-register-setns.png
## /documents/tutorial/platform/index.md
# Category A: DigitalPlat FreeDomain Guide
This category documents the DigitalPlat FreeDomain product itself. It is intentionally separated from the general DNS and website textbook.
## Current Product Boundary
DigitalPlat registers eligible domain names and delegates them to external authoritative nameservers supplied by the user.
DigitalPlat does not provide a DNS record editor. Records such as `A`, `AAAA`, `CNAME`, `MX`, and `TXT` are created and managed at the external authoritative DNS service, not in the DigitalPlat Dashboard.
The Dashboard is used for account, registration, nameserver delegation, domain status, renewal, registration data, and other features currently shown by the product.
## Chapters
1. [About the FreeDomain Project](./project-overview.md)
2. [Dashboard Tour](./dashboard-tour.md)
3. [What DigitalPlat Does](./1.0-product-boundaries.md)
4. [Create a DigitalPlat Account](./1.1-account-registration.md)
5. [Register a FreeDomain Name](./1.2-domain-registration.md)
6. [Connect External Nameservers](./1.3-connect-nameservers.md)
7. [Check Status and Renew](./1.4-status-and-renewal.md)
8. [Manage Account Data and Policies](./1.5-account-and-policies.md)
9. [Use the API Safely](./1.6-api-overview.md)
## Product Completion Check
Before moving to the general textbook:
- The account can sign in.
- The domain appears in Domain List.
- The external DNS zone exists.
- DigitalPlat delegates the domain to the assigned external nameservers.
- `dig NS` returns the intended nameservers.
- The reader understands that all ordinary DNS records are managed outside DigitalPlat.
Continue to [About the FreeDomain Project](./project-overview.md).
## /documents/tutorial/platform/project-overview.md
# About the FreeDomain Project
DigitalPlat FreeDomain exists to make domain access easier for individuals, open-source projects, communities, and organizations that may not begin with a traditional domain budget.
## What a FreeDomain Name Provides
A registered FreeDomain name provides a stable name that can be delegated to external authoritative nameservers.
After delegation, the user can connect the name to independently selected website, email, or verification services by creating records at the external DNS provider.
The domain is one part of a complete online service. It does not automatically include:
- Website hosting
- Email mailboxes
- A DNS record editor inside DigitalPlat
- Application development
- HTTPS configuration
- Ongoing server maintenance
The general textbook teaches these separate layers.
## Why Policies Matter
Free registration lowers the cost of entry, but it also creates abuse pressure. Spam, phishing, impersonation, automated registrations, unauthorized proxying, and abandoned domains can harm users and the reputation or availability of an entire namespace.
Users must read current terms, acceptable-use rules, privacy information, and suffix-specific requirements before registration. A tutorial summary cannot replace the current policy shown by the service.
## Namespaces, Availability, and Limits
Supported suffixes, pauses, free or paid slot requirements, account limits, and renewal rules can change. The Dashboard notice board and registration form are the current source of truth.
Do not promise another user that a name is free, available, or renewable based only on an old screenshot or README list.
## Responsible Ownership
A registrant should:
- Keep registration data accurate.
- Maintain access to the account email.
- Record the expiration date.
- Protect account credentials.
- Use external authoritative DNS responsibly.
- Patch and monitor public services.
- Respond to security and abuse reports.
- Remove abandoned services and records.
## Project and General Knowledge
This book uses two categories because they change at different speeds:
```text
DigitalPlat product guide
-> current interface, policy, registration, renewal, nameserver delegation
General textbook
-> DNS protocols, HTML, servers, HTTPS, email records, security, operations
```
Product behavior must be verified against the current Dashboard. General protocol behavior can be studied through standards and independent command-line verification.
Continue to [Dashboard Tour](./dashboard-tour.md).
## /documents/tutorial/website/3.0-html-css-foundations.md
# HTML and CSS Foundations
HTML describes the meaning and structure of a page. CSS controls presentation. JavaScript can add behavior, but a useful first website does not require it.
## Learning Objectives
After this chapter, you should be able to:
- Explain the roles of HTML and CSS.
- Recognize elements, attributes, headings, links, and landmarks.
- Create a valid document structure.
- Link a stylesheet with a relative URL.
- Inspect a page without exposing private files.
## Anatomy of an HTML Element
```html
<a href="about.html">About this site</a>
```
- `<a>` is the opening tag.
- `href` is an attribute.
- `about.html` is the link destination.
- `About this site` is the link text.
- `</a>` is the closing tag.
Choose link text that describes the destination. Repeated “click here” links are harder to scan and understand.
## Document Structure
```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Page Title</title>
</head>
<body>
<header>
<nav aria-label="Primary navigation">
<a href="index.html">Home</a>
<a href="about.html">About</a>
</nav>
</header>
<main>
<h1>One clear page heading</h1>
<p>Page content belongs here.</p>
</main>
<footer>
<p>Site information belongs here.</p>
</footer>
</body>
</html>
```
Use semantic elements for meaning, not merely for appearance. A `button` performs an action; a link navigates to another resource.
## Headings
Use one descriptive `h1` for the page's main topic, then nest subsections logically:
```html
<h1>Project Documentation</h1>
<h2>Installation</h2>
<h3>Linux</h3>
<h3>macOS</h3>
<h2>Configuration</h2>
```
Do not choose heading levels because of font size. CSS controls size.
## Images
```html
<img src="assets/team-at-work.jpg" alt="Two volunteers assembling a community network kit">
```
The `alt` text communicates the image's purpose when it cannot be seen. Decorative images may use an empty `alt` attribute. Never place passwords, private addresses, account dashboards, or unrelated browser content in public screenshots.
## Relative and Absolute URLs
Relative URL:
```html
<a href="about.html">About</a>
```
Root-relative URL:
```html
<a href="/about/">About</a>
```
Absolute URL:
```html
<a href="https://example.dpdns.org/about/">About</a>
```
Relative URLs make a small static site easier to test in different environments. Root-relative URLs are useful when the site is always served from the domain root.
## CSS Selectors and the Cascade
```css
body {
margin: 0;
font-family: system-ui, sans-serif;
}
.card {
max-width: 42rem;
padding: 2rem;
}
.card a {
color: #075985;
}
```
- `body` selects the element by name.
- `.card` selects elements with `class="card"`.
- `.card a` selects links inside a card.
When multiple rules target the same property, origin, importance, specificity, and source order determine the result. Prefer simple class selectors over deeply nested selectors.
## The Box Model
Every rendered element has:
```text
margin -> border -> padding -> content
```
Use this rule in new projects:
```css
*,
*::before,
*::after {
box-sizing: border-box;
}
```
It makes declared widths include padding and borders, which simplifies layout.
## Responsive Design
Begin with a flexible narrow layout:
```css
.page {
width: min(68rem, calc(100% - 2rem));
margin-inline: auto;
}
img {
max-width: 100%;
height: auto;
}
```
Add media queries only when the content needs a different arrangement:
```css
@media (min-width: 48rem) {
.grid {
display: grid;
grid-template-columns: 2fr 1fr;
gap: 2rem;
}
}
```
## Browser Developer Tools
Developer tools can inspect elements, applied CSS, network requests, console messages, and responsive layouts. Editing a rule in developer tools is temporary; update the source file after finding the correct change.
In the Network panel, look for:
- `404` missing files
- Wrong content types
- Unexpected redirects
- Large images
- HTTP resources loaded by an HTTPS page
## Mini Lab
Create `practice.html` with:
1. A semantic header and navigation.
2. One `h1` and two `h2` sections.
3. A relative link.
4. An image with useful alternative text.
5. A linked stylesheet.
Serve it locally and resize the browser from narrow to wide. Record one layout problem and the CSS rule that fixes it.
## Review Questions
1. Why is HTML not a programming language in the same sense as a server application?
2. When should an action use a button instead of a link?
3. What does the viewport meta element accomplish?
4. Why should a heading level not be selected for visual size?
5. What evidence does the Network panel provide that the page itself cannot?
Continue to [How a Website Request Works](./3.1-how-websites-work.md).
## /documents/tutorial/website/3.1-how-websites-work.md
# How a Website Request Works
Publishing a website connects several independent layers.
## From URL to Page
For `https://www.example.dpdns.org/about/`, the browser interprets:
```text
Scheme: https
Hostname: www.example.dpdns.org
Port: 443 by default
Path: /about/
```
The browser then:
1. Resolves the hostname through DNS.
2. Connects to the returned IP address.
3. Negotiates TLS for HTTPS.
4. Sends an HTTP request containing the hostname and path.
5. Receives an HTTP response.
6. Parses the HTML and requests linked assets.
## One IP Can Serve Many Domains
The HTTP `Host` header and the TLS Server Name Indication identify the requested hostname. A single server IP can therefore serve multiple sites.
The server still needs a virtual host configured for each hostname. Pointing DNS at an IP does not automatically configure the server.
## Static and Dynamic Websites
### Static website
Files such as HTML, CSS, JavaScript, and images are served as stored. Static sites have a small attack surface and are a good first deployment.
### Dynamic website
Application code generates responses, often using a database, authentication, background jobs, and secrets. Dynamic sites require additional deployment, backup, and security practices.
This book builds a static site first. The DNS and HTTPS concepts also apply to dynamic applications.
## HTTP Status Codes
| Code | Meaning |
| ---: | --- |
| `200` | Request succeeded |
| `301` or `308` | Permanent redirect |
| `302` or `307` | Temporary redirect |
| `404` | Path not found |
| `500` | Application or server error |
| `502` | Reverse proxy could not reach the application |
| `503` | Service temporarily unavailable |
## Headers Worth Checking
```bash
curl -I https://www.example.dpdns.org
```
Look for the status code, `content-type`, redirects, caching headers, and security headers. Do not assume a browser error is a DNS error.
## Layer-by-Layer Verification
```text
Registration -> NS delegation -> DNS record -> Network port -> TLS -> HTTP -> Application
```
Test in that order. A later layer cannot repair an earlier one.
Continue to [Build a Static Website](./3.2-build-static-site.md).
## /documents/tutorial/website/3.2-build-static-site.md
# Build a Static Website
Create a project directory:
```bash
mkdir my-first-site
cd my-first-site
```
## Create `index.html`
```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta name="description" content="My first website">
<title>My First Website</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<main class="card">
<p class="eyebrow">Hello, Internet</p>
<h1>My first website is online.</h1>
<p>This page is served from my own domain.</p>
<a href="about.html">About this site</a>
</main>
</body>
</html>
```
## Create `styles.css`
```css
:root {
color-scheme: light dark;
font-family: system-ui, sans-serif;
line-height: 1.5;
}
body {
display: grid;
min-height: 100vh;
margin: 0;
place-items: center;
background: #0f172a;
color: #e2e8f0;
}
.card {
width: min(38rem, calc(100% - 3rem));
padding: 3rem;
border: 1px solid #334155;
border-radius: 1.5rem;
background: #111827;
box-shadow: 0 1.5rem 4rem rgb(0 0 0 / 30%);
}
.eyebrow {
color: #38bdf8;
font-weight: 700;
letter-spacing: 0.12em;
text-transform: uppercase;
}
a {
color: #7dd3fc;
}
```
## Create `about.html`
```html
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>About | My First Website</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<main class="card">
<h1>About this site</h1>
<p>I built this site to learn domains, DNS, HTTP, and HTTPS.</p>
<a href="index.html">Return home</a>
</main>
</body>
</html>
```
## Check the Project
```text
my-first-site/
├── about.html
├── index.html
└── styles.css
```
Use relative links so the pages also work when served from a test directory. Avoid placing passwords, API keys, private documents, source maps containing secrets, or configuration backups in the public site directory.
## Add Basic Project Files
Create `.gitignore` if tools generate local files:
```gitignore
.DS_Store
*.log
.env
```
Never commit `.env` files or credentials merely because they are ignored locally. Check staged files before every commit.
Continue to [Test the Website Locally](./3.3-test-locally.md).
## /documents/tutorial/website/3.3-test-locally.md
# Test the Website Locally
Opening `index.html` directly does not reproduce all web-server behavior. Run a local HTTP server instead.
## Start a Local Server
From the project directory:
```bash
python3 -m http.server 8000 --bind 127.0.0.1
```
The bind address limits the development server to the local machine.
Open:
```text
http://127.0.0.1:8000/
```
This development server is for local testing, not public production use.
## Verify from the Terminal
In another terminal:
```bash
curl -I http://127.0.0.1:8000/
curl -I http://127.0.0.1:8000/about.html
```
Expect a successful status and an HTML content type for both pages.
## Browser Checks
- The page fits on a narrow mobile viewport.
- Text remains readable in light and dark system themes.
- The About and Return links work.
- The browser console contains no missing-file errors.
- Refreshing a page returns the same content.
- No local absolute paths appear in HTML or CSS.
## Stop the Server
Return to the terminal running the server and press `Ctrl+C`.
Confirm that nothing remains listening:
```bash
lsof -nP -iTCP:8000 -sTCP:LISTEN
```
No output means the test server has stopped.
## Do Not Expose the Development Server Accidentally
Binding to `0.0.0.0` makes the server reachable on every network interface allowed by the firewall. Only do that when LAN testing is intentional and the files are safe to share.
Continue to [Prepare a Linux Web Server](./3.4-prepare-server.md).
## /documents/tutorial/website/3.4-prepare-server.md
# Prepare a Linux Web Server
This chapter uses a generic Debian- or Ubuntu-based server and Nginx as an example. Equivalent web server software can be used if it provides the same HTTP, TLS, logging, and virtual-host capabilities.
## Server Requirements
- A public IPv4 address, IPv6 address, or both
- Administrative access through a non-root account with `sudo`
- Inbound TCP ports 80 and 443 permitted by network and host firewalls
- Security updates enabled or applied regularly
- A backup and recovery plan
Do not publish a server before confirming who is responsible for updates, monitoring, and incident response.
## Update the System
```bash
sudo apt update
sudo apt upgrade
```
Review package changes before confirming on a production server.
## Install Nginx
```bash
sudo apt install nginx
```
Verify the service:
```bash
systemctl status nginx --no-pager
sudo ss -lntp
```
Nginx should listen on port 80. Do not expose unrelated administration ports to the public internet.
## Create a Site Directory
```bash
sudo mkdir -p /var/www/example.dpdns.org
sudo chown -R "$USER":"$USER" /var/www/example.dpdns.org
```
Copy the site files into that directory using a deployment method that preserves expected ownership and permissions.
## Configure a Virtual Host
Create `/etc/nginx/sites-available/example.dpdns.org`:
```nginx
server {
listen 80;
listen [::]:80;
server_name example.dpdns.org www.example.dpdns.org;
root /var/www/example.dpdns.org;
index index.html;
location / {
try_files $uri $uri/ =404;
}
access_log /var/log/nginx/example.dpdns.org.access.log;
error_log /var/log/nginx/example.dpdns.org.error.log;
}
```
Enable it:
```bash
sudo ln -s /etc/nginx/sites-available/example.dpdns.org /etc/nginx/sites-enabled/example.dpdns.org
sudo nginx -t
sudo systemctl reload nginx
```
The configuration test must succeed before reloading.
## Test Before DNS Changes
From a machine that can reach the server, replace the example IP:
```bash
curl -I -H 'Host: example.dpdns.org' http://192.0.2.10
```
This tests the intended virtual host without waiting for DNS.
## Firewall Check
Use the firewall system already chosen for the server. Permit only required inbound services. At minimum, website traffic requires TCP 80 and 443; administration access should be restricted as tightly as practical.
Continue to [Deploy and Connect the Domain](./3.5-deploy-and-connect.md).
## /documents/tutorial/website/3.5-deploy-and-connect.md
# Deploy and Connect the Domain
This chapter copies the tested site to the server, creates DNS records, and verifies public HTTP access.
## Step 1: Back Up the Current Site
If the server already hosts content, back it up before replacing anything. Record the current DNS values so they can be restored.
## Step 2: Copy the Files
From the parent directory of `my-first-site`, replace the server address:
```bash
rsync -av --delete ./my-first-site/ user@192.0.2.10:/var/www/example.dpdns.org/
```
`--delete` removes files on the destination that are absent locally. Omit it until you have confirmed the source and destination paths.
On the server:
```bash
find /var/www/example.dpdns.org -maxdepth 2 -type f -print
sudo nginx -t
```
## Step 3: Create DNS Records
Create these records in the external authoritative DNS service, not in the domain registration interface.
For IPv4:
```text
Name: @
Type: A
Value: your-server-ipv4
```
For IPv6, only when the server is publicly reachable over IPv6:
```text
Name: @
Type: AAAA
Value: your-server-ipv6
```
For `www`:
```text
Name: www
Type: CNAME
Value: example.dpdns.org
```
Remove obsolete address records that point to old servers after the planned overlap period.
## Step 4: Verify DNS
```bash
dig A example.dpdns.org
dig AAAA example.dpdns.org
dig CNAME www.example.dpdns.org
```
The answers must match the server paths that actually work. Test IPv4 and IPv6 separately when both are published.
## Step 5: Verify HTTP
```bash
curl -I http://example.dpdns.org
curl -I http://www.example.dpdns.org
```
Both names should reach the intended server. A successful DNS query followed by an HTTP timeout usually indicates a server, firewall, or routing problem.
## Step 6: Choose the Canonical Hostname
Choose either the registered domain or `www` as the primary public URL. Redirect the other at the web server after HTTPS is configured for both names.
## Rollback
If the new deployment fails:
1. Restore the previous DNS value or server files.
2. Keep the old service running until cached DNS answers expire.
3. Record the failure evidence before retrying.
Continue to [Enable and Verify HTTPS](./3.6-https.md).
## /documents/tutorial/website/3.6-https.md
# Enable and Verify HTTPS
HTTPS authenticates the hostname and encrypts traffic between the client and server. A domain and an open port do not create HTTPS automatically.
## Before Requesting a Certificate
Confirm:
- The domain resolves to the intended server.
- Port 80 or another validation method required by the certificate workflow is available.
- The web server accepts every hostname that will appear on the certificate.
- No stale `AAAA` record points to an unreachable server.
- Any CAA records permit the certificate authority used by the workflow.
## Use an ACME Client
ACME automates domain-control validation, certificate issuance, installation, and renewal. Select a maintained client compatible with your operating system and web server, then follow its official documentation.
An Nginx-integrated client typically requests a certificate for both names:
```bash
sudo acme-client --nginx -d example.dpdns.org -d www.example.dpdns.org
```
`acme-client` is a placeholder in this example. Replace it with the actual command and reviewed options for the client you installed.
Never paste a private certificate key into a website, issue report, chat, or DNS record.
## Redirect HTTP to HTTPS
After HTTPS works directly, configure the web server to redirect HTTP requests to the canonical HTTPS URL.
Example Nginx HTTP redirect:
```nginx
server {
listen 80;
listen [::]:80;
server_name example.dpdns.org www.example.dpdns.org;
return 308 https://example.dpdns.org$request_uri;
}
```
Test the configuration before reload:
```bash
sudo nginx -t
sudo systemctl reload nginx
```
## Verify the Certificate and Redirects
```bash
curl -I http://example.dpdns.org
curl -I https://example.dpdns.org
curl -I https://www.example.dpdns.org
```
Inspect the certificate dates and names:
```bash
openssl s_client -connect example.dpdns.org:443 -servername example.dpdns.org </dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates -ext subjectAltName
```
The certificate must be valid for every public hostname served over HTTPS.
## Test Renewal
Use the ACME client's documented dry-run or test-renewal command. Automatic renewal is not proven merely because the first certificate succeeded.
Monitor:
- Renewal timer or scheduled task
- Certificate expiration
- Renewal logs
- Port and DNS changes that could break validation
## Security Headers
After the application is stable, consider headers such as:
```nginx
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
```
Content Security Policy and HTTP Strict Transport Security require site-specific planning. A copied policy can break resources or make an incorrect HTTPS deployment difficult to recover. Test them before long-lived enforcement.
## Final Website Check
- DNS answers are correct for IPv4 and IPv6.
- HTTP redirects once to the intended HTTPS hostname.
- HTTPS returns the expected page.
- The certificate covers the hostname and renews automatically.
- No mixed HTTP content appears in the browser console.
- Server logs show no repeated application errors.
- An external backup of the website exists.
Continue to [Dynamic Applications and Reverse Proxies](./3.7-dynamic-applications.md).
## /documents/tutorial/website/3.7-dynamic-applications.md
# Dynamic Applications and Reverse Proxies
A dynamic application creates responses using code, data, authentication, or user input. It requires more operational controls than a static site.
## A Common Architecture
```text
Browser
|
| HTTPS :443
v
Nginx reverse proxy
|
| HTTP on 127.0.0.1:3000
v
Application process
|
v
Database or external services
```
The reverse proxy handles the public connection and forwards selected requests to an application bound to the local interface.
## Why Use a Reverse Proxy
A reverse proxy can:
- Terminate TLS.
- Route multiple hostnames or paths.
- Apply request size and timeout limits.
- Serve static files efficiently.
- Add standard headers.
- Keep the application port off the public network.
It does not automatically make an insecure application safe.
## Bind the Application Locally
Prefer:
```text
127.0.0.1:3000
```
over:
```text
0.0.0.0:3000
```
when only the reverse proxy should reach the application. Confirm the real listener:
```bash
sudo ss -lntp
```
## Example Nginx Location
```nginx
location / {
proxy_pass http://127.0.0.1:3000;
proxy_http_version 1.1;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_connect_timeout 5s;
proxy_read_timeout 30s;
}
```
Header trust is an application decision. Configure the application to trust proxy headers only from the actual proxy, or clients may forge scheme and address information.
## Application Process Management
A production application needs:
- A non-root service account
- A defined working directory
- Environment or secret loading
- Automatic restart with limits
- Structured logs
- Health checks
- Graceful shutdown
- A deployment and rollback procedure
Do not use a development server as a permanent production process unless its documentation explicitly supports production operation.
## Secrets and Configuration
Separate configuration into:
```text
Public configuration: ports, feature flags, public URLs
Sensitive configuration: database passwords, signing keys, API tokens
```
The frontend bundle is public. A secret embedded in browser JavaScript is no longer secret.
## Database Safety
If the application uses a database:
- Bind it to a private interface unless remote access is required.
- Use a dedicated database role with limited permissions.
- Apply schema migrations through a reviewed process.
- Back up data before migrations.
- Test restoration, not only backup creation.
- Avoid logging passwords, tokens, or full personal records.
## Uploads and User Input
Treat all user input as untrusted.
- Validate type, length, and expected format on the server.
- Generate storage names instead of trusting uploaded filenames.
- Store uploads outside executable application directories.
- Set size limits.
- Escape output according to its HTML, URL, JavaScript, shell, or SQL context.
- Use parameterized database queries.
Client-side validation improves usability but is not a security boundary.
## Health Checks
Create a lightweight endpoint that proves the application can serve requests without exposing secrets:
```text
GET /healthz -> 200 OK
```
Decide whether a health check verifies only the process or also dependencies such as the database. Deep checks can create load or expose dependency failures to the public.
## Diagnose a `502` Response
1. Confirm the application process is running.
2. Confirm the expected local port is listening.
3. Request the application directly from the server.
4. Check reverse-proxy error logs.
5. Check application logs.
6. Verify protocol, address, and port in `proxy_pass`.
7. Check local firewall or security policy.
Example:
```bash
curl -I http://127.0.0.1:3000/healthz
sudo tail -n 100 /var/log/nginx/example.dpdns.org.error.log
```
## Deployment Exercise
Draw a dynamic application architecture and label:
- Public ports
- Private ports
- TLS termination
- Secret storage
- Logs
- Backup boundary
- Health check
- Rollback target
Do not deploy it until every label has an owner.
Continue to [Accessibility and Search Basics](./3.8-accessibility-and-search.md).
## /documents/tutorial/website/3.8-accessibility-and-search.md
# Accessibility and Search Basics
A website is not complete merely because it loads. It should be understandable, navigable, and usable across devices and assistive technologies.
## Start with Semantic HTML
Use native elements before recreating them with generic containers:
```html
<button type="button">Open settings</button>
<nav aria-label="Primary navigation">...</nav>
<main>...</main>
```
Native elements provide keyboard behavior and semantics that custom implementations often miss.
## Keyboard Navigation
Test without a mouse:
1. Press `Tab` through interactive elements.
2. Confirm focus is visible.
3. Confirm focus order follows the reading order.
4. Activate links and buttons with the keyboard.
5. Confirm no keyboard trap prevents leaving a component.
Do not remove focus outlines without providing a clear replacement.
## Color and Contrast
Do not use color as the only signal. Pair color with text, icons, or structure.
Example error message:
```html
<p class="error" role="alert">Enter a valid email address.</p>
```
Test foreground and background combinations with an accessibility contrast tool. Check hover, focus, disabled, and dark-theme states separately.
## Forms
Associate every input with a visible label:
```html
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">
```
Placeholder text is not a substitute for a label. Explain errors near the field and preserve entered data after a validation failure when safe.
## Images and Media
- Write useful alternative text for informative images.
- Use empty alternative text for decorative images.
- Provide captions or transcripts for meaningful audio and video.
- Avoid autoplaying audio.
- Do not place critical text only inside an image.
## Page Metadata
Each public page should have a unique title and useful description:
```html
<title>Installation Guide | Example Project</title>
<meta name="description" content="Install and verify the Example Project on Linux and macOS.">
```
Metadata helps users distinguish tabs and can help search systems understand the page. It does not guarantee ranking.
## Canonical URLs
If the same content is reachable at several URLs, select one public URL and use redirects consistently. A canonical link can communicate the preferred document URL:
```html
<link rel="canonical" href="https://example.dpdns.org/guide/">
```
Do not use a canonical link to hide incorrect redirects or duplicate deployment paths.
## `robots.txt`
A basic file may declare crawl preferences:
```text
User-agent: *
Allow: /
```
`robots.txt` is public and voluntary. It is not access control. Do not list private paths in it expecting them to become secret.
## Sitemap
A small site may publish a sitemap containing canonical public URLs. Update it when pages move or are removed. The sitemap supports discovery but does not guarantee indexing.
## Structured Content
Clear headings, descriptive links, real text, and stable URLs benefit both accessibility and search understanding. Avoid pages created only to repeat keywords or manipulate rankings.
## Accessibility Review Lab
For the static site built earlier:
1. Navigate the entire site using only a keyboard.
2. Check every image's alternative text.
3. Check heading order.
4. Zoom the page to 200 percent.
5. Test a narrow viewport.
6. Disable CSS and confirm the document remains understandable.
7. Record and fix at least three issues.
## Review Questions
1. Why is a placeholder not a label?
2. Why is `robots.txt` not a security boundary?
3. What is the difference between a redirect and a canonical hint?
4. How does semantic HTML help without adding visible design?
Continue to [Performance and Caching](./3.9-performance-and-caching.md).
## /documents/tutorial/website/3.9-performance-and-caching.md
# Performance and Caching
Performance is the time and stability experienced by a user, not a single score. Optimize after measuring the real page and network path.
## Build a Request Budget
List every resource required for the first view:
```text
HTML
CSS
JavaScript
Fonts
Images
Third-party scripts
```
Every resource adds transfer, processing, and failure risk. Remove unnecessary dependencies before compressing them.
## Measure Transfer and Timing
```bash
curl -sS -o /dev/null \
-w 'status=%{http_code} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total} size=%{size_download}\n' \
https://example.dpdns.org/
```
Run several times and compare results. A single measurement can reflect temporary network conditions or a warm cache.
## Optimize Images
- Resize images to the maximum displayed dimensions.
- Select an appropriate format.
- Compress without destroying important detail.
- Set width and height to reduce layout shifts.
- Lazy-load images below the first screen when appropriate.
- Preserve screenshots at a resolution where interface text remains readable.
Example:
```html
<img src="assets/guide.webp" width="960" height="540" loading="lazy" alt="DNS record editor showing an A record">
```
## Compression
Text resources such as HTML, CSS, JavaScript, SVG, and JSON compress well. Configure the web server to use a supported compression method and verify the response:
```bash
curl -I -H 'Accept-Encoding: gzip' https://example.dpdns.org/styles.css
```
Look for a suitable `content-encoding` and correct `vary` behavior.
## Browser Cache Headers
Short-lived HTML example:
```text
Cache-Control: no-cache
```
Versioned asset example:
```text
Cache-Control: public, max-age=31536000, immutable
```
Long-lived caching is safe when the asset filename changes with its content, such as `styles.a1b2c3.css`. Do not apply a one-year immutable policy to a file whose content changes without a new URL.
## DNS TTL and HTTP Cache Are Different
DNS TTL controls caching of DNS answers. HTTP cache headers control web responses. Changing one does not clear the other.
An old page with a correct new IP is usually an HTTP or application cache issue. An old IP before any HTTP connection is a DNS cache issue.
## Third-Party Resources
External scripts, fonts, analytics, embeds, and stylesheets create additional DNS lookups, network connections, privacy considerations, and availability dependencies.
Before adding one, ask:
- Is it necessary for the user goal?
- What data does the request disclose?
- What happens if it is slow or unavailable?
- Can the functionality be served locally?
- How will version changes be controlled?
## Server Caching
A reverse proxy or application cache can reduce repeated work, but only if cache keys include the correct hostname, path, query parameters, authentication state, language, and content variants.
Never cache private authenticated responses in a shared public cache without an explicit safe design.
## Performance Lab
1. Record page size, request count, and total time.
2. Identify the three largest resources.
3. Remove or optimize one resource.
4. Repeat the same measurement conditions.
5. Verify that accessibility and visual quality remain acceptable.
6. Document the before and after values.
## Completion Check
- The first page does not require unnecessary third-party scripts.
- Images use appropriate dimensions and formats.
- Static assets have intentional cache headers.
- HTML can update without a year-long stale cache.
- Compression is verified from the response, not assumed from configuration.
- Measurements are recorded before and after changes.
Continue to [Part 4: Email and Service Records](../email/index.md).
## /documents/tutorial/website/index.md
# Part 3: Build and Publish a Website
This part creates a small static website, tests it locally, deploys it to a Linux server, connects the domain, and enables HTTPS.
## Chapters
1. [HTML and CSS Foundations](./3.0-html-css-foundations.md)
2. [How a Website Request Works](./3.1-how-websites-work.md)
3. [Build a Static Website](./3.2-build-static-site.md)
4. [Test the Website Locally](./3.3-test-locally.md)
5. [Prepare a Linux Web Server](./3.4-prepare-server.md)
6. [Deploy and Connect the Domain](./3.5-deploy-and-connect.md)
7. [Enable and Verify HTTPS](./3.6-https.md)
8. [Dynamic Applications and Reverse Proxies](./3.7-dynamic-applications.md)
9. [Accessibility and Search Basics](./3.8-accessibility-and-search.md)
10. [Performance and Caching](./3.9-performance-and-caching.md)
## What You Need
- A registered domain with working authoritative DNS
- A text editor
- A terminal
- A server or hosting environment that can serve HTTP content
- Permission to configure the server and its firewall
Third-party hosting, DNS, and certificate services have their own terms, limits, and security models. Evaluate them independently and keep a copy of your site outside the provider.
Continue to [HTML and CSS Foundations](./3.0-html-css-foundations.md).
The better and more specific the context, the better the LLM can follow instructions. If the context seems verbose, the user can refine the filter using uithub. Thank you for using https://uithub.com - Perfect LLM context for any GitHub repo.