soa записи | Wiki — PeterHost

Категория:Виртуальный хостинг -> Домены
Категория:Виртуальный хостинг -> DNS

Содержание

SOA

SOA-запись DNS , которая определяет авторитетную информацию о DNS-зоне.

Формат

SOA запись содержит следующие параметры:

Primary Name Server

Имя первичного DNS-сервера зоны

Hostmaster

Контактный адрес лица, ответственного за администрирование файла зоны. Обратите внимание на то, что вместо «@» используется «.»

Serial number

Серийный номер файла зоны. 32-разрядное целое число, меняющееся при каждом обновлении зоны.

Refresh

Время (в секундах) ожидания вторичного DNS перед запросом SOA-записи с первичного. По истечении данного времени, вторичный DNS обращается к первичному, для получения копии текущей SOA-записи. Первичный DNS-сервер выполняет этот запрос. Вторичный DNS-сервер сравнивает полученный серийный номер зоны с имеющимся. Если они отличаются, то осуществляется запрос к первичному DNS-серверу на трансфер зоны.

Retry

Время в секундах, вступает в действие тогда, когда первичный DNS-сервер недоступен. Интервал времени, по истечении которого вторичный DNS должен повторить попытку синхронизировать описание зоны с первичным.

Expire

Время (в секундах), в течение которого вторичный DNS будет пытаться завершить синхронизацию зоны с первичным. Если это время истечет до того, как синхронизация осуществится, зона на вторичном DNS-сервере истечет, и он перестанет обслуживать запросы об этой зоне.

Minimum TTL

Минимальное время жизни, применяемое ко всем ресурсным записям зоны. Это значение применяется в ответах на запросы с целью проинформировать остальные серверы, сколько времени они могут хранить данные в кэше.

Как посмотреть?

nslookup

С помощью команды nslookup(Доступна в операционных системах Windows и UNIX-подобных)

$ nslookup
> set type=SOA 
> peterhost.ru
Server:        192.168.192.168
Address:    192.168.192.168#53
Non-authoritative answer:
peterhost.ru
    origin = ns1.peterhost.ru
    mail addr = dnsmaster.peterhost.ru
    serial = 1264777100
    refresh = 10800
    retry = 1800
    expire = 3600000
    minimum = 3600
Authoritative answers can be found from:

dig

Команда dig доступна в UNIX-подобных операционных системах.

Необходимо выполнить команду:
dig имя_домена SOA

dig peterhost.ru SOA
; <<>> DiG 9.6.1-P1 <<>> peterhost.ru SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26854
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;peterhost.ru.            IN    SOA
;; ANSWER SECTION:
peterhost.ru.        86400    IN    SOA    ns1.peterhost.ru. dnsmaster.peterhost.ru. 1264777100 10800 1800 3600000 3600
;; Query time: 62 msec
;; SERVER: 192.168.192.168#53(192.168.192.168)
;; WHEN: Fri Jan 29 18:54:23 2010
;; MSG SIZE  rcvd: 80

Категории:

peterhost.ru

DNS SOA запись

DNS SOA запись — Start of Authority — зона DNS, характеризующая как информация о доменном имени распространяется на вторичные DNS сервера. Данная запись и ее значение фактически не влияют на работу домена (как А-записи или PTR), SOA содержит административную информацию.

 

 

• TTL – количество секунд в течение которых информация будет кэшироваться другими DNS серверами
• Computer – FQDN — полностью определенное доменное имя (с точкой на конце), являющееся первичным источником информации для зоны
• Email – адрес администратора доменной зоны
• Starting Serial – версия доменной зоны с которой начнется отсчет, число будет инкрементироваться при каждом изменении
• Refresh – количество секунд через которое значение будет обновлено после изменения, часто это 86400 (24 Hours)
• Retry – количество секунд по прошествии которого будет предпринята повторная попытка обновления информации если первая не удалась, обычно это 7200 (2 Hours)
• Expire – The time internal (in seconds) that specifies the upper limit on the time internal that can elapse before the zone is no longer authoritative. This is when the secondary name servers will expire if they are unable to refresh. Recommended value – up to 2419200 (672 Hours)
• Negative Cache – количество секунд по прошествии которых кэшируется пустое значение записи, выставляется, как правило, в 180 — 172800 секунд (3 минуты – 2 дня)

 

Просмотреть значение записи можно, например, при помощи утилиты dig

dig example.com SOA

; <<>> DiG 9.10.3-P4-Ubuntu <<>> example.com SOA
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38193
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;example.com. IN SOA

;; ANSWER SECTION:
example.com. 300 IN SOA ns1.examplehost.com. hostmaster.examplehost.com. 1505669677 300 600 86400 300

;; Query time: 88 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)

;; WHEN: Sat Nov 18 16:59:35 +05 2017
;; MSG SIZE rcvd: 86

 

Запись не является обязательной — если ее нет, будут применяться параметры обновления зоны, указанные для всего сервера.

 

Основное предназначение записи в том, что она определяет отношения с вторичными DNS серверами (сервера DNS организуются в виде кластера и SOA определяет как информация будет распространяться между ними).

Каждое обновление порядкового номера SOA является сигналом вторичным серверам о том, что они также должны обновить значение в своей базе.

server-gu.ru

Запись «Start Of Authority» | http://info.nic.ru

В данном материале мы обсудим одну из самых важных записей описания ресурсов «Start of Authority»(SOA). Именно эта запись определяет ту зону, к которой относятся все описания ресурсов — прочие Resource Records.

Описание зоны по традиции начинают с записи SOA (Start Of Authority). На самом деле, после 1998 года, когда появился документ RFC 2308, описание зоны начинают с директивы управления $TTL, которая задает время хранения соответствий в кэше resolver или сервера доменных имен.

Запись SOA отмечает начало описания зоны. Обычно, это первая запись описания ресурсов (Resource Record — RR). Настоятельно рекомендуется наличие одной и только одной записи типа SOA в каждом файле описания зоны, который указан в записи primary файла named.boot или в директиве zone файла named.conf.

Формат записи SOA можно представить как:

[zone] [ttl] IN SOA origin contact (serial refresh retry expire minimum)

В этой записи каждое из полей обозначает следующее:

Поле zone — имя зоны. Если речь идет о зоне, описанной в записи primary файла named.boot, то в качестве имени употребляется символ коммерческого эт — «@». В этом случае в качестве имени текущей зоны берется имя, указанное в качестве первого аргумента команды primary из файла named.boot, или имя зоны, указанное в директиве zone файла named.conf.

