<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Dns on DRM HSE</title><link>https://www.drmhse.com/tags/dns/</link><description>Recent content in Dns on DRM HSE</description><generator>Hugo</generator><language>en</language><lastBuildDate>Wed, 15 Jul 2026 23:13:04 +0300</lastBuildDate><atom:link href="https://www.drmhse.com/tags/dns/index.xml" rel="self" type="application/rss+xml"/><item><title>Reproducing Stale Nginx DNS with Docker Compose</title><link>https://www.drmhse.com/posts/nginx_stale_dns_resolved_for_domains/</link><pubDate>Tue, 28 Oct 2025 05:20:09 +0000</pubDate><guid>https://www.drmhse.com/posts/nginx_stale_dns_resolved_for_domains/</guid><description>&lt;p>A literal hostname in &lt;code>proxy_pass&lt;/code> can outlive the IP address it first resolved to. The configuration starts cleanly and requests succeed, but replacing the backend later leaves Nginx connecting to the old address. A reload appears to fix the problem because it triggers another lookup.&lt;/p>
&lt;p>I wanted a local reproduction that separated this DNS behaviour from the rest of a production system. The useful part of the exercise was not just making Nginx return &lt;code>502 Bad Gateway&lt;/code>; it was discovering why my first test could not expose the bug.&lt;/p></description></item></channel></rss>