This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Home Services

1 - DNS

  • _index

1.1 - DoT vs DoH vs DoQ

DoT

DNS over TLS (DoT) is a DNS encryption protocol based on TLS. TLS 1.2 requires at least four round-trips, TLS 1.3 requires at least three round-trips, while DNS requests only need one round-trip.

Timeline
  ↓
  ┌───────────────────────────────────────────────────────────────────────┐
  │                          Client                                       Server
  │                                                                        │
  │  Client sends SYN segment                                              │
  │  ────────────────────────────────────────────────────────────────────▶│
  │  SYN = 1, Seq = x                                                     │
  │                                                                        │
  │  ←─────────────────────────────────────────────────────────────────────│
  │  Server responds with SYN-ACK segment                                 │
  │  SYN = 1, ACK = 1, Seq = y, Ack = x + 1                               │
  │                                                                        │
  │  Client sends ACK segment                                              │
  │  ────────────────────────────────────────────────────────────────────▶│
  │  ACK = 1, Seq = x + 1, Ack = y + 1                                    │
  │                                                                        │
  │  TCP connection established                                           │
  │  Client sends ClientHello                                              │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │  ←─────────────────────────────────────────────────────────────────────│
  │  Server responds with ServerHello                                     │
  │  Server sends certificate chain                                       │
  │                                                                        │
  │  Client sends key exchange message                                    │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │  Server sends key exchange message                                    │
  │  ←─────────────────────────────────────────────────────────────────────│
  │                                                                        │
  │  Client sends Finished                                                 │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │  Server sends Finished                                                 │
  │  ←─────────────────────────────────────────────────────────────────────│
  │                                                                        │
  │  TLS handshake completed                                              │
  │  Client sends DNS query                                                │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │  ←─────────────────────────────────────────────────────────────────────│
  │  Server responds with DNS query                                       │
  │                                                                        │
  └───────────────────────────────────────────────────────────────────────┘

TLS 1.2 handshake requires at least two round-trip times (RTT): client sends ClientHello, server replies with ServerHello and certificates, then client sends ClientKeyExchange and ChangeCipherSpec, finally server sends Finished. TLS 1.3 simplifies the handshake to one round-trip (1-RTT). When sending ClientHello, client can include key share information (ClientKeyShare), server also includes key share information in ServerHello response, completing key negotiation and handshake within the first round-trip.

DoH

DNS over HTTPS (DoH) is a DNS encryption protocol based on HTTPS. HTTPS, being TCP-based, requires at least three round-trips to establish a connection while DNS requests only need one round-trip. Therefore, DoH is the slowest among the three encrypted DNS protocols.

Compared to DoT, DoH has higher protocol overhead due to additional HTTP protocol headers, making it slightly slower than DoT. Other aspects are similar to DoT.

DoQ

DNS over QUIC (DoQ) is a DNS encryption protocol based on QUIC. QUIC, being UDP-based, requires two round-trips to establish a connection while DNS requests only need one round-trip. Therefore, DoQ is the fastest among the three encrypted DNS protocols.

Timeline
  ↓
  ┌───────────────────────────────────────────────────────────────────────┐
  │                         Client                                      Server
  │                                                                        │
  │  Client sends Initial Packet                                          │
  │  Contains: QUIC version, Connection ID, encrypted handshake message   │
  │  (ClientHello), possibly application-layer data                       │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │                                                                        │
  │  ←─────────────────────────────────────────────────────────────────────│
  │  Server responds with Initial Packet                                  │
  │  Contains: encrypted handshake message (ServerHello, Certificate,     │
  │  ServerKeyExchange etc.)                                                │
  │  May contain confirmation or rejection of client's 0-RTT data         │
  │                                                                        │
  │  Client sends encrypted handshake message (EndOfEarlyData, Finished)  │
  │  ────────────────────────────────────────────────────────────────────▶│
  │                                                                        │
  │  Server sends encrypted handshake message (Finished)                  │
  │  ←─────────────────────────────────────────────────────────────────────│
  │                                                                        │
  │  Handshake completed                                                  │
  │  Connection established                                               │
  │  Data transmission begins                                             │
  │  ────────────────────────────────────────────────────────────────────▶│
  │  ←─────────────────────────────────────────────────────────────────────│
  │  Data transmission                                                    │
  │  Data transmission                                                    │
  │  Data transmission                                                    │
  └───────────────────────────────────────────────────────────────────────┘