Поле зоны обязательно должно быть указано, иначе named не сможет привязать следующие за данной записью описания ресурсов к имени зоны. Пустое имя зоны не является допустимым.

Можно, конечно, указывать и полное имя зоны, не забывая при этом ставить на конце имени «.»:

kyky.ru. IN SOA ns.kyky.ru adm.kyky.ru ( 2 8h 30m 2w 2h )

Поле ttl в записи SOA всегда пустое. Дело в том, что время кэширования для записей описания зоны задается либо последним аргументом данных записи SOA (версии BIND до 8.2.), либо директивой управления $TTL. Запрет на кэширование SOA определен в RFC 1035.

Вообще говоря, данное жесткое ограничение (наличие 0 в поле ttl) было снято в 1997 году (RFC 2181). Связано это было с тем, что реально требование наличия нуля в поле ttl записи SOA нигде не использовалось и не проверялось. С тех пор записи SOA могут содержать значения в поле ttl.

Поле origin — это доменное имя primary master сервера зоны. В случае описания зоны kyky.ru в качестве сервера используется машина ns.kyky.ru. Данное доменное имя и должно быть указано в поле origin.

Очень часто в этом поле можно встретить имена, которые начинаются с «ns», например, ns.kiae.su или ns.relarn.ru. В данном случае это означает только то, что primary master сервер зоны размещен на машине с таким именем. Никого специального зарезервированного имени для указания в поле origin нет. Использование, указанных выше имен обосновано тем, что их просто легче запомнить, т.к. «ns» означает «name server».

Довольно часто администраторы зон, которые делегируют части своих зон другим организациям, в ультимативной форме требуют, чтобы имя primary master не совпадало с именем зоны.

Elz и Bush в RFC-2181 отмечали, что это требование повсеместно нарушается и практически является бесполезным. Кроме того, существует документ (ripe-203), в котором написано, что данное требование (отличие имени primary master сервера от имени зоны в SOA) справедливо, за исключением случая, когда доменное имя зоны связано адресной записью с IP-адресом primary master этой зоны. Для небольших зон это случается сплошь и рядом, т.к. и primary master зоны и почтовый транспортный агент и прочие сервисы в мелких организациях устанавливаются на одной и той же машине.

Требование, однако, справедливо при заполнении интерактивных форм регистрации домена, т.к. система в момент регистрации не имеет ни малейшего понятия о том, что администратор зоны напишет в файле описания зоны, т.е. гарантии того, что имя зоны и имя primary master сервера совпадают, в момент регистрации домена нет.

Поле contact определяет почтовый адрес лица, осуществляющего администрирование зоны. Данный адрес должен совпадать со значением адреса указанным в заявке на домен. Есть, однако, одна особенность при указании этого адреса. Так как символ «@» имеет особый смысл при описании зоны, то вместо этого символа в почтовом адресе используется символ «.».

Например, если ваш администратор домена имеет почтовый адрес adm@kyky.ru, то в поле contact следует писать не adm@kyky.ru, а adm.kyky.ru.

Если в имени пользователя есть какие-либо особые символы, имеющие специальные значения при описании зоны, то они должны маскироваться символом обратного слэша — «\».

Типичный пример — почтовый адрес типа user.name@kuku.ru. В этом случае точку следует замаскировать и написать в поле contact: user.name.kuku.ru. Поступая таким образом, мы исключили особое значение точки как разделителя поддоменов и обеспечили интерпретацию имени как единой символьной строки.

Вообще говоря, почтовые адреса приведенного выше типа не являются редкостью, но у администраторов компьютерных систем встречаются очень редко. Кроме того, если следовать рекомендациям (RFC 2142), то лучше всего, чтобы администратор DNS сервера имел адрес hostmaster@kuku.ru.

Поле данных в записи SOA разбито на аргументы, которые определяют порядок работы сервера с записями описания зоны. Как правило, все аргументы располагают на другой строке или, для лучшего отображения, каждый на своей строке, что заставляет записывать их внутри скобок. Напомним, что скобки позволяют продлить запись описания ресурса на несколько строк, а символы табуляции и пробелы разделяют поля записи описания ресурса между собой.

Атрибут serial — определяет серийный номер файла зоны. Если говорить проще, то в этом поле ведется учет изменений файла описания зоны. Serial — это 32-битное целое число, и ограничение по числу цифр, которое можно встретить в руководствах по BIND, на самом деле условно.

В принципе это могут быть любые числа, но чаще всего администраторы используют в качестве серийного номера год (4 позиции), месяц (две позиции), день (две позиции) и версию внесения изменений в файл описания зоны (две позиции). Таким образом эта нотация будет выглядеть как:

ГГГГММДДВВ

Итого получается 10 символов. В старых руководствах по BIND указывают максимальное значение длины этого поля 8 символов.

Важность серийного номера определяется тем, что когда вторичный(secondary) сервер обращается к первичному(primary) серверу для обновления информации о зоне, то он сравнивает серийный номер из своего кэша с серийным номером из базы данных первичного сервера. Если серийный номер из primary сервер больше, то secondary сервер обращается к primary и копирует описание всей зоны целиком, если нет, то он не вносит изменений в свою базу данных. Таким образом, когда производятся изменения в базе данных primary сервера, то значение атрибута serial в поле данных записи SOA для зоны, описание которой было изменено, должно быть увеличено. Неизменение номера — это типичная ошибка, которую совершают администраторы зон. По этой причине лучше пользоваться средствами автоматического обновления зоны.

А что делать при достижении максимально возможного порядкового номера? Вопрос гипотетический, т.к., если даже использовать в качестве серийного номера приведенную выше нотацию, то мы достигнем предельных значений серийного номера только в 4294 году (цитируем по man named для FreeBSD 4.2 -RELEASE), но все же?

На самом деле все просто: нужно начинать сначала. До BIND 9 можно было просто указать 0-ую версию описания зоны в любой момент, и потом снова начать ее увеличивать.

Любителям математики следует прочитать раздел «Цикл порядкового номера» в книге Пола Альбитца и Крикета Ли «DNS и BIND» на странице 194 (Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.). Там подробно объяснена концепция непрерывного арифметического пространства и способ перехода к младшим целым номерам от старших за два шага изменения серийного номера описания зоны. Кроме того, арифметике серийного номера посвящен отдельный документ — RFC 1982.

