Addr что это

Перевод «ADDR» на русский

Linux: Linux users can launch a terminal window and enter the command hostname -I (that’s a capital «i»), ifconfig, or ip addr show.

Пользователи Linux могут запускать окно терминала и вводить имя хоста команды -I (это капитальный «i»), ifconfig или ip addr show.

ip addr show — Shows the ip address of the board.
ip addr show — показать ip адрес

The most successful Polonia Warszawa was in 2000 when the team won the Polish championship, League Cup and Polish Supercup. A year later, in 2001 the club won the second cup of Poland. Other Addr dło:.

Наиболее успешных Полония был в 2000 году, когда команда выиграла Чемпионат Польши, польских Суперкубок и Кубок Лиги. Год спустя в 2001 году клуб выиграл второй Кубок Польши. Другие Addr dło:.

ADDR has also set up a mechanism to detect fraudulent demobilization.
УРДР также создало механизм для выявления случаев мошенничества во время демобилизации.
Today I send everyone to ADDR.
В последнее время всех направляют в ЕЦД.

Regarding the heavy machine guns, the Group notes that one of them had been marked by ADDR (see annex 14).

Что касается тяжелых пулеметов, то, как отмечает Группа, на одном из них имеются отметки, нанесенные УРДР (см. приложение 13).

The Minister of Defence confirmed to the Group that following a census conducted in 2013 by the National Security Council, ADDR decided to increase the number of ex-combatants under consideration from 64,777 to 74,068 (see annex 4).

Министр обороны сообщил Группе, что после переписи, проведенной в 2013 году Национальным советом безопасности, УРДР решило увеличить число бывших комбатантов, дела которых оно рассматривает с 64777 до 74068 человек (см. приложение 4).

You know how to addr ess her?
Вы знаете как к ней обращаться?
JEQ addr — Jump, if equal, to address
jump if equal — перейти, если равно

addrlen specifies the size, in bytes, of the address structure pointed to by addr. Traditionally, this operation is called «assigning a name to a socket».

Когда сокет только что создан с помощью socket (2), он существует в пространстве имён (семействе адресов), но не имеет назначенного имени.

Addr: Los Ciruelos 514 y Diego de Vasquez.
Адресс: Los Ciruelos 514 y Diego de Vásquez.
These jokes are made to addr.
Но отпуская шутки в адр.
Assignment of static IP addr.
Присваивание статического IP адерса.
In this article, we are going to addr
Статья: Едем в Адлер

The globes of PIR Center are awarded to the Russian and foreign statesmen and community leaders, scholars, experts, journalists and philanthropists, that have significantly contributed to the strengthening of the nuclear nonproliferation regime, addr.

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

While this caseload represents a 9.5% decrease over 2008, it covers the highest number of individual domain names in a given year (4,688) since the UDRP — a quick and cost effective way of addr

Хотя этот объем на 9,5% ниже уровня 2008 г., он покрывает самое высокое число отдельных доменных имен в отдельном году (4688) за десять лет со времени введения ЕПУС — оперативного и рентабельного способа рассмотрения обвинений в киберсквоттинге.

DNS address — Enter the IP addresses of the Primary DNS address and Secondary DNS addr. if required by your service provider

Адрес DNS — введите IP-адреса DNS-серверов: Первичный DNS и Вторичный DNS, если это требуется поставщиком услуг

Возможно неприемлемое содержание

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

Ничего не найдено для этого значения.
Предложить пример
Больше примеров Предложить пример

Новое: Reverso для Windows

Переводите текст из любого приложения одним щелчком мыши .

Скачать бесплатно
Перевод голосом, функции оффлайн, синонимы, спряжение, обучающие игры

Результатов: 18 . Точных совпадений: 18 . Затраченное время: 32 мс

Помогаем миллионам людей и компаний общаться более эффективно на всех языках.

Precious C++

Проясним момент насчет различия операторов ADDR и OFFSET в программах, написанных на Ассемблере.
Первоочередное назначение данных операторов — это получение адреса переменной в памяти.
В программах на ассемблере могут присутствовать как локальные так и глобальные переменные.
Глобальные переменные существуют в памяти на протяжении всего времени выполнения программы, локальные — только во время выполнения процедуры, в которой они определены, и удаляются как только она завершит работу. Поэтому адреса глобальных переменных известны уже на стадии ассемблирования, тогда как адреса локальных переменных в стеке станут известны только во время выполнения программы, а точнее при выполнении процедуры, в которой эти переменные объявлены.
Что касается операторов, то OFFSET вычисляет адрес уже размещенных к началу выполнения программы переменных, а это значит что данный оператор можно использовать для вычисления адресов только глобальных переменных.
С помощью оператора ADDR можно получить адрес локальной переменной.
Но почему так получается, что с помощью ADDR можно узнать адрес локальной пременной, а с помощью OFFSET — нельзя. Дело в том, что ассемблер, встретив оператор ADDR, использующийся с локальной переменной, генерирует последовательность инструкций

lea eax, localVar push eax

ну а инструкция lea уже делает свое дело. Т.к. ADDR превращается в выше указанную посдедовательность инструкций, данный оператор можно использовать только с директивой invoke для передачи адреса переменной в качестве параметра. Присваивание регистру полученного таким способом адреса невозможно. ADDR можно так же использоваться и с глобальными переменными. В этом случае ассемблер сгенерирует

push offset globalVar

И в отличие от OFFSET, ADDR не умеет вычислять смещения меток, определенных далее в коде.

mov eax, offset l1 ; так можно invoke Foo, ADDR l1; так нельзя l1: xor ebx, ebx invoke Foo, ADDR l1; так можно

Addr что это

В этом материале мы рассмотрим, как решается в DNS задача поиска доменного имени по IP-адресу, что из себя представляет загадочный домен IN-ADDR.ARPA, какие проблемы возникают при делегировании «обратных» зон.

Задача поиска доменного имени по IP-адресу является обратной к прямой задаче — поиску IP-адреса по доменному имени. Как было рассмотрено в материале «Адресная запись «Address»…» прямая задача решается в DNS при помощи записей типа A (Address). Обратная же задача решается при помощи записей-указателей типа PTR (Pointer), которые совместно с записями SOA и NS составляют описание так называемой «обратной» зоны.

На самом деле в DNS решение задачи поиска доменного имени по IP-адресу несколько необычно. Казалось бы, что для решения этой задачи можно использовать описание «прямой» зоны. В ней ведь вся информация есть!

На самом деле решать «обратную» задачу по «прямой» зоне неудобно. Поиск сведется к полному перебору всех зон, т.к. удобного аппарата рефералов (отсылок по NS записям) для IP-адресов в прямых зонах нет.

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

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

Вот здесь и возникает довольно логичное и простое решение, которое позволяет использовать стандартный механизм поиска доменного имени для решения «обратной» задачи, — специальный домен, структура которого совпадает со структурой IP-адресов. Называется этот домен IN-ADDR.ARPA.

Сначала немного истории. В то время когда затевалась система доменных имен (примерно 1983 год — год выхода RFC 882 и 883) под Internet подразумевалась сеть ARPA, а кроме нее еще обсуждалась возможность построения единого адресного пространства с CSNET. По этой причине кроме класса записей описания ресурсов IN — INTERNET (в то время ARPA) был еще класс описания ресурсов CS — CSNET (Computer Science Network).

В рамках этой концепции в сети ARPA вводился домен для адресов интернет (IN-ADDR — Internet ADDRess). При этом отдельно оговаривалось, что для других сетей алгоритм поиска доменного имени по IP-адресу может отличаться от того, который предложен для адресного пространства сети ARPA.

При этом доменные адреса в ARPA оканчивались словом «ARPA», вот пример из RFC 883:

.. 9999999 IN NS B.ISI.ARPA
9999999 CS NS UDEL.CSNET
B.ISI.ARPA 9999999 IN A 10.3.0.52
UDEL.CSNET 9999999 CS A 302-555-0000

В нем мы видим, что у записей класса IN доменное имя оканчивается на ARPA, а у всех записей класса CS — на CSNET. Таким образом домен IN-ADDR был доменном верхнего уровня в рамках Internet (ARPA) в то время.

Сейчас уже нет ни CSNET, ни более поздних CH (CHAOS) и HS(Hesiod), которые можно найти в спецификации RFC 1035. Была реорганизована и исчезла ARPA. Но задуманный для адресного пространства ARPA домен IN-ADDR.ARPA остался.

На самом деле, в апреле 2000 года между DARPA (бывшей ARPA) и ICAAN было заключено соглашение о том, что домен верхнего уровня (TLD) ARPA будет использоваться для целей поддержки инфраструктуры Интернет.

Кроме того, само слово «ARPA» следует расшифровывать как «Address and Routing Parameter Area Domain (ARPA)», и не следует его ассоциировать с сетью ARPANET.

Основное назначение домена ARPA — обеспечивать отображение численных величин, определяемых протоколами межсетевого обмена, в пространство имен.

Делегирование поддоменов в домене ARPA возложено на IAB (Internet Architecture Board). В настоящее время в ARPA выделено три поддомена:

• in-addr.arpa для отображения IP-адресов IPv4 в пространство доменных имен;
• ip6.arpa для отображения IP-адресов IPv6 в пространство доменных имен;
• е164.arpa для отображения телефонных номеров формата Е.164.

Сама зона ARPA поддерживается корневыми серверами и серверами TLD зон, хотя в соответствии с рекомендациями RFC 2870 для ARPA желательно выделение отдельных серверов.

Имена в домене IN-ADDR.ARPA образуют иерархию цифр, которые соответствуют IP-адресам. Правда, записываются эти имена в обратном порядке относительно написания IP-адреса.

Например, машина vega-gw.vega.ru, которая имеет адрес 194.226.43.1 должна быть описана в домене in-addr.arpa как 1.43.226.194.in-addr.arpa, т.е. адрес записывается в обратном порядке.

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

Рис.1. Пример структуры части домена in-addr.arpa

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

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

Однако на самом деле сама идея инверсной записи IP-адреса опирается на принципы построения этого адреса. Понятно, что первая группа цифр, ближайших к корню IN-ADDR.ARPA, задает номер сети, а остальные номер хоста. Принимая во внимание тот факт, что первоначально при создании доменной адресации в ARPA речь шла о сетях класса A (первый байт-октет определяет номер сети), то первая цифра в доменном имени в зоне IN-ADDR.ARPA — это номер сети, а все последующие — это номер хоста:

Пример определяет первый хост в 10-ой сети.

Поиск этого адреса занял бы поиск сервера, ответственного за 10.IN-ADDR.ARPA, а тот бы ответил именем соответствующим адресу хоста.

В настоящее время, когда адреса раздаются, главным образом, из сетей класса C, и сама классификация сетей подменена спецификацией CIDR, цепочка обращений к серверам доменных имен значительно длиннее, но тем не менее, работает она также исправно, как и вся система DNS.

Теперь, прежде чем обсуждать проблемы поиска доменных имен в IN-ADDR.ARPA, необходимо вернуться к формату описания зон этого домена, которые принято называть «обратными».

Обратная зона состоит, главным образом из записей типа «Pointer» или PTR-записей. Формат записи имеет следующий вид:

[name][ttl] IN PTR [host]

Поле имя задает номер. Это, как уже обсуждалось, не реальный IP-адрес машины, а имя в специальном домене in-addr.arpa или в одной из его зон.Приведем пример PTR записи:

$ORIGIN 43.226.194.in-addr.arpa.
1 IN PTR vega-gw.vega.ru.

По всей видимости провайдер выделили организации сетку класса С 194.226.43.0 (В нотации CIDR 194.226.43.0/24). При этом организации было также делегировано право ведения «обратной» зоны 43.226.194.in-addr.arpa. Вот в этой зоне администратор зоны и начал описывать «обратные» соответствия.

Следует признать, что соответствие обратных зон сетям — это общая практика описания «обратных» зон. Здесь точно также надо делегировать зоны из «обратного» домена. А делается это, как правило, на основе разбиения сети на подсети или сети.

В качестве примера для нашей учебной зоны в файле named.boot (BIND 4 или named.conf для BIND 8 — 9) определена «обратная» зона 43.226.194.in-addr.arpa. Ее описание будет выглядеть примерно так:

$TTL 3600
@ IN SOA vega-gw.vega.ru hostmaster.vega.ru (
101 ; serial number
86400 ; refresh within a day
3600 ; retry every hour
3888000 ; expire after 45 days
3600 ) ; negative caching
IN NS vega-gw.vega.ru.
IN NS ns.relarn.ru.
;
1 IN PTR vega-gw.vega.ru.
4 IN PTR dos1.vega.ru.
5 IN PTR dos2.vega.ru
2 IN PTR zone1-gw.zone1.vega.ru.
3 IN PTR zone2-gw.zone2.vega.ru.

Из этого примера видно, что для обратной зоны указаны те же записи описания зоны, что и для «прямой». Кроме того, обратную зону вовсе не обязательно разбивать в соответствии с разделением прямой зоны на другие зоны. Речь в данном случае идет о зонах zone1 и zone2. С точки зрения домена in-addr.apra все машины принадлежат одной зоне — 43.226.194.in-addr.arpa.

Другое дело машина с IP-адресом 127.0.0.1 (localhost). С точки зрения домена in-addr.arpa она принадлежит другой ветке иерархии, отличной от той, которой принадлежат все остальные хосты. Поэтому для домена 127.in-addr.arpa на любой машине есть отдельный файл обратной зоны, хотя localhost, которому соответствует этот IP-адрес, обычно описывается в прямой зоне домена вместе с другими хостами. Вот пример описания этой зоны:

; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10
; 15:31:40 peter Exp $
;
; This file is automatically edited by the `make-localhost’ script in
; the /etc/namedb directory.
;
$TTL 3600
@ IN SOA generate.polyn.kiae.su. root.generate.polyn.kiae.su. (
00000001 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS generate.polyn.kiae.su.
1 IN PTR localhost.polyn.kiae.su.
>

Как следует из комментария этого файла для его генерации можно использовать специальный sh-скрипт make-localhost, который входит в комплект поставки BIND. Он берет в качестве основы файл прототипа PROTO.localhost.rev подставляет в него имя хоста и имя домена.

Любопытно, что вместо пользователя hostmaster, что рекомендовано в RFC2142, в данном случае указывается пользователь root. Оно и понятно. Пользователя hostmaster может и не быть, ведь не все читают все подряд RFC, а пользователь root есть обязательно. Тем более, что это скорее всего и есть администратор локального сервера доменных имен.

Следует при этом помнить, что в файле конфигурации named.conf должен быть блок, который указывает на эту «обратную» зону:

zone «0.0.127.IN-ADDR.ARPA» type master;
file «localhost.rev»;
>;

На самом деле мы опустили один интересный вопрос, а как прямой IP-адрес формата IPv4 преобразуется в доменное имя, которое имеет инверсную запись цифр.

Эти функции возложены на resolver. Resolver преобразует 32-битовый адрес в текстовую строку, размещая октеты в обратном порядке, разделяя их символами «.». К полученному имени resolver через разделитель «.» добавляет суфикс «in-addr.arpa». После этого формирует PTR запрос к системе доменных имен.

Вопросы делегирования зон в IN-ADDR.ARPA не столь просты, как может показаться на первый взгляд. Эта проблема тесно связана с получением пулов IP-адресов. Кроме получения адреса, нужно еще получить право на ведение обратного домена, соответствующего вашему адресному пулу.

На самом деле, никто кроме владельца адресного пула не знает, как распределено адресное пространство. Отдать кому-то ведение «обратной» зоны — это значит, во-первых, не обеспечить оперативность управления этой зоной, если только нет средств удаленного управления, как, например, в nic.ru, а, во-вторых, такая услуга стоит денег. По этим причинам обратную зону лучше вести самим.

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

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

Прежде всего, следует знать, что первоначально все адреса, которые мы используем в RuNet, получают RIPE Network Coordination Centre (RIPE — это Reseaux IP Europeens), который является одним из трех региональных интернет регистраторов поддерживающих глобальную инфраструктуру Интернет.

Из предыдущего абзаца важно только то, что все блоки адресов в нотации CIDR xxxx.xxxx.xxxx.xxxx/16 и xxxx.xxxx.xxxx.xxxx/24 выдаются этой организацией локальным интернет регистраторам (Local Internet Registres — LIR). А вот уж они и распределяют эти адреса между своими клиентами.

В обычной классификации сетей Интернет это означает, что RIPE NCC отвечает за делегирование в зоне IN-ADDR.ARPA не только сетей класса B, но и сетей класса C. Сети класса B сейчас почти не выдают, поэтому смело можно остановиться на сетях класса C.

Если Вы не являетесь LIR, а Вам выделена сетка класса C, то направить заявку на делегирование обратной зоны в RIPE NCC Вы напрямую все равно не сможете. Сделать это сможет только провайдер, имеющий статус LIR, который, собственно, эту сетку в RIPE NCC получил. Следовательно, нужно связываться с ним и выяснять все вопросы делегирования обратной зоны. Если Вам выделен пул адресов из сетки класса B, то все вопросы по делегированию обратной зоны нужно также направлять своему провайдеру, т.к. именно ему делегировано право управления обратной зоны этой сети.

Если Вы сами имеете статус LIR, то лучше всего не читать это краткое описание, а обратиться к первоисточникам (http://www.ripe.net/ripencc/mem-services/rigistration/reverse/howtoreverse.html или http://www.ripe.net/.c/ripencc/mem-services/training/material/c.refbooknew.pdf.txt)J.

Тем не менее следует знать, что для делегирования зоны необходимо три вещи:

1. получить адресный блок;
2. обеспечить поддержку зоны /16 или /24 в соответствии с требованиями RIPE NCC;
3. направить заявку в RIPE NCC на делегирование домена.

Адресный блок получают в соответствии с документом RIPE «IPv4 Address Allocation and Assignment Policies in the RIPE NCC Service Region».

Требования по поддержке зоны заключаются в том, что параметры записи SOA зоны должны соответствовать RFC 1912. при этом серийный номер зоны следует записывать в виде YYYYMMDDnn.

Для зон /24 LIR должен организовать два сервера (один у себя, а другой желательно у другого провайдера, во всяком случае, должно быть обеспечено независимое подключение). Для зон /16 должно быть обеспечено 3 сервера, причем один из них дожен быть сервер RIPE NCC ns.ripe.net. Он должен выполнять функцию slave (secondary) для зоны.

Заявка на делегирование зоны, которая посылается в RIPE NCC роботу регистрации на адрес auto-inaddr@ripe.net, должна выглядеть примерно так:

domain: 65.35.80.in-addr.arpa
descr: Reverse delegation for Bluelight 2nd /24
admin-c: JJ231-RIPE
tech-c: JAJA1-RIPE
zone-c: WF2121-RIPE
nserver: ns.bluelight.nl
nserver: ns2.bluelight.nl
mnt-by: BLUELIGHT-MNT
changed: jan@bluelight.nl 19991110
source: RIPE

О назначении полей и правилах их заполнения лучше всего справиться у вашего LIR, либо в nic.ru, либо в RIPE.

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

Отдельно обратим внимание на то, что для каждой «обратной» зоны, которая соответствует сети класса C (адреса в CIDR xxxx.xxxx.xxxx/24) нужно свое собственное описание зоны. Нельзя в один файл мешать несколько зон данного типа. Мешать их может только в файле, описывающем родительскую зону типа xxxx.xxxx/16, например, в зоне 206.144.in-addr.arpa могут быть записи типа PTR для зон 160.206.144.in-addr.arpa и 192.206.144.in-addr.arpa, и то, только при условии, что данные зоны не делегированы на другой сервер.

Действительно, NS запись для делегирования будет находиться в том же файле описания зоны, что записи типа PTR. BIND отловит эту коллизию и проигнорирует соответствующие PTR записи.

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

Но на самом деле для небольших компаний гораздо более серьезной проблемой становится делегирование обратных зон для пулов адресов, меньших, чем сеть класса С. Рассмотрим эту проблему более подробно. Все примеры будем брать из RFC 2317, т.к. именно оно рекомендовано RIPE NCC для решения нашей проблемы. Именно этот способ поддерживается в самом RIPE NCC.

Сначала о существе проблемы. Провайдер «нашинковал» в сети класса С (пул адресов в нотации CIDR /24) на несколько частей. Таким образом границы пулов адресов не приходятся на границы октетов.

Пусть мы имеем дело с сетью 192.0.2.0/24. Провайдер разделил адресное пространство следующим образом:

192.0.0/25 — организация А
192.0.128/26 — организация Б
192.0.192/26 — организация С

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

$ORIGIN 2.0.192.in-addr.arpa.
;
1 PTR host1.a.ru.
2 PTR host2.a.ru.
3 PTR host3.a.ru.
;
129 PTR host1.b.ru.
130 PTR host2.b.ru.
131 PTR host3.b.ru.
;
193 PTR host1.c.ru.
194 PTR host2.c.ru.
195 PTR host3.c.ru.

Делегировать поддержку такой зоны можно только кому-то одному. Все остальные будут зависимы от владельца зоны и все изменения должны будут вносить через него.

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

$ORIGIN 2.0.192.in-addr.arpa.
@ IN SOA ns.provider.ru. hostmaster.provider.ru. (…)
;
; 0-127 /25
;
0/25 IN NS ns.a.ru.
0/25 IN NS ns.slave.ru.
;
1 IN CNAME 1.0/25.2.0.192.in-addr.arpa.
2 IN CNAME 2.0/25.2.0.192.in-addr.arpa.
3 IN CNAME 3.0/25.2.0.192.in-addr.arpa.
;
; 129-191 /26
;
128/26 IN NS ns.b.ru.
128/26 IN NS ns.slave.ru.
;
129 IN CNAME 129.128/26.2.0.192.in-addr.arpa.
130 IN CNAME 130.128/26.2.0.192.in-addr.arpa.
131 IN CNAME 131.128/26.2.0.192.in-addr.arpa.
;
; 193-255 /26
;
192/26 IN NS ns.c.ru.
192/26 IN NS ns.slave.ru.
;
193 IN CNAME 193.192/26.2.0.192.in-addr.arpa.
194 IN CNAME 194.192/26.2.0.192.in-addr.arpa.
195 IN CNAME 195.192/26.2.0.192.in-addr.arpa.

Сами организации при это обязаны зависти зоны следующего содержания:

$ORIGIN 0/25.2.0.192.in-addr.arpa.
@ IN SOA ns.a.ru hostmaster.a.ru (…)
IN NS ns.a.ru.
IN NS ns.slave.ru.
;
1 IN PTR host1.a.ru.
2 IN PTR host2.a.ru.
3 IN PTR host3.a.ru.

Для блока 128/26 соответственно последовательность «0/25» следует заменить на «128/26», а сервер ns.a.ru на сервер ns.b.ru. Для блока 192/26 нужно также будет выполнить соответствующие замены.

Идея данного метода заключается в том, что, попадая в зону 2.0.192.in-addr.arpa, локальный сервер доменных имен или resolver на свой запрос доменного имени получают CNAME, т.е. сервер зоны говорит, что имя, которое ему было сообщено не является каноническим именем хоста, указанным в адресной записи. Это лишь синонимом канонического имени. При этом каноническое имя сообщается в качестве ответа на запрос. Обращаясь по каноническому имени, локальный сервер доменных имен или resolver получают в ответ ссылку на другой сервер, т.к. в нашей зоне указан NS для поддержки зон с каноническими именами. Переходя на новый сервер, локальный сервер доменных имен или resolver получают уже обычную PTR запись ресурсов и могут сообщить доменное имя приложению, которое инициировало запрос к обратной зоне.

Может показаться накладным набивать большое количество CNAME в зонах типа 2.0.192.in-addr.arpa. Но здесь можно воспользоваться директивой управления $GENERATE, которая существенно сократит число набираемых вручную записей описания ресурсов.

Следует также обратить внимание на то, что имена зон в 2.0.192.in-addr.arpa могут быть любыми допустимыми именами, а не только «0/25» или «192/26», как это указано в примере. Более того, имена могут указывать на зоны из совершенно других доменов, не входящих в in-addr.arpa. Правда, зоны должны содержать соответствующие PTR записи описания ресурсов.

Мы в самом начале этого материала упоминали об инверсных запросах, которые не следует путать со стандартными запросами к серверам домена IN-ADDR.ARPA. Какова их судьба?

В принципе, поддержка инверсных запросов в серверах доменных имен возможна. Во всяком случае, они обязаны такие запросы распознавать и отвечать на них, либо списками доменных имен, либо 0, либо сообщением, о том, что данную опцию сервер не поддерживает.

При этом реальная область применения такого сорта запросов ограничивается рамками одного сервера.

И в заключении о том, зачем вообще нужно искать доменные имена по IP_адресам. Этому есть несколько причин.

Во-первых, многие сетевые сервисы блокируют доступ, если не могут отобразить IP-адрес хоста, с которого к ним обращаются, в доменное имя. Так поступают, например, ftp-серверы и серверы электронной почты.

Во-вторых, большое число запросов к «обратным» зонам возникает при работе систем электронной почты и веб-серверов. В электронной почте рассылка почты почтовыми транспортными агентами (ПТА) основана на процедуре канонизации адресов отправителя и получателя. А эта процедура подразумевает обращение к обратной зоне. Кроме того, ПТА блокируют пересылку почты, основываясь, в том числе, и на информации из «обратных» зон. При работе веб-серверов обращение к «обратной» зоне используется для сбора статистики.

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

Любопытно, что на 1999 год по данным RIPE NCC из 163124 зон, которые могли бы быть делегированы (зарегистрированые IP-адреса), реально было делегировано только 85352 или примерно 52%.

И еще одно замечание. Мы здесь вообще не рассматривали «обратное» отображение в рамках такой «экзотики», как адресное пространство IPv6. На самом деле современные версии BIND прекрасно справляются с этой задачей, но об этом как-нибудь в другой раз.

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

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. H.Eidnes, G. de Groot, P. Vixie. RFC-2317. Classless IN-ADDR.ARPA delegation. 1998. (http://www.ietf.org/rfc/rfc2317.txt?number=2317)
4. Альбитц П., Ли К.. DNS и BIND. — Пер. с англ. — СПб: Символ-Плюс, 2002. — 696 с.
5. Документация по BIND 9. Справочное руководство системного администратора. (http://www.nominum.com/resources/documentation/Bv9ARM.pdf)

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

1. P. Mockapetris. RFC-883. DOMAIN NAMES — IMPLEMENTATION AND SPECIFICATION. ISI, 1987. (http://www.ietf.org/rfc/rfc883.txt?number=883) — документ интересен с точки зрения исторического развития домена IN-ADDR.ARPA как домена «обратного» соответствия.
2. R. Bush, D. Karrenberg, M. Kosters, R. Plzak. RFC 2870. Root Name Server Operational Requirements. 2000. (http://www.ietf.org/rfc/rfc2870.txt?number=2870)
3. D. Crocker. RFC 2142. MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS. 1997. (http://www.ietf.org/rfc/rfc2142.txt?number=2142)
4. D. Barr. RFC 1912. Common DNS Operational and Configuration Errors. 1996. (http://www.ietf.org/rfc/rfc1912.txt?number=1912)
5. Policy for Reverse Address Delegation under in-addr.arpa in the RIPE NCC Service Region (http://www.ripe.net/ripe/docs/ripe-224.html) — очень коротенькое описание политики делегирования обратных зон в зоне ответственности RIPE NCC.
6. Reverse Delegation. IPv4 Request Procedure (reverse /24, /16) (http://www.ripe.net/ripencc/mem-services/registration/reverse/howtoreverse.html) — документ в стиле «делай раз, делай два, …». Все просто и доступно, но нужно иметь некоторое представление об устройстве сервисов RIPE NCC.
7. http://www.ripe.net/.c/ripencc/mem-services/training/material/c.refbooknew.pdf.txt — материалы учебного курса для LIR, которые зарегистрированы в RIPE. Интересен раздел 9 — «Reverse Delegation». Достаточно сжато и подробно описывается процедура делегирования «обратных» зон из зоны ответственности RIPE NCC.
8. G.Huston. RFC-3172. Management Guidelines & Operational Requirements for the Address and Routing Parameter Area Domain («arpa»). 2001. (http://www.ietf.org/rfc/rfc3172.txt?number=3172) — статус домена ARPA, начиная с конца апреля 2000 года. Документ фиксирует состояние домена ARPA, ответственность ICAAN и IAB за управление этим доменом, его статус, а также правила делегирования поддоменов.
9. http://www.ripe.net/ripencc/pub-services/stats/revdns/assign/19990426.html — статистика соответствия регистрации пулов адресов и «обратных» зон на 1999 год в RIPE NCC.

• Книга П.Б. Храмцова о системе DNS
• Система DNS

Addr что это

Команда ip address применяется для назначения адресов и маски данному интерфейсу.

ip address ip-address mask [secondary]

no ip address ip-address mask [secondary]

локальный IP -адрес.

показывается для второго и последующих адресов.

• Команда ip address выполняется немедленно после ввода, изменения IP -адреса интерфейса и маски сохраняются в загрузочных скриптах ОС.

• Команда ip address будет выполняться даже в том случае, если данный адрес уже присутствует на интерфейсе. Это сделано для того, чтобы избежать ситуации, когда текущий адрес на интерфейсе не совпадает с адресом, прописанным в загрузочных скриптах. В этом случае введенная команда принудительно запишет указанный адрес в загрузочные скрипты.

• При выполнении команды ip address автоматически выставляется broadcast address в значение ip -address | ~mask .
Например, по команде ip address 192.168.10.10 255.255.255.0 автоматически выставляется broadcast address 192.168.10.255 .

• Различаются primary и secondary IP -адреса. В качестве primary адреса выбирается первый по списку адрес, остальные – в качестве secondary . Primary адрес может быть только один и задается командой:

ip address primary-ip primary-mask

• Повторное задание IP -адреса замещает предыдущее значение:

• если смена primary адреса не удалась, то выдается сообщение:

Cannot set the primary address (Reason: )

• если адрес был изменен, но состояние интерфейса не удалось сохранить, то выдается сообщение:

The primary address was set, but the state of the interface was not saved. The changes will be lost after reboot

• если в качестве нового primary адреса задать существующий secondary адрес, то сначала будет удален существующий secondary адрес, а затем будет изменен primary адрес. При этой двойной операции возможны следуюшие ошибки:

— если не удалось удалить существующий secondary адрес, то выдается сообщение:

Cannot remove the address (Reason: )

— если не удалось изменить primary адрес, то выдается сообщение:

Cannot set the primary address (Reason: )

— если не удалось сохранить состояние интерфейса, то выдается сообщение:

The primary address was set, but the state of the interface was not saved. The changes will be lost after reboot

• Если до ввода primary адреса на интерфейсе отсутствовали IP -адреса и была введена команда “ no shutdown ”, то после выставления IP -адреса на интерфейсе выполняется отложенное включение интерфейса (подробнее см. команду shutdown ).

• Адресов secondary может быть несколько. Secondary адрес задается командой:

ip address ip-address mask secondary

• Адрес secondary можно задать, если задан primary адрес. В противном случае, выдается сообщение об ошибке:

Cannot add secondary without primary (Reason: )

• Нельзя задавать в качестве secondary тот же адрес, что и primary . Иначе выдается сообщение об ошибке:

Secondary can’t be same as primary

• Нельзя задать IP -адрес 0.0.0.0 . В этом случае выдается сообщение:

Not a valid host address — 0.0.0.0

Это ограничение приводит к тому, что если задать IP-адрес 0.0.0.0 (с ненулевой маской) с помощью других средств (не в консоли), то он будет показан по команде show running -config , но удалить этот адрес в консоли невозможно, он будет отвергаться. В такой ситуации удалить все адреса на интерфейсе (включая и 0.0.0.0) можно с помощью команды no ip address .

• Нельзя задать IP -адрес 255.255.255.255. В этом случае выдается сообщение:

Not a valid host address — 255.255.255.255 .

• Нельзя задать маску 0.0.0.0. В этом случае выдается сообщение об ошибке: Bad mask /0 for address . Нельзя задавать маску 255.255.255.255. В этом случае выдается сообщение:

Bad mask /32 for address

• Если попытаться задать некорректную маску (например, 255.0.255.0), то выдается сообщение вида:

Bad mask 0xFF00FF00 for address

• Если попытаться задать некорректное сочетание IP-адреса и маски (все биты адреса, не попадающие на маску, выставлены в 0 или в 1), выдается сообщение:

Bad mask / for address

Bad mask /24 for address 192.168.10.0

Bad mask /24 for address 192.168.10.255

• Если не удалось добавить на интерфейс новый адрес, то выдается сообщение:

Cannot add the address (Reason: )

• Если новый адрес был добавлен, но состояние интерфейса не удалось сохранить, то выдается сообщение:

The address was added, but the state of the interface was not saved. The changes will be lost after reboot .

• Допускается задавать полную копию существующего адреса, чтобы предотвратить ситуацию несовпадения текущего адреса и адреса в загрузочных скриптах ОС. Также можно для существующего адреса изменить маску:

• в случае ошибки выдается сообщение:

Cannot change the address (Reason: )

• если параметры интерфейса удалось изменить, но состояние интерфейса не удалось сохранить, то выдается сообщение:

The address was changed, but the state of the interface was not saved. The changes will be lost after reboot.

Удаление всех адресов с интерфейса осуществляется командой: no ip address .

После этой команды интерфейс будет выключен. Команда показывается по show running -config .

• Если не удалось удалить все адреса с интерфейса, то выдается сообщение:

Cannot remove all addresses (Reason: )

• Если не удалось сохранить состояние интерфейса после удаления всех адресов, то выдается сообщение:

All addresses were removed, but the state of the interface was not saved. The changes will be lost after reboot .

Удаление конкретного адреса с интерфейса осуществляется командой:

no ip address ip-address mask

no ip address ip-address mask secondary

Удаление primary адреса по последствиям аналогично команде:

При удалении secondary адреса, в команде слово secondary можно и не писать.

• При попытке удалить несуществующий адрес выдается сообщение об ошибке:

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

Invalid address mask

• Не допускается удалять primary адрес, если присутствует хотя бы один secondary . Выдается сообщение об ошибке:

Must delete secondary before deleting primary

• В команде удаления primary адреса не допускается писать слово secondary , в противном случае, выдается сообщение об ошибке:

Secondary can’t be same as primary. Invalid address .

• Если по каким-то причинам не удалось удалить адрес, выдается сообщение:

Cannot remove the address (Reason: )

• Если удаление выполнилось, но состояние интерфейса не удалось сохранить, выдается сообщение:

The address was removed, but the state of the interface was not saved. The changes will be lost after reboot .

Команда show running -config всегда показывает текущее системное состояние интерфейса.

• Если адрес на интерфейсе изменен каким-либо образом помимо консоли, то по команде show running -config это изменение будет показано. Отсюда возможна ситуация, когда текущий адрес интерфейса отличается от адреса, прописанного в загрузочных скриптах ОС, и это отличие никак не проявляется в cisco-like конфигурации:

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

• Для предотвращения такой ситуации рекомендуется не смешивать выставление адресов на сетевых интерфейсах с помощью консоли с другими средствами (например, командой ifconfig ).

• Если на интерфейсе присутствует адрес 0.0.0.0/0 (нулевой адрес с нулевой маской) наряду с другими, то по команде show running -config он не показывается.

• Если на интерфейсе отсутствуют адреса или присутствует только адрес 0.0.0.0/0 , то по команде show running -config для данного интерфейса показывается команда no ip address .

• После команды no ip address данный интерфейс выключается.

• Нельзя задать secondary адрес, не задав перед этим primary адрес.