⌕ Поиск по атласу

IETF · RFC · RFC5001

RFC5001 · DNS Name Server Identifier (NSID) Option

DNS Name Server Identifier (NSID) Option

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. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. [STANDARDS-TRACK]

Официальная английская аннотация

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. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. [STANDARDS-TRACK]

Связи документа

Официальный источник · 2007-08-01

Полные импортированные сведения карточки
{
  "id": "RFC5001",
  "number": 5001,
  "title_en": "DNS Name Server Identifier (NSID) Option",
  "title_ru": "",
  "summary_ru": "",
  "purpose_ru": "",
  "use_ru": "",
  "full_translation_path": "",
  "full_translation_checked_at": "",
  "full_translation_source_sha256": "",
  "architect_note_ru": "",
  "topics_ru": [],
  "translation_state": "not_prepared",
  "verification_level": "not_prepared",
  "verification_level_ru": "Русская выжимка не подготовлена",
  "verification_note_ru": "",
  "abstract_en": "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. While existing ad-hoc mechanisms allow an operator to send follow-up queries when it is necessary to debug such a configuration, the only completely reliable way to obtain the identity of the name server that responded is to have the name server include this information in the response itself. This note defines a protocol extension to support this functionality. [STANDARDS-TRACK]",
  "authors": [
    "R. Austein"
  ],
  "organizations": [],
  "publication_date": "2007-08-01",
  "current_status": "PROPOSED STANDARD",
  "current_status_ru": "Предлагаемый стандарт",
  "publication_status": "PROPOSED STANDARD",
  "publication_status_ru": "Предлагаемый стандарт",
  "lifecycle": "active",
  "lifecycle_ru": "Действующий",
  "stream": "IETF",
  "stream_ru": "IETF",
  "area": "int",
  "area_ru": "Интернет",
  "working_group": "dnsext",
  "source_draft": "draft-ietf-dnsext-nsid-02",
  "page_count": 11,
  "doi": "10.17487/RFC5001",
  "keywords": [
    "domain name space",
    "namespace"
  ],
  "formats": [
    "TXT",
    "HTML"
  ],
  "relations": {
    "obsoletes": [],
    "obsoleted_by": [],
    "updates": [],
    "updated_by": [],
    "is_also": [],
    "see_also": []
  },
  "links": {
    "info": "https://www.rfc-editor.org/info/rfc5001/",
    "html": "https://www.rfc-editor.org/rfc/rfc5001.html",
    "txt": "https://www.rfc-editor.org/rfc/rfc5001.txt",
    "datatracker": "https://datatracker.ietf.org/doc/rfc5001/"
  }
}