Атрибут refresh определяет интервал времени, после которого slave сервер обязан обратиться к master серверу с запросом на верификацию своего описания зоны. Как уже было сказано в разделе «Типы серверов доменных имен», при этом проверяется серийный номер описания зоны.

Описание зоны загружается slave сервером каждый раз, когда он стартует или перегружается. Однако, при стабильной работе может пройти достаточно большой интервал времени, пока эти события не произойдут в действительности. Кроме того, большинство систем, которые поддерживают сервис доменных имен, работают круглосуточно. Следовательно, необходим механизм синхронизации баз данных master и slave серверов.

Поле refresh задает интервал, после которого эта синхронизация автоматически выполняется. Длительность интервала указывается в секундах. В поле refresh можно указать любое целое 32-битное число. Указание маленького значения приведет к неоправданной загрузке сети, ведь в большинстве случаев описание зон довольно стабильно, но иногда, когда зона только создается, можно указать и небольшой интервал.

Атрибут retry начинает играть роль тогда, когда master сервер по какой-либо причине не способен удовлетворить запрос slave сервера за время определенное атрибутом refresh. А если говорить точнее, то в момент наступления времени синхронизации описания зоны master сервер по какой-либо причине не отвечает на запросы slave сервера.

Атрибут retry определяет интервал времени, после которого slave сервер должен повторить попытку синхронизовать описание зоны с master сервером. Ограничения на значение этого атрибута те же, что и для атрибута refresh.

При установке этого значения во внимание следует принимать несколько факторов. Во-первых, если master сервер не отвечает, то, скорее всего, произошло что-то серьезное (отделочники вырезали часть сети, т.к. мешала красить стены, экскаватор перекопал магистраль или отключили питание в сети). Такая причина не может быть быстро устранена, поэтому установка слишком малого времени опроса просто зря нагружает сеть.

Во-вторых, если на master сервере прописано много зон, и он обслуживает большое количество запросов, то сервер может просто не успеть ответить на запрос, а очень частые запросы от slave сервера просто «подливают масло в огонь», ухудшая и без того медленную работу сервера.

Атрибут expire определяет интервал времени, после которого slave должен прекратить обслуживание запросов к зоне, если он не смог в течение этого времени верифицировать описание зоны, используя информацию с master сервера.

Обычно это интервал делают достаточно большим. Если сделать маленький интервал, то какой смысл в slave сервере? Он просто скоропостижно скончается после отключения master сервера.

В течение всего этого времени, т.е. до достижения конца интервала expire, slave сервер будет пытаться установить контакт c master сервером и обслуживать запросы к зоне.

Правда все эти соображения хороши для случая, когда просто отключится или ломается машина, на которой стоит master сервер. Если же отключится вся сеть, которая описана в зоне, а для большинства организаций так оно и есть, то slave сервер становится подобным космическому аппарату «Пионер», который путешествует во Вселенной, давно потеряв всякую связь с Землей.

Тем не менее, существует несколько причин, по которым его наличие полезно. Во-первых, различные приложения по разному реагируют на ситуацию отсутствия соединения или невозможности найти соответствие доменному имени. Во-вторых, если зона доступна, а хост в ней недоступен, то приложение гораздо быстрее прерывает свою работу. В-третьих, время положительно кэширования гораздо больше времени негативного кэширования, а это ускоряет процесс прекращения попыток соединения с неработающим хостом, т.к. не нужно находить его адрес. В-четвертых, в отключенной сети все хосты не доступны, а они принадлежат, как правило, к одному домену, а адрес его slave сервера доменных имен закэширован и сам сервер доступен, что ускоряет, по крайней мере не замедляет, проверку доступности хостов домена (подробнее см. RFC 2182).

Последний атрибут из поля данных записи SOA — minimum. В разных версиях BIND он определяет совершенно разные понятия. До 8.2 этот параметр определял время кэширования по умолчанию ответов на запросы к DNS. Еще раньше он определял время кэширования по умолчанию только положительных ответов, т.е. тех, которые устанавливали наличие соответствия между IP-адресом и доменным именем. Теперь этот параметр обозначает время негативного кэширования (negative caching), т.е. время кэширования ответов, которые утверждают, что установить соответствие между доменным именем и IP-адресом нельзя.

Последнее обстоятельство заставило ввести в описание зоны новую директиву управления $TTL, которая и определяет время кэширования по умолчанию положительных ответов от системы DNS.

Существуют рекомендации по установки параметров записи SOA. Например, RFC 1537 рекомендует следующие установки для серверов, отличных от тех, которые поддерживают домены верхнего уровня:

28800 ; Refresh 8 hours
7200 ; Retry 2 hours
604800; Expire 7 days
86400 ; Minimum TTL 1 day

На самом деле установить в современных серверах minimum больше 3 часов нельзя (в том смысле, что написать-то можно, работать параметр не будет). Это максимальное время негативного кэширования, согласно документации на BIND 9.

Для TLD в том же документе рекомендованы:

86400 ; Refresh 24 hours
7200 ; Retry 2 hours
2592000; Expire 30 days
345600 ; Minimum TTL 4 days

Конечно, это не догма. В этом легко убедиться, посмотрев соответствующие параметры в SOA для зоны ru программой nslookup:

> set type=soa
> ru.
Server: ns.ripn.net
Address: 194.85.119.1

ru
origin = ns.ripn.net
mail addr = hostmaster.ripn.net
serial = 4005176
refresh = 7200 (2H)
retry = 900 (15M)
expire = 2592000 (4w2d)
minimum ttl = 345600 (4D)
ru nameserver = ns.ripn.net
ru nameserver = ns1.relcom.ru
ru nameserver = ns.uu.net
ru nameserver = sunic.sunet.se
ru nameserver = ns2.nic.fr
ru nameserver = ns2.ripn.net
ns.ripn.net internet address = 194.85.119.1
ns1.relcom.ru internet address = 193.125.152.3
ns2.ripn.net internet address = 194.226.96.30
>

Для зоны com информация несколько иная:

> com.
Server: [192.5.6.30]
Address: 192.5.6.30

com
origin = A.GTLD-SERVERS.NET
mail addr = NSTLD.VERISIGN-GRS.com
serial = 2002092401
refresh = 1800 (30M)
retry = 900 (15M)
expire = 604800 (1W)
minimum ttl = 86400 (1D)

