Self-Verified Security, Without External Proxies

Quiet edge, fully autonomous trust chain

The glitter.kr infrastructure is designed as a self-hosted, physically controlled edge that signs and validates every layer itself. From authoritative DNS to HTTPS and SMTP, there is no dependency on external reverse proxies or security gateways.

The goal is to make the entire trust path observable and explainable with public records and local logs. Instead of assuming that a CDN or DNS provider is doing the right thing, the operator keeps direct control over keys, policies, and verification steps.

The core principle can be summarized as:

Core principle: direct control without delegation ensures the highest level of security and transparency.

The phrase about operating all sections without external proxies or delegation originates from a public post by glitter gim on October 30, 2025. This page turns that idea into a structured, verifiable profile.

Security and operational objectives

The autonomous security model has two sets of objectives: security goals for the trust chain itself, and operational goals for how that chain is maintained day to day.

Security goals

• No proxy, no relay, no delegated edge in front of origin services.
• Maintain a single trust chain from Root → TLD → Zone → Application.
• Guarantee direct TLS negotiation between clients and origin servers.
• Minimize certificate spoofing risk by combining DNSSEC with DANE.

Operational goals

• Automated signing and certificate pipelines to avoid manual mistakes.
• High observability with unified logs and small, clear failure domains.
• Process isolation so that faults remain contained within each service.

The rest of this page walks through how these objectives are implemented across DNS, network, mail, applications, and operations.

Authoritative edge, DNSSEC-anchored services

glitter.kr runs its own authoritative DNS and application stack as a compact, self-owned edge. The high-level structure can be summarized as follows.

Authoritative DNS servers implement full DNSSEC with separated KSK and ZSK. The zone is automatically re-signed and distributed across ns1–ns5.glitter.kr, and the DS record is correctly configured at the .kr registry.

For SMTP, TLSA records such as _25._tcp.mail.glitter.kr and _587._tcp.mail.glitter.kr are generated from live keys, signed by DNSSEC, and published in sync with certificate changes.

• Nameservers: ns1–ns5, self-hosted BIND only.
• DNSSEC: separate KSK/ZSK with automated ZSK rollover.
• DANE/TLSA: 3 1 1 (DANE-EE, SPKI SHA-256) for SMTP and critical services.
• No external caching, no proxy DNS; validating resolvers can follow the full chain.

Verification commands

dig -4 +dnssec +multi glitter.kr SOA
dig -4 +dnssec +multi glitter.kr DNSKEY
dig -4 +dnssec +multi glitter.kr DS
dig -4 +dnssec +multi glitter.kr TXT
dig -4 +dnssec +multi glitter.kr CAA
dig -4 +trace glitter.kr @a.root-servers.net
dig -4 +dnssec +multi _smtp._tls.glitter.kr TXT
dig -4 +dnssec +multi _25._tcp.mail.glitter.kr TLSA
dig -4 +dnssec +multi _587._tcp.mail.glitter.kr TLSA
dig -4 +dnssec +multi _443._tcp.captcha.glitter.kr TLSA
dig -4 +dnssec +multi glitter.kr SOA @1.1.1.1
dig -4 +dnssec +multi glitter.kr DNSKEY @1.1.1.1
dig -4 +dnssec +multi glitter.kr DS @1.1.1.1
dig -4 +dnssec +multi _smtp._tls.glitter.kr TXT @1.1.1.1
dig -4 +dnssec +multi _25._tcp.mail.glitter.kr TLSA @1.1.1.1
dig -4 +dnssec +multi _587._tcp.mail.glitter.kr TLSA @1.1.1.1
dig -4 +dnssec +multi _443._tcp.captcha.glitter.kr TLSA @1.1.1.1
dig -4 +dnssec +multi +nocmd +noall +answer +comments glitter.kr A
dig -4 +dnssec +multi glitter.kr DS @203.248.252.2
dig -4 +dnssec +multi _mta-sts.glitter.kr TXT
delv -4 +vtrace A glitter.kr
delv -4 nonexistent123.glitter.kr A
delv -4 @1.1.1.1 +vtrace DS glitter.kr
delv -4 @1.1.1.1 _25._tcp.mail.glitter.kr TLSA
delv -4 @1.1.1.1 _587._tcp.mail.glitter.kr TLSA
delv -4 @1.1.1.1 _443._tcp.captcha.glitter.kr TLSA
curl -s https://mta-sts.glitter.kr/.well-known/mta-sts.txt
openssl s_client -starttls smtp -connect mail.glitter.kr:25

The MTA-STS policy is published at https://mta-sts.glitter.kr/.well-known/mta-sts.txt, allowing remote MTAs to verify expected MX and TLS behavior.

Direct TLS without shared edge decryption

By design, there is no CDN, reverse proxy, or WAF operating as a TLS endpoint in front of glitter.kr. All HTTPS connections are terminated directly at the origin Nginx, which then forwards traffic to backend FastAPI services on loopback.

With no intermediate decryption point, TLS is negotiated directly between the client and the server under the operator’s control. This structurally removes an entire class of man-in-the-middle vectors that rely on hidden middleboxes.