QUIC uses TLS 1.3 or higher to secure connections. The encrypted handshake process resembles traditional TLS handshake but is conducted through QUIC’s packet format, allowing data transmission to start simultaneously with handshake. If a client has previously established a QUIC connection with the server, it can immediately send application-layer data in new connection attempts without waiting for server response. This mechanism, called 0-RTT, can significantly reduce interaction latency. However, 0-RTT data might be rejected by servers due to replay attack risks.

QUIC’s design objectives include faster connection establishment and better congestion control compared to TCP, while maintaining compatibility with existing network infrastructure. Through these mechanisms, QUIC achieves fast handshake during first connection and utilizes 0-RTT for reduced latency in subsequent connections.

Conclusion

In stable network environments, DoQ theoretically offers the fastest speed thanks to its UDP and TLS 1.3 foundation. However, in actual networks, UDP’s connectionless nature may lead to random packet drops by ISPs during heavy traffic, causing connection instability. DoT is slightly slower than DoQ but offers more stable TCP-based connections. DoH is slower due to its HTTP-based protocol, but provides richer backend functionality. Choose the appropriate encrypted DNS protocol based on your network environment and requirements.

Reference

1.2 - Fastest DNS

Ordinary users typically measure ping response speed of plaintext DNS IP addresses, but this rarely reflects actual server connection performance. Modern DNS requires encrypted DNS protocols to ensure service integrity against hijacking.

From client to destination, traffic usually passes through 5-8 network devices. Any of these can hijack UDP:53 requests through simple commands. Never rely on plaintext DNS, especially in enterprise environments where hijacking is nearly inevitable.

Example hijacking command: sudo iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 1.1.1.1:53

Hijacking setup is trivial. Enterprise internal DNS speeds often stay under single-digit milliseconds while home networks typically see sub-1ms latency. Whatever plaintext DNS you configure, responses ultimately come from local DNS services.

Now discussing encrypted DNS speeds. Three common protocols: DNS over TLS (DoT), DNS over HTTP (DoH), and DNS over QUIC (DoQ).

Theoretical comparison:

  • Fastest: DoQ. QUIC (UDP-based) requires 1 round-trip (RTT) for connection + 1 RTT for DNS request
  • DoT: TLS 1.2 needs 4 RTT, TLS 1.3 needs 3 RTT connection + 1 RTT DNS request
  • DoH: HTTPS requires ≥4 RTT connection + HTTP overhead makes it slower than DoT
  • Traditional UDP:53: 0 RTT connection + 1 RTT

Encrypted DNS requires 2-4x longer for initial requests, but matches plaintext DNS speed once connected (ignoring connection timeouts).

Network reality: ISPs randomly drop UDP packets during congestion. TCP’s retransmission mechanism prevents this, making TCP DNS more stable during peak hours.

Connection time alone won’t significantly improve browsing experience. Proper DNS parameter configuration often yields better results than server selection.

Internet access involves two steps: domain IP lookup followed by direct IP communication. Local DNS cache checks happen first - cache queries take nanoseconds. TTL (Time to Live) controls cache duration. For example, TTL=600 keeps records valid 10 minutes. Many enterprises set TTL=10 (10 seconds).

Self-hosted DNS servers can modify TTL values. Services like www.adguardprivate.com allow DNS customization with extended TTL to reduce queries and improve browsing.

This article only discusses connection speed - DNS services offer many other performance-affecting features.

2 - Devices

This section discusses suitable devices for hosting home services.

Hardware Platforms

There are many options for home-use devices: retired laptops,闲置 desktops, development boards, NAS devices, soft routers, Macs, etc., all of which can host services.

Hardware choices in 2024 no longer need to be limited to x86 platforms. ARM platforms have matured with advantages including low cost, sufficient performance, low power consumption, and rich ecosystems suitable for home use. Unless you must run legacy software, ARM platforms are excellent choices.

Installing Windows/Linux on Apple devices or running Hackintosh on non-Apple hardware requires technical expertise, suitable for users comfortable with system modifications.

Device Selection Criteria

  • CPU: Prioritize power efficiency/performance ratio
  • Memory: Minimum 4GB baseline
  • Storage: Consider redundancy and expandability
  • Network: Gigabit Ethernet essential
  • Cooling: Reliable thermal management for 24/7 operation
  • Noise: Acoustic requirements depend on placement location

Operating Systems

Linux offers the best ecosystem with abundant tools. Command-line operations suit users with technical backgrounds. Non-professional users might consider Ubuntu Desktop. Black NAS systems are viable but require self-troubleshooting.

Windows has the broadest user base. Most requirements can be met through IIS (Internet Information Services) with simple mouse operations.
Windows installation reference: massgrave.dev

Apple’s ARM CPUs make Mac Mini a cost-effective hardware option. However, macOS requires alternating between GUI and command-line interfaces, suitable for technically proficient users.

System Selection Recommendations

  • Beginners: Windows + Docker Desktop
  • Advanced Users: Ubuntu Server/Debian
  • Stability-Centric: RHEL/Rocky Linux
  • Specialized Needs:
    • Media Server: unRAID
    • Storage-Focused: TrueNAS
    • Full-Featured NAS: Synology DSM

Recommended Devices & Systems

Professional users have diverse requirements, while non-professionals primarily need NAS devices. Simply search for “NAS” on e-commerce platforms and purchase according to needs.

For budget-conscious users: repurpose闲置 devices or purchase discounted hardware from second-hand markets. Windows Server 2022/2025 or Black NAS systems can be installed with technical effort.

Data Security

Hard Drive Failure

Initial drive failures often manifest as intermittent read errors. Waiting until complete failure risks expensive recovery costs and potential irrecoverable data.
Recommend purchasing a RAID enclosure. With 5-year drive failure rate at 10%, dual-drive RAID reduces effective failure risk to 1%. As long as drives don’t fail simultaneously, data remains recoverable through replacement.

Data Theft

Unencrypted data on stolen drives creates significant risks, especially for sensitive materials like confidential documents and password backups. Enable drive encryption to mitigate losses from theft.
Encryption incurs system resource overhead. Performance-sensitive users might disable encryption but must prioritize physical drive security.

Multiple Backups

Local storage isn’t foolproof - risks include theft, natural disasters, and ransomware attacks. Implement multi-location backups using reliable cloud services for critical data.

Network Security

Avoid Exposing Public IPs

Some network configurations assign public IPv6 addresses to devices, making them vulnerable to port scanning and potential exploits.
Unless specifically required, configure IPv6 in NAT6 mode for address translation to prevent direct IP exposure. For external services, use DMZ hosts. For personal use, consider WireGuard/Tailscale/ZeroTier VPN solutions for secure home network access.

Software Installation Caution

All software (mainstream or niche) may contain vulnerabilities. Regularly update software, remove unused applications, and avoid granting unnecessary privileges.

Firewall Usage

Disabling firewalls creates immediate convenience at the cost of security risks. Invest time in configuring firewall rules rather than leaving them disabled.

Security Software

Free security solutions offer basic protection better than nothing. Consider tools like Huorong Security or 360 Security.

Security Recommendations Summary

  • Network Segregation: VLAN Partitioning
  • Access Control: Reverse Proxy + Authentication
  • Monitoring: Hardware Status Alerts
  • Backup Strategy: 3-2-1 Principle
    • 3 Copies
    • 2 Media Types
    • 1 Offsite Copy

2.1 - Device Classification

  • Device Classification

Popular network devices such as NAS, soft routers, Mac minis, and traditional routers are unified as “devices”. Users don’t need to focus on their naming or physical forms, but should primarily consider four aspects: processor, storage, networking, and application ecosystem.

The most important consideration for processors is architecture, with x86 and ARM being the most commonly used. Other architectures are not recommended for non-professionals due to their limited ecosystems which increase learning and usage difficulties.

You might hear people saying ARM is typically used in low-power devices suitable for home use, while x86 is used in high-performance devices suitable for enterprises. However, by 2024 this view is outdated. We should base our decisions on ecosystem considerations. Currently, the ARM ecosystem has become very rich with better cost-performance ratios, making it worth considering. For non-professionals, we recommend choosing ARM architecture devices - taking Alibaba Cloud as an example, ARM devices cost only half as much as x86 devices while providing sufficient performance for home use. Professionals can choose x86 architecture devices based on their specific needs.