Для полноты картины укажем и на более поздние рекомендации. Так, например, для небольших стабильных зон в 1999 году (ripe-203) рекомендовались следующие параметры SOA:

example.com. 3600 SOA dns.example.com. hostmaster.example.com. (
1999022301 ; serial YYYYMMDDnn
86400 ; refresh ( 24 hours)
7200 ; retry ( 2 hours)
3600000 ; expire (1000 hours)
172800 ) ; minimum ( 2 days)

При этом автор (Peter Koch) подробно описывает причины, по которым установлены эти значения.

Например, для refresh интервал в сутки выставлен потому, что существует динамическое обновление зоны и оповещение slave серверов о произошедших изменениях. По этой причине нет смысла ставить маленький интервал обновления базы данных slave сервера. Если оповещение отключено или используются старые версии BIND, то, видимо, нужно спуститься с небес на землю и поставить интервал поменьше, скажем часов 8 (RFC 1537) или еще меньше.

Для атрибута expire обычно указывают одну или две недели. Однако считается, что за это время серьезные проблемы с primary master не решить, следовательно, период должен быть большим, что-то порядка месяца-двух.

Peter Koch написал в 2001 году более свежие рекомендации по установке значений в записи SOA (RIPE DNS GUIDE). По факту (значениям, перечисленным в примере записи SOA) они ничем не отличаются от приведенного выше примера.

В новых рекомендациях существует важное замечание относительно значения параметра minimum. Интерпретация его значения зависит от того, поддерживает ли конкретная реализация BIND негативное кэширование. Если поддерживает и mininum — это время негативного кэширования, то следует указывать значение 3600, если не поддерживает, то — 172800.

Обратите внимание на то, что все атрибуты записи SOA определяют порядок взаимодействия master сервера и slave серверов. Исключение составляет только атрибут minimum. В данном случае речь идет о кэшировании адресов не только сервером, но системой «умного» resolver.

Дело в том, что в качестве resolver на локальной вычислительной установке выступают функции из стандартной библиотеки, которые направляют рекурсивные запросы к локальному серверу доменных имен и сами не осуществляют кэширования соответствий между именами и IP-адресами. В этом случае кэширование осуществляется локальным сервером доменных имен.

Если на машине запускается свой кэширующий сервер, который не описывает никакой зоны, а используется только для обслуживания запросов к сервису доменных имен, то именно он и является той частью resolver, которая кэширует соответствия.

Таким образом, когда речь идет об атрибуте minimum, то чаще всего его описывают в контексте программы named, которая может использоваться не только как master или slave сервер, но и как кэширующий сервер. В этом случае поле ttl записи описания ресурса, директива управления $TTL и атрибут minimum задают время хранения записи описания ресурса в кэше.

Приведем еще один пример записи типа SOA:

example.com. 3600 SOA dns.example.com. hostmaster.example.com. (
1999022301 ; serial YYYYMMDDnn
1d ; refresh
2h ; retry
30d ; expire
1H ) ; minimum

В данном примере имя зоны указано непосредственно — example.com. Время ttl для самой записи указано равным часу, хотя записи SOA и не хранятся в кэше. Primary master зоны указан как dns.example.com, и его имя отличается от имени домена. Адрес электронной почты администратора соответствует всем существующим рекомендациям — hostmaster@example.com. Серийный номер версии описания зоны занимает 10 позиций и соответствует шаблону даты. Время обновления базы данных описания зоны на slave серверах установлено равным 1 суткам, время повторения попыток обновления установлено равным 2 часам, период «умирания» зоны равен одному месяцу, а время негативного кэширования установлен равным одному часу.

Обратите внимание, что интервалы заданы не в секундах, а в более понятной нотации (минутах (m), часах (h), днях (d), неделях (w)).

И еще одно замечание в завершении этого материала. Мы много говорили о параметрах негативного кэширования, но вопроса о необходимости этого самого кэширования не обсудили. Мы сделаем это отдельно, т.к. кэширование отрицательных ответов вызвано не только теоретическими соображениями, но и суровой прозой жизни.

 

Рекомендованная литература:

 

