Transparent updates on our infrastructure, security patches, and feature rollouts.
Port 853 now offers the hybrid post-quantum key exchange X25519MLKEM768 on DoT and DoQ, like DoH and DoH3 on port 443, and clients without it still get X25519. It has done so since 22 October 2026 at 17:33 (UTC+3), when dnsdist was rebuilt with OpenSSL 4.0.3 and quiche on BoringSSL. This closes the gap we corrected on 19 October: since dnsdist took over port 853 on 27 September, it had offered only X25519.
An internal audit on 10-11 October found that our privacy page promised more than the server delivered: client IP addresses were kept longer than intended by the DDoS defence layers and system diagnostics, short diagnostic captures of DNS traffic were kept on disk, and off-site backups containing some of these records were not encrypted. Legacy logs are purged, retention is limited, backups are encrypted, and the privacy page now lists exactly what is kept. Our resolvers keep no query logs.
Four patched forks - AdGuard Home, dnsproxy, urlfilter and dnscrypt-proxy - were replaced by dnsdist in front of Unbound, both run exactly as their authors release them. Addresses, transports and blocklists are unchanged, and no client needs reconfiguring. The reason was maintenance, not speed.
Unbound 1.26.1 was published at 08:22 UTC and was serving here at 11:48 UTC. It consolidates nine CVEs and ships a Changelog that mentions none of them, so the mapping from identifier to code had to be recovered by diffing the trees. nginx 1.31.6 carries CVE-2026-90439, whose fix is confined to the OpenSSL compatibility layer - code a BoringSSL build does not compile.
Plain DNS answered four queries in twelve while the service reported itself active and every encrypted transport was healthy. The read loop had exited on an error logged at debug level without closing its socket, so the kernel kept queueing datagrams into a buffer nothing was draining. Reported upstream as dnsproxy issue 525; the fix has been in the serving path here since 15 September.
The AdGuard Home fork was rebuilt with a DoQ 0-RTT opcode gate ported from dnsproxy v0.84.2, nginx went to 1.31.5 with the binary replaced under a live socket, and every Go service moved to 1.27.1. A month of BoringSSL was reviewed and left alone: 137 commits, no CVEs.
A truncated DNS answer is one a client is required to throw away, so the bytes in it serve nobody except a spoofed victim. Until today we filled that datagram with 1,023 to 1,256 bytes; the large public resolvers send a bare header. We now send one too: fifteen of eighteen census names dropped to 63-71 bytes. The worst case is unchanged at 20.1x, and the reason it is unchanged is the interesting part. Includes a correction: Quad9 does not behave identically to Google.
Encrypted Client Hello puts its key in a DNS HTTPS record, so one dig command tells you whether a site supports it. Of eight names checked, three publish a key and cloudflare.com is not among them. Neither DNS tool that ships with Windows can retrieve the record: Resolve-DnsName has no HTTPS type in its enum, and nslookup quietly queries A and AAAA instead. Stock PowerShell can, though, if you build the query by hand - and the answer matches the Linux result byte for byte.
Fifteen minutes of live port-53 traffic on this resolver: 17,424 queries over UDP, 309 over TCP, and five truncated replies out of 17,735. Six public resolvers advertise five different UDP buffer sizes and none uses the 1400 that RFC 9715 recommends. The fallback costs one round trip, 6.4 ms against a resolver 6.31 ms away - a figure dig's own Query time reports as zero, because it does not count the handshake.
Six transports measured with one client against one Quad9 address, so only the transport varies. A cold lookup costs 168 bytes over plain DNS, 1,052 over DNSCrypt, 7,186 over DoT, 7,781 over DoH, 11,769 over DoQ and 12,420 over DoH3 - and the two QUIC transports are the only ones where the client sends more than it receives. Includes a correction: the first version of this measurement compared two programs and blamed the protocols, and its headline was backwards.
A measurement published on 27 August said a cold DNSCrypt lookup costs more bytes than a TLS 1.3 handshake. It was live for about two and a half hours and it was backwards, because it compared dnscrypt-proxy against a different client and blamed the protocols. Same client on both arms, DNSCrypt is about seven times cheaper than DoT. What the wrong numbers were, why they survived, and what is withdrawn rather than replaced.
OpenSSH 10.1 warns when a connection negotiates a classical key exchange. The warning comes from the client and describes the server, it is suppressed entirely by pinning KexAlgorithms, and four algorithm names count as post-quantum rather than two. What to change on each side, how to check what was really negotiated, and how the same transition looks in DoH and TLS.
A maintainer reproduced the handshake deadlock and a core developer explained why the code meant to prevent it never fires. Two commits, from 2020 and 2021, neither wrong on its own.
A leak test shows which resolver answered, not whether the query was encrypted getting there. The per-protocol commands that actually check it, with the real output and the traps that produce a wrong answer.
--accept-dns defaults to true, so joining a tailnet quietly replaces the resolver you configured. How to tell, what each fix costs, and why no test reports a problem.
Restoring ten tabs puts 61 DNS queries on the wire in 145 milliseconds at a 16 ms cadence. Scored one way that burst reads as human, scored another the identical traffic reads as automated, and the only difference is whether the paired address and HTTPS queries count as one event or two. Measured against 226 real client addresses, plus three corrections to our own account of a false positive - the last of which, added on 27 August, reverses the conclusion the other two reached.
Three verified Meta crawlers were hard-banned while asking for /robots.txt. The evidence against them was a 444 our own edge rule had returned to them a moment earlier. A second loop ran the other way: a short ban erased a real user's earned history, and 69 seconds later the same client drew a far longer one. Both loops measured from the durable records, plus the determinism test that separates a client's mistake from your own and how to check a Fail2Ban jail for the same shape.
The update checker said everything was current. It said that because a systemd timer could not find the Go binary. Four components moved on 21 August, two of them carried a security label, and neither label described this deployment.
A new guide measures the two work functions behind browser proof-of-work challenges in the same WebAssembly runtime a browser uses. One SHA-256 probe costs 0.3997 microseconds; one Argon2id probe at 32 MiB costs 154.6 milliseconds - a ratio of about 387,000 to one. That inverts the difficulty settings: a memory-hard tier runs at a handful of bits where the compute tier needs 20 or more, and pushing the compute tier to 26 bits costs a real user a measured median of 19.1 seconds, with a worst run of 64.4 while a rented GPU farm barely notices. A 12-minute flood on 7 August, 67,751 challenges to 923 addresses across 525 networks in 97 countries, produced zero incorrect proofs - and the article is explicit that this shows nobody attempted the work, not that nobody could. Updated 9 August: a fleet of native solvers now answers what the flood could not - a botnet can earn about 0.6 tokens per second per core at four bits, costing it roughly 16 times our verification cost. Two corrections are published with it: one separating the derived compute figures from the measured memory-hard ones, and one retracting the claim that memory-hardness taxes an attacker's parallelism, which measurement reversed. A second flood on 9 August, 1.18 million requests in twenty-four minutes, reproduced the result on three times the scale: 2,036 challenges issued to the swarm and not one attempted, with the machine never short of capacity and DNS still answering in 25 to 43 milliseconds. Updated 11 August: the benchmark scripts are published at github.com/Ozy-666/dns-pow-bench with the raw output of four measurement passes. Repeating the run put real error bars on it - the four-bit solve median moved by 69 per cent across three passes of the same measurement, while the per-probe costs that carry the argument reproduced within 2.7 per cent.
DoH3 on this resolver failed about one connection in twenty and logged nothing. The cause is in nginx: when a post-quantum ServerHello spans two QUIC Initial packets and one is lost, the loss is detected and the CRYPTO frame is requeued, but the congestion window has collapsed below the bytes in flight and the output loop sends acknowledgements only. The client cannot derive handshake keys without that frame, so it cannot acknowledge anything, so the window never reopens. Reported as nginx/nginx#1616 with a scripted reproduction; a contributor proposed a one-line fix, #1617, which cleared the reported case on a different TLS library than the one used to verify it. Extending the test found the limit of that fix: a certificate flight large enough to fill the 12000-byte initial window deadlocks again, and post-quantum certificates are that large.
DoH, DoH3, DoT and DoQ all run on this resolver, so the same query can go through each of them and be counted. We measured round trips to a first answer, bytes on the wire per cold lookup, latency percentiles at 2% packet loss, and what the post-quantum key exchange costs. DoQ answers a full round trip before DoT and DoH; DoH3 is also QUIC but hands that round trip back to QUIC address validation, which a packet capture pinned down after we first blamed HTTP/3. Under loss the medians barely move while the tails separate completely: across 300 lookups per transport, both TCP transports land almost exactly one second above their own median at the 99th percentile, while the QUIC transports stop at 310 and 329ms. DoH3 is the transport that fails worst, and tracing that led to a bug in nginx itself, now reported upstream as nginx/nginx#1616 with a scripted reproduction.
Our DNS leak test reported a phone leaking queries to Google Public DNS. It was not. The probe zone is delegated to a host whose port 53 serves strictly as a recursive resolver, so probe queries ended in SERVFAIL. Quad9 retried 18 times, gave up, and the phone fell back to a secondary resolver 57ms later - which we then recorded as an extra 'leaked' resolver on top of the correct ones. The test itself kept working and kept finding real leaks throughout; the defect added entries rather than removing them, which is why it survived so long.
A hardening change on this resolver set nginx's http2_body_preread_size to 16k. Any value below 65535 makes nginx refuse every HTTP/2 request carrying a body - every RFC 8484 DoH POST - for at least five weeks. A new post-mortem documents the code path, the measurement, and a reproduction anyone can run on localhost.
A new how-to documents the pattern this server uses to hide its management plane: the AdGuard Home admin panel and SSH answer two devices over Tailscale and nobody else. Three gates - a localhost bind, an nginx geo allowlist, and a DNS split view from the resolver itself - plus one nftables rule for port 22, each verified from both sides.
The two remaining defence layers are live: the public edge truncates UDP answers at 1,232 bytes whatever buffer size a client advertises, and a valid DNS Cookie now exempts a client from rate limiting. Testing the truncation promise end to end also surfaced a silent 4 KB limit in dnscrypt-proxy's TCP path that had been failing large answers for years - fixed.
A reflection attack turned the resolver into a 31.8x amplifier pointed at spoofed victims in the US and Brazil. We banned no one: a size-gated response rate limiter with a TC=1 slip collapsed the amplification to 0.45x, neutralising 12,301,925 responses with zero collateral to real users.
The unified certificate behind the site and all encrypted DNS transports lives 160 hours - the condition attached to the only free way to put an IP address in a SAN. The complete production operation is now documented: issuance, ARI renewal, the watchdog and DANE guard scripts published in full, and the failure timeline.
A DNS provider served our signed zone's delegation without the NSEC record proving DS absence, and validating resolvers refused the whole subtree with EDE 22. We diagnosed it across six providers, reported it with a one-line reproduction, and the platform-wide fix is now verified. The full account is published as a runbook.
Every DDR designation the resolver returns for _dns.resolver.arpa now includes ipv4hint=194.180.189.33, on DoH, DoT and DoQ alike. A bootstrapping device can open the encrypted handshake immediately instead of first resolving the target name, saving one round trip at the moment latency is most visible.
A new flagship guide walks through the real dnsdoh.art zone record by record: DNSSEC, DANE on all four transports, the HTTPS record with ECH, DDR discovery, mail lockdown and CAA. Published together with an infrastructure change: the ECH key now rotates monthly, automatically.
A crowd-sourced IP blocklist this service imports had listed real Googlebot addresses. The firewall dropped them before nginx ever saw a request, and the site began to fall out of search. The full incident writeup is now published as a guide, with every tool included.
The resolver engine now carries four security fixes from the upstream AdGuard Home project, applied before they ship in an official release. Full technical notes are on GitHub.
Automatic discovery (DDR, RFC 9462) designates dnsdoh.art directly for DoH, DoT and DoQ. One name, one certificate carrying the resolver IP, strictly verified on every transport.
dnsdoh.art now answers Discovery of Designated Resolvers (RFC 9462) in strict verified mode. A device that knows only the resolver address 194.180.189.33 discovers the encrypted endpoints on its own, and Windows 11 fills in the DoH template automatically.
Post-quantum key exchange (X25519MLKEM768) is now live and verified across all four encrypted-DNS transports (DoH, DoH3, DoT and DoQ), and Encrypted Client Hello keeps the site name out of plaintext during the TLS handshake.
Two new evergreen guides: one explains DNS caching and TTL, including why a record can keep resolving to an old address after you change it; the other walks through what an IP address lookup actually shows about you, and what it does not.
A guide on how a site can recognise you from dozens of small browser details, even with cookies cleared and your IP hidden, and what actually reduces it.
Three guides that pair with our leak test: how the test actually works, what to do when you find a leak, and how to check whether a VPN is leaking your DNS.
Four guides on the fundamentals: what a resolver is and what it sees, how the encrypted protocols compare, what DNSSEC does and does not do, and a runbook for building your own validating resolver.
We spent the week sharpening the parts of the site you actually use: setup guides for more devices, plain-language protocol explainers, an expanded knowledge base, and a faster-loading homepage.
A wave of behind the scenes tuning makes lookups quicker and far more stable when our servers are busy. We also load tested the resolver to confirm it stays fast well beyond everyday demand.
We rebuilt the engine that looks up and security-checks your DNS requests, switching its cryptography to Google's high-speed BoringSSL for snappier encrypted lookups.
We are open-sourcing the complete architectural specification and optimization logs for our custom AdGuardHome Edge core engine.
We are open-sourcing dns-ultra, an advanced DNS diagnostic engine designed to benchmark upstream resolvers with real-world accuracy and intelligent scoring.
We have successfully migrated our custom network engine to the fresh v0.81.4 base, incorporating critical upstream DNSSEC cache fixes into our optimized stack.
We have rewritten the core DNS-over-UDP response path, deploying a package-level sync.Pool mechanism that completely eliminates heap allocations.
We are formalizing our infrastructure under the AdGuardHome-Edge designation, a high-performance, custom-optimized fork of the core AdGuard engine.
Routine component updates across our full software stack, keeping all binaries current with the latest upstream releases.
A deep tuning cycle of our kernel networking parameters has improved DNS response consistency and reduced tail latency during peak usage periods.
We have migrated to AMD EPYC Zen 2 processors and recompiled our entire software stack from source with platform-native optimizations for maximum throughput.
A comprehensive security update introducing real-time traffic monitoring, smarter flood mitigation, and improved protection for legitimate users during high-traffic events.
We have completed a major infrastructure hardening cycle, migrating our packet processing pipeline to XDP native mode and modernizing our TLS configuration to eliminate weak cipher suites.
Our nftables ruleset has been fully migrated to production mode with refined per-IP rate limiting, a global SYN circuit breaker, and improved amplification reflection defense.
We have completely re-engineered our edge packet processing pipeline, introducing eXpress Data Path (XDP) technology and a deterministic memory model for sub-millisecond traffic analysis.
Our network stack has been re-calibrated for next-gen 5G cellular connectivity. We have heavily tuned nftables for microsecond-latency packet processing.
Rapid deployment of Nginx 1.29.5 addressing upstream bugs, alongside a critical logic update to our nftables firewall engine to tighten stateful packet inspection.
We have upgraded our core network stack. Nginx 1.29.4 and OpenSSL 3.6.0 are now live, alongside the new nftables 1.1.6 firewall engine for superior performance.
A massive expansion of our edge security. We have integrated 7 global threat intelligence feeds-including FireHOL and Spamhaus-and optimized our firewall synchronization engine.
Major infrastructure hardening with kernel-level nftables firewall, intelligent bot detection, automated threat blocklists, and multi-layer rate limiting across all DNS protocols.
A complete visual overhaul (v2.0), a new IP & Fingerprint analysis tool, and implementation of our transparent legal framework.
Major architectural shift for our DNS Leak Test. Now utilizing kernel-level packet capture (tcpdump) piped to Redis for zero-latency tracking.
We have upgraded our core filtering engine to AdGuard Home v0.107.70, bringing enhanced performance, security patches, and better blocklist handling.
We have launched a professional-grade DNS Leak Test on our main site. Instantly verify your VPN security and detect transparent proxies.
November 2025 brings our biggest update yet: a complete website redesign and the integration of Redis Server for caching.
Critical update for Unbound fixing CVE-2025-11411 (Domain Hijacking vulnerability).
Core filtering engine updated to version v0.107.69 for improved stability.
Support for IPCrypt client IP encryption and stability fixes.
Routine version updates for the core trio: AdGuard Home, Unbound, and dnscrypt-proxy.
Keeping our infrastructure secure with the 2024 release cycle updates.
Optimizing the integration between AdGuard Home, Unbound, and our newly added dnscrypt-proxy.
A major security upgrade introducing dnscrypt-proxy to encrypt upstream traffic.
DNSDOH.ART goes live with a privacy-first foundation powered by AdGuard Home and Unbound.