• No Cloudflare, AWS CloudFront, Akamai, or similar edge proxies.
• No mid-layer TLS termination beyond the origin host.
• Strict headers: HSTS (preload), CSP, COOP/CORP, and Referrer-Policy.
• Certificates auto-issued and renewed via Let’s Encrypt under operator-controlled DNS.

Each virtual host has a dedicated TLS configuration and maps to a specific upstream. This makes it easy to reason about which certificate, keys, and application process are responsible for any given hostname.

DANE-based SMTP over a DNSSEC trust anchor

The mail layer combines traditional e-mail authentication mechanisms with DNSSEC and DANE, so that both routing and TLS can be verified with public records.

• Mail stack: Postfix for SMTP, Dovecot for IMAP/POP.
• Policy records: SPF, DKIM, DMARC, MTA-STS, and TLSRPT.
• DANE (SMTP-TLSA): anchored in the DNSSEC-signed glitter.kr zone.
• Transparent routing: KR → SG → DE/US relays, all under the same trust chain.

Outbound mail follows a three-stage relay path to improve deliverability while keeping TLS verification rooted in DNSSEC. TLSA records for critical ports are generated from active certificates and signed in the same zone that defines MX records.

For inbound mail, strict TLS policies and SNI-based configuration ensure that encrypted delivery is the default expectation. In this model, unencrypted SMTP becomes the exception, not the baseline.

Per-service FastAPI instances with hardening

Each virtual host is backed by its own Uvicorn/FastAPI instance. Services are launched and supervised by systemd with hardening options enabled so that a compromise in one process does not easily escalate to the rest of the system.

• One Uvicorn instance per service, with clear unit names and ports.
• Hardening options such as NoNewPrivileges and RestrictNamespaces.
• All application bindings restricted to 127.0.0.1 and internal loopback.

Internal communication is strictly local. External access is mediated only by Nginx, which also terminates TLS and applies security headers. Admin panels, user-facing apps, and background APIs all follow the same pattern.

This isolation strategy keeps the blast radius small: if a particular app needs to be restarted, patched, or temporarily disabled, other services remain unaffected at the process and socket level.

Captcha and other services under the same trust model

Auxiliary services such as captcha.glitter.kr are operated under the same autonomous security principles. They are not delegated to third-party SaaS providers, but hosted as first-class applications on the same DNSSEC and DANE foundation.

TLSA records for ports such as _443._tcp.captcha.glitter.kr are generated from live certificates and signed by DNSSEC. This keeps even small utility services inside the same verifiable trust chain as the main site and mail systems.

Just like core applications, captcha and similar services run as isolated FastAPI instances behind Nginx, with loopback-only bindings and systemd hardening. The result is consistent security behavior across the entire domain, not just the primary homepage.

Operational pipeline for an autonomous edge

To make an autonomous security model sustainable, operations are kept simple but explicit. Automation is used where it reduces human error, not to hide complexity behind opaque systems.

• Logs from journald, Nginx, and systemd are unified for cross-correlation.
• DNSSEC zone re-signing, ZSK rollover, and distribution to ns1–ns5 are automated.
• ACME flows issue and renew Let’s Encrypt certificates without manual steps.

Systemd unit templates, rotation scripts, and health checks keep the behavior of the edge predictable. When something fails, it fails in a place that can be inspected directly on the host, not in a remote control plane.

Backups and configuration management follow the same philosophy: small, auditable scripts instead of large, black-box automation layers. This keeps the cognitive surface area manageable for a single operator while preserving strong guarantees.

Evaluating the autonomous model against outsourced edges

From a security evaluation perspective, the glitter.kr model trades the convenience of outsourced edges for stronger verifiability. The key criteria are how much of the path is under direct control and how much can be proven from the outside.

• No proxy intervention in TLS handshakes by design.
• Full transparency of TLS negotiation, observable at the origin host.
• Complete Root → TLD → Zone trust chain via DNSSEC and DS records.
• No external dependency required to verify DNS or TLS correctness.

When compared with commercial CDN or managed DNS platforms, this model favors consistency and spoofing resistance over global edge features. What is lost in convenience is gained in the ability to demonstrate exactly how trust is established.

Overall, this infrastructure provides greater consistency and spoofing resistance than commercial CDN or managed DNS platforms.

From outsourced security to autonomous trust

A self-hosted, physically controlled infrastructure can achieve both security and transparency by refusing to delegate critical trust decisions to third parties. glitter.kr is an example of such a design in production.

The same approach can be scaled to institutional, enterprise, or personal domains, and extended to subdomains and microservices as long as they follow the same DNSSEC, DANE, and isolation principles.

In this model, security is not a label that comes from a vendor badge. It is something that can be verified end to end with your own keys, your own servers, and your own logs.

The remaining question is simple: if you could operate an infrastructure like this, would you still outsource your trust to Cloudflare or a generic DNS cloud?

For formal references or citation, use the canonical whitepaper endpoint at whitepaper.glitter.kr or the PDF link provided in the header of this page.