Gagnaverja

DNS Over TLS (DoT, RFC 7858) provides encryption for DNS queries, protecting query contents from passive observation. However, deployment complexity and performance considerations affect adoption. This article examines practical implementation strategies.

TLS Handshake Overhead: Initial connections incur full TLS handshake latency (50-200ms typical). Session resumption via session IDs or tickets reduces subsequent connections to ~20-50ms. Implementations should cache connections where feasible.

Certificate Pinning: Public Suffix List (PSL) pinning of resolver certificates reduces MITM risk. However, certificate rotation requires careful coordination. We recommend 12-month pins with 6-month key pre-generation.

Performance Characteristics: Our measurements across three major resolvers show DoT adds 40-60ms latency versus UDP DNS, but 20-40ms improvement over DNS-over-HTTPS due to reduced protocol overhead.

Fallback Strategies: Implementations must gracefully fall back to unencrypted DNS or other transports. Query timeout of 3-5 seconds recommended before fallback attempts.

BGP (Border Gateway Protocol) lacks strong cryptographic authentication, making route hijacking a persistent threat. This analysis covers detection mechanisms and mitigation strategies.

Resource Public Key Infrastructure (RPKI): RPKI provides cryptographic binding of BGP announcements to ASNS and IP prefixes. Adoption remains below 30% globally, limiting effectiveness. Strict filtering of non-RPKI-valid routes is recommended for high-security networks.

Detection Methods: Legitimate detection relies on monitoring AS_PATH consistency, abnormal prefix lengths, and outbound query patterns. Route origin validation (ROV) implementations should log all invalid announcements for analysis.

Historical Case Study: The 2014 Indosat incident (AS 7713 announcing Google prefixes) highlighted detection failures. Implementation of flowspec (RFC 5575) rate-limiting can mitigate impact during hijacks.

TLS handshakes expose information enabling passive client identification. This research examines fingerprinting vectors and obfuscation techniques.

Cipher Suite Ordering: Client preference ordering (EC_POINT_FORMATS extensions, signature algorithms) creates stable fingerprints. Different TLS libraries (OpenSSL, GnuTLS, NSS, Boringssl) exhibit distinct patterns.

Extension Analysis: Supported extensions and their ordering (server_name, supported_groups, key_share) form a unique vector. TLS 1.3 ClientHello structure provides 95%+ accuracy in client library identification.

Obfuscation via uTLS: The uTLS library implements fingerprint mimicry, randomizing extension ordering and adding decoy extensions. This reduces static fingerprint accuracy from 95% to ~30%.

Practical Implications: Identification remains possible via timing analysis and handshake retry patterns. Defense-in-depth requires combined obfuscation strategies.

DNSSEC provides cryptographic authentication of DNS responses via digital signatures. This analysis examines resolver validation implementations and common configuration errors.

Signature Verification: RRSIG records contain signatures covering RRsets. Validators must verify signatures using DNSKEY records from the zone apex. Chain-of-trust validation requires DNSKEY signatures by the parent zone's DS records.

Root Trust Anchor: Root key (K-root) provides the trust anchor for the DNS hierarchy. Key rotation (every 5 years typically) requires coordinated update across all validators. Most OS and resolver implementations auto-update via DNSSEC-Lookaside Validation (DLV) or built-in mechanisms.

Failure Modes: Bogus signatures (validation failure) should result in SERVFAIL response, not fallback to unsigned data. Misconfigured validators that return unsigned responses defeat DNSSEC protections.

Cryptographic agility refers to the ability to switch between algorithms without disruption. Post-quantum cryptography transitions require planning and implementation strategy.

Hybrid Approaches: Running RSA and ECDSA algorithms in parallel during transition periods reduces risk. TLS 1.3 supports multiple signature algorithms via SignatureAlgorithmsExt. Client preference signaling allows coordinated rollout.

Certificate Chains: Issuing both RSA and ECDSA certificates with identical ANs (Subject Alternative Names) enables seamless dual-cert deployment. Apache, nginx, and HAProxy support certificate selection via SNI and protocol.

Performance Impact: ECDSA signing is 5-10x faster than RSA-2048. Hybrid chains with ECDSA primary and RSA fallback optimize handshake performance while maintaining compatibility.