Добавление записи ресурса DNS | Microsoft Docs
- Чтение занимает 2 мин
В этой статье
Применяется к: Windows Server (Semi-Annual Channel), Windows Server 2016Applies to: Windows Server (Semi-Annual Channel), Windows Server 2016
С помощью этого раздела можно добавить в консоль клиента IPAM одну или несколько новых записей ресурсов DNS.You can use this topic to add one or more new DNS resource records by using the IPAM client console.
Для выполнения этой процедуры необходимо быть членом группы Администраторы или пользователем с аналогичными правами.Membership in Administrators, or equivalent, is the minimum required to perform this procedure.
Добавление записи ресурса DNSTo add a DNS resource record
В диспетчер сервера щелкните IPAM.In Server Manager, click IPAM. Откроется консоль клиента IPAM.The IPAM client console appears.
В области навигации в окне мониторинг и управление щелкните зоны DNS.In the navigation pane, in MONITOR AND MANAGE, click DNS Zones. Панель навигации разделяется на верхнюю панель навигации и нижнюю панель навигации.The navigation pane divides into an upper navigation pane and a lower navigation pane.
В нижней области навигации щелкните
Right-click the zone where you want to add a resource record, and then click Add DNS resource record.Откроется диалоговое окно
Диалоговое окно разворачивается для отображения
Отобразится список типов записей ресурсов.The list of resource record types is displayed. Выберите тип записи ресурса, который требуется добавить.Click the resource record type that you want to add.
В окне Новая запись ресурса в списке имя введите имя записи ресурса.In New Resource Record, in Name
Если вы не хотите создавать дополнительные записи ресурсов, нажмите кнопку ОК.If you do not want to create additional new resource records, click OK.
Если вы хотите создать дополнительные записи ресурсов, нажмите кнопку Диалоговое окно разворачивается для отображения новой записи ресурса.The dialog box expands to reveal New Resource Record. Щелкните тип записи ресурса.Click Resource record type. Отобразится список типов записей ресурсов.The list of resource record types is displayed. Выберите тип записи ресурса, который требуется добавить.Click the resource record type that you want to add.
В окне Новая запись ресурса в списке имя введите имя записи ресурса.In
Если требуется добавить дополнительные записи ресурсов, повторите эту процедуру для создания записей.If you want to add more resource records, repeat the process for creating records. По завершении создания новых записей ресурсов нажмите кнопку
В диалоговом окне Добавление записи ресурса отображаются сводные записи о ресурсах, в ходе которых IPAM создает записи ресурсов на указанном DNS-сервере.The Add Resource Record dialog box displays a resource records summary while IPAM creates the resource records on the DNS server that you specified. После успешного создания записей состояние записи — Success.When the records are successfully created, the
Нажмите кнопку ОК.Click OK.
Right-click the zone where you want to add a resource record, and then click Add DNS resource record.
Click Resource record type.
Если вы хотите создать дополнительные записи ресурсов, нажмите кнопку 
Щелкните Добавить запись ресурса.Click Add Resource Record.
См. также:See Also
Управление записью ресурса DNS Управление IPAMDNS Resource Record Management Manage IPAM
Типы DNS записей | 2IP.ua
Записи DNS, или Ресурсные записи (англ. Resource Records, RR) — единицы хранения и передачи информации в DNS.
Наиболее важные типы DNS-записей:
- Запись A.
- Запись AAAA.
- Запись CNAME.
- Запись MX.
- TXT-запись.
- Запись PTR.
- Запись SOA.
- SRV-запись.
Запись A задает IP-адрес этого хоста. С помощью записей A выполняется запрос на преобразование имени домена в IP-адрес.
Запись AAAA (IPv6 address record) связывает имя хоста с адресом протокола IPv6. Например, запрос AAAA-записи на имя K.ROOT-SERVERS.
NET вернет его IPv6 адрес — 2001:7fd::1
Запись типа CNAME (Canonical Name — Каноническое имя) позволяют присваивать хосту мнемонические имена. Если DNS при обращении к псевдониму обнаруживает запись CNAME, содержащую полное имя, DNS затем запрашивает полное имя домена.
Записи MX содержат определение хоста системы обмена почтой для почтовых сообщений, отправляемых в этот домен. С помощью записей этого типа и значений параметров конфигурации хостов системы обмена почтой в SMTP (Простой протокол передачи почты) определяются адреса хостов, обрабатывающих и перенаправляющих почту для этого домена. Каждому хосту системы обмена почтой должна соответствовать запись адреса хоста (A) в существующей области.
Запись NS указывает ответственный сервер для данного хоста.
Запись типа TXT обычно используется для текстового описания доменного имени.
Запись PTR (pointer) или запись указателя связывает IP хоста с его каноническим именем.
Запись SOA (Start Of Authority) содержит имя первичного DNS-сервера (Primary Name Server), адрес, необходимый для установления технических контактов (Hostmaster), серийный номер (Serial number) различные значения таймеров (Refresh, Retry, Expire, Minimum TTL)
SRV-запись (server selection) указывает на серверы для сервисов, используется, в частности, для Jabber и Active Directory.
Все о ресурсных записях DNS
DNS-записи — это набор записей, используемых для предоставления информации о доменной зоне.
DNS-записи хранятся на DNS-серверах и содержат данные о обработке запросов связанных с доменом. Каждая запись отвечает за определенный функционал и имеет свое назначение. В ресурсных записях можно найти информацию о IP-адресе на какой ссылается домен, алиасы к домену, данные об использовании служб, серверах и т.д.
Эти записи помогают пользователям подключать свои веб-сайты к использованию в сети Интернет.
Больше информации о настройке и обновлении DNS на хостинге можно узнать в нашей статье здесь.
DNS записи могут быть двух типов: статическими и динамическими.
- Статическая запись — это запись, в которой нет информации о метке времени (вместо этого в свойствах метки времени будет указано “static”). Статическая запись может быть обновлена или удалена с DNS-сервера только по команде администратора или другой программы.
- Динамическая запись — это запись с добавленной меткой времени. Обычно создается автоматически клиентской машиной, которая получает IP-адрес от сервера DHCP, или также может быть создан вручную на сервере DNS. Временная метка указывает период действия записи, если запись не обновляется или не обновляется после того, как прошло время, указанное в метке времени, то она может быть удалена при возникновении очистки DNS.
Временная метка указывает период действия записи, если запись не обновляется или не обновляется после того, как прошло время, указанное в метке времени, то она может быть удалена при возникновении очистки DNS.Существует много DNS записей основные с них : A, AAAA, CNAME, MX, PTR, TXT, NS, SRV записи.
A запись являются наиболее базовым типом записи DNS и используются для направления домена или субдомена на IP-адрес (используется для 32-битных адресов IPv4).
Где:
Name — имя записи (указываем доменное имя).
IP — значение записи (указываем IP сервера).
TTL (Time to Live) — время обновления информации о записи ( время в секундах, хранения записи в кеше DNS системы) .
A записи могут принимать только IP-адрес в качестве значения, Вы можете направить один и тот же домен / поддомен на несколько IP-адресов, просто добавив еще одну запись A с тем же именем, но с другим IP-адресом в поле “значение”.
Запись AAAA (также запись quad-A) указывает адрес IPv6 для данного хоста. Таким образом, он работает так же, как запись A, и разница заключается в типе IP-адреса.
Записи CNAME (Canonical Name Record — запись канонического имени) являются другим часто используемым типом записи DNS.
CNAME используется для создания псевдонима для существующей A и AAAA записи. При этом в поле со значением заполняется именем домена, которое ранее было связано с IP-адресом в файле. Таким образом, разные адреса могут ссылаться на один и тот же сервер. Например, псевдоним «service.google.ru» может использоваться для указания на существующую A-запись «story.google.ru», где размещен сервис.
Записи CNAME действительно полезны, когда мы хотим сделать перенаправление части сайта на сайт, который находится в другом месте и при запуске нескольких служб (таких как FTP и веб-сервер) с одного IP-адреса. Каждая служба может иметь свою собственную запись в DNS (например, support.
google.ru или ftp.google.ru).
Вас также могут попросить ввести запись CNAME, чтобы подтвердить право собственности на домен для онлайн-сервисов, таких как Google Apps.
В других случаях мы можем удалить записи CNAME и заменить их A записями и снизить накладные расходы на производительность.
Запись ресурса MX ( Mail Exchange — почтовый обмен) используется специально для отправки электронной почты и указывает сервер обмена почтой для доменного имени DNS. Эта информация используется протоколом SMTP для маршрутизации электронной почты на соответствующие узлы. Здесь определен один или несколько почтовых серверов, которые принадлежат соответствующему домену. При использовании нескольких почтовых серверов (например, для компенсации сбоя), лучше сразу указать разные уровни приоритета.
Номер приоритета используется для указания того какой из серверов, перечисленных в записях MX, следует попытаться использовать в первую очередь. Чем ниже значение приоритета, приоритет 0 является наивысшим приоритетом, тем выше приоритетное значение указанного почтового ящика (письма в первую очередь будут приходить туда, если приоритет одинаковый, то ящик для приема писем будет выбран рандомно).
Запись PTR является аналогом записи A. По сути это обратная запись A, где поле «имя» содержит информацию о IP-адресе, а поле «значение» содержит строку имени хоста. Запись PTR используется для сопоставления IP-адреса с соответствующим именем хоста, обычно используется для определения того, какое имя хоста использует указанный IP-адрес.
TXT или текстовая запись — это особый тип записи DNS. Он не используется для пересылки трафика, а используется для предоставления информации о домене. TXT может быть создан в любой зоне в виде статической или динамической записи. Поле «имя» и поле «значение» могут быть заполнены чем угодно, как того требует программа или протокол. TXT запись часто используется для подтверждения владение доменом ( например, при добавлении Google-метрики на сайт).
SRV или служебная запись — это тип DNS-записи, используемой для указания служб. Запись SRV предоставляет информацию о том, какие службы доступны в определенной зоне или домене.
Запись SRV имеет формат для поле «имя», где она начинается с имени службы, имени протокола, а затем имени зоны или домена. А поле «значение» будет содержать несколько сведений, таких как приоритет, вес, номер порта службы и имя хоста, на котором находится служба.
Service — название службы, для которой предназначена запись SRV ( начинать ввод название с префикса подчеркивания ).
Protocol — название протокола для службы ( тоже с префиксом вначале).
Domain — домен для которого предназначена запись SRV.
Type — тип записи DNS, по умолчанию установлена на «SRV».
Priority — приоритет записи SRV. Низший приоритет считается наиболее важным. Суть похожая как и для указания приоритета в записи MX.
Weight — используется для разрыва связи, когда две или более записи SRV имеют одинаковый приоритет.
Port — порт для использования службы.
Target — полное доменное имя (FQDN) хоста, предоставляющего эту услугу.
NS запись — это DNS-запись, основная ее цель связывать домен и хостинг, в ней содержится список доверенных серверов имен для домена. Для этого нужно добавить в запись NS-сервера, которые предоставляет Ваш текущий хостинг провайдер для той или иной услуги. Минимум может быть два NS-сервера
Например, NS-ы нашей компании HyperHost следующие:
Для виртуального хостинга:
dns1.hyperhost.ua
dns2.hyperhost.ua
Для виртуальных серверов:
vps1.hyperhost.ua
vps2.hyperhost.ua
SOA запись или Start of Authority — это запись DNS, которая содержит имя сервера, на котором хранится вся информация, касающаяся этой записи. Он включает в себя достоверную информацию, такую как идентификационный номер сервера, ответственный почтовый адрес, основной сервер имен и т. д. Предполагается, что сервер, на который есть ссылка в записи SOA, отвечает за любой процесс в соответствующей записи.
Primary server — главный сервер имен для домена.
Должен быть указан только один сервер имен, даже если в домене есть несколько авторитетных серверов имен.
Hostmaster — адрес почты администратора домена.
Serial — «номер версии» для записи SOA. Он увеличивается каждый раз, когда обновляется файл зоны, в котором находится запись SOA. Допустимые значения: от 1 до 4 294 967 295.
Refresh — время в секундах, в течение которого подчиненный сервер имен должен ждать, перед обновлением файла зоны.
Retry — время в секундах, в течение которого подчиненный сервер имен должен ждать, прежде чем пытаться установить соединение с ведущим устройством после ошибки связи.
Expire — время в секундах, которое может пройти до того, как файл зоны больше не считается достоверным.
Minimum TTL — минимальное время в секундах для кэширования.
Настройка DNS записей очень важна для корректной работы домена и сопутствующих служб, поэтому до этого дела нужно подойти очень серьезно.
Если на каком-то этапе добавления записей у Вас возникли вопросы или трудности тех.поддержка ГиперХост с радостью помогут Вам с этим.
Типы ресурсных записей DNS. Ресурсные записи DNS
Пользователи также искали:
cname dns, cname запись, dns запись что значит @, dns запись что значит собака, отсутствуют dns записи для узла, приоритет dns записи, типы dns серверов, запись, Типы, типы, записи, cname, значит, записей, cname запись, cname dns, как работает dns, приоритет dns записи, отсутствуют dns записи для узла, типы dns серверов, собака, работает, приоритет, отсутствуют, узла, серверов, ресурсных, dns запись что значит собака, dns запись что значит, Типы ресурсных записей DNS, типы ресурсных записей dns,
DNS — wiki студи Клондайк
DNS (англ.
Domain Name System — система доменных имён)— компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты, обслуживающих узлах для протоколов в домене (SRV-запись).
Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.
Основой DNS является представление об иерархической структуре доменного имени и зонах. Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть домена другому серверу (с административной точки зрения — другой организации или человеку), что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей), отвечающих только за «свою» часть доменного имени.
DNS обладает следующими характеристиками:
- Распределённость администрирования. Ответственность за разные части иерархической структуры несут разные люди или организации.
- Распределённость хранения информации. Каждый узел сети в обязательном порядке должен хранить только те данные, которые входят в его зону ответственности, и (возможно) адреса корневых DNS-серверов.
- кэширование информации. Узел может хранить некоторое количество данных не из своей зоны ответственности для уменьшения нагрузки на сеть.
- Иерархическая структура, в которой все узлы объединены в дерево, и каждый узел может или самостоятельно определять работу нижестоящих узлов, или делегировать (передавать) их другим узлам.
- Резервирование. За хранение и обслуживание своих узлов (зон) отвечают (обычно) несколько серверов, разделённые как физически, так и логически, что обеспечивает сохранность данных и продолжение работы даже в случае сбоя одного из узлов.
Ответственность за разные части иерархической структуры несут разные люди или организации.Дополнительные возможности DNS
- поддержка динамических обновлений
- защита данных (DNSSEC) и транзакций (TSIG)
- поддержка различных типов информации
Ключевыми понятиями DNS являются:
| Понятие | Значение |
|---|---|
Домен (англ. domain — область) | — узел в дереве имён, вместе со всеми подчинёнными ему узлами (если таковые имеются). |
| Поддомен (англ. subdomain) | — подчинённый домен (например, klondike-studio.ru — поддомен домена ru). |
| Ресурсная запись | — единица хранения и передачи информации в DNS. Каждая ресурсная запись имеет имя (то есть привязана к определенному Доменному имени, узлу в дереве имен), тип и поле данных, формат и содержание которого зависит от типа. |
| Зона | — часть дерева доменных имен (включая ресурсные записи), размещаемая как единое целое на некотором сервере доменных имен (DNS-сервере, см. ниже), а чаще — одновременно на нескольких серверах. |
| Делегирование | — операция передачи ответственности за часть дерева доменных имен другому лицу или организации. |
| DNS-сервер | — специализированное ПО для обслуживания DNS, а также компьютер, на котором это ПО выполняется. |
| DNS-клиент | — специализированная библиотека (или программа) для работы с DNS. В ряде случаев DNS-сервер выступает в роли DNS-клиента. |
| Авторитетность (англ. authoritative) | — признак размещения зоны на DNS-сервере. Ответы DNS-сервера могут быть двух типов: авторитетные (когда сервер заявляет, что сам отвечает за зону) и неавторитетные. |
| Non-authoritative | когда сервер обрабатывает запрос, и возвращает ответ других серверов. В некоторых случаях вместо передачи запроса дальше DNS-сервер может вернуть уже известное ему (по запросам ранее) значение (режим кэширования). |
| DNS-запрос (англ. DNS query) | — запрос от клиента (или сервера) серверу. Запрос может быть рекурсивным или нерекурсивным. |
| Тип | Расшифровка названия (англ. ) | Код | Описание | Употребимость | RFC |
|---|---|---|---|---|---|
| A | Address | 1 | Адресная запись, соответствие между именем и IP-адресом | одна из самых часто используемых записей | RFC 1035 |
| A6 | Address version 6 | 38 | Адрес в формате IPv6 | заменена на AAAA из-за чрезмерной сложности в реализации, статус «экспериментальной».[1] | RFC 3363, RFC 2874 |
| AAAA | A+1+1+1 (A использовался для IPv4, AAAA для IPv6) | 28 | Адрес в формате IPv6 | эквивалента А для IPV4 | RFC 3596 |
| AFSDB | AFS database | 18 | Расположение базы данных AFS | редкоупотребимая, чаще используется SRV-запись | RFC 1183 |
| CNAME | Canonical name | 5 | Каноническое имя для псевдонима (одноуровневая переадресация) | широко используется (но имеет ограничения по применению) | RFC 1035 |
| DNAME | Domain Name | 39 | Псевдоним для домена | ? | RFC 2672 |
| DNSKEY | DNS Key record | 48 | Ключ подписи в DNSSEC. Формат — как в записи KEY. | DNSSEC | RFC 4034 |
| DS | Delegation signer | 43 | Отпечаток (fingerprint) ключа подписи в DNSSEC | DNSSEC | RFC 3658 |
| GPOS | Geographical position | 27 | Географическое положение | устарела, см LOC | RFC 1712 |
| HINFO | Host Information | 13 | Информация об узле | редкоупотребима | RFC 1035 |
| ISDN | ISDN address | 20 | Адрес в формате ISDN | редкоупотребима (из-за малой популярности сетей ISDN без IP-маршрутизации) | RFC 1183 |
| KEY | Public key | 25 | Открытый ключ, используется в DNSSEC | малоупотребима | RFC 2535, RFC 3445 |
| KX | Key Exchanger | 36 | ? | ? | RFC 2230 |
| LOC | Location information | 29 | Географическое местоположение домена | ? | RFC 1876 |
| MB | Mailbox | 7 | Почтовый ящик | редкоупотребима | RFC 1035 |
| MD | Mail destination | 3 | Почтовый адрес | устарела | RFC 1035 |
| MF | Mail forwarder | 4 | Перенаправление почты | устарела | RFC 1035 |
| MG | Mail group member | 8 | Номер почтовой группы | редкоупотребима | RFC 1035 |
| MINFO | Mailbox or mailing list information | 14 | Информация о почтовом ящике или рассылке | ? | RFC 1035 |
| MR | Mail rename domain name | 9 | ? | редкоупотребима | RFC 1035 |
| MX | Mail Exchanger | 15 | Адрес почтового шлюза для домена. Состоит из двух частей — приоритета (чем число больше, тем ниже приоритет), и адреса узла | критически важна для SMTP-протокола, основа маршрутизации почты в Интернете | RFC 1035 |
| NAPTR | Naming authority pointer | 35 | Указатель на авторитетный узел именования (используется для IP-телефонии) | малоупотребима | RFC 3263, RFC 3403 |
| NULL | Null record | 10 | Пустая запись | редкоупотребима | RFC 1035 |
| NS | Authoritative name server | 2 | Адрес узла, отвечающего за доменную зону. Критически важна для функционирования самой системы доменных имён | DNS | RFC 1035 |
| NSAP | Network service access point address | 22 | Указатели в стиле OSI | редкоупотребима | RFC 1706 |
| NSAP-PTR | NSAP pointer | 23 | Указатель на NSAP | устарела | RFC 1348 |
| NSEC | Next-Secure record | 47 | Часть DNSSEC — подтверждение отсутствие записи. Формат — как у NXT. | DNSSEC | RFC 4034 |
| NSEC3 | Next-Secure record | 50 | Расширение DNSSEC, подтверждающее отсутствие записи без возможности просмотра содержимого зоны | DNSSEC | RFC 5155 |
| NSEC3PARAM | NSEC3 parameters | 51 | Запись с параметрами для NSEC3. | DNSSEC | RFC 5155 |
| NXT | Next domain | 30 | Указатель на следующий домен подписанной зоны | DNSSEC | RFC 2065 |
| PTR | Domain name pointer | 12 | Реализует механизм переадресации | широко используется для IPv4-адресов в домене in-addr.arpa, для IPv6 — в ip6.arpa | RFC 1035 |
| PX | Pointer to X.400 | ? | Указатель на систему маршрутизации почты X.400 | X.400 | RFC 822, RFC 2163 |
| RP | Responsible person | 17 | Ответственный | ? | RFC 1183 |
| RRSIG | DNSSEC signature | 46 | Подпись записи средствами DNSSEC. Формат — как у SIG. | DNSSEC | RFC 4034 |
| RT | Route through | 21 | Указание на узел, через который следует осуществлять маршрутизацию | малоупотребима | RFC 1183 |
| SIG | Cryptographic public key signature | 24 | Сигнатура публичной подписи | малоупотребима | RFC 2931 |
| SOA | Start of authority | 6 | Указание на авторитетность информации, используется для указания на новую зону | DNS | RFC 1035 |
| SPF | Sender Policy Framework | 99 | Указывает сервера, которые могут отправлять почту с данного домена | Должна заменить spf запись, которая размещается в TXT | RFC 4408 |
| SRV | Server selection | 33 | Указание на местоположение серверов для сервисов | Jabber, Active Directory | RFC 2782 |
| TKEY | Transaction key | 249 | Метод распространения ключей для TSIG-записей | ? | RFC 2930 |
| TLSA | Certificate association | 52 | Ресурсная запись DANE | ? | RFC 6698 |
| TSIG | Transaction signature | 250 | Идентификация для DNS-операций с использованием общих секретных ключей и хэшей | при передаче зон между DNS-серверами | RFC 2845 |
| TXT | Text string | 16 | Запись произвольных двоичных данных, до 255 байт в размере | Sender Policy Framework (устарело), DNS-туннели | RFC 1035 |
| WKS | Well-known service | 11 | Список доступных общеизвестных сервисов (общеизвестные — с регистрированными номерами портов) | ? | RFC 1035 |
| X25 | PSDN address | 19 | Адрес в формате X.25 | редкоупотребима | RFC 1183 |
Привязка домена и поддомена в обновленной панели reg.ru – База знаний LPgenerator.ru
Здравствуйте, дорогие друзья!
В этом руководстве мы подробно рассказываем, как привязать существующий домен к платформе LPgenerator в панели регистратора доменных имен reg.ru с обновленным дизайном личного кабинета.
В случае, если ваш личный кабинет reg.ru по-прежнему отображается в старом дизайне, пожалуйста, воспользуйтесь иным руководством, доступным по следующей ссылке: привязка домена и поддомена в панели reg.ru.
Подготовка к привязке домена1. Перейдите по следующей ссылке и войдите в личный кабинет регистратора reg.ru. На открывшейся странице выберите в панели сверху пункт «Домены»:
2. Отыщите в списке домен, который вы желаете привязать к платформе. Кликните по его названию:
3. Нажмите на кнопку «Изменить» напротив пункта «DNS-серверы и зона»:
4. Убедитесь, что в блоке настроек «DNS-серверы» установлены те же параметры, как и на следующем скриншоте:
Если DNS-серверы не совпадают с «ns1.reg.ru» и «ns2.reg.ru» (бесплатными DNS-серверами reg.ru), кликните по иконке карандаша в правом верхнем углу карточки параметров:
В раскрывшемся справа списке выберите пункт «Бесплатные DNS-серверы REG.RU»:
Подтвердите изменение DNS-серверов:
В случае успеха вы получите уведомление о том, что изменения внесены.
При возникновении каких-либо ошибок на данном этапе, пожалуйста, обратитесь в службу поддержки пользователей регистратора reg.ru.
Привязка домена к платформе1. Прокрутите страницу ниже, до раздела «Ресурсные записи». Убедитесь, что в списке отсутствуют A-записи, указывающие на корень домена «@», и CNAME-записи, указывающие на «www». Примеры таких записей отражены на скриншоте ниже:
Если подобные записи есть в списке, удалите их, кликнув поочередно по иконке корзины напротив каждой из записей:
2. Кликните по кнопке «Добавить запись»:
3. В отобразившемся справа списке выберите тип записи «А»:
4. Введите следующие значения в предложенные поля и сохраните DNS-запись:
- Subdomain: @
- IP Address: 164.132.93.140
5. Повторите действия согласно пунктам 2-4, только на этот раз значение IP-адреса для записи с типом A будет другим:
Subdomain: @
IP Address: 164.132.93.141
6. Таким же образом добавьте новую запись, только на этот раз с типом «CNAME». Обязательно убедитесь, что в поле «Canonical name», в записи «testlpgenerator.ru.» присутствует точка в конце:
- Subdomain: www
- Canonical name: testlpgenerator.ru.
7. Проверьте список и убедитесь в том, что в нем отображаются все только что добавленные DNS-записи.
Настройка завершена. Теперь вы можете публиковать лендинги по адресу домена согласно следующему руководству: как опубликовать страницу в интернете и изменить ее адрес?
Обратите внимание: после изменения DNS-записей должно пройти некоторое время для обновления списков на мировых DNS-серверах. Ваш домен станет активен после обновления серверов, которое обычно занимает от 4-x до 24-х часов.
По любым возникшим вопросам обязательно обращайтесь к нашим специалистам службы технической поддержки. По будням, с 10 до 18 часов по Москве мы доступны по номеру телефона 8(800)505-72-45, а с 11 до 19 часов с нами можно будет связаться в рамках Skype (логин: lpgenerator).
Также мы будем рады ответить на любые ваши вопросы, адресованные на email-адрес [email protected], круглосуточно и без выходных.
Высоких Вам конверсий!
С уважением,
команда LPgenerator.
записей ресурсов DNS — Cisco
Записи ресурсовопределяют типы данных в системе доменных имен (DNS). Записи ресурсов, идентифицированные RFC 1035, хранятся во внутреннем двоичном формате для использования программным обеспечением DNS. Но записи ресурсов отправляются по сети в текстовом формате во время передачи зон. В этом документе обсуждаются некоторые из наиболее важных типов записей ресурсов.
Примечание: Существует ряд других типов записей, которые активно не поддерживаются.К ним относятся адрес электронной почты (MD), пересылка почты (MF), почтовая группа (MG), информация о почтовом ящике или списке рассылки (MINFO), переименование почты (MR) и NULL. Вы можете получить полный список типов записей DNS в параметрах DNS IANA.
Требования
Для этого документа нет особых требований.
Используемые компоненты
Этот документ не ограничивается конкретными версиями программного и аппаратного обеспечения.
Условные обозначения
Дополнительные сведения об условных обозначениях в документах см. В разделе «Условные обозначения технических советов Cisco».
На верхнем уровне домена база данных имен должна содержать запись Start of Authority (SOA). Эта запись SOA определяет лучший источник информации для данных в домене. SOA содержит текущую версию базы данных DNS и различные другие параметры, которые определяют поведение конкретного DNS-сервера.
Должна быть ровно одна запись SOA для каждого домена сервера имен (каждого поддомена). Это относится к поддоменам IN-ADDR.ARPA (обратные домены).Область пространства имен, имеющая отдельную SOA, называется зоной.
Формат этой записи виден в этих выходных данных. Значения, указанные для временных интервалов в этой SOA, рекомендованы RFC 1537.
ИМЯ ДОМЕНА. IN SOA Hostname.Domain.Name. Mailbox.Domain.Name. (
1; серийный номер
86400; обновление в секундах (24 часа)
7200; повторить попытку в секундах (2 часа)
2592000; истекает через секунды (30 дней)
345600); TTL в секундах (4 дня)
Рекорд SOA для вымышленного файла foo.edu может выглядеть примерно так:
FOO.EDU. В SOA FOO.EDU. Joe_Smith.Foo.EDU. (
2; серийный номер
28800; обновить через 8 часов
7200; повторить попытку через 2 часа
604800; истекает через 7 дней
86400); TTL - 1 день Поля данных записи SOA
В этом списке объясняются поля данных вымышленной записи SOA.
ДОМЕННОЕ ИМЯ. —Имя домена, к которому относится запись SOA. Обратите внимание на конечную точку (.). Это означает, что к имени нельзя добавлять суффикс.
IN —Класс записи DNS. IN означает «Интернет».
SOA —Тип записи DNS, начало полномочий в этом примере.
Имя хоста.Домен.Имя. —Поле происхождения должно содержать имя хоста первичного сервера имен для этой зоны, хоста, на котором находятся авторитетные данные.
Почтовый ящик.Домен.Имя. —Почтовый ящик лица, ответственного за (службу имен) этого домена. Чтобы преобразовать это поле в пригодный для использования адрес электронной почты, замените первую точку (.) На @ (знак at). В этом примере, если есть проблемы с foo.edu, отправьте электронное письмо на адрес [email protected].
Серийный номер — серийный номер текущей версии базы данных DNS для этого домена.Серийный номер — это средство, с помощью которого другие серверы имен узнают, что ваша база данных была обновлена. Этот серийный номер начинается с 1 и должен быть монотонно увеличивающимся целым числом. Не ставьте десятичную точку в серийный номер, так как это может привести к запутанным и неприятным результатам. Некоторые администраторы DNS используют дату последнего изменения в качестве серийного номера в формате ГГММДДЧЧММ, другие просто увеличивают serno на небольшое число при каждом обновлении базы данных. Половинная скобка, которая стоит перед serno и закрывается после минимального времени жизни (TTL), позволяет SOA занимать несколько строк.
Когда вторичный сервер имен для домена foo.edu связывается с первичным сервером имен, чтобы проверить, не было ли изменений в базе данных DNS первичного, и если вторичный сервер должен выполнить передачу зоны, он сравнивает свой собственный серийный номер с серийным номером первичный сервер имен.
Если серийный номер вторичного сервера имен выше, чем у первичного, перенос зоны не происходит. Если серийный номер первичного сервера имен больше, вторичный сервер имен выполняет передачу зоны и обновляет свою собственную базу данных DNS.
Другие числовые поля известны как поля TTL. Они контролируют частоту, с которой серверы имен опрашивают друг друга для получения обновлений информации (например, как долго данные хранятся в кэше и т. Д.).
Refresh — Сообщает вторичному серверу имен, как часто опрашивать первичный сервер имен и как часто проверять изменение серийного номера. Этот интервал влияет на время, необходимое для распространения изменений DNS, внесенных на основном сервере имен.
Retry —Интервал в секунду, с которым вторичный сервер имен пытается повторно подключиться к первичному серверу имен в случае, если ему не удалось подключиться в течение интервала обновления.
Expire —Количество секунд, по истечении которых вторичный сервер имен должен «истечь» данные первичного сервера имен, если ему не удается повторно подключиться к первичному серверу имен.
TTL — значение по умолчанию, которое применяется ко всем записям в базе данных DNS на сервере имен.Для каждой записи ресурса DNS можно настроить значение TTL. TTL по умолчанию для записи SOA используется только в том случае, если для конкретной записи ресурса не настроено явное значение. Это значение предоставляется официальными серверами имен (первичным и вторичным серверами имен для определенной зоны), когда они отвечают на запросы DNS.
Каждый субдомен, который имеет отдельное имя, должен иметь по крайней мере одну соответствующую запись службы имен (NS). Серверы имен используют записи NS для поиска друг друга.
Запись NS имеет следующий формат:
ИМЯ ДОМЕНА. IN NS Hostname.Domain.Name.
Значение NS-записи для домена — это имя сервера имен для этого домена. Вам необходимо указать NS-запись для каждого первичного или вторичного сервера имен для домена.
Адресная запись (запись A) дает IPv4-адрес, соответствующий имени хоста. Может быть несколько IP-адресов, соответствующих одному имени хоста, также может быть несколько имен хостов, каждое из которых сопоставляется с одним и тем же IP-адресом.
Запись A принимает следующий формат:
Host.domain.name. IN A xx.xx.xx.xx (IPv4-адрес)
В DNS должна быть допустимая запись A для Host.domain.name, чтобы команда, такая как telnet host.domain.name , работала (или должен быть CNAME, указывающий на имя хоста с допустимой записью A).
Примечание. расширений DNS для поддержки адресов IPv6 рассматриваются в RFC 1886.
Запись информации о хосте (HINFO) может быть настроена для предоставления информации о типе оборудования и операционной системе (ОС) для каждого хоста. Его присутствие необязательно, но наличие доступной информации может быть полезно.
Для каждого имени хоста может быть только одна запись HINFO.
Запись HINFO имеет следующий формат:
Host.DOMAIN.NAME. IN HINFO "Тип процессора" "Операционная система"
Примечание: Поля типа ЦП и ОС являются обязательными.Если вы хотите оставить одно из этих полей пустым, укажите его как «» (пробел, заключенный в двойные кавычки). Вы не можете использовать только пару двойных кавычек [«»].
Примечание: Официальные имена компьютеров, которые вам нужны для HINFO, можно найти в RFC 1700. RFC 1700 перечисляет полезную информацию, такую как значения / etc / services, адреса оборудования производителя Ethernet и значения по умолчанию HINFO.
Запись текста (TXT) позволяет связать любой произвольный текст с именем хоста.Некоторые нестандартные реализации команды bind не поддерживают запись TXT. Однако некоторые нестандартные реализации команды bind действительно поддерживают фиктивный тип записи под названием «UINFO», который делает то же самое. Cisco рекомендует использовать только тип записи «TXT».
У вас может быть несколько записей TXT для одного имени хоста.
Запись TXT принимает следующий формат:
Host.DOMAIN.NAME. IN TXT »системный менеджер: melvin @ host.доменное имя"
В TXT "меласу"
Зона может иметь одну или несколько записей почтового обмена (MX). Эти записи указывают на хосты, которые принимают почтовые сообщения от имени хоста. Хост может быть MX для себя. Записи MX не обязательно указывают на хост в той же зоне.
Запись MX принимает следующий формат:
Host.domain.name. IN MX nn Otherhost.domain.name.
В MX nn Otherhost2.доменное имя.
Номера предпочтений «MX» nn (значение от 0 до 65535) обозначают порядок, в котором почтовые программы выбирают записи «MX» при попытке доставки почты на хост. Чем ниже номер MX, тем выше приоритет хоста.
Запись канонического имени (CNAME) используется для определения псевдонима хоста.
Запись CNAME имеет следующий формат:
alias.domain.name. В CNAME otherhost.domain.название.
Это определяет alias.domain.name как псевдоним для хоста, каноническим (стандартным) именем которого является otherhost.domain.name.
Примечание: Имя хоста, существующее как CNAME, не может иметь никаких других записей DNS, примененных к нему. Например, если ваш домен называется Philophysics.arizona.edu, и он имеет отдельное имя (так что у него есть свои собственные записи SOA и NS), то вы не можете предоставить философию .arizona.edu запись CNAME. Для этого отправьте электронное письмо на адрес anyuser @ Философия.arizona.edu, вам необходимо использовать записи MX и / или A.
Записи указателя противоположны записям A и используются в файлах зоны обратного сопоставления для сопоставления IP-адреса с именем хоста. В отличие от других записей SOA, записи указателя (PTR) используются только в обратных (IN-ADDR.ARPA) доменах. Для каждого адреса в Интернете должна быть ровно одна запись PTR. Например, если хост gadzooks.poetry.arizona.edu имеет IP-адрес 128.196.47.55, то для него должна быть PTR-запись в следующем формате:
. 55.47.196.128.IN-ADDR.ARPA. В ПТР gadzooks.poetry.arizona.edu.
Обратные домены содержат в основном записи PTR (плюс записи SOA и NS вверху).
R-утилиты Berkeley используют значение записи PTR для аутентификации имени хоста. Хотя DNS указывает, что регистр не имеет значения в именах хостов, имейте в виду, что некоторые операционные системы чувствительны к регистру имени хоста.
общих записей ресурсов DNS с примерами
Автор Jithin 22 августа, 2016
Записи ресурсов DNS являются содержимым файла зоны DNS.Файл зоны содержит сопоставления между доменными именами и IP-адресами в виде текстовых записей. Есть много типов ресурсных записей. В этой статье мы подробно рассмотрим записи ресурсов DNS.
Ниже приведены общие типы записей ресурсов DNS. Есть также много других ресурсов.
1) SOA
2) NS
3) А
4) ПТР
5) CNAME
6) MX
7) СРВ
Давайте подробно рассмотрим каждую запись.
Запись SOA
Каждый файл зоны будет иметь запись SOA. Он будет присутствовать в начале зоны. SOA расшифровывается как Start of Authority. Обычно этот тип записи содержит информацию о самой зоне и о других записях. В каждой зоне будет только одна запись SOA.
Запись SOA содержит следующие поля.
Например: IN SOA nameserver.place.dom. postmaster.place.dom.
NS Record
Запись NS обозначает запись сервера имен.Это показывает авторитетные серверы зоны. Они указывают первичный и вторичный серверы для зоны, указанной в записи SOA. Зоны могут содержать много NS-записей, но они должны содержать хотя бы одну NS-запись для зоны DNS.
Например, когда администратор на abc.com делегировал полномочия для поддомена noam.abc.com на noamdc1.noam.abc.com., В зону abc.com и noam.abc.com была добавлена следующая строка:
noam.abc.com. В НС noamdc1.noam.abc.com.
Запись
Следующая запись ресурса, которую мы увидим, — это запись A.Запись A означает запись адреса. Он сопоставляет доменное имя с IP-адресом, чтобы преобразователь мог запросить соответствующий IP-адрес для домена. В качестве примера следующая запись ресурса A, расположенная в зоне abc.com, сопоставляет полное доменное имя сервера с его IP-адресом.
abc.com IN A 172.16.48.1
Записи PTR
Запись PTR обозначает запись указателя. Он работает обратным образом, как у записи A. Он сопоставляет доменное имя с IP-адресом.Нам знаком термин обратный DNS. Эта запись используется для достижения обратного DNS. Пример приведен ниже.
1.48.16.172.in-addr.arpa. НА PTR abc.com.
Записи ресурса CNAME
Далее идет запись ресурса CNAME. CNAME означает каноническое имя. Функция записи CNAME — создать псевдоним для доменного имени. Полезно скрыть детали реализации сети от клиентов.
Пример записи CNAME приведен ниже.
ftp.abc.com. В CNAME ftp1.abc.com.
Как только клиент DNS запрашивает запись ресурса A для ftp.abc.com, сервер DNS находит запись ресурса CNAME. Затем он разрешает запрос записи ресурса A для ftp1.abc.com и возвращает клиенту записи ресурсов A и CNAME. Так работает запись CNAME.
Записи ресурсов MX
Запись MX представляет собой запись почтового обмена. Запись ресурса почтового обмена (MX) определяет почтовый сервер обмена для доменного имени DNS.Сервер почтового обмена — это хост, который будет обрабатывать или пересылать почту для доменного имени DNS. Обработка почты означает ее доставку адресату или передачу на другой тип почтового транспорта. Пересылка почты означает ее отправку на конечный сервер назначения. Это будет простой протокол передачи почты (SMTP) на другой почтовый сервер обмена, который находится ближе к конечному пункту назначения, или поставить его в очередь в течение определенного времени.
Только почтовые серверы обмена используют записи MX.
У нас может быть несколько записей ресурсов MX для этого домена.В следующем примере показаны записи ресурсов MX для почтовых серверов для домена noam.abc.com .:
*. noam.abc.com. В MX 0 mailserver1.noam.abc.com.
*. noam.abc.com. В MX 10 mailserver2.noam.abc.com.
*. noam.abc.com. В MX 10 mailserver3.noam.abc.com.
Записи SRV
С записями MX у нас может быть несколько почтовых серверов в домене DNS, и когда почтовому агенту нужно отправить почту на хост в домене, он может найти расположение почтового сервера обмена.Записи ресурсов службы (SRV) позволяют указать расположение серверов для конкретной службы, протокола и домена DNS. Таким образом, если у вас есть два веб-сервера в вашем домене, вы можете создать записи ресурсов SRV, определяющие, какие хосты служат веб-серверами, а преобразователи могут затем получить все записи ресурсов SRV для веб-серверов.
Если вам потребуется дополнительная помощь, обратитесь в нашу службу поддержки.
Общие записи DNS — Справка DNSimple
Содержание
Система доменных имен (DNS) состоит из множества различных типов записей (или записей ресурсов): A , AAAA , CNAME , MX , CAA и т. Д.Некоторые типы записей распространены. Другие менее актуальны, устарели или заменены.
DNSimple поддерживает общие и традиционные типы записей, а также некоторые новые типы, представленные для предоставления инновационных услуг. В этой статье мы рассмотрим наиболее распространенные типы записей и рассмотрим наиболее распространенные записи DNS, необходимые для работы ваших доменов.
Общие типы записей
Это наиболее распространенные типы записей DNS:
Тип Описание A запись Это самый популярный вид.Записи создают запись DNS, указывающую на адрес IPv4. Это позволяет вам использовать memonic-имена, такие как www.example.com , вместо IP-адресов, таких как 127.0.0.1 . CNAME запись Эта запись работает как псевдоним и сопоставляет одно имя с другим. Его часто используют для уменьшения дублирования в конфигурациях доменных имен. Это также упрощает обслуживание нескольких записей, связанных с одним и тем же IP-адресом. Это один из распространенных механизмов, используемых облачными службами для предоставления услуг для конкретных клиентов. MX запись Эта запись используется для идентификации серверов, на которые должна доставляться почта для домена. Вам необходимо настроить эти записи для получения электронных писем. TXT запись Эта запись используется для связывания текста с доменом. NS запись Эта запись используется для делегирования подзоны набору серверов имен. Это типы записей, которые вам нужно изменить, если вы хотите делегировать домен поставщику DNS. SOA запись В этой записи хранится важная информация о зоне DNS (ваш домен). Каждая зона должна иметь запись SOA. Однако маловероятно, что вам придется создавать запись SOA напрямую. DNSimple автоматически управляет записями SOA для всех ваших доменов.
Общие записи DNS
Хотя каждый домен уникален и, вероятно, будет иметь особую конфигурацию DNS, существует базовый набор записей DNS, который является общим для большинства доменов.
Если вы только что приобрели домен или просматриваете конфигурацию DNS своего домена, сравните записи DNS в своем домене со следующими, чтобы определить, отсутствует ли что-либо:
В этой статье предполагается, что example.com — ваше доменное имя.
1. Корневой домен (
example.com ) Каждый домен должен иметь запись для корневого домена. В противном случае ваш домен не будет разрешен, и доступ к URL-адресу в браузере вернет ошибку разрешения.
В большинстве случаев эта конфигурация представляет собой запись A, указывающую на IP-адрес, на котором размещен ваш сайт. Однако это также может быть АЛИАС, если ваш сайт размещен в другом месте (это обычное дело, когда вы хотите указать свой корневой домен на облачный сервис, такой как Heroku, Netlify, GitHub и т. Д.), Или запись URL, если домен необходимо перенаправить в другое место.
Для проверки
- Используйте
dig example.com , чтобы проверить наличие корневой записи. Ответ должен вернуть хотя бы одну запись A, как показано ниже:
копать просто.ком
;; ОТВЕТНАЯ ЧАСТЬ:
dnsimple.com. 59 IN A 104.245.210.170
Записи ALIAS и URL синтезируются как записи A.
Если вы видите запись CNAME, ваша конфигурация недействительна. CNAME нельзя использовать для корневого домена.
2. Субдомен www: (
www.example.com ) Обычно настраивается субдомен www в дополнение к корневому домену.Есть несколько возможностей:
- Использование записи A для указания на тот же IP-адрес корневого домена.
- Использование записи CNAME для указания на корневой домен.
- Использование записи URL для перенаправления в корневой домен.
Использование записи ALIAS для субдомена www не является неправильным, но, как правило, в этом нет необходимости. В большинстве случаев вы можете заменить ALIAS на CNAME.
Для проверки
- Используйте
dig www.example.com , чтобы проверить наличие записи www. Ответ должен возвращать хотя бы одну запись A или ровно одну запись CNAME, как показано ниже:
копать www.dnsimple.com
;; ОТВЕТНАЯ ЧАСТЬ:
www.dnsimple.com. 59 IN A 104.245.210.170
копать www.dnsimple.com
;; ОТВЕТНАЯ ЧАСТЬ:
www.dnsimple.com. 3599 В CNAME dnsimple.com.
dnsimple.com. 59 IN A 104.245.210.170
3.Записи электронной почты MX
Если вы хотите получать электронные письма для своего домена, у вас должна быть хотя бы одна запись MX, указывающая на ваш почтовый сервер doamin. Для воспроизведения обычно используются две или более записей MX, каждая с разным содержанием и приоритетом.
Для проверки
- Используйте
dig MX example.com , чтобы проверить наличие записей MX в корневом домене. Ответ должен вернуть хотя бы одну запись MX, как показано ниже:
dig MX www.dnsimple.com
;; ОТВЕТНАЯ ЧАСТЬ:
dnsimple.com. 3599 В MX 1 aspmx.l.google.com.
dnsimple.com. 3599 IN MX 5 alt1.aspmx.l.google.com.
dnsimple.com. 3599 IN MX 5 alt2.aspmx.l.google.com.
dnsimple.com. 3599 IN MX 10 alt3.aspmx.l.google.com.
dnsimple.com. 3599 IN MX 10 alt4.aspmx.l.google.com.
4. Запись CAA
Рекомендуется добавить запись CAA к корневому домену, чтобы указать, какие центры сертификации могут выдавать сертификат для вашего домена.
Для проверки
- Используйте
dig CAA example.com , чтобы проверить наличие записи CAA в корневом домене. Ответ должен возвращать хотя бы одну запись CAA, как показано ниже:
dig CAA www.dnsimple.com
;; ОТВЕТНАЯ ЧАСТЬ:
dnsimple.com. 3599 IN CAA 0 iodef "mailto: [email protected]"
dnsimple.com. 3599 IN CAA 0 проблема "amazonaws.com"
dnsimple.com. 3599 IN CAA 0 проблема "comodoca.com"
dnsimple.com. 3599 В CAA 0 проблема "letsencrypt.org "
dnsimple.com. 3599 IN CAA 0 issueewild "comodoca.com"
записей ресурсов (RR) — Сетевое руководство
Нетворкинг / Новички
Запись ресурса DNS (RR) содержит всю информацию о доменном имени.
система. Он определяет все атрибуты для доменного имени, такие как IP-адрес или
почтовый маршрут.
DNS RR имеет шесть полей:
<ИМЯ>, <ТИП>, <КЛАСС>, , <Длина RD> и Эти поля объяснены в следующем списке:
- Имя. В этом поле указывается DNS-имя, также известное как владелец.
имя, которому принадлежит РР.
- Тип. Это поле представляет собой 2-байтовое значение, указывающее тип ресурса.
который определен в записи ресурса. Это поле необходимо, потому что
DNS-имя может иметь более одного типа RR.
- Класс. Определяет семейство протоколов для записи RR. Например,
IN, что означает Интернет.
- Время жизни (TTL). Это поле — время в секундах, в течение которого
сервер имен может кэшировать RR.Нулевой TTL означает, что сервер не должен кэшировать RR.
- RD Длина. Это поле — длина поля RDATA в октетах.
- RDATA. Это поле является полем данных ресурса и представляет собой значение, до которого
сущность, указанная в картах поля ИМЯ. Он уникален для каждого типа РР.
Общие записи ресурсов DNS
Тип записи Описание Использование A Адресная запись Сопоставляет полное доменное имя с IP-адресом.Например,
Mail IN A 172.100.100.1
Login IN A 172.100.100.2 PTR Запись указателя Сопоставляет IP-адрес с полным доменным именем. Например,
1.100 IN PTR mail.example.com. NS Запись сервера имен Обозначает сервер имен для зоны. Например,
IN NS ns1.abc.com.
IN NS ns2.abc.com. SOA A Начало авторитетной записи Задает множество атрибутов, относящихся к зоне, например, имя домена (вперед
или наоборот), административный контакт, серийный номер зоны, интервал обновления, интервал повтора и т. д. CNAME Запись канонического имени Определяет псевдоним и сопоставляет его с абсолютным (каноническим) именем. Например,
POP IN CNAME mail MX Запись обмена почтой Используется для перенаправления электронной почты для данного домена или хоста на другой хост. Например,
xyz.com IN MX 0
mail.abc.com
записей DNS | Объяснение типов записей ресурсов
1 А Адрес указывает IPv4-адрес хоста. 2 NS Сервер имен уточняет полномочия зоны. 3 Доктор медицины Пункт назначения почты был заменен записью MX (устаревшей). 4 MF Mail Forwarder был заменен записью MX (устаревшей). 5 CNAME Каноническое имя определяет псевдоним. 6 SOA Start of Authority раскрывает подробности о зоне. 7 МБ Доменное имя почтового ящика является экспериментальным. 8 MG Член почтовой группы является экспериментальным. 9 МИСТЕР Имя домена для переименования почты является экспериментальным. 10 НОЛЬ Нулевой ресурс является экспериментальным. 11 WKS Для пересылки почты использовался сервис Well Known (ныне устаревший). 12 PTR Указатель предназначен для обратного просмотра. 13 HINFO Информация о хосте предоставляет сведения об аппаратном и программном обеспечении хоста. 14 МИНФО Информация о почтовом ящике является экспериментальной. 15 MX Mail Exchange назначает почтовым серверам домен. 16 текст Текст предоставляет возможность ввода дополнительных текстов. 17 RP Ответственное лицо предоставляет информацию об ответственном лице. 18 AFSDB База данных AFS специально предназначена для клиентов AFS. 19 X25 Адрес X.25 PSDN предоставляет подробную информацию об инкапсуляции через X.25 (устарело). 20 ISDN Эта запись присваивает DNS-имени номер ISDN (устаревший). 21 год RT Запись сквозного маршрута обеспечивает привязку сквозного маршрута без адреса WAN (устарело). 22 NSAP Эта запись позволяет назначать доменные имена точкам доступа к сетевым службам (устарело). 23 NSAP-PTR Указатель NSAP был заменен на PTR (устаревший). 24 SIG Подпись заменена на RRSIG (устарела). 25 КЛЮЧ Ключ был заменен на IPSECKEY (устаревший). 26 год PX Указатель на X.400 указывает правила отображения MIXER (устарело). 27 GPOS Географическое положение было заменено на LOC (устаревшее). 28 год AAAA AAAA предоставляет IPv6-адрес хоста. 29 LOC Местоположение содержит информацию о местоположении. 30 NXT Далее был заменен на NSEC (устаревший). 31 год EID Идентификатор конечной точки предназначен для архитектуры маршрутизации Nimrod (устарело). 32 НИМЛОК Nimrod Locator предназначен для архитектуры маршрутизации Nimrod (устарело). 33 SRV Service Locator предоставляет информацию о других услугах. 34 ATMA ATM Address предоставляет информацию, когда есть асинхронные режимы передачи (устаревшие). 35 год НАПТР Указатель полномочий по присвоению имен — это расширение записи A, которое разрешает шаблон поиска (регулярные выражения). 36 KX Key Exchanger позволяет управлять ключами для криптографии. 37 CERT Cert сохраняет сертификаты. 38 A6 A6 был заменен на AAAA. 39 DNAME Имя делегирования определяет псевдонимы для полных доменов. 40 РАКОВИНА Кухонная мойка позволяет хранить различные данные (устарело). 41 год OPT Параметр является псевдозаписью при наличии механизма расширения DNS (EDNS). 42 APL Список префиксов адресов перечисляет области адресов в формате CIDR. 43 год DS Орган, подписывающий делегирование, определяет зоны, подписанные DNSSEC. 44 год SSHFP Отпечаток открытого ключа SSH раскрывает отпечаток ключей SSH. 45 IPSECKEY Ключ IPsec содержит ключ IPsec. 46 RRSIG Подпись RR содержит цифровую подпись для DNSSEC. 47 NSEC Далее Зоны, подписанные безопасными потоками в DNSSEC. 48 DNSKEY DNS Key содержит открытый ключ для DNSSEC. 49 DHCID Идентификатор DHCP связывает доменные имена с DHCP-клиентами. 50 NSEC3 Next Secure 3 — альтернатива NSEC. 51 NSEC3PARAM Эта запись содержит параметр для NSEC3. 52 TLSA Эта запись выдает ассоциацию сертификата TLSA с доменным именем, относящимся к DANE. 53 СМИМЕА Эта запись выдает ассоциацию сертификата S / MIME с доменным именем. 54 н / д Не назначен 55 БЕДРО Протокол идентификации хоста отделяет маркеры конечных точек и функции позиционирования от IP-адресов. 56 НИНФО NINFO предоставляет информацию о статусе зоны (та же структура, что и TXT; устарело). 57 RKEY RKEY сохраняет ключи (та же структура, что и KEY и DNSKEY; устарело). 58 ТАЛИНК Ссылка якоря доверия связывает два доменных имени (устарело). 59 CDS Дочерний DS — это дочерняя копия записи DS. 60 CDNSKEY Дочерний DNSKEY — это дочерняя копия записи DNSKEY. 61 OPENPGPKEY OpenPGP Key раскрывает открытые ключи. 62 CSYNC Синхронизация между дочерними и родительскими объектами позволяет согласовывать родительскую и дочернюю зоны (устарело). 63 ЗОНЕМД Дайджест сообщений для зоны DNS является экспериментальным (устаревшим). 64–98 н / д Не назначен. 99 SPF Платформа политики отправителя была заменена записью TXT (устарела). 100 УИНФО Зарезервированный. 101 UID Зарезервированный. 102 GID Зарезервированный. 103 UNSPEC Зарезервированный. 104 NID NodeID экспериментальный. 105 L32 32-битный локатор является экспериментальным. 106 L64 64-битный локатор является экспериментальным. 107 LP Указатель локатора является экспериментальным. 108 EUI48 48-битный расширенный уникальный идентификатор шифрует адреса. 109 EUI64 64-битный расширенный уникальный идентификатор шифрует адреса. 110–248 н / д Не назначен. 249 TKEY Ключ транзакции позволяет обмениваться секретными ключами. 250 TSIG Подпись транзакции используется для аутентификации. 251 IXFR Добавочная передача зоны позволяет обновлять компоненты файла зоны на втором сервере (устарело). 252 AXFR AFXR передает полный файл зоны на второй сервер (устарело). 253 ПОЧТА Почтовый ящик запрашивает записи, относящиеся к почтовому ящику (устарело). 254 MAILA Почтовый агент заменен на MX-Record (устарел). 255 * * запрашивает все записи (устаревшие). 256 URI Uniform Resource Identifier раскрывает отображение имен хостов в URI. 257 CAA Авторизация центра сертификации определяет возможные центры сертификации домена. 258 AVC Видимость и контроль приложений содержит метаданные приложения для DNS-AS (устарело). 259 DOA DOA больше не действует (устарело). 260 AMTRELAY Автоматическое туннельное реле многоадресной рассылки позволяет обнаруживать реле AMT (устарело). 261–32767 н / д Не назначен. 32768 TA DNSSEC Trust Authorities включает DNSSEC без подписанного корня. 32769 DLV Проверка DNSSEC Lookaside выявляет якоря доверия за пределами стандартной цепочки DNS. 32770–65279 н / д Не назначен. 65280–65534 н / д Для личного пользования. 65535 н / д Зарезервированный.
Запись ресурса DNS для HTTP
Запись ресурса DNS для HTTP Запись ресурса DNS для HTTP
draft-bellis-dnsop-http-record-00
Этот документ определяет тип записи ресурса «HTTP» для DNS, чтобы облегчить поиск имени хоста сервера для HTTP (ов) URI.Он предназначен для замены использования записей CNAME для этой цели и в процессе предоставляет решение для неспособности DNS разрешить размещение CNAME на вершине имени домена.
Этот Интернет-проект представлен в полном соответствии с положениями BCP 78 и BCP 79.
Internet-Drafts являются рабочими документами Инженерной группы Интернета (IETF). Обратите внимание, что другие группы также могут распространять рабочие документы как Интернет-проекты. Список текущих Интернет-проектов находится по адресу https: // datatracker.ietf.org/drafts/current/.
Интернет-проекты — это черновики документов, срок действия которых не превышает шести месяцев, и они могут быть обновлены, заменены или отменены другими документами в любое время. Неуместно использовать Интернет-черновики в качестве справочного материала или цитировать их иначе, как «незавершенные работы».
Срок действия этого Интернет-проекта истекает 8 мая 2019 г.
Авторские права (c) 2018 IETF Trust и лица, указанные в качестве авторов документа. Все права защищены.
Этот документ регулируется BCP 78 и Правовыми положениями IETF Trust, касающимися документов IETF (https: // trustee.ietf.org/license-info), действующий на дату публикации этого документа. Пожалуйста, внимательно ознакомьтесь с этими документами, поскольку они описывают ваши права и ограничения в отношении этого документа. Компоненты кода, извлеченные из этого документа, должны включать упрощенный текст лицензии BSD, как описано в разделе 4.e Правовых положений Trust, и предоставляются без гарантии, как описано в упрощенной лицензии BSD.
Очень часто URI HTTP (ов) содержат доменное имя, которое не совпадает с именем хоста фактического сервера, на котором размещается контент.
Обычно это достигается с помощью записи CNAME, где имя владельца этой записи («Псевдоним») является доменным именем из URI, а поле канонического имени в его RDATA соответствует имени целевого хоста (хотя следует отметить, что это строгое нарушение исходной семантики дизайна записи CNAME).
Также невозможно сохранить CNAME на вершине доменного имени, что вызывает значительные трудности, если вы хотите перенаправить свое доменное имя без префикса «www» в сеть доставки контента (CDN).Единственное портативное решение на данный момент — определить записи IP-адреса хоста контента и вставить их непосредственно в верхнюю часть зоны, но это непрочно и мешает правильной работе типичных функций CDN.
Несмотря на то, что ранее были попытки продвинуть использование записи SRV вместо записей CNAME, были высказаны опасения по поводу влияния на производительность дополнительного поиска DNS, который обычно требуется для записи SRV.
Для достижения производительности конечного пользователя, эквивалентной существующим решениям на основе CNAME, этот документ позволяет рекурсивным распознавателям упреждающе искать цель записи HTTP и возвращать соответствующие записи клиенту.Хотя эта функция не является обязательной, есть надежда, что со временем поддержка станет почти повсеместной.
Кроме того, наличие поля порта в записи SRV несовместимо с политикой безопасности «Одинаковое происхождение», применяемой веб-браузерами, и на практике возможности балансировки нагрузки / восстановления записи SRV также широко не используются и не используются. Решения на основе DNS для этого уже широко используются для HTTP-трафика.
Таким образом, этот документ определяет минимальный тип записи ресурса «HTTP» для DNS, чтобы облегчить перенаправление от части имени домена HTTP (ов) URI к имени хоста сервера и оттуда к записям A или AAAA.Он специально предназначен для замены использования записей CNAME для этой цели и в процессе предоставляет решение для неспособности DNS разрешить размещение CNAME на вершине доменного имени.
Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ОБЯЗАТЕЛЬНО», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и « ДОПОЛНИТЕЛЬНО »в этом документе следует интерпретировать, как описано в BCP 14 [RFC2119] [RFC8174], когда и только когда они появляются заглавными буквами, как показано здесь.
Имя владельца HTTP RR является частью имени домена HTTP (ов) URI.
Использование префиксов меток подчеркивания (например, _http._tcp) было рассмотрено, но отклонено, поскольку оно запрещает использование записей с подстановочными знаками, которые являются ценным методом для предложения префиксов домена для каждого клиента, не требуя индивидуальной настройки каждого префикса.
RDATA HTTP RR — это доменное имя в несжатом проводном формате.
RDATA HTTP RR представляется как доменное имя в стандартном формате главного файла.
Рекурсивные преобразователи МОГУТ при получении запроса на запись HTTP искать записи A и AAAA для цели (либо из кеша, либо с помощью новых итеративных запросов) и включать результаты в дополнительный раздел ответа.
Если рекурсивный преобразователь выполняет разрешение DNSSEC, но не может проверить ответы A или AAAA, он НЕ ДОЛЖЕН включать их в ответ, если клиент не указал флаг + CD (проверка отключена).
Если клиентская подсеть EDNS [RFC7871] настроена на преобразователе, эти запросы A и AAAA ДОЛЖНЫ выполняться, как если бы клиент отправил эти запросы непосредственно в преобразователь.
HTTP-клиенты, поддерживающие эту спецификацию, ДОЛЖНЫ выдавать параллельные DNS-запросы для записей A, AAAA и HTTP для доменной части http: или https: URI.
Если возвращается запись HTTP, клиент ДОЛЖЕН либо использовать записи A и AAAA, содержащиеся в дополнительном разделе ответа, либо выдавать дополнительные параллельные запросы для записей A и AAAA, соответствующих доменному имени в RDATA записи HTTP. а затем используйте эти IP-адреса для доступа к URI.
Если исходные поисковые запросы A и AAAA возвращают IP-адреса, они ДОЛЖНЫ использоваться только в том случае, если не возвращается запись HTTP.
«в приведенном выше тексте требуется больше текста о сроках, счастливых глазах и т. Д.»
TBD
«Примечание редактора RFC. Удалите весь раздел перед публикацией в качестве RFC. »
TBD (если есть)
«здесь появится копия шаблона приложения RFC 6895 IANA RR TYPE»
[RFC2119] Браднер, С., «Ключевые слова для использования в RFC для обозначения уровней требований», BCP 14, RFC 2119, DOI 10.17487 / RFC2119, март 1997 г. [RFC8174] Лейба Б., «Неоднозначность прописных и строчных букв в ключевых словах RFC 2119», BCP 14, RFC 8174, DOI 10.17487 / RFC8174, май 2017 г.
Рэй Беллис Беллис Консорциум Интернет-систем, Inc. 950 Чартер-стрит Редвуд-Сити, CA 94063 США Телефон: +1 650 423 1200 Электронная почта: [email protected] RFC 3597 — Обработка неизвестных типов записей ресурсов DNS (RR)
[Документы] [txt | pdf] [draft-ietf-dnse…] [Tracker] [Diff1] [Diff2] [Errata]
Обновлено: 4033, 4034, 4035, 5395, 6195, 6895 ПРЕДЛАГАЕМЫЙ СТАНДАРТ
Есть исправления
Сетевая рабочая группа А. Густафссон
Запрос комментариев: 3597 Nominum Inc.
Категория: Standards Track Сентябрь 2003 г.
Обработка неизвестных типов записей ресурсов DNS (RR)
Статус этого меморандума
Этот документ определяет протокол отслеживания стандартов Интернета для
Интернет-сообщество и просит обсуждения и предложения по
улучшения.См. Текущую редакцию "Интернет
Официальные стандарты протокола »(STD 1) для состояния стандартизации
и статус этого протокола. Распространение этой памятки не ограничено.
Уведомление об авторских правах
Авторское право (C) The Internet Society (2003). Все права защищены.
Абстрактный
Расширение системы доменных имен (DNS) с помощью новой записи ресурса (RR)
types в настоящее время требует изменений в программном обеспечении сервера имен. Этот
документ определяет изменения, необходимые для обеспечения возможности использования DNS в будущем.
реализации для прозрачной обработки новых типов RR.1. Введение
DNS спроектирован так, чтобы его можно было расширять для поддержки новых услуг через
введение новых типов ресурсных записей (RR). На практике,
развертывание нового типа RR в настоящее время требует изменения сервера имен
программное обеспечение не только на авторитетном DNS-сервере, который предоставляет
новая информация и клиент, использующий ее, но и
подчиненные серверы для зоны, в которой он находится, а в некоторых случаях также на
кэширование серверов имен и серверов пересылки, используемых клиентом.Поскольку развертывание нового серверного программного обеспечения происходит медленно и дорого,
потенциал DNS в поддержке новых услуг никогда не был
полностью реализовано. В этой памятке предлагаются изменения в серверах имен и в
процедуры определения новых типов RR, направленные на упрощение будущего
внедрение новых типов RR.
Ключевые слова «ДОЛЖНЫ», «НЕ ДОЛЖНЫ», «ОБЯЗАТЕЛЬНО», «ДОЛЖНЫ», «НЕ ДОЛЖНЫ»,
«ДОЛЖЕН», «НЕ ДОЛЖЕН», «РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и «ДОПОЛНИТЕЛЬНО» в этом
документ следует интерпретировать, как описано в [RFC 2119].Gustafsson Standards Track [Страница 1]
RFC 3597 Обработка неизвестных типов DNS RR Сентябрь 2003 г.
2. Определение
«Запись неизвестного типа» - это запись, формат RDATA которой неизвестен.
реализация DNS под рукой, и тип которой не назначен
QTYPE или Meta-TYPE, как указано в [RFC 2929] (раздел 3.1), ни
в пределах диапазона, зарезервированного в этом разделе для присвоения только
QTYPE и мета-типы. Такой RR не может быть преобразован в тип -
конкретный текстовый формат, сжатый или иным образом обрабатываемый в типе -
конкретным образом.В случае типа, формат RDATA которого зависит от класса, RR будет
считается неизвестным типом, когда формат RDATA для этого
сочетание типа и класса неизвестно.
3. Прозрачность
Чтобы разрешить развертывание новых типов RR без изменений сервера, назовите
серверы и преобразователи ДОЛЖНЫ прозрачно обрабатывать записи RR неизвестного типа.
То есть они должны рассматривать раздел RDATA таких RR как
неструктурированные двоичные данные, хранение и передача без изменения
[RFC1123].
Для обеспечения корректной работы сравнения на равенство (раздел 6)
и канонической формы DNSSEC (раздел 7), когда известен тип RR
для некоторых, но не для всех задействованных серверов, серверы ДОЛЖНЫ также
точно сохранить RDATA RR известного типа, за исключением изменений
из-за сжатия или декомпрессии, если это разрешено разделом 4
эта памятка.В частности, регистр символов доменных имен, которые
не подлежат сжатию ДОЛЖНЫ быть сохранены.
4. Сжатие доменного имени
Записи RR, содержащие указатели сжатия в части RDATA, не могут быть
обрабатываются прозрачно, поскольку указатели сжатия только
имеет смысл в контексте сообщения DNS. Прозрачно
копирование RDATA в новое сообщение DNS вызовет сжатие
указатели, указывающие на соответствующее место в новом сообщении,
который теперь содержит несвязанные данные.Это приведет к тому, что сжатый
имя будет испорчено.
Чтобы избежать такого повреждения, серверы НЕ ДОЛЖНЫ сжимать доменные имена.
встроены в RDATA типов, которые относятся к классу или плохо
известен. Это требование было сформулировано в [RFC1123] без определения
термин «общеизвестный»; настоящим указывается, что только типы RR
определенные в [RFC1035], считаются «общеизвестными».
Gustafsson Standards Track [Страница 2]
RFC 3597 Обработка неизвестных типов DNS RR Сентябрь 2003 г.
Спецификации нескольких существующих типов RR явно разрешили
сжатие вопреки этой спецификации: [RFC2163] указывает, что
сжатие применяется к PX RR, и разрешенное сжатие [RFC2535]
в записях SIG RRs и NXT RRs.Поскольку эта спецификация запрещает
сжатие в этих случаях, это обновление [RFC2163] (раздел 4)
и [RFC2535] (разделы 4.1.7 и 5.2).
Принимающие серверы ДОЛЖНЫ распаковывать доменные имена в RR известных
type, и СЛЕДУЕТ также распаковать записи RR типа RP, AFSDB, RT, SIG, PX,
NXT, NAPTR и SRV (хотя текущая спецификация SRV RR
в [RFC2782] запрещает сжатие, [RFC2052] требует его, а некоторые
серверы, соответствующие этой более ранней спецификации, все еще используются).Будущие спецификации для новых типов RR, содержащих доменные имена
в их RDATA НЕ ДОЛЖНЫ допускать использование сжатия имен для
эти имена, и ДОЛЖЕН явно указывать, что встроенный домен
имена НЕ ДОЛЖНЫ быть сжаты.
Как отмечено в [RFC1123], имя владельца RR всегда имеет право на
сжатие.
5. Текстовое представление
В поле "type" строки основного файла указан неизвестный тип RR.
представлен словом "ТИП", сразу за которым следует десятичный RR
введите номер без пробелов.В поле "класс"
неизвестный класс аналогично представлен словом «КЛАСС»
сразу за ним следует десятичный номер класса.
Это соглашение позволяет отличать типы и классы от
друг друга и из значений TTL, что позволяет "[] []
"и" [] [] "формы
[RFC1035], чтобы оба были однозначно проанализированы.
Раздел RDATA записи RR неизвестного типа представлен как
последовательность слов, разделенных пробелами, выглядит следующим образом:
Специальный токен \ # (обратная косая черта, сразу за которой следует хеш
знак), который идентифицирует RDATA как имеющий общую кодировку
определенное здесь, а не традиционное кодирование, зависящее от типа.Десятичное целое число без знака, определяющее длину RDATA в октетах.
Ноль или более слов шестнадцатеричных данных, кодирующих фактические RDATA
поле, каждое из которых содержит четное число шестнадцатеричных цифр.
Если RDATA имеет нулевую длину, текстовое представление содержит только
токен \ # и единственный ноль, представляющий длину.
Gustafsson Standards Track [Страница 3]
RFC 3597 Обработка неизвестных типов DNS RR Сентябрь 2003 г.
Реализация МОЖЕТ также выбрать представление некоторых RR известного типа.
используя приведенные выше общие представления для типа, класса и / или
RDATA, который позволяет сделать итоговый мастер-файл
переносится на серверы, где эти типы неизвестны.Используя общий
представление RDATA RR известного типа также может быть
полезно в случае типа RR, где формат текста меняется
в зависимости от версии, протокола или аналогичного поля (или нескольких)
встроены в RDATA, когда такое поле имеет значение, для которого нет текста
известен формат, например, LOC RR [RFC1876] с ВЕРСИЕЙ, отличной от
0.
Несмотря на то, что RR известного типа, представленного в формате \ #, является
эффективно рассматривается как неизвестный тип с целью анализа
Текстовое представление RDATA, вся дальнейшая обработка сервером ДОЛЖНА
рассматривать его как известный тип и принимать во внимание любой применимый тип -
особые правила относительно сжатия, канонизации и т. д.Ниже приведены примеры RR, представленных таким образом.
иллюстрируя различные комбинации общих и специфичных для типа
кодировки для различных полей формата мастер-файла:
а. пример. CLASS32 TYPE731 \ # 6 abcd (
эф 01 23 45)
б. пример. ТИП ГС62347 \ # 0
д. пример. IN A \ # 4 0A000001
д. пример. КЛАСС1 ТИП1 10.0.0.2
6. Сравнение равенства
Для некоторых протоколов DNS, в частности для динамического обновления [RFC2136], требуются записи RR.
для сравнения на равенство.Два RR одного и того же неизвестного типа являются
считается равным, когда их RDATA побитово равны. Чтобы гарантировать, что
результат сравнения идентичен, если RR известен
сервер или нет, спецификации для новых типов RR НЕ ДОЛЖНЫ указывать
правила сравнения для конкретных типов.
Это означает, что встроенные доменные имена, включенные в
общее побитовое сравнение сравнивается с учетом регистра.
В результате, когда новый тип RR содержит один или несколько встроенных доменов
имена, можно иметь несколько RR, принадлежащих одному и тому же имени
которые отличаются только регистром символов встроенного домена
имя (а).Это похоже на существующую возможность множественного TXT
записи, отличающиеся только регистром символов, и не должны вызывать
никаких проблем на практике.
Программа стандартов Густафссона [Страница 4]
RFC 3597 Обработка неизвестных типов DNS RR Сентябрь 2003 г.
7. Каноническая форма DNSSEC и заказ
DNSSEC определяет каноническую форму и порядок RR [RFC2535]
(раздел 8.1). В этой канонической форме доменные имена, встроенные в
RDATA преобразуются в нижний регистр.Нижний регистр необходим для обеспечения корректности DNSSEC.
подписи при потере регистрационных различий в доменных именах из-за
сжатие, но поскольку это требует знания о наличии и
положение встроенных доменных имен, его нельзя применять к неизвестным
типы.
Для обеспечения постоянной согласованности канонической формы типов RR
где разрешено сжатие, и для постоянной совместимости с
существующие реализации, которые уже реализуют [RFC2535]
канонической формы и применить ее к своим известным типам RR, канонический
форма остается неизменной для всех типов RR, чьи начальные
публикация как RFC была до первоначальной публикации этого
спецификация как RFC (RFC 3597).В знак любезности к разработчикам настоящим отмечаем, что полный
набор таких ранее опубликованных типов RR, которые содержат встроенные
доменные имена, каноническая форма DNSSEC которых, следовательно, включает
понижающий регистр согласно правилам DNS для сравнения символов,
состоит из типов RR NS, MD, MF, CNAME, SOA, MB, MG, MR, PTR,
HINFO, MINFO, MX, HINFO, RP, AFSDB, RT, SIG, PX, NXT, NAPTR, KX, SRV,
DNAME и A6.
В этом документе указывается, что для всех других типов RR (независимо от того,
как неизвестные типы или обрабатываются как известные типы в соответствии с типом RR
определение RFC более новое, чем RFC 3597), каноническая форма такова
что не происходит понижения регистра встроенных доменных имен, и
в остальном идентичен канонической форме, указанной в [RFC2535]
Раздел 8.1.
Обратите внимание, что имя владельца всегда вводится в нижнем регистре в соответствии с
Правила DNS для сравнения символов, независимо от типа RR.
Канонический порядок RR в DNSSEC указан в разделе [RFC2535].
8.3, где последовательность октетов является канонической формой, исправленной
эта спецификация.
8. Дополнительная обработка раздела
Неизвестные типы RR не вызывают дополнительной обработки раздела. Будущее RR
спецификации типа МОГУТ указывать дополнительный раздел для конкретного типа
правила обработки, но любая такая обработка ДОЛЖНА быть необязательной, поскольку она может
может выполняться только серверами, для которых известен тип RR.Дорожка стандартов Густафссона [Страница 5]
RFC 3597 Обработка неизвестных типов DNS RR Сентябрь 2003 г.
9. Соображения IANA
Этот документ не требует каких-либо действий со стороны IANA.
10. Соображения безопасности
Считается, что эта спецификация не приведет к возникновению каких-либо новых мер безопасности
проблем, ни для решения существующих.
11. Нормативные ссылки
[RFC1034] Mockapetris, P., "Доменные имена - концепции и
Помещения », STD 13, RFC 1034, ноябрь 1987 г.[RFC1035] Мокапетрис П., «Доменные имена - реализация и
Технические характеристики », STD 13, RFC 1035, ноябрь 1987 г.
[RFC1123] Braden, R., Ed., «Требования к Интернет-хостам -
Применение и поддержка », STD 3, RFC 1123, октябрь 1989 г.
[RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для обозначения
Уровни требований », BCP 14, RFC 2119, март 1997 г.
[RFC2535] Истлейк Д., «Расширения безопасности системы доменных имен»,
RFC 2535, март 1999 г.[RFC2163] Аллоккио, К., «Использование DNS в Интернете для распространения
MIXER Conformant Global Address Mapping (MCGAM) ", RFC
2163, январь 1998 г.
[RFC2929] Истлейк Д., Бруннер-Уильямс Э. и Б. Мэннинг,
«Соображения IANA по системе доменных имен (DNS)», BCP 42,
RFC 2929, сентябрь 2000 г.
12. Информативные ссылки.
[RFC1876] Дэвис, К., Викси, П., Гудвин, Т. и И. Дикинсон, "A
Средства выражения информации о местоположении в домене
Система имен », RFC 1876, январь 1996 г.[RFC2052] Гулбрандсен, А. и П. Викси, "Запись DNS RR для указания
расположение сервисов (DNS SRV) », RFC 2052, октябрь
1996 г.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y. and J. Bound,
«Динамические обновления в системе доменных имен (ОБНОВЛЕНИЕ DNS)»,
RFC 2136, апрель 1997 г.
Дорожка стандартов Густафссона [Страница 6]
RFC 3597 Обработка неизвестных типов DNS RR Сентябрь 2003 г.
[RFC2782] Гулбрандсен, А., Викси, П. и Л. Есибов, "DNS RR для
с указанием местоположения служб (DNS SRV) », RFC 2782,
Февраль 2000 г.
13. Заявление об интеллектуальной собственности
IETF не занимает никакой позиции относительно действительности или объема каких-либо
интеллектуальная собственность или другие права, которые могут быть заявлены на
относятся к реализации или использованию технологии, описанной в
этот документ или степень, в которой любая лицензия на такие права
может быть, а может и нет; и не означает, что это
предпринял какие-либо усилия для определения любых таких прав.Информация о
Процедуры IETF в отношении прав на отслеживание стандартов и
документацию по стандартам можно найти в BCP-11. Копии
требования о правах, предоставленных для публикации, и любые гарантии
лицензии, которые должны быть предоставлены, или результат попытки
получить генеральную лицензию или разрешение на использование таких
права собственности разработчиков или пользователей данной спецификации могут
можно получить в Секретариате IETF.
IETF приглашает любую заинтересованную сторону довести до ее сведения любые
авторские права, патенты или заявки на патенты или другие проприетарные
права, которые могут охватывать технологии, которые могут потребоваться для практики
этот стандарт.Пожалуйста, направьте информацию исполнительному директору IETF.
Директор.
14. Адрес автора.
Андреас Густафссон
Nominum, Inc.
2385 Bay Rd
Редвуд-Сити, Калифорния 94063
США
Телефон: +1 650 381 6004
Электронная почта: [email protected]
Gustafsson Standards Track [Страница 7]
RFC 3597 Обработка неизвестных типов DNS RR Сентябрь 2003 г.
15. Полное заявление об авторских правах
Авторское право (C) The Internet Society (2003). Все права защищены.Этот документ и его переводы могут быть скопированы и предоставлены
другие и производные работы, которые комментируют или иным образом объясняют это
или помочь в его реализации могут быть подготовлены, скопированы, опубликованы
и распространяется, полностью или частично, без ограничения каких-либо
добрый, при условии, что указанное выше уведомление об авторских правах и этот абзац
включены во все такие копии и производные работы. Однако это
сам документ не может быть изменен каким-либо образом, например, путем удаления
уведомление об авторских правах или ссылки на Internet Society или другие
Интернет-организации, за исключением случаев, когда это необходимо для
разработка Интернет-стандартов, в этом случае процедуры для
авторские права, определенные в процессе разработки стандартов Интернета, должны быть
следовали, или по мере необходимости перевести его на другие языки, кроме
Английский.Ограниченные разрешения, предоставленные выше, являются бессрочными и не будут
аннулировано Интернет-сообществом или его правопреемниками или правопреемниками.
Этот документ и содержащаяся в нем информация размещены на
Основа "КАК ЕСТЬ" и ИНТЕРНЕТ-ОБЩЕСТВО И ИНТЕРНЕТ-ИНЖИНИРИНГ
TASK FORCE ОТКАЗЫВАЕТСЯ ОТ ВСЕХ ГАРАНТИЙ, ЯВНЫХ ИЛИ ПОДРАЗУМЕВАЕМЫХ, ВКЛЮЧАЯ
НО НЕ ОГРАНИЧИВАЕТСЯ НИКАКОЙ ГАРАНТИЕЙ, ЧТО ИСПОЛЬЗОВАНИЕ ИНФОРМАЦИИ
ЗДЕСЬ НЕ НАРУШАЕТ НИКАКИХ ПРАВ ИЛИ ПОДРАЗУМЕВАЕМЫХ ГАРАНТИЙ
КОММЕРЧЕСКАЯ ЦЕННОСТЬ ИЛИ ПРИГОДНОСТЬ ДЛЯ ОПРЕДЕЛЕННОЙ ЦЕЛИ.Подтверждение
Финансирование функции редактора RFC в настоящее время обеспечивается
Интернет-общество.
Курс по стандартам Густафссона [Страница 8]
Разметка HTML, созданная rfcmarkup 1.129d, доступная по адресу
https://tools.ietf.org/tools/rfcmarkup/ .