Created
August 8, 2025 11:22
-
-
Save spaze/c1e100d26e8d9d07dc669905525d02bc to your computer and use it in GitHub Desktop.
"Refresh DNS" RFC draft as written by ChatGPT because bots frustrate me
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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