1. P. Mockapetris. RFC-1034. DOMAIN NAMES — CONCEPTS AND FACILITIES. ISI, 1987. (http://www.ietf.org/rfc/rfc1034.txt?number=1034)
2. P. Mockapetris. RFC-1035. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc1035.txt?number=1035)
3. M. Andrews. RFC 2308. Negative Caching of DNS Queries (DNS NCACHE). 1998.(http://www.ietf.org/rfc/rfc2308.txt?number=2308)
4. Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.
5. P. Beertema. RFC 1537. Common DNS Data File Configuration Errors. 1993.(http://www.ietf.org/rfc/rfc1537.txt?number=1537)
6. D. Crocker. RFC 2142. MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS. 1997.(http://www.ietf.org/rfc/rfc2142.txt?number=2142)
7. Peter Koch. RIPE-203. Recommendations for DNS SOA Values. 1999. (http://www.ripe.net/docs/ripe-203.html)
8. R. Elz, R. Bush. RFC 2181. Clarifications to the DNS Specification. 1997. (http://www.ietf.org/rfc/rfc2181.txt?number=2181)
9. R. Elz, R. Bush. RFC 2182. Selection and Operation of Secondary DNS Servers. 1997. (http://www.ietf.org/rfc/rfc2182.txt?number=2182)

 

Полезные ссылки:

 

1. http://www.isc.org/products/BIND/bind9.html — страничка BIND 9.2.1
2. http://www.ludd.luth.se/~kavli/BIND-FAQ.html — DNS FAQ. Ответы на большинство вопросов, начинающих и «продвинутых» администраторов. Есть только одно большое НО! Этот материал посвящен BIND версии 4. Но все, что касается описания зоны вполне подходит и для более поздних версий BIND.
3. Peter Koch. INTERNET-DRAFT. RIPE DNS WG Guide To Setting Up a DNS Server. 2001. (http://www.techfak.uni-bielefeld.de/~pk/dns/draft-koch-ripe-dns-setup-guide-01.txt.gz)- это рекомендации по установке параметров записи SOA и описание применения других записей RR.
4. R. Elz, R. Bush. RFC 1982. Serial Number Arithmetic. 1996.(http://www.ietf.org/rfc/rfc1982.txt?number=1982)- этот документ для особо дотошных читателей. В нем подробно описана концепция непрерывного арифметического пространства серийного номера и приведены примеры изменения номера и сравнения номеров.

info.nic.ru

Введение в DNS-записи | Вебмастеру

Система доменных имен (DNS) — это адресная книга интернета. DNS направляет трафик на сайт почту, сопоставляя доменные имена с IP-адресами. В этом руководстве рассматриваются основные концепции DNS и DNS- записей.

Общая группа доменов указывается справа. В приведенных ниже примерах домен верхнего уровня или TLD — это .com.

example.com
mail.hello.example.com

Каждое значение слева от TLD отделяется точкой, и называются поддоменами. hello и mail соответственно являются поддоменами второго и третьего уровня. Субдомены используются для идентификации определенных компьютеров или служб.

Выбор и указание сервера DNS является неотъемлемой частью владения доменом. Иначе клиентские устройства не будут знать, где найти информацию о DNS.

Серверы имен размещают информацию о домене DNS в текстовом файле, который называется файлом зоны. Они также известны как записи Start of Authority (SOA). Вы можете разместить свою информацию DNS на серверах имен в одном из нескольких мест:

• Регистратор домена;
• Ваш собственный DNS-сервер;
• Сторонний DNS-хостинг.

Записи DNS сопоставляют доменные имена с IP-адресами. Затем DNS-записи автоматически объединяются в файл зоны, что позволяет подключенным устройствам искать правильный IP-адрес домена. Если вы решите использовать серверы имен Linode, диспетчер DNS поможет создать файл зоны. Он содержит следующие записи:

; example.com [448369]
$TTL 86400
@  IN  SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600 86400
@       NS  ns1.linode.com.
@       NS  ns2.linode.com.
@       NS  ns3.linode.com.
@       NS  ns4.linode.com.
@       NS  ns5.linode.com.
@           MX  10  mail.example.com.
@           A   12.34.56.78
mail        A   12.34.56.78
www         A   12.34.56.78

Файл зоны каждого домена включает в себя адрес электронной почты администратора домена, серверы имен и DNS-записи. Вы можете создавать множество записей для любого количества поддоменов.

Доменное имя должно быть переведено на IP-адрес. DNS сопоставляет понятные пользователю доменные имена (example.com) с IP-адресами (192.0.2.8). Это происходит в специальном текстовом файле, называемом файлом зоны. В нем перечислены домены и соответствующие им IP-адреса. Файл зоны похож на телефонную книгу, в которой имена совпадают с адресами улиц.

Вот как работает процесс поиска DNS:

1. Вы вводите доменное имя, например com,в адресную строку браузера.
2. Компьютер подключен к интернету через провайдера (ISP). DNS-преобразователь интернет-провайдера запрашивает у корневого сервера имен соответствующий сервер имен TLD.
3. Корневой DNS-сервер отвечает IP-адресом для сервера имен .com.
4. DNS-распознаватель провайдера использует IP-адрес, полученный от корневого сервера имен.
5. Сервер имен .comотвечает IP-адресом сервера имен com.
6. DNS-распознаватель ISP считывает файл зоны с сервера имен домена.
7. Файл зоны показывает, какой IP-адрес соответствует домену.
8. Теперь, когда у провайдера есть IP-адрес для com, он возвращает его браузеру, который затем обращается к серверу сайта.

Описанный выше сценарий выполняется, если у провайдера нет информации о запрашиваемом домене. На самом деле провайдеры кэшируют данные о DNS после того, как получили ее в первый раз. Это ускоряет поиск и снижает нагрузку на DNS-серверы.

Но кэширование может стать проблемой, если вы недавно внесли изменения в информацию о DNS. Для ее решения измените значение времени жизни файла зоны (TTL), чтобы обновление DNS происходило быстрее.

Запись A связывает домен или субдомен с IP-адресом, что позволяет трафику достигать сайта. Это основная функция DNS. Типичная запись A выглядит следующим образом:

example.com     A       12.34.56.78

hello.example.com       A       12.34.56.78

Вы можете указать разные субдомены на разных IP-адресах. Если нужно указать каждый субдомен example.com на IP, то можете использовать для субдомена звездочку (*):

*.example.com   A       12.34.56.78

Запись AAAA аналогична записи A, но она используется для IP-адресов IPv6. Типичная запись AAAA выглядит следующим образом:

Запись AAAA аналогична записи A, но она используется для IP-адресов IPv6. Типичная запись AAAA выглядит следующим образом:

Запись AXFR используется для репликации DNS. Хотя существуют более современные способы.

Записи AXFR не используются в обычных файлах зон. Чаще всего они применяются на подчиненном DNS-сервере для репликации файла зоны с главного DNS-сервера.

DNS Certification Authority Authorization (CAA) использует DNS, чтобы владелец домена мог указать, каким центрам сертификации разрешено выдавать сертификаты для этого домена.

Запись CNAME (запись канонического имени) соответствует домену или поддомену. При записи CNAME используются разрешения DNS целевого домена в качестве разрешения псевдонима. Например:

alias.com       CNAME   example.com.
example.com     A       12.34.56.78

При запросе alias.com начальный поиск DNS найдет запись CNAME с целью example.com. Будет запущен новый поиск DNS example.com, который найдет IP-адрес 12.34.56.78. Посетители alias.com будут направлены к IP-адресу 12.34.56.78.

Записи CNAME применяются, чтобы домены могли иметь псевдонимы. Некоторые почтовые серверы странным образом обрабатывают почту для доменов с записями CNAME. Поэтому не следует использовать запись CNAME для домена, который принимает электронную почту.

Записи MX не могут ссылаться на имена хостов, определенные CNAME. Целевой домен для записи CNAME также должен иметь нормальное разрешение A-записи.

Примечание

CNAME-запись может быть эффективным способом перенаправления трафика от одного домена к другому, сохраняя тот же URL-адрес. Но она не работает так же, как редирект URL-адресов. CNAME-запись направляет трафик для определенного домена на IP-адрес целевого домена. Как только пользователь достигнет этого IP-адреса, конфигурация сервера будет определять способ обработки домена. Если этот домен не настроен, сервер отобразит веб-страницу по умолчанию. Она может быть веб-страницей целевого домена в записи CNAME, в зависимости от того, как настроен сервер.

Запись DKIM она же запись DomainKeys Identified Mail отображает открытый ключ для аутентификации сообщений, которые подписаны с помощью протокола DKIM. Это расширяет возможности проверки подлинности электронной почты. Типичная запись DKIM выглядит следующим образом:

selector1._domainkey.example.com        TXT     k=rsa;p=J8eTBu224i086iK

DKIM-записи представлены в виде текстовых записей. Запись должна быть создана для субдомена, который имеет уникальный селектор для этого ключа, затем указывается точка (.) и _domainkey.example.com. Тип -TXT, значение включает в себя тип ключа, за которым следует фактический ключ.

Запись MX устанавливает адресат доставки почты для домена или субдомена. Типичная MX-запись выглядит следующим образом:

example.com         MX      10  mail.example.com.
mail.example.com    A           12.34.56.78

Приведенные выше записи направляют почту для example.com на сервер mail.example.com. В идеале MX-запись должна указывать на домен, который также является именем хоста его сервера. Если вы используете стороннюю почтовую службу, такую ​​как Google Apps, то следует применять предоставленные ими MX-записи.

Приоритет является еще одним компонентом MX-записей. Это число, записанное между типом записи и целевым сервером. В примере, приведенном выше, использован приоритет 10.

Приоритет позволяет назначить резервный почтовый сервер (или серверы) для определенного домена. Меньшие числа имеют более высокий приоритет. Пример домена, который имеет два резервных почтовых сервера:

example.com         MX      10  mail_1.example.com
example.com         MX      20  mail_2.example.com
example.com         MX      30  mail_3.example.com

Если mail_1.example.com не работает, электронная почта будет доставлена на mail_2.example.com. Если mail_2.example.com также не работает, почта будет доставлена на mail_3.example.com.

NS-записи устанавливают серверы имен для домена. Они задаются для домена у регистратора и в файле зоны. Типичные записи сервера имен выглядят следующим образом:

example.com     NS      ns1.linode.com.
example.com     NS      ns2.linode.com.
example.com     NS      ns3.linode.com.
example.com     NS      ns4.linode.com.
example.com     NS      ns5.linode.com.

Серверы имен, которые вы назначаете у своего регистратора, содержат файл зоны для домена.

Также можно настроить различные серверы имен для любого из поддоменов. Они задаются в файле зоны вашего основного домена:

mail.example.com    NS      ns1.nameserver.com
mail.example.com    NS      ns2.nameserver.com

Первичные серверы имен настраиваются у регистратора, а вторичные — в файле зоны основного домена. Порядок NS- записей не имеет значения. DNS-запросы отправляются случайным образом на разные серверы. Если один хост не отвечает, будет запрошен другой.

Запись PTR или запись указателя сопоставляет IP-адрес с доменом или поддоменом, позволяя функционировать обратным DNS-запросам. Она работает противоположно записи A, в том смысле, что позволяет искать домен, связанный с конкретным IP-адресом, а не наоборот.

Записи PTR обычно устанавливаются на хостинге. Они не являются частью файла зоны домена.

Для добавления записи PTR необходимо создать действительную запись A или AAAA, которая указывает IP-адрес для нужного домена.

Примечание

Можно использовать разные IP-адреса (включая адреса IPv4 и IPv6), на которых один и тот же домен установлен для обратного DNS. Для этого необходимо настроить несколько записей A или AAAA для этого домена, которые указывают на различные IP-адреса.

Запись SOA обозначает файл зоны с именем хоста, на котором он был создан. Далее в нем указывается контактный адрес электронной почты администратора домена. Типичная запись SOA:

@ IN  SOA ns1.linode.com. admin.example.com. 2013062147 14400 14400 1209600 86400

Примечание

Адрес электронной почты администратора пишется с точкой (.) вместо символа @.

Вот что означают эти цифры:

• Серийный номер: номер редакции файла зоны этого домена. Он изменяется, когда файл обновляется.
• Время обновления: количество времени (в секундах), в течение которого вторичный DNS-сервер будет хранить файл зоны, прежде чем проверит изменения.
• Время повтора: время, которое вторичный DNS-сервер будет ожидать, прежде чем повторить передачу файла зоны.
• Время истечения: время, в течение которого вторичный DNS-сервер будет ожидать, прежде чем истечет срок действия текущей копии файла зоны, если он не сможет обновить себя.
• Минимальный TTL: минимальный период времени, в течение которого другие серверы должны хранить в кэше данные из файла зоны.

Сервер имен, упомянутый в записи SOA, считается основным для динамического DNS. На нем изменения файла зоны производятся до того, как они распространяются на другие серверы имен.

Запись Sender Policy Framework (SPF) содержит список почтовых серверов, назначенных для домена или субдомена. Это помогает подтвердить легитимность почтового сервера и снижает вероятность подделки заголовков писем. Спамеры часто пытаются сделать это, чтобы обойти фильтры.

SPF- запись домена сообщает другим почтовым серверам, какие исходящие серверы являются допустимыми источниками электронной почты. Поэтому они могут отклонять поддельную почту с вашего домена, отправленную с неавторизованных серверов. Простая SPF-запись выглядит следующим образом:

example.com   TXT     "v=spf1 a ~all"

В SPF-записи необходимо перечислить почтовые серверы, с которых вы отправляете почту, а затем исключить остальные. Ваша SPF- запись будет содержать домен или поддомен, тип (TXT или SPF, если ваш сервер имен поддерживает его) и текст (который начинается с «v = spf1» и содержит настройки SPF- записи).

С помощью этой SPF-записи принимающий сервер проверит и IP-адрес отправляющего сервера, и IP-адрес example.com.

Примечание

Убедитесь, что SPF- записи не слишком строгие. Если вы случайно исключите легитимный почтовый сервер, полученные от него письма могут быть помечены как спам.

Рекомендуем посетить ресурс openspf.org, чтобы узнать, как работают SPF- записи и как создать запись, которая подходит для вашей настройки.

Запись SRV сопоставляет конкретную службу, работающую на домене или поддомене, с целевым доменом. Это позволяет направлять трафик, предназначенный для определенных служб, на другой сервер. Типичная запись SRV:

_service._protocol.example.com  SRV     10      0       5060    service.example.com

Описание элементов, которые используются в SRV-записи:

• Служба: названию службы должно предшествовать подчеркивание ( _ ) и точка ( . ). Служба может быть чем-то вроде _xmpp.
• Протокол: имя протокола должно начинаться с подчеркивания ( _ ) и заканчиваться точкой ( . ). Протокол может быть чем-то вроде _tcp.
• Домен: имя домена, который будет получать исходный трафик для службы.
• Приоритет: первое число (10 в приведенном выше примере) позволяет установить приоритет для целевого сервера. Можно установить цели с разными приоритетами, что позволит иметь резервный сервер (или серверы) для этой службы. Меньшие числа имеют более высокий приоритет.
• Вес: Если две записи имеют одинаковый приоритет, вместо него учитывается вес.
• Порт: порт TCP или UDP, на котором работает служба.
• Цель: целевой домен или поддомен. Он должен иметь запись A или AAAA, которая разрешается в IP-адресе.

Примером использования SRV-записей является настройка федеративной VoIP .

Запись TXT (текстовая запись) предоставляет информацию о домене другим интернет-ресурсам. Одно из распространенных применений TXT-записи — создание SPF- записи на серверах имен, которые изначально не поддерживают SPF. Другой вариант использования — создание записи DKIM для почты.

Данная публикация представляет собой перевод статьи «DNS Records: An Introduction» , подготовленной дружной командой проекта Интернет-технологии.ру

www.internet-technologies.ru

Редактировать DNS-запись — Технологии Яндекса

Обязательные
domain	Строка	Имя домена.
record_id	Число	Идентификатор DNS-записи.
Необязательные
subdomain	Строка	Имя поддомена. Например, «domain.com» — имя поддомена домена «com», а «my.domain.com» — имя поддомена домена «domain.com». Значение по умолчанию — «@» (корень домена). Параметр нужно передать, если требуется создать или отредактировать DNS-запись не для домена, а для его поддомена.
ttl	Число	Время жизни DNS-записи в секундах. Для SOA-записи это время, на которое кешируется значение DNS-записи промежуточными DNS-серверами. Это же время будет использоваться по умолчанию для всех остальных новых записей зоны. Допустимые значения — от 900 и до 1209600. Рекомендуемое значение — 21600.
refresh	Число	Частота проверки в секундах вторичными DNS-серверами DNS-записи для этой зоны. Допустимые значения — от 900 и до 86400. Рекомендуемое значение — 10800. Параметр нужно передать, если редактируется SOA-запись.
retry	Число	Время в секундах между повторными попытками вторичных DNS-серверов получить записи зоны, если основной сервер ничего не вернул. Допустимые значения — от 90 и до 3600. Рекомендуемое значение — 900. Параметр нужно передать, если редактируется SOA-запись.
expire	Число	Время в секундах, по истечении которого вторичные DNS-сервера считают записи зоны несуществующими, если основной сервер повторно ничего не возвращает. Допустимые значения — от 90 и до 3600. Рекомендуемое значение — 900. Параметр нужно передать, если редактируется SOA-запись.
neg_cache	Число	Время в секундах, в течении которого будет кешироваться отрицательный ответ (ERROR = NXDOMAIN) от DNS-сервера. Допустимые значения — от 90 и до 86400. Рекомендуемое значение — 10800. Параметр нужно передать, если редактируется SOA-запись.
admin_mail	Строка	Email-адрес администратора домена. Параметр обязателен только для SOA-записи.
content	Строка	Содержимое DNS-записи. Для записи типа: A — адрес в формате IPv4 (например, «194.84.46.241»). AAAA — адрес в формате IPv6 (например, «2001:0db8:11a3:09d7:1f34:8a2e:07a0:765d»). CNAME, MX или NS — полностью определенное имя домена (FQDN). TXT — текст TXT-записи (например, «v=spf1 redirect=_spf.yandex.ru»).
priority	Число	Приоритет DNS-записи (чем меньше значение, тем выше приоритет). Параметр обязателен только для SRV или MX-записи. Значение по умолчанию — 10.
port	Строка	TCP или UDP-порт хоста, на котором размещен сервис. Сервисом может быть, например, джаббер. Параметр обязателен только для SRV-записи.
weight	Число	Вес SRV-записи относительно других SRV-записей для того же домена, с тем же приоритетом. Параметр обязателен только для SRV-записи.
target	Строка	Каноническое имя хоста, предоставляющего сервис. Параметр обязателен только для SRV-записи.

yandex.ru

Типы DNS-записей | | Obu4alka.ru

Часто используемые DNS-записи

SOA-запись (Start of authority)
SOA-запись DNS определяет авторитетную информацию о доменном имени и зоне в целом.

A-запись (Address)
Эта запись указывает имя хоста и адрес IP определенного компьютера. По сути, любая система с подключением http/https должна иметь свою A-запись, чтобы по доменному имени определялся привязанный к нему IP-адрес.

NS-запись (Name Server)
Определяет сервер, который отвечает за выбранную вами зону. У каждого домена должна быть хотя бы одна NS-запись, хотя на самом деле их может быть несколько — вплоть до отдельной записи для любого указанного поддомена.

CNAME-запись (Name Alias)
Позволяет создавать отсылки к ранее созданным A-записям и PTR-записям. Чаще всего используется для того, чтобы тот же сайт был доступен под разными доменными именами, например, при создании «зеркал». Запись CNAME позволяет компьютеру иметь более чем одно имя хоста.

MX-запись (Mail Server)
DNS MX-запись сообщает различным почтовым программам о том, где находится нужный почтовый сервер. Без нее предназначенная для указанного домена почта не будет отправлена на IP-адрес из A-записи.

TXT-запись (Text)
Применяется для добавления комментария к выбранному домену. Иначе, чем как добавить TXT-запись в DNS (при его изменении), вы не сможете привязать текст произвольного содержания к домену.

SPF (Sender Policy Framework)
указывает сервера, которые могут отправлять почту от имени домена. Запись SPF вносят в TXT-запись домена.
Пример:

site.ru  IN TXT "v=spf1 a mx ip4:11.11.11.11 ~all"

• v=spf1 — определяет версию используемой записи SPF;
• a — разрешает приём почты с сервера, IP-адрес которого стоит в ресурсной A записи домена. Проще говоря с сервера, где размещен сайт;
• mx — разрешает приём почты, если отправляющий сервер указан в одной из записей MX для домена;
• ip4:11.11.11.11 — разрешает приём почты с IP-адреса 11.11.11.11;
• ~all — если письмо пришло с сервера, который не входит в вышеперечисленный список, его стоит проанализировать более тщательно. Также можно использовать:
• -all— отвергать
• +all— пропускать
• ?all— нейтральный режим.

PTR-запись (Reverse Address)
Связывает домен хоста с его IP в обратной зоне DNS, поэтому должен быть прописан для каждого хоста отдельно. Зачастую эта запись создается автоматически, но проверка никогда не помешает. При этом сама же обратная зона DNS допускает использование только трех типов записи — PTR, NS и CNAME.

CAA-запись(Certification Authority Restriction)
С помощью данной записи владелец домена указывает удостоверяющий центр, имеющий право выпускать SSL/TLS-сертификаты для указанного домена. Запись CAA в DNS позволяет избежать несанкционированной выдачи сертификата, что делается либо случайно, либо с целью фишинга или каких-либо другой атаки.

Редко используемые DNS-записи

LOC-запись (Location)
Подобный тип записи востребован среди крупных компаний и организаций, так как применяется для определения месторасположения хоста с указанием широты и долготы.

SRV-запись (Service Address)
Используется для ассоциации домена и названия сервиса с указанием протокола на хосте. Проще говоря, с ее помощью определяется размещение сервиса на хосте.

HINFO-запись (Host Information)
Позволяет получить данные об архитектуре и используемой ОС хоста, так как для хранения данных подобного вида используется именно такая запись.

DNAME-запись (Domain Name)
Псевдоним для домена

WKS-запись (Well Known Service)
Данный тип записи связывает с определенной зоной имя хостинга, номер порта и протокол сервиса. Зачастую используется на хостах, используемых в качестве почтовых серверов.

RP-запись (Responsible Person)
Этот тип позволяет получить данные отдельного человека или организации, ответственных за конкретно взятое доменное имя. По этой записи можно узнать e-mail ответственного лица.

KEY-запись (Public Key)
Используется довольно редко — для ассоциации ключа для некоторых хостингов и используется в IETF-протоколе DNS для минимизации риска атак с подменой самого DNS.

Для того, чтобы изменить или добавить DNS-запись, необходимо зайти в административную панель хостинга, после чего перейти в управление зоной DNS и выполнить все необходимые действия.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

obu4alka.ru

Получаем информацию из DNS: SOA

Вопрос. С помощью какой команды можно узнать SOA запись в DNS для любого домена из шелла UNIX / Linux shell?

Ответ. получить SOA (start of authority record) — запись о сервере, хранящем эталонную конфигурацию в DNS, можно с помощью команд dig или host в UNIX или Linux.

Получаем SOA используя команду host

<code>$ host -t soa {domain.com}
$ host -t soa ya.ru</code>

Результат:

ya.ru has SOA record ns1.yandex.ru. sysadmin.yandex.ru. 2009031101 10800 900 2592000 900

Получаем SOA используя команду dig

<code>$ dig SOA {domain.com}
$ dig SOA ya.ru</code>

Результат:

; <<>> DiG 9.3.4-P1 <<>> SOA ya.ru
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23933
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 7, ADDITIONAL: 9
;; QUESTION SECTION:
;ya.ru.                         IN      SOA
;; ANSWER SECTION:
<span>ya.ru.                  6546    IN      SOA     ns1.yandex.ru. sysadmin.yandex.ru. 2009031101 10800 900 2592000 900</span>
;; AUTHORITY SECTION:
ru.                     165718  IN      NS      E.DNS.RIPN.NET.
ru.                     165718  IN      NS      NS.RIPN.NET.
ru.                     165718  IN      NS      NS2.NIC.FR.
ru.                     165718  IN      NS      NS2.RIPN.NET.
ru.                     165718  IN      NS      NS5.MSK-IX.NET.
ru.                     165718  IN      NS      NS9.RIPN.NET.
ru.                     165718  IN      NS      SUNIC.SUNET.SE.
;; ADDITIONAL SECTION:
E.DNS.RIPN.NET.         108935  IN      A       193.232.142.17
NS.RIPN.NET.            108935  IN      A       194.85.105.17
NS2.NIC.FR.             103861  IN      A       192.93.0.4
NS2.NIC.FR.             103860  IN      AAAA    2001:660:3005:1::1:2
NS2.RIPN.NET.           108935  IN      A       194.226.96.30
NS5.MSK-IX.NET.         108935  IN      A       193.232.128.6
NS9.RIPN.NET.           108935  IN      A       194.85.252.62
SUNIC.SUNET.SE.         97662   IN      A       192.36.125.2
SUNIC.SUNET.SE.         97662   IN      AAAA    2001:6b0:7::2
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Mar 27 14:17:30 2009
;; MSG SIZE  rcvd: 405

Замените домен ya.ru на нужный вам.

Получаем SOA используя команду nslookup

nslookup -type=SOA ya.ru

Результат:

Non-authoritative answer:
ya.ru
        origin = ns1.yandex.ru
        mail addr = sysadmin.yandex.ru
        serial = 2009031101
        refresh = 10800
        retry = 900
        expire = 2592000
        minimum = 900
Authoritative answers can be found from:
ru      nameserver = NS5.MSK-IX.NET.
ru      nameserver = NS9.RIPN.NET.
ru      nameserver = SUNIC.SUNET.SE.
ru      nameserver = E.DNS.RIPN.NET.
ru      nameserver = NS.RIPN.NET.
ru      nameserver = NS2.NIC.FR.
ru      nameserver = NS2.RIPN.NET.
E.DNS.RIPN.NET  internet address = 193.232.142.17
NS.RIPN.NET     internet address = 194.85.105.17
NS2.NIC.FR      internet address = 192.93.0.4
NS2.NIC.FR      has AAAA address 2001:660:3005:1::1:2
NS2.RIPN.NET    internet address = 194.226.96.30
NS5.MSK-IX.NET  internet address = 193.232.128.6
NS9.RIPN.NET    internet address = 194.85.252.62
SUNIC.SUNET.SE  internet address = 192.36.125.2
SUNIC.SUNET.SE  has AAAA address 2001:6b0:7::2

Постовой

Совсем недавно переезжал в Москве с одной квартиры на другую. Могу с уверенностью сказать, что это был переезд стоивший мне настоящие копейки. Воспользовался услугами компании «Альянс Плюс» и совершенно не жалею.

Еще записи по теме

guruadmin.ru