RFC 4892: Requirements for a Mechanism Identifying a Name Server Instance
In plain English — editorial summary, not part of the RFC
With the increased use of DNS anycast, load balancing, and other mechanisms allowing more than one DNS name server to share a single IP address, it is sometimes difficult to tell which of a pool of name servers has answered a particular query. A standardized mechanism to determine the identity of a name server responding to a particular query would be useful, particularly as a diagnostic aid for administrators. Existing ad hoc mechanisms for addressing this need have some shortcomings, not the least of which is the lack of prior analysis of exactly how such a mechanism should be designed and deployed. This document describes the existing convention used in some widely deployed implementations of the DNS protocol, including advantages and disadvantages, and discusses some attributes of an improved mechanism. This memo provides information for the Internet community.
Document record
- Document ID
- RFC4892
- Published
- June 2007
- Authors
- S. Woolf; D. Conrad
- Status
- INFORMATIONAL
- Stream
- IETF
- Area
- ops
- Pages
- 8
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 4074Common Misbehavior Against DNS Queries for IPv6 AddressesCurrent
June 2005
- RFC 4891Using IPsec to Secure IPv6-in-IPv4 TunnelsCurrent
May 2007
- RFC 4890Recommendations for Filtering ICMPv6 Messages in FirewallsCurrent
May 2007
- RFC 4883Benchmarking Terminology for Resource Reservation Capable RoutersCurrent
July 2007
- RFC 4878Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like InterfacesCurrent
June 2007
- RFC 4864Local Network Protection for IPv6Current
May 2007
- RFC 4852IPv6 Enterprise Network Analysis - IP Layer 3 FocusCurrent
April 2007
- RFC 4935Fibre Channel Fabric Configuration Server MIBCurrent
August 2007
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?