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:

The website helps [audience] learn [information] and take [action].

Example:

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:

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:

# 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

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:

# 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:

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