Skip to content

Instantly share code, notes, and snippets.

@spaze
Created August 8, 2025 11:22
Show Gist options
  • Save spaze/c1e100d26e8d9d07dc669905525d02bc to your computer and use it in GitHub Desktop.
Save spaze/c1e100d26e8d9d07dc669905525d02bc to your computer and use it in GitHub Desktop.
"Refresh DNS" RFC draft as written by ChatGPT because bots frustrate me
You are a RFC (Request For Comments, the Internet standards) document author.
Please create a RFC document that would define a new HTTP response code in the
4xx range that would instruct the HTTP client to refresh their stale DNS records.
Why? Because when moving a site to the new IP address, some HTTP clients still
query the old iP even after many hours after the DNS record should be invalid
because it has a TTL of 5 minutes or so. Format it using plain text, like the
other RFC documents usually are.
Internet Engineering Task Force (IETF) A. Example
Request for Comments: XXXX ExampleOrg
Category: Standards Track August 2025
ISSN: 2070-1721
HTTP 432 Refresh DNS Client Error Response
Abstract
This document defines a new HTTP client error status code in the 4xx
range that explicitly instructs the client to refresh its cached DNS
records for the origin host. This status code addresses operational
issues where some HTTP clients continue to use stale IP address
resolutions far beyond the advertised Time-To-Live (TTL) of DNS
records, resulting in failed connections after an origin migrates to
a new network address. A corresponding structured media type is
defined for carrying diagnostic information.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfcXXXX.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
1. Introduction
HTTP clients often depend on DNS resolvers or local caches to obtain
the IP address of an origin server. In practice, some clients
disregard DNS TTL values or retain stale entries beyond their
intended lifetime. When a server migrates to a new IP address, such
stale resolutions can lead to connection failures, degraded
performance, or connections to unintended hosts.
This document specifies a new HTTP status code in the 4xx class that
allows an origin server to instruct the client that it MUST refresh
its DNS resolution for the requested host before retrying. A
structured media type is also defined for providing machine-readable
diagnostics.
2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. New Status Code Definition
Code: 432
Short Description: Refresh DNS
Semantics:
The 432 (Refresh DNS) status code indicates that the server has
received a request that was sent to an IP address which is no
longer valid for the target host, or otherwise suspects the client
is using stale DNS resolution data.
Upon receiving this status code, a client SHOULD discard any DNS
cache entries for the request's origin host and perform a fresh
DNS lookup before retrying the request.
A server MAY include a "Retry-After" header field to indicate the
delay before retrying, though the primary instruction is to
resolve the hostname anew.
Example Response:
HTTP/1.1 432 Refresh DNS
Date: Fri, 08 Aug 2025 10:00:00 GMT
Retry-After: 0
Content-Type: application/dns-refresh+json
{
"reason": "Observed IP mismatch with current DNS A record",
"expected_ip": "203.0.113.45",
"observed_ip": "198.51.100.17",
"migration_completed": "2025-08-08T09:55:00Z",
"ttl_expired_at": "2025-08-08T10:00:00Z"
}
4. Rationale
While DNS TTLs are designed to limit cache lifetimes, empirical
evidence shows that various clients, proxies, and resolvers may
retain entries for significantly longer periods. This can occur for
reasons including:
o Browser connection pools retaining resolved IP addresses until the
pool is closed, regardless of DNS TTL.
o IoT devices with simplistic resolvers that ignore TTL entirely and
only re-resolve on restart.
o Corporate or ISP DNS resolvers that override short TTL values with
a static minimum, often several hours or days.
o HTTP libraries that cache DNS results in memory without any TTL
enforcement logic.
During server migrations, failover events, or transitions to new
hosting providers, such behavior can cause clients to continue
sending traffic to an obsolete IP address long after it has been
decommissioned. In some cases, this can result in persistent
downtime for a subset of users, even though DNS records have been
correctly updated.
The 432 status code provides an application-layer signal to trigger
re-resolution without requiring the operator to wait for misbehaving
caches to expire naturally.
5. Media Type Definition
Type name: application
Subtype name: dns-refresh+json
Required parameters: None
Optional parameters: None
Encoding considerations: Same as for application/json.
See [RFC8259].
Security considerations: See Section 5 of this document.
Interoperability considerations: None known.
Published specification: This document.
Applications that use this media type:
HTTP servers and clients that implement the 432 Refresh DNS
mechanism.
Fragment identifier considerations: Same as for application/json.
Additional information:
Magic number(s): N/A
File extension(s): .json
Macintosh file type code(s): TEXT
Person & email address to contact for further information:
A. Example <[email protected]>
Intended usage: COMMON
Restrictions on usage: None.
Author: A. Example
Change controller: IETF
6. Security Considerations
A malicious intermediary could inject a 432 response to cause
unnecessary DNS queries or to redirect a client to a malicious
address via DNS poisoning. Clients MUST ensure DNS lookups are
performed securely (e.g., via DNSSEC [RFC4033] or DNS-over-HTTPS/TLS
where available) and validate the TLS certificate of the origin host
after refreshing.
Clients SHOULD apply rate limiting to avoid excessive DNS lookups in
the presence of repeated 432 responses from a potentially misbehaving
or compromised server.
Clients receiving `application/dns-refresh+json` MUST treat it as
advisory metadata only and MUST NOT automatically trust its content
without DNS and TLS verification.
Servers SHOULD only send the 432 status when confident that the
client is using stale DNS information, to avoid unnecessary load on
DNS infrastructure and the risk of inducing denial-of-service
behavior.
7. IANA Considerations
IANA is requested to add the following entry to the HTTP Status Code
Registry:
Code: 432
Description: Refresh DNS
Reference: This document
IANA is also requested to add the following entry to the Media Types
registry:
Type name: application
Subtype name: dns-refresh+json
Reference: This document
8. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119
Key Words", BCP 14, RFC 8174, May 2017.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, December 2017.
Author's Address
A. Example
ExampleOrg
Email: [email protected]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment