от сервис-менеджера к директору домена / Хабр

Привет, Хабр! Меня зовут Андрей Китов, я технический директор одного из доменов X5. Уже пару лет мы работаем с технологиями для бизнеса в рамках доменной структуры. Это необычный подход, как и мой опыт смены профессии внутри одной компании. Об этом я и решил рассказать. Статья, надеюсь, будет интересна тим-лидам, инженерам, менеджерам по сервисам и тем, кто хочет пойти в управление проектами. 

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

Андрей Китов

Технический директор домена «Операции и эксплуатация «Пятёрочки»»

В Х5 всё начинается с «Пятёрочки». Вот и я пришел в торговую сеть в 2015 году на должность менеджера по сервисам. Тогда подразделение сервис-менеджеров только начинало формироваться в X5 под потребности «Пятёрочки», я стал пятым человеком в команде. Мне досталась работа с сервисами «Ведение мастер-данных о товарах», «Управление розничными ценами», «Управление ПРОМО» и другие. 

Основная задача, которая перед нами тогда стояла – внедрить сервисный подход в компании. На тот момент в X5 уже был свой ИТ: поддержка, инфраструктура, разработка, проектный офис, даже были карточки сервисов и как-то считался SLA.  Но каждое подразделение существовало в своих процессах, не поддерживая связь между собой, а заявки «футболились» между направлениями поддержки. Одним словом, не было чётких правил игры. Процесс передачи проектов в поддержку всегда превращался в «танцы с бубном» и напоминал «тушение пожара», потому что функционал разработан и внедрён, а вот процессы для решения инцидентов по нему не отлажены. Получалось, что в случае аварии привлекаются разработчики проекта, которые уже давно занимаются другими активностями.

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

Следующим шагом стал выбор методологии. Мы остановились на набирающей тогда популярность методологии ITIL (Information Technology Infrastructure Library), которая послужила базой и вектором нашего будущего развития. ITIL – это набор лучших практик, который предоставляет рекомендации по организации работы ИТ. Если вы с ней ещё не знакомы, очень рекомендую к изучению всем, кто связан с поддержкой или сервисами. Она помогает структурировать разрозненную информацию в голове. Плюсы ITIL, которые мы тогда для себя выделили – это лёгкость адаптации методологии под нас, понятный и общепринятый глоссарий, доступность обучения и простота внедрения. Так как какие-то процессы уже работали, нам надо было их просто слегка подтянуть.

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

Самым сложным было принять, что теперь у нас всё красное. SLA упал до 30% по некоторым сервисам, при том что работа поддержки не менялась – мы просто изменили методику расчёта. Из-за этого мы сталкивались с непониманием со стороны бизнеса. К счастью, нам удалось объяснить необходимость изменений и значимость прозрачного расчёта SLA. Сейчас у нас SLA примерно 98%, а показатель доступности не опускается ниже 99,8%.

На «наведение порядка» у нас ушло два года. Примерно в это же время я стал старшим сервис-менеджером, а затем менеджером направления. В моём подчинении было несколько сервис-менеджеров, у каждого из которых был свой пул сервисов. Я же выполнял роль старшего наставника и при этом отвечал за более критичные сервисы. 

Что такое сервисы в «Пятёрочке»

Начну с очевидного: ИТ-сервис это набор инструментов и технологий, обеспечивающих работу бизнес-процессов. Если описывать, какие процессы предшествуют тому, чтобы вы могли купить свежие и вкусные помидоры в ближайшей к вашему дому «Пятёрочке», то можно выделить такие этапы:

  1. Закупки

  2. Управление магазинами (более чем 19 000 «Пятёрочек» в стране) 

  3. Маркетинг и реклама

  4. Управление персоналом (более 300 000 сотрудников по всей России) 

  5. Финансовое управление

  6. Логистика и доставка

Впечатляет, правда?

Если коротко, то сервисы можно сравнить со слоёным пирогом: первый уровень – бизнес-процессы и бизнес-операции, второй уровень – это программное обеспечение, в котором эти процессы и операции происходят, третий – платформы, и под этим всем идёт инфраструктура. Каждому уровню присваиваются индивидуальные SLA: за какое время, по каким маршрутам, что и как мы должны чинить. Сервис-менеджер отвечает за то, чтобы это всё работало, как часы, и чтобы все сроки соблюдались. Он также проектирует эти сервисы, модернизирует и отвечает за их вывод из эксплуатации.

Если изобразить схематично, то выглядит это так:

Помимо этого, каждому из сервисов и уровней должен быть присвоен свой уровень качества и это должно между собой биться. Нельзя выстроить сервис таким образом, чтобы инцидент по системе решался за два часа, а инцидент по инфраструктуре в рамках того же сервиса – за четыре. Это приведёт к тому, что SLA будет постоянно в просадке.

Как пример:

Мой рост внутри сервис-менеджмента

Через три года работы мой начальник получил повышение внутри компании и рекомендовал меня на должность начальника отдела сервисов в «Пятёрочке». С этого момента я стал руководить подразделением. Не скажу, что мой уровень экспертизы был выше, чем у ребят, работающих со мной. Но я точно знал, как реализовать разработанную ранее стратегию. Команда меня поддерживала, и это придавало уверенности. Наше подразделение на тот момент состояло из 12 менеджеров по сервисам, но уже через два года мы выросли в управление, состоящие из менеджеров по сервисам, методологов, инженеров поддержки проектов и аналитиков данных. 

В это время в компании был запущен проект по замене ITSM системы в рамках миграции на новую ИС. Наконец наступил момент, когда мы могли реализовать все наши наработки на новой системе. Мы обновили все справочники и сразу внедрили правильные процессы управления каталогом сервисов, инцидентами, конфигурациями, запросами на обслуживание, проблемами и т. д. Так, спустя 1,5 года мы перешли на новую ИС, с совершенно новыми процессами, с полностью переделанным каталогом сервисов, которыми мы пользуемся до сих пор. 

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

Ещё одна проблема, которую надо было решить – это поддержка продуктов и проектов на стадии разработки. У нас был выстроен процесс передачи проектов на поддержку, но с продуктами мы столкнулись впервые. Магазины писали о своих проблемах, команды бросали всё и начинали выявлять причины, искать баги. Количество обращений только увеличивалось и это приводило к неприятным последствиям. Мы поняли, что таким командам при выходе на определённые объёмы пользователей, нужна постоянная поддержка. Но так как функционал постоянно развивается, простая схема поддержки (1, 2, 3 линии поддержки) нам не подходила. Нам нужны были инженеры уровня 2, 3 линии поддержки, которых мы сможем оперативно подключать в команды. Ребята должны были сами общаться с разработчиками, готовить инструкции для себя и для будущей передачи в поддержку, решать обращения от пользователей и давать обратную связь команде. Мы искали заряженных бойцов, которым было бы интересно ковыряться в новом и которые не были бы связаны жёсткими рамками. Так у нас появилась служба поддержки проектов/продуктов.

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

В целом, опыт работы в сервисах дал мне чёткое представление о том, как работает ИТ, как все процессы связаны между собой и как этим можно управлять. Конечно, пробелы в навыках и знаниях были. Я закрывал их не только в процессе работы. Изучая ITIL, я прошёл все курсы по третьей версии, учил проектную и продуктовую методологию и никогда не стеснялся спрашивать, если что-то не понимал. Иногда даже у своей команды. У многих экспертиза была выше, и я не видел в этом ничего зазорного для руководителя. 

На самом деле, я считаю, что команда – это главный рычаг. Если доверие на высоком уровне, открытость – это норма, а люди не боятся предлагать идеи, то вместе вы точно сможете свернуть горы.

Переход в домены и что это такое 

В 2020 году Х5 Group решила сосредоточить экспертизу по цифровому развитию в отдельной бизнес-единице – Х5 Tech, и ДИТы торговых сетей перешли туда. Многие ребята из сервисов «Пятёрочки» стали начальниками управлений и отделов внутри компании. 

В рамках этой трансформации моё подразделение сервисов ушло в другое направление – в функцию поддержки. А я выбрал другой вектор развития и пошёл в новую для компании структуру – домены, руководителем направления «Технологии продаж в домене «Операции и эксплуатация торговой сети «Пятёрочка». 

Домен – это единая точка взаимодействия бизнеса и IT. Главная задача доменов – это максимально реализовать технологический потенциал в бизнес-подразделении.  

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

Домены тогда были новой функцией, и они только формировалась в компании. Мне досталось интересное направление в рамках операционной деятельности бизнеса. В него входило всё, что связано с технологиями в магазинах: кассы, торговое оборудование, программное обеспечение, то, что имеет отношение к росту производительности магазина.

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

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

Позже я стал техническим директором домена «Операции и эксплуатация «Пятёрочки»». И тут мой мир изменился. Уровень ответственности был повышен многократно, мне досталось одно из самых больших направлений бизнеса. Сейчас объём портфеля ИТ-инициатив составляет порядка 15 запущенных проектов и продуктов и ещё 40 находятся в проработке.

Что для меня было самым сложным в смене профессии

Домены для меня были новым направлением – в этом и заключалась главная сложность. Несмотря на то, что я занимался сервисами, очень плотно взаимодействовал с проектным офисом и хорошо разбирался во всех проектах, я не запускал их. Моя ответственность заключалась в передаче этих проектов/продуктов на поддержку.

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

Тогда я начал изучать методологии Agile, Scrum, Kanban и др. Знакомился с лучшими практиками проектного управления, Prince-2, PMBOK. Прошёл курс обучения MBA в РАНХиГС – там достаточно широкая программа, в которой есть управление организацией и проектами в том числе. Все эти курсы помогли мне структурировать знания и лучше понимать, какие методики и где стоит применять. 

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

Управление командой – что я вынес из опыта работы с людьми

Сейчас моя команда состоит из 12 человек: три руководителя направления, два менеджера развития информационных технологий, два аналитика домена и руководители проектов, которые отвечают за реализацию задач с IT-составляющей. Но это только верхушка айсберга: если посчитать, сколько ресурсов выделено под наш домен для реализации инициатив и сопровождения систем в эксплуатации, то цифра перевалит за 500 человек: это и разработчики, и аналитики, и тестировщики, архитекторы, дизайнеры, сервис-менеджеры, Devops, инженеры и многие другие. Всё это центры компетенций, которые управляют людьми административно и обеспечивают нас высококвалифицированными ресурсами.

Управление командой – это, скорее, философская тема, рассуждать на которую можно очень долго. И тут нет какого-то одного гениального совета или волшебной пилюли. Здесь самое важное, на мой взгляд, опираться на внутреннюю эмпатию и чутьё. Руководитель должен чётко понимать свои цели и задачи, а команда – куда она идёт и зачем. 

Лично я сформулировал для себя ряд принципов в работе с командой, которые доказали свою эффективность. Уверен, вы слышите о них постоянно, но они и правда работают, я убедился в этом на своём опыте. 

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

  2. Взаимопомощь. Я всегда пытаюсь донести до своих ребят мысль: если к тебе пришли с какой-то проблемой, помоги её решить. Если пришли к тебе, а не к кому-то другому, значит, в тебе увидели того человека, который может помочь. Если ты не знаешь, как решить эту проблему, найди того, кто знает, подключи его к задаче и проконтролируй до финального решения. 

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

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

    Я не прокачивал скилл делегирования специально. Просто я не боюсь брать в команду людей сильнее меня. Это моё кредо. К ним больше доверия, соответственно, им даётся и больше свободы в выборе действий. С ними я постоянно развиваюсь и как профессионал, и как руководитель. 

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

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

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

В итоге процессы начали работать. Ребята начали помогать друг другу, если кто-то был перегружен или не знал, что делать. Сейчас команда работает, как живой механизм, поэтому у нас нет потребности встречаться каждую неделю: раз в две недели теперь более чем достаточно. Я вижу, что мои люди заряжены, у них горят глаза, они понимают, что приносят пользу, уровень мотивации значительно вырос, в том числе и у меня. 

Почему не нужно бояться смены профессии

Любой рост – горизонтальный, вертикальный – это всегда хорошо. Ведь на любой должности в какой-то момент ты оказываешься в зоне комфорта. Ты становишься профессионалом своего дела, чётко знаешь все процессы, можешь ответить на любой вопрос, с которым к тебе приходят.  

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

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

Человеку, наверное, свойственно всегда искать пути дальнейшего развития. Но развиваться ты можешь только там, где чего-то не знаешь. И этого не нужно бояться. Пройдёт год, и ты снова все будешь знать, снова окажешься в зоне комфорта. Но будешь уже сильнее, профессиональнее, у тебя расширится кругозор, появится больше возможностей. 

Советы начинающим руководителям

Не претендуя на истину, вот что могу посоветовать, опираясь на свой опыт:

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

Беритесь за сложные задачи. Лично для меня, чем сложнее задача, тем интереснее. Я получаю удовольствие, когда удаётся сделать то, что изначально выглядит практически невыполнимым. Никто не осмеливается, а ты вместе со своей командой просто берёшь и делаешь… Такие победы мотивируют и приносят чувство уверенности в том, что ты можешь больше и лучше. 

Выстраивайте отношения с членами команды, как с партнёрами. Модель «руководитель – подчинённый» часто превращается в барьер. Будьте гибким, чтобы добиться комфортной и эффективной командной работы.  

Выполняйте обещания, которые вы даёте другим людям. Надо уметь договариваться, находить компромиссы и достигать стратегии win-win.

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

Правовая природа доменных имен -Статьи

Содержание:

  • Правовая природа доменных имен 
  • Юридическая помощь

Правовая природа доменных имен 

 

Доменное имя обычно рассматривается с двух точек зрения:

1. Как техническое средство с функциями адресации;

2. Как средство индивидуализации.

 

Доменное имя как техническое средство с функциями адресации

Доменное имя определяется с точки зрения первой позиции в соответствии со ст. 2 ФЗ «Об информации, информационных технологиях и о защите информации» от 27 июля 2006 г. N 149-ФЗ. Так, доменное имя – это обозначение символами, предназначенное для адресации сайтов в сети Интернет в целях обеспечения доступа к информации, размещенной в сети Интернет.

 

Некоторые ученые также придерживаются данной точки зрения. Например, по мнению Гришаева С.П. «под доменным именем понимается любое слово, зарегистрированное в качестве адреса компьютера в сети Интернет. Доменные имена заменяют цифровые адреса, которые присваиваются любому компьютеру пользователя Интернета. По существу, их можно рассматривать как адреса доступа к информации, представленной владельцем адреса». Другой специалист Андронов А.С. считает, что доменное имя «является способом коммуникационного соединения (адресации пользователя) в сети Интернет и наименованием идентифицируемого им информационного ресурса».

 

В судебной практике также встречаются решения, поддерживающие точку зрения о том, что доменное имя является техническим средством. Так, апелляционный суд в деле по домену ctroyka. ru отметил, что домен – это «набор символов, позволяющий идентифицировать и найти в сети Интернет ресурс (веб-сайт) с определенными доменными именами»[1].

 

Об определении доменного имени как технического средства изложено в одном из решений Арбитражного суда г. Москвы: «Доменное имя не является ни средством индивидуализации, ни объектом авторского права, ни вещью. Доменное имя – это «номер телефона» в сети Интернет. Таким образом, координатор не мог нарушить чьих-либо «прав на доменные имена» – то есть «прав на телефонные номера», так как в законодательстве РФ отсутствует само понятие «права на адресацию»[2]. Таким образом, суд в своем решении указал на невозможность нарушения права на доменное имя.

 

Интересным также представляется определение, которое дал Суд по интеллектуальным правам: «Доменное имя используется в сети Интернет, которая представляет собой объединение компьютеров, соединенных друг с другом посредством телефонной либо иной связи. С помощью этой сети можно передавать, получать информацию с одного компьютера на другой, обмениваясь информацией. Возможности данной сети широко используются коммерческими организациями для продвижения своих товаров на рынок для покупки и продажи товаров»[3]. В этом же деле суд указал, что основной функцией доменного имени является преобразование адресов IP, выраженных в виде цифр, в доменное имя для упрощения поиска и идентификации владельца информационного ресурса.

 

Сторонники данной позиции также указывают на то, что даже если признать, что доменное имя частично выполняет идентификационную функцию, оснований считать право на доменное имя исключительным нет. Такой вывод следует прежде всего из анализа ст. 1483 ГК РФ.

 

Доменное имя как средство индивидуализации

Существует другая позиция, которая заключается в том, что назначение домена – это не только получение доступа к информации, но и ее идентификация или индивидуализация. Так, например, А. Серго указывает на то, что доменное имя в сети Интернет выполняет ту же функцию средства индивидуализации, что и наименование, и товарный знак. Домен – это обозначение, предназначенное отличать размещенные в сети Интернет информационные массивы одних лиц от аналогичных массивов других лиц. Таким образом, доменное имя – это одно из средств индивидуализации.

 

В.О. Калятин придерживается той же точки зрения и указывает на то, что «доменные имена не только выступают как адрес компьютера в Интернете, но и являются средством индивидуализации их владельца, товаров и услуг. Доменное имя способно сообщать дополнительную информацию о своем владельце, соответствующих товарах или услугах, указывать на географическую привязку, выполнять рекламную и гарантийную функции».

 

В судебной практике также находит поддержку данная точка зрения. В 2001 году Президиум ВАС РФ пришел к выводу о том, что «доменные имена фактически трансформировались в средство, выполняющее функцию товарного знака, который дает возможность отличать соответственно товары и услуги одних юридических или физических лиц от однородных товаров и услуг других юридических или физических лиц. Кроме того, доменные имена, содержащие товарные знаки или торговые наименования, имеют коммерческую стоимость»[4].

Эта позиция находит отражение в судебных решениях нижестоящих судов. В частности, согласно мнению Федерального арбитражного суда Поволжского округа, изложенному в Постановлении от 7 июля 2011 г. N А57-10483/2010, «доменное имя используется в сети Интернет для идентификации владельца информационного ресурса и ассоциируется у потребителя с конкретным участником хозяйственного оборота или его деятельностью… Учитывая, что информационная технология имеет определенную ценность и может быть предметом сделки, доменное имя, право его администрирования следует квалифицировать как имущественное право, заключающееся в возможности лица, зарегистрировавшего доменное имя, разместить в сети Интернет информационный ресурс, доступ к которому осуществляется пользователем сети Интернет путем набора определенных символов, составляющих доменное имя. Доменное имя является средством индивидуализации, которое индивидуализирует информационный ресурс, размещенный под данным доменным именем».

 

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

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

 

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

 

В то же время суд обратил внимание на возможность доменного имени индивидуализировать не только товары и услуги, но и информационные ресурсы. В этом смысле интересен вывод суда, о том, что доменное имя compromat.ru не является только способом адресации запросов в сети Интернет, а фактически доменное имя трансформировалось в средство индивидуализации информационного ресурса Интернет-сайта, размещенного под указанным именем[7].

 

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

 

Юридическая помощь

Юридическая компания «Лекс Альянс» готова оказать юридическую помощь по любым спорным вопросам, возникающим в отношении доменных имён. Мы проанализируем Вашу ситуацию, изучим представленные Вами документы и подготовим позицию по защите Ваших интересов в досудебном и судебном порядках. Все интересующие Вас вопросы Вы можете задать нам по телефону 8(495)144-25-17, по электронной почте [email protected] или заполнив любую из форм обратной связи на сайте.

 

[1] Постановление 18 арбитражного апелляционного суда от 06.04.2011 №18АП-2336/2011 по делу № А76-9128/2010

[2] Решение АС г. Москвы от 10.06.2011 по делу № А40-136893/10 (6-1133)

[3] Постановление Суда по интеллектуальным правам от 30.10.2013 № С01-155/2013 по делу № А40-12151/2013

[4] Постановление Президиума Высшего Арбитражного Суда Российской Федерации от 16 января 2001 г.              N 1192/00 // Вестник ВАС РФ. 2001. N 5.

[5] Решение АС г. Москвы от 03.11.2011, постановление 9-го ААС от 20.02.2012 по делу № А40-73876/11-12-626

[6] Постановление Суда по интеллектуальным правам от 06. 04.2017 №С01-107/2017 по делу № А41-29186/2016

[7] Постановление ФАС МО от 26.03.2009 № КГ-А40/964-09 по делу № А40-44359/07-93-440

RFC 8375: домен специального назначения «home.arpa».

RFC 8375: домен специального назначения «home.arpa». [Домашняя страница RFC] [ТЕКСТ|PDF|HTML] [Отслеживание] [ПИС] [Ошибки] [Информационная страница]

ПРЕДЛАГАЕМЫЙ СТАНДАРТ
Имеющиеся исправления

 Инженерная рабочая группа Интернета (IETF) П. Пфистер
Запрос комментариев: 8375 Cisco Systems
Обновления: 7788 Т. Лимон
Категория: Отслеживание стандартов Nibbhaya Consulting
ISSN: 2070-1721 Май 2018 г.
                    Домен специального назначения «home.arpa».
Абстрактный
   Этот документ определяет поведение, ожидаемое от домена.
   Система имен в отношении DNS-запросов для имен, оканчивающихся на
   '.дом.арпа.' и назначает этот домен доменом специального назначения
   имя. 'дом.арпа.' предназначен для неуникального использования в жилых
   домашние сети. Протокол управления домашней сетью (HNCP)
   обновлено для использования «home.
 
 arpa». домен вместо «.home».
Статус этого меморандума
   Это документ для отслеживания стандартов Интернета.
   Этот документ является продуктом Инженерной группы Интернета.
   (IETF). Он представляет собой консенсус сообщества IETF. В нем есть
   получил общественное мнение и был одобрен для публикации
   Руководящая группа по разработке Интернет-технологий (IESG). Дополнительная информация о
   Интернет-стандарты доступны в разделе 2 RFC 7841.
   Информация о текущем статусе этого документа, любые опечатки,
   и как предоставить отзыв о нем можно получить на
   https://www.rfc-editor.org/info/rfc8375.
Уведомление об авторских правах
   Copyright (c) 2018 IETF Trust и лица, указанные в качестве
   авторы документа. Все права защищены.
   Этот документ регулируется BCP 78 и юридическими документами IETF Trust.
   Положения, касающиеся документов IETF
   (https://trustee.ietf.org/license-info) действует на дату
   публикации этого документа. Пожалуйста, ознакомьтесь с этими документами
   внимательно, так как они описывают ваши права и ограничения в отношении
   к этому документу.
 
  Компоненты кода, извлеченные из этого документа, должны
   включить текст упрощенной лицензии BSD, как описано в Разделе 4.e
   Доверительные юридические положения и предоставляются без гарантии, поскольку
   описан в Упрощенной лицензии BSD.
Отслеживание стандартов Pfister & Lemon [Страница 1] 
RFC 8375 home.arpa. май 2018 г.
Оглавление
   1. Введение  . . . . . . . . . . . . . . . . . . . . . . . . 3
   2. Язык требований. . . . . . . . . . . . . . . . . . . . 4
   3. Общее руководство. . . . . . . . . . . . . . . . . . . . . . 4
   4. Вопросы резервирования доменных имен. . . . . . . . . . . 4
   5. Обновления протокола управления домашней сетью. . . . . . . . . 7
   6. Вопросы безопасности. . . . . . . . . . . . . . . . . . . 7
     6.1. Местное значение. . . . . . . . . . . . . . . . . . . 7
     6.2. Небезопасное делегирование. . . . . . . . . . . . . . . . . . . 8
     6.3. Обход настроенных вручную распознавателей. . . . . . . . . 97. Делегация home.arpa. . .
 
  . . . . . . . . . . . . . . . 9
   8. Соображения IANA. . . . . . . . . . . . . . . . . . . . . 9
   9. Ссылки. . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1. Нормативные ссылки  . . . . . . . . . . . . . . . . . . 10
     9.2. Информативные ссылки. . . . . . . . . . . . . . . . . 10
   Благодарности. . . . . . . . . . . . . . . . . . . . . . . . . 12
   Адреса авторов. . . . . . . . . . . . . . . . . . . . . . . 12
Отслеживание стандартов Pfister & Lemon [Страница 2] 
RFC 8375 home.arpa. май 2018 г.
1. Введение
   Пользователи и устройства в домашней сети (далее
   «homenet») требует, чтобы устройства и службы идентифицировались по именам
   которые уникальны в пределах домашней сети [RFC7368].
   механизм именования должен функционировать без настройки со стороны
   пользователь. Несмотря на то, что имя может быть делегировано провайдером,
   домашние сети также должны функционировать при отсутствии такого делегирования.
   Этот документ резервирует имя «home. arpa». служить по умолчанию
   имя для этой цели, с областью действия, ограниченной каждым человеком
   домашняя сеть.
   Этот документ исправляет ошибку в [RFC7788], заменяя '.home'
   с 'home.arpa.' в качестве доменного имени по умолчанию для домашних сетей. '.дом'
   был выбран как наиболее удобный вариант; однако есть
   существующие варианты использования «.home», которые могут противоречить этому использованию.
   Факты показывают, что запросы «.home» часто просачиваются и достигают
   корневые серверы имен [ICANN1] [ICANN2].
   Кроме того, для совместимости с DNSSEC (см. Раздел 6)
   необходимо, чтобы небезопасное делегирование (см. раздел 4.3 [RFC4035])
   присутствовать для имени. Существует существующий процесс распределения
   имена в разделе «.arpa.» [RFC3172]. Такой процесс недоступен для
   запрашивая аналогичное делегирование в корне по запросу
   IETF, который не управляет этой зоной. В результате все
   незарегистрированное использование домена .home (то есть все текущие использования на момент
   публикации этого документа), в частности, как указано в
   [RFC7788], устарели.
 
 
 
   Этот документ регистрирует домен «home.arpa». как специальное использование
   доменное имя [RFC6761] и указывает ожидаемое поведение
   из системы доменных имен в отношении DNS-запросов на имена
   чьи крайние правые нетерминальные метки — «home.arpa.». Запросы для
   имена, оканчивающиеся на «.home.arpa». имеют местное значение в пределах
   охват домашней сети, что означает, что идентичные запросы приведут к
   разные результаты от одного хоумнета к другому. Другими словами,
   имя, оканчивающееся на «.home.arpa». не является глобально уникальным.
   Хотя в этом документе содержится конкретная ссылка на [RFC7788],
   не предполагалось, что использование 'home.arpa.' ограничиваться исключительно
   сети, в которых развернут HNCP. Скорее, 'home.arpa'. намеревается
   быть правильным доменом для использования, подобного тому, который описан для «.home» в
   [RFC7788]: локальная служба имен в домашних сетях.
Отслеживание стандартов Pfister & Lemon [Страница 3] 
RFC 8375 home.
 
 arpa. май 2018 г.
2. Язык требований
   Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «ДОЛЖЕН», «НЕ ДОЛЖЕН»,
   «СЛЕДУЕТ», «НЕ СЛЕДУЕТ», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ», «МОЖЕТ» и
   «НЕОБЯЗАТЕЛЬНО» в этом документе следует интерпретировать, как описано в
   BCP 14 [RFC2119] [RFC8174], когда и только тогда, когда они появляются во всех
   столицы, как показано здесь.
3. Общее руководство
   Доменное имя 'home.arpa.' должен использоваться для именования внутри
   жилые дома. Имена, оканчивающиеся на «.home.arpa». ссылка
   зона, обслуживаемая локально, содержимое которой уникально только для
   конкретной домашней сети и не являются глобально уникальными. Такие названия относятся
   к узлам и/или службам, расположенным в домашней сети (например,
   принтер или тостер).
   DNS-запросы для имен, оканчивающихся на «.home.arpa». решаются с помощью
   локальные резолверы в домашней сети. Такие запросы НЕ ДОЛЖНЫ быть рекурсивными
   пересылаются на серверы за пределами логических границ домашней сети.
 
 
   Некоторые пользовательские интерфейсы обнаружения служб, которые предполагается использовать
   в домашних сетях скрывают от конечных пользователей такую ​​информацию, как имена доменов.
   Однако в некоторых случаях ожидается, что пользователям потребуется
   увидеть, запомнить и даже ввести имена, оканчивающиеся на '.home.arpa.'.
   Рабочая группа Homenet надеется, что это имя каким-то образом укажет
   как можно большему количеству читателей, на которые ссылаются такие доменные имена
   к устройствам в доме, но мы признаем, что это несовершенный
   решение.
4. Вопросы резервирования доменных имен
   В этом разделе приведены рекомендации для систем, участвующих в домене.
   разрешение имен при разрешении запросов на имена, оканчивающиеся на
   '.дом.арпа.'. Каждый пункт в этом разделе касается определенного аспекта
   DNS или процесс разрешения доменных имен, которые
   затронутых этим распределением специального использования. Подробные пояснения
   эти элементы можно найти в разделе 5 [RFC6761].
 
 
  Хотя
   термин «домашняя сеть» в [RFC7788] относится к домашним сетям, которые реализуют
   определенный набор функций, в этом документе термин используется для обозначения
   любая домашняя сеть, вне зависимости от набора функций, которые она реализует.
   1. Пользователи могут использовать имена, оканчивающиеся на «.home.arpa». так же, как они
       использовать любое другое доменное имя. 'home.arpa.' имя выбрано, чтобы быть
       легко распознается пользователями как означающее, что имя
       обращение к службе в домашней сети, к которой подключено устройство пользователя
       связанный.
Отслеживание стандартов Pfister & Lemon [Страница 4] 
RFC 8375 home.arpa. май 2018 г.
   2. Прикладное программное обеспечение НЕ ДОЛЖНО обрабатывать имена, оканчивающиеся на
       '.дом.арпа.' иначе, чем другие имена. В частности, там
       не является основанием доверять именам, которые являются субдоменами
       'дом.арпа.' (см. раздел 6).
   3. API и библиотеки разрешения имен НЕ ДОЛЖНЫ распознавать имена,
       заканчиваются на «. home.arpa». как особенные и НЕ ДОЛЖНЫ относиться к ним как к имеющим
       особое значение, за исключением того, что может быть необходимо, чтобы такие
       API не обходят локально настроенные рекурсивные преобразователи.
       Один или несколько IP-адресов для рекурсивных DNS-серверов обычно
       передаваться клиенту через объявления маршрутизатора или DHCP.
       Для административного домена, использующего поддомены
       'home.arpa.', такой как домашняя сеть, предоставленные рекурсивные распознаватели
       этим доменом сможет отвечать на запросы для субдоменов
       'дом.арпа'; другие преобразователи не будут, или они предоставят
       ответы, которые не являются правильными в этом административном домене.
       Хост, настроенный на использование резолвера, отличного от
       была предоставлена ​​локальной сетью, может быть не в состоянии разрешить,
       или могут быть получены неправильные результаты для поддоменов 'home.arpa.'.
       Во избежание этого хосты могут использовать
       резолверы, которые предоставляются локально для разрешения «home. arpa.»,
       даже если они настроены на использование других преобразователей.
   4. Есть три соображения относительно рекурсивных распознавателей, которые
       следуйте этой спецификации:
       A. Рекурсивные преобразователи на сайтах, использующих «home.arpa». ДОЛЖЕН
           прозрачно поддерживать запросы DNSSEC: запросы для DNSSEC
           записи и запросы с установленным битом DNSSEC OK (DO) (см.
           Раздел 3.2.1 [RFC4035]). Пока проверка не
           требуется, настоятельно рекомендуется: кэширующий рекурсивный
           преобразователь, который не проверяет ответы, которые могут быть проверены
           может кэшировать неверные данные. Это, в свою очередь, предотвратит
           проверка резольверов-заглушек от успешной проверки
           ответы.
       B. Если не указано иное, рекурсивные преобразователи и DNS
           прокси-серверы ДОЛЖНЫ вести себя, как описано в Разделе 3 Локально
           Документ обслуживаемых зон [RFC6303]. То есть запросы на
           'дом. арпа.' и поддомены home.arpa. Не должен быть
           перенаправлены, за одним важным исключением: запрос на DS
           запись с установленным битом DO ДОЛЖНА возвращать правильный ответ для
           этот вопрос, включая правильную информацию в органе
           раздел, который доказывает, что запись не существует.
Отслеживание стандартов Pfister & Lemon [Страница 5] 
RFC 8375 home.arpa. май 2018 г.
           Так, например, запрос записи NS для «home.arpa».
           НЕ ДОЛЖЕН приводить к тому, что этот запрос перенаправляется вышестоящему
           кэш, ни полномочному DNS-серверу для «.arpa.».
           Однако, поскольку это необходимо для предоставления точных полномочий
           информации, запрос записи DS ДОЛЖЕН привести к
           переадресация любых необходимых запросов; как правило, это
           будет просто запрос на запись DS, так как необходимая
           информация о полномочиях будет включена в полномочия
           раздел ответа, если установлен бит DO. 
       C. В дополнение к указанному выше поведению, рекурсивный
           резолверы, которые могут использоваться в домашней сети, ДОЛЖНЫ быть конфигурируемыми
           для переадресации запросов для 'home.arpa.' и поддомены
           'дом.арпа.' на авторитетный сервер для «home.arpa.».
           Этот сервер предоставит достоверные данные для «home.arpa».
           внутри конкретной домашней сети. Особая обработка для DS
           записи для 'home.arpa.' делегирование по-прежнему требуется.
           Допустимо комбинировать функцию рекурсивного резольвера
           для общего поиска DNS с авторитетным распознавателем для
           'дом.арпа'; в этом случае вместо пересылки запросов
           для поддоменов home.arpa. на авторитетный сервер,
           преобразователь отвечает на них авторитетно. Поведение с
           в отношении переадресации запросов специально для «home.arpa».
           остается такой же.
   5. Никакой специальной обработки 'home.arpa'. требуется для
       авторитетные реализации DNS-серверов.  Возможно, что
       авторитетный DNS-сервер может попытаться проверить
       серверы для 'home.arpa.' для делегации под этим именем
       прежде чем авторитетно отвечать за такое делегированное имя. В
       такого случая, потому что имя всегда имеет только местное значение,
       в 'home.arpa' такой делегации не будет. зона и так
       сервер отказался бы авторитетно отвечать на такой
       зона. Сервер, реализующий такую ​​проверку, ДОЛЖЕН быть
       настраивается таким образом, чтобы либо не выполнять эту проверку для
       'дом.арпа.' домен или игнорирует результаты проверки.
   6. Операторы DNS-серверов МОГУТ настроить полномочный сервер для
       'дом.арпа.' для использования в домашних сетях и других домашних сетях.
       оператор DNS-серверов, уполномоченных для «home.arpa». в
       глобальный DNS настроит любые такие серверы, как описано в
       Раздел 7.
   7. 'дом.арпа.' является субдоменом домена верхнего уровня arpa, который
       управляется IANA под управлением Интернета
       Совет по архитектуре в соответствии с правилами, установленными в
       [RFC3172].  Других регистраторов для .arpa нет.
Отслеживание стандартов Pfister & Lemon [Страница 6] 
RFC 8375 home.arpa. май 2018 г.
5. Обновления протокола управления домашней сетью
   Последний абзац в Разделе 8 [RFC7788], Домашняя сеть
   Протокол управления обновляется следующим образом:
   СТАРЫЙ:
      Имена и неквалифицированные зоны используются в сети HNCP для предоставления
      присвоение имен и обнаружение служб с локальным значением. Сеть-
      широкая зона добавляется ко всем одиночным меткам или неквалифицированным зонам в
      для того, чтобы их квалифицировать. «.home» — значение по умолчанию; однако
      администратор МОЖЕТ настроить объявление доменного имени TLV
      (раздел 10.6), чтобы сеть использовала другой. В случае
      объявляются множественные, домен узла с наибольшим
      идентификатор узла имеет приоритет.
   НОВЫЙ:
      Имена и неквалифицированные зоны используются в сети HNCP для предоставления
      присвоение имен и обнаружение служб с локальным значением.  Сеть-
      широкая зона добавляется ко всем одиночным меткам или неквалифицированным зонам в
      для того, чтобы их квалифицировать. 'дом.арпа.' по умолчанию; однако
      администратор МОЖЕТ настроить объявление доменного имени TLV
      (раздел 10.6), чтобы сеть использовала другой. В случае
      объявлено несколько TLV, домен узла с
      наибольший идентификатор узла имеет приоритет.
      'home.arpa.' специальное имя не требует специального
      протокол разрешения. Имена, для которых крайние две правые метки
      'дом.арпа.' разрешаются с использованием протокола DNS [RFC1035].
6. Вопросы безопасности
6.1. Местное значение
   Запись DNS, которая возвращается в качестве ответа на запрос для полного
   Полное доменное имя (FQDN), которое является поддоменом «home.arpa». является
   предполагается иметь местное значение. Ожидается, что он будет возвращен
   сервером, участвующим в разрешении имен для домашней сети, устройство
   подключен. Однако такой ответ НЕ ДОЛЖЕН рассматриваться как более
   заслуживает доверия, чем аналогичный ответ для любого другого DNS-запроса. 
   Потому что 'home.arpa.' не имеет глобального масштаба и не может быть защищен
   используя DNSSEC на основе якоря доверия корневого домена, невозможно
   определить с помощью стандартного DNS-запроса, в какой области домашней сети находится ответ
   принадлежит. Следовательно, пользователи могут получить неожиданные результаты с
   такие имена при роуминге в разных хоумнетах.
Отслеживание стандартов Pfister & Lemon [Страница 7] 
RFC 8375 home.arpa. май 2018 г.
   Чтобы этого не произошло, может быть полезно для резолвера
   на хосте, чтобы безопасно различать различные домашние сети и
   между одинаковыми именами в разных домашних сетях. Однако механизм
   потому что это еще не стандартизировано, и это выходит за рамки
   область применения этого документа. Ожидается, что это будет изучено
   в будущей работе.
   Совет в [RFC6303], раздел 7, по установке локальных якорей доверия.
   для локально обслуживаемых зон может работать только в том случае, если есть какой-либо способ
   настройка якоря доверия на хосте.  Домашняя сеть в настоящее время
   не указывает механизма для настройки таких якорей доверия. Как
   результат, хотя этот совет звучит хорошо, он не практичен.
   Кроме того, хотя может быть полезно установить якорь доверия для
   конкретного экземпляра 'home.arpa.', разумно ожидать, что
   хост с таким якорем доверия может время от времени подключаться к
   более одной сети с собственным экземпляром 'home.arpa.'. Такой
   хост не сможет получить доступ к службам на любом экземпляре
   'дом.арпа.' кроме той, для которой якорь доверия был
   настроен.
   В принципе, к экземпляру можно прикрепить идентификатор.
   из 'home.arpa.' которые можно использовать для определения того, какой якорь доверия
   полагаться для проверки имен в этом конкретном случае. Однако,
   последствия для безопасности этого сложны, и такой
   механизм, а также обсуждение этих последствий выходит за рамки
   область применения этого документа.
6.2. Небезопасное делегирование
   Для этой зоны невозможно установить якорь доверия (DS RR). 
   в зоне .arpa. Причина этого в том, что для этого
   необходимо иметь ключ подписи для зоны (см.
   Раздел 5 [RFC4034]). Поскольку зона не является глобально уникальной, нет
   один ключ будет работать.
   Альтернативой может быть предоставление аутентифицированного отказа от
   существование (см. раздел 3.2 [RFC4033]). Это было бы сделано просто
   отсутствием делегации от арпы. зона. Однако это
   требует, чтобы проверяющий преобразователь обрабатывал «home.arpa». специально. Если
   проверяющий распознаватель, который не обрабатывает 'home.arpa.' специально
   пытается проверить имя в 'home.arpa.', аутентифицированный отказ
   существования «дома» как подобласти «арпа». вызовет
   проверка на провал. Поэтому единственная делегация, которая позволит
   имена в разделе «home.arpa». должны быть разрешены всеми валидирующими распознавателями
   является небезопасным делегированием, как в разделе 7 [RFC6303].
Отслеживание стандартов Pfister & Lemon [Страница 8] 
RFC 8375 home. arpa. май 2018 г.
   Следовательно, если якорь доверия для конкретного экземпляра
   'home.arpa.' проверяемая зона настраивается вручную на
   проверка резолвера, подпись DNSSEC и проверка имен внутри
   'home.arpa.' зона невозможна.
6.3. Обход настроенных вручную распознавателей
   В пункте 3 раздела 4 сделано исключение для поведения заглушки
   резолверы, что позволяет им запрашивать локальные резолверы для субдоменов
   'дом.арпа.' даже если они были настроены вручную для использования
   другие резольверы. Это поведение, очевидно, имеет безопасность и конфиденциальность
   последствия и могут быть нежелательными в зависимости от контекста. Это
   может быть лучше просто игнорировать это исключение и, когда одно или несколько
   рекурсивные распознаватели настраиваются вручную, просто не обеспечивают
   правильные ответы для поддоменов 'home.arpa.'. В это время делаем
   не иметь опыта эксплуатации, который помог бы нам в этом
   решение; разработчикам рекомендуется учитывать контекст в
   какое их программное обеспечение будет развернуто при принятии решения о том, как решить
   этот вопрос. 
7. Делегация home.arpa.
   Чтобы быть полностью функциональным, должно быть делегирование
   'дом.арпа.' в '.arpa.' зона [RFC3172]. Эта делегация ДОЛЖНА
   НЕ включать запись DS и ДОЛЖНО указывать на одну или несколько черных дыр
   серверы, например, «blackhole-1.iana.org». и «черная дыра-
   2.iana.org.'. Причина, по которой это делегирование не должно быть подписано,
   что неподписание делегирования нарушает цепочку доверия DNSSEC,
   что предотвращает отклонение имен валидирующим распознавателем-заглушкой
   опубликовано в разделе «home.arpa». на сервере имен домашней сети.
8. Соображения IANA
   IANA зарегистрировала доменное имя «home.arpa». в разделе «Спец.
   Реестр доменных имен» [SUDN]. IANA, с одобрения IAB,
   выполнил делегирование, запрошенное в Разделе 7.
   IANA создала новый подреестр в «Локально обслуживаемой DNS».
   Zones» реестра [LSDZ], озаглавленного «Transport-Independent Locally-Served».
   Реестр зоны DNS» в том же формате, что и другие подреестры.
   IANA добавила в этот новый реестр запись для «home. arpa». с
   описание «Домен специального назначения Homenet», в котором указан этот документ
   в качестве ссылки. Порядок регистрации данного подреестра
   должно быть таким же, как и для других, в настоящее время "IETF Review" (см.
   Раздел 4.8 [RFC8126]).
Отслеживание стандартов Pfister & Lemon [Страница 9] 
RFC 8375 home.arpa. май 2018 г.
9. Ссылки
9.1. Нормативные ссылки
   [RFC2119] Брэднер, С., «Ключевые слова для использования в RFC для указания
              Уровни требований», BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, март 1997 г.,
              .
   [RFC3172] Хьюстон, Г., изд., «Руководство по управлению и операционная
              Требования к области адресов и параметров маршрутизации
              Домен ("arpa")", BCP 52, RFC 3172, DOI 10.17487/RFC3172,
              Сентябрь 2001 г., .
   [RFC4035] Арендс Р., Остайн Р., Ларсон М., Мэсси Д. и С.
              Роуз, «Модификации протокола для безопасности DNS». 
              Расширения», RFC 4035, DOI 10.17487/RFC4035, март 2005 г.,
              .
   [RFC6303] Эндрюс, М., «Локально обслуживаемые зоны DNS», BCP 163,
              RFC 6303, DOI 10.17487/RFC6303, июль 2011 г.,
              .
   [RFC6761] Чешир, С. и М. Крохмаль, «Доменные имена специального назначения»,
              RFC 6761, DOI 10.17487/RFC6761, февраль 2013 г.,
              .
   [RFC8174] Лейба, Б., «Неоднозначность прописных и строчных букв в RFC».
              2119Ключевые слова», BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              Май 2017 г., .
9.2. Информативные ссылки
   [ICANN1] «Снижение риска коллизии новых gTLD», август 2013 г.,
              .
   [ICANN2] «Управление конфликтами в новых gTLD», октябрь 2013 г. ,
              .
   [LSDZ] «Локально обслуживаемые зоны DNS», июль 2011 г.,
              .
   [RFC1035] Мокапетрис, П., «Доменные имена — реализация и
              спецификация", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              19 ноября87, .
Трек стандартов Pfister & Lemon [Страница 10] 
RFC 8375 home.arpa. май 2018 г.
   [RFC4033] Арендс Р., Остайн Р., Ларсон М., Мэсси Д. и С.
              Роуз, «Введение и требования безопасности DNS»,
              RFC 4033, DOI 10.17487/RFC4033, март 2005 г.,
              .
   [RFC4034] Арендс Р., Остайн Р., Ларсон М., Мэсси Д. и С.
              Роуз, «Ресурсные записи для расширений безопасности DNS»,
              RFC 4034, DOI 10.17487/RFC4034, март 2005 г. ,
              .
   [RFC7368] Чаун, Т., Эд., Аркко, Дж., Брандт, А., Троан, О., и Дж.
              Вейл, «Принципы архитектуры домашней сети IPv6»,
              RFC 7368, DOI 10.17487/RFC7368, октябрь 2014 г.,
              .
   [RFC7788] Стенберг, М., Барт, С., и П. Пфистер, "Домашняя сеть
              Протокол управления», RFC 7788, DOI 10.17487/RFC7788, апрель
              2016 г., .
   [RFC8126] Коттон, М., Лейба, Б., и Т. Нартен, «Руководство по
              Написание раздела рекомендаций IANA в документах RFC», BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, июнь 2017 г.,
              .
   [SUDN] «Доменные имена специального назначения», июль 2012 г.,
              .
Отслеживание стандартов Pfister & Lemon [Страница 11] 
RFC 8375 home. arpa. май 2018 г.
Благодарности
   Авторы хотели бы поблагодарить Стюарта Чешира, а также
   председателей homenet, Марка Таунсли и Рэя Беллиса, за их предыдущую работу над
   '.дом'. Мы также хотели бы поблагодарить Пола Хоффмана за предоставление
   обзор и комментарии к разделу «Соображения IANA», Эндрю
   Салливану за обзор и предложенный текст, а также Сюзанне Вульф и Рэю.
   Bellis за их очень подробные комментарии и понимание процесса.
   Спасибо Марку Эндрюсу за предоставление исчерпывающего списка ссылок на
   тема небезопасных делегаций. Спасибо Дейлу Уорли за
   поймав довольно вопиющую ошибку и для обзора Gen-Art, и
   спасибо Даниэлю Миго за тщательный обзор SecDir. Благодаря
   Уоррену Кумари за обнаружение некоторых дополнительных проблем и Адаму Роучу.
   за некоторые полезные разъяснения.
Адреса авторов
   Пьер Пфистер
   Сиско Системы
   Париж
   Франция
   Электронная почта: [email protected]
   Тед Лемон
   Ниббхая Консалтинг
   ПО Вставка 958
   Брэттлборо, Вермонт 05301-0958
   Соединенные Штаты Америки
   Электронная почта: mellon@fugue. com
Отслеживание стандартов Pfister & Lemon [Страница 12]

Домен/суффикс домена верхнего уровня для частной сети?

Что касается RFC 8375 — домен специального назначения «home.arpa.», ниже приведен файл хостов , демонстрирующий простую настройку сети для жилых и офисных помещений. До строки 23 точно такой же, как в Windows 11. home.arpa. исключен из глобальной системы DNS и поэтому является самым безопасным вариантом для тех, кто не арендует доменное имя .

Комментарии включают соответствующие части:

RFC952 — СПЕЦИФИКАЦИЯ ТАБЛИЦЫ ИНТЕРНЕТ-ХОСТА DOD

RFC1123 — Требования к хостам в Интернете — Применение и поддержка

RFC6762 — Многоадресный DNS

RFC8375 — Домен специального назначения дом.арпа. 

 # Copyright (c) 1993-2009 Microsoft Corp.
#
# Это пример файла HOSTS, используемого Microsoft TCP/IP для Windows. #
# Этот файл содержит сопоставления IP-адресов с именами хостов. Каждый
# запись должна быть сохранена на отдельной строке. IP-адрес должен
# помещается в первый столбец, за которым следует соответствующее имя хоста.
# IP-адрес и имя хоста должны быть разделены хотя бы одним
# космос.
#
# Кроме того, комментарии (такие как эти) могут быть вставлены в отдельные
# строк или после имени машины, обозначенного символом '#'.
#
# Например:
#
# 102.54.94.97 rhino.acme.lan # исходный сервер
# 38.25.63.10 x.acme.lan # x клиентский хост
# Разрешение имени локального хоста выполняется внутри самого DNS.
# 127.0.0.1 локальный хост
# ::1 локальный хост
# -------------------------------------------------- -------------------------
# Файл хостов RFC 952 и RFC 1123
# https://www.rfc-editor.org/rfc/rfc952
# https://www.rfc-editor.org/rfc/rfc1123
#
# Этот файл содержит сопоставление имени хоста с IP-адресом для сетей TCP/IP.
#
# РФЦ 952 и RFC 1123 — это стандарты, определяющие правила для имен хостов в
# Интернет. Согласно этим стандартам, совместимое имя хоста должно
# соответствуют следующим критериям:
#
# Он может содержать буквы (A-Z, a-z), цифры (0-9), дефисы (-) и точки (.).
# Он должен начинаться с буквенно-цифрового символа (буквы или цифры) и заканчиваться
# с буквенно-цифровым символом.
# Дефис (-) можно использовать в качестве разделителя, но не в начале
# или конец метки (часть имени хоста, разделенная точками).
# Точки (.) используются для разделения меток, которые обычно
# разные уровни иерархии доменов.
# Имена хостов нечувствительны к регистру.
#
# RFC 1123 обновил исходные требования к имени хоста в RFC 9.52 позволить
# имена хостов, которые должны начинаться с цифр. Тем не менее, это не изменило максимум
# длина имени хоста. Максимальная длина полного доменного имени (FQDN)
# составляет 253 символа (без конечной точки). Этот предел основан на
# максимальный размер DNS-сообщения, который составляет 512 байт, и требование
# разместить другие поля данных в сообщении DNS, например, запрос
# тип и класс. #
# Формат для записей в файле hosts:  <имя хоста> <алиас(а)> #
# RFC 6762 — Многоадресный DNS
# https://www.rfc-editor.org/rfc/rfc6762
# https://serverfault.com/a/1041148
#
# Приложение G. Частные пространства имен DNS
#
# Особая обработка имен, оканчивающихся на «.local». был
# реализовано в компьютерах Macintosh со времен Mac OS 9, и
# продолжается и сегодня в Mac OS X и iOS. Есть и реализации
# для Microsoft Windows [B4W], Linux и других платформ.
#
# Некоторые сетевые операторы настраивают частные внутренние сети
# («внутренние сети») использовали незарегистрированные домены верхнего уровня, и некоторые из них могут
# использовали домен верхнего уровня ".local". Использование «.local» в качестве частного
# домен верхнего уровня конфликтует с многоадресной DNS и может вызвать проблемы
# для пользователей. Клиенты могут быть настроены для отправки как Multicast, так и
# Одноадресные DNS-запросы для этих имен параллельно, и это позволяет
# имена нужно искать в обоих направлениях, но это приводит к дополнительным
# сетевой трафик и дополнительные задержки в разрешении имен, а также
# потенциально может ввести пользователей в заблуждение, если неясно, есть ли какие-либо
# данный результат был получен через групповую рассылку link-local от пира на
# по той же ссылке или с настроенного сервера одноадресных имен. Из-за
# это, мы не рекомендуем использовать ".local" в качестве частного Unicast DNS
# домен верхнего уровня. Мы не рекомендуем использовать незарегистрированные
# доменов вообще, но если сетевые операторы решат это сделать,
# следующие домены верхнего уровня использовались в частных внутренних
# сети без проблем, вызванных попыткой повторного использования «.local». для
# эта цель:
#
# .интранет.
#     .внутренний. (Google, Amazon) виртуальные интрасети
#     .частный.
# .корп.
#     .дом.
# .лан.
#
# RFC 8375 - Домен специального назначения 'home.arpa.'
# https://www.rfc-editor.org/rfc/rfc8375
#
№ 3. Общее руководство
#
# Доменное имя 'home.arpa.' должен использоваться для именования внутри
# домашние сети. Имена, оканчивающиеся на «.home.arpa». ссылка
# зона, которая обслуживается локально, содержимое которой уникально только для
# конкретной домашней сети и не являются глобально уникальными. Такие названия относятся
# к узлам и/или службам, расположенным в домашней сети (например,
# принтер или тостер). #
# Запросы DNS для имен, оканчивающихся на '.home.arpa.' решаются с помощью
# локальные резолверы в домашней сети. Такие запросы НЕ ДОЛЖНЫ быть рекурсивными
# перенаправляется на серверы за пределами логических границ домашней сети.
#
# Некоторые пользовательские интерфейсы обнаружения служб, которые предполагается использовать
# в домашних сетях скрывают от конечных пользователей такую ​​информацию, как имена доменов.
# Однако в некоторых случаях ожидается, что пользователям потребуется
# увидеть, запомнить и даже ввести имена, оканчивающиеся на '.home.arpa.'.
# Рабочая группа Homenet надеется, что это имя каким-то образом
# как можно большему количеству читателей, на которые ссылаются такие доменные имена
# к устройствам в доме, но мы понимаем, что это несовершенный
# решение.
#
# -------------------------------------------------- -------------------------
# петлевой адрес
127.0.0.1 локальный хост
::1 локальный хост
# РФЦ 952-совместимые записи узлов с использованием домена специального назначения RFC 8375 «home.
No related posts.