8-900-374-94-44
Фото — John Markos O’Neill — CC BY-SA
Разработанная учащимися университета система автоматически преобразовывала DNS-имя в IP-адрес и наоборот. Интересно, что когда её код загрузили на BSD (систему распространения ПО), первые исходники уже имели номер версии 4.3. Первое время DNS-сервером пользовались сотрудники лабораторий университета. Вплоть до версии 4.8.3 за разработку BIND отвечали члены исследовательской группы Университета в Беркли — Computer Systems Research Group (CSRG), но во второй половине 1980-х DNS-сервер вырвался за пределы вуза — его передали в руки Пола Викси (Paul Vixie) из корпорации DEC. Пол выпустил обновления 4.9 и 4.9.1, а потом основал Internet Software Consortium (ISC), который с тех пор и отвечает за поддержку BIND. По словам Пола, все предыдущие версии опирались на код студентов из Беркли, и за прошедшие пятнадцать лет он полностью исчерпал свои возможности для модернизации. Поэтому в 2000 году BIND переписали с нуля.
Сервер BIND включает в себя сразу несколько библиотек и компонентов, реализующих «клиент-серверную» архитектуру DNS и отвечающих за настройку функций DNS-сервера. BIND широко распространен, особенно на Linux, и остается популярной реализацией DNS-сервера. Это решение установлено на серверах, обеспечивающих поддержку корневой зоны.
BIND и PowerDNS одни из самых распространенных, но не единственные DNS-серверы. Также стоит отметить Unbound, djbdns и Dnsmasq.
Изначально DNS-сеть была недоступна для широкой публики и потенциальные проблемы с ИБ не являлись приоритетом при разработке системы, но такой подход дал о себе знать впоследствии. С развитием интернета уязвимости системы начали эксплуатировать — например, появились такие атаки как DNS-спуфинг. В этом случае кэш DNS-серверов наполняют данными, не имеющими авторитетного источника, и перенаправляют запросы на серверы злоумышленников.
Чтобы решить проблему, в DNS внедрили криптоподписи для DNS-ответов (DNSSEC) — механизм, позволяющий построить цепочку доверия для домена от корневой зоны. Отметим, что аналогичный механизм добавили для аутентификации хостов при передаче DNS-зоны — он получил название TSIG.
Модификации, упрощающие репликацию баз DNS и исправляющие проблемы безопасности, ИТ-комьюнити всячески приветствовало. Но были и изменения, которые сообщество восприняло не лучшим образом. В частности, переход от бесплатных к платным доменным именам. И это пример лишь одной из «войн» в истории DNS. Подробнее об этом мы поговорим в следующем материале.
Всем доброго времени суток, прочитал в группе VK — DNS — интересное интервью с ген. директором ДНС (третий справа).
интервью взято с сайта CRN IT.
Сегодня компания ДНС — крупнейший игрок по продаже цифровой техники в России, а по итогам 2011 г. еще и один из пяти самых крупных сборщиков настольных компьютеров (данные IT Research). С другой стороны, ДНС — одна из самых «закрытых» компаний. Достоверным можно считать, пожалуй, только год ее основания и город, из которого она стартовала. Зато слухов, сплетен и наветов недоброжелателей — хоть отбавляй. «Мы не даем интервью, потому что мы очень скромные. Ну что мы будем сами себя хвалить? Пусть за нас говорят наши дела», — такова официальная PR-позиция руководства компании. И все же для нашего издания Дмитрий Алексеев, генеральный директор ДНС, сделал исключение и согласился ответить на вопросы заместителя главного редактора CRN/RE Светланы Беловой.
CRN/RE: О вашей компании говорят много, но понять, что из этого — правда, а что — вымысел, непросто. Поэтому, давайте, начнем с самого начала, с истории. Как, когда, откуда, на чьи деньги?
Дмитрий Алексеев (в дальнейшем Д.А.): Мы из Владивостока. И это — правда. А вот про разные мафиозные кланы, связь с которыми нам приписывают, я вам ничего интересного не расскажу. Мы к ним никакого отношения не имеем. Розничная компания ДНС появилась в 1998 г. До этого мы тоже занимались компьютерным бизнесом и назывались так же — ДНС. Правда, у нас была другая специализация — сейчас это называют системной интеграцией. Но во время кризиса 1998 г. весь корпоративный рынок региона приказал долго жить. По, крайней мере, на какое-то время. А нам надо было семьи кормить, поэтому мы и занялись розницей. Ведь, именно розница тогда и выжила: курс доллара «скакал», и люди с удовольствием меняли полученные деньги хоть на что-то, например, на компьютеры. В общем, попробовали, нам понравилось, и мы решили развивать это направление бизнеса.
Конечно, и магазины тогда были другими, и подход к бизнесу. Но мы искали, шли поэтапно, и потихоньку все это выкристаллизовалось в то, что у нас есть сейчас. Я же говорю, ничего интересного, просто мы много трудились.
CRN/RE: Кто является владельцем ДНС?
Д. А: Сейчас у компании около десятка владельцев — топ-менеджмент. Мы придерживаемся коммунистического принципа — владеет тот, кто работает. При этом структура собственности такова, что ни у одного из нас нет больше половины акций, т. е. решающего голоса. И еще, все, кто начинал этот бизнес, продолжают работать в нашей компании.
CRN/RE: Большинство ИТ-компаний начинали с того, что объединялись «технари», которые просто умели скрутить компьютер. Но на руководящие должности нужны люди с совсем другими знаниями. Как было у вас?
Д. А: А мы и сейчас — «технари». Просто нам пришлось учиться менеджменту. Например, я закончил МВА в МГУ. Могу сказать, что на этих «курсах» говорят много интересных вещей. А еще там можно встретить очень интересных людей.
CRN/RE: Что означает название вашей компании?
Д. А: Сейчас уже ничего.
CRN/RE: Ваша розничная сеть — это несколько сотен магазинов. Как вам удается находить продавцов и руководителей для них? Практически все региональные ИТ-компании жалуются на жесточайший дефицит квалифицированных кадров. Но, судя по всему, для вас этой проблемы не существует. Поговаривают, что во все открывающиеся магазины в других регионах вы присылаете людей из Владивостока.
Д. А: У нас — прекрасные кадры. И я считаю, что все эти разговоры о нехватке квалифицированных специалистов — от лукавого. Просто надо любить людей. Русские люди — замечательные, талантливые. Да не оскудеет ими земля русская. И неправда то, что мы во все регионы присылаем людей именно из Владивостока. Сейчас у нас уже работает несколько команд из разных регионов.
Поймите, мы — провинциальная компания. И поэтому нам проще. Ну вот на каких условиях человек из Москвы согласится поехать, например, в Екатеринбург поднимать бизнес в новом филиале? Скорее всего, только если ему пообещают много-много каких-то бонусов. А из нашей глубинки люди едут работать в другие регионы и без всяких бонусов. Просто, чтобы быть ближе к цивилизации. Мы внутри компании с трудом сдерживаем тех, кто рвется открыть магазины, например, в Санкт-Петербурге. Знаете сколько у нас таких желающих? Огромное количество. Но в Санкт-Петербурге с розницей и так все хорошо. Поэтому мы на этот рынок не собираемся приходить. Есть много других городов, которыми нам хочется заняться.
Вот и получается, что в этих вопросах нам действительно проще. У нас реализована система социальных лифтов. У нас люди из провинции могут быстро и эффективно вырасти. И при этом они знают, что для этого надо делать. Просто хорошо работать. А желание уехать из глубинки — это очень сильный мотив.
CRN/RE: Вернемся к вашей «переориентации». Розница — более затратный бизнес, чем системная интеграция. Как же вам удалось так резко поменять специализацию, причем во время кризиса?
Д. А: Повторюсь, в тот момент в нашем регионе «системная интеграция» как таковая просто умерла. Мы и после 1998 г. еще некоторое время пытались работать с корпоративными клиентами, но особых успехов не добились. Я до сих пор очень люблю программировать, мне нравится заниматься сетями: я по натуре — не торгаш. Да и в тех книжках, на которых мы воспитывались, говорилось о том, что перепродавать и спекулировать — это плохо. Для нас и сейчас розничные продажи — не главное. Но раз уж мы занимаемся этим, то стараемся делать профессионально. Нам гораздо интереснее развивать собственное производство. Можно сказать, что это и есть наш основной бизнес. Мы считаем его даже более перспективным, чем розницу.
CRN/RE: Какова структура канала продаж того, что вы производите?
Д. А: Всю собранную технику мы продаем только в своих магазинах. Сейчас мы — крупнейший локальный сборщик не только в России, но и в регионе ЕМЕА. Но это потому, что в Европе локальной сборки уже практически нет. На всех рынках господствуют международные бренды. А мы продолжаем собирать технику под собственной маркой.
CRN/RE: Кто же покупает эту продукцию?
Д. А: Россия — самый крупный в Европе рынок сбыта компьютеров. И если вы думаете, что «все уже всем закупились», то вы глубоко ошибаетесь. Этот процесс бесконечен: в домах появляются второй компьютер, ноутбук, планшет нужен. Да и на работе ПК стоят. Покупать компьютеры будут всегда. Другой вопрос, какие именно.
CRN/RE: Что собирается на вашем производстве?
Д. А: Все компьютеры, продающиеся в наших магазинах, мы собираем сами. Мультинациональные бренды у нас не прижились: честно пытаемся их продавать, но не получается. Еще собираем ноутбуки, моноблоки, планшеты, неттопы, клавиатуры, «мышки», мониторы, ИБП. Все это выпускается под двумя торговыми марками, но к концу года останется одна — DNS. И все это продается только через нашу розничную сеть. Такая концепция «а-ля Dell». Некоторое время назад этот производитель отказался от дистрибьюторов и сделал ставку на прямые продажи, в основном на продажи через Интернет. Мы делаем сейчас примерно то же самое. Но так как в России интернет-инфраструктура развита хуже, чем в США, нам для продажи пришлось развивать собственный ретейл.
CRN/RE: Но в нашей стране уже были попытки пойти по этому пути. Я имею в виду, например, компанию DEPO.
Д. А: Да, но у нее не было канала сбыта как такового. А у нас он есть и потихоньку расширяется. А вместе с ним расширяются и наши производственные планы. Мы пытаемся активно развивать именно российское производство, но пока это получается только для части нашей продукции. Так, компьютеры и ноутбуки выгодно с точки зрения логистики производить здесь, на локальном производстве. Есть комплектующие, дорогие, но маленькие (жесткие диски, память, процессоры). Они летают самолетами. А есть тяжелые, более объемные, но не такие уж и дорогие (корпуса, системные платы, платформы для ноутбуков). Они плывут по морю в контейнерах. Поэтому у нас есть некий выигрыш в логистике: худо-бедно, но какая-то доставка до Владивостока все-таки существует. По крайней мере контейнерные перевозки — точно. И все, что идет по этому пути, мы возим из Китая напрямую и таможим у себя. А все маленькое и дорогое покупаем у дистрибьюторов в Москве. Это позволяет нам сократить логистическое плечо, оно становится короче, чем у тех же самых мультинациональных брендов, что дает нам большую фору. Например, мы «пережили» наводнение в Таиланде уже в конце осени, а международные компании ощущают его отголоски до сих пор.
CRN/RE: Т. е. ваши основные конкуренты — это зарубежные вендоры, а не российские сборщики?
Д. А: А у нас нет конкурентов. Если говорить о зарубежных вендорах, так мы с ними на разных ступенях стоим. Где они, а где мы? Да и с российскими сборщиками мы не конкурируем, т. к. у них другая модель бизнеса. Например, «Аквариус» и «Крафтвей» работают на корпоративном рынке. А мы туда ничего не поставляем. Т. е. мы с ними даже не пересекаемся, у нас совершенно разные ниши.
CRN/RE: Вы сказали, что в России собираете только ноутбуки и компьютеры…
Д. А: Действительно, под нашим брендом сейчас выпускается практически все, что нам необходимо. Повторюсь, это — такая модель «а-ля Dell», только ориентированная на розницу. Но в России мы собираем только компьютеры и ноутбуки, а все остальное — это ОЕМ-производство в Китае. При этом у нас есть планы увеличить объем локальной сборки. Современное производство — это уже не столько умение купить станок, сделать пресс-форму и выдувать что-то из пластмассы: все это на своих заводах прекрасно делают китайские товарищи. Задача владельца торговой марки — понять, что нужно рынку, и по мере необходимости корректировать номенклатуру выпускаемого товара. При этом я не исключаю, что рано или поздно мы перенесем все свое производство в Россию: начиная с определенных объемов такое производство может быть рентабельным. Да и в самом производственном процессе нет ничего сложного, это просто правильно выстроенная цепочка. Кто-то одно хорошо умеет делать, кто-то — другое. Тогда почему все переносят производство в Китай? Да потому, что в России пока еще нет кластеров, в которых все это можно «собрать», а в Китае есть. Например, в одной компании делают пресс-формы, в другой просверлят дырочки, сделают печатные платы и качественно их «разведут», в третьей изготовят упаковку. И все это быстро, эффективно, в пределах одного кластера. Но в самом производстве нет никакого волшебства: купил машину, запрограммировал, она все и делает. Гораздо интереснее создавать что-то свое, собственные разработки, заниматься R&D.
Сейчас мы работаем над разными интересными проектами. Некоторые из них реализуются при поддержке компании Intel. Судя по всему, этот вендор заинтересован в развитии независимой сборки. Например, мы участвуем в программе — она собирает под эгидой Intel локальных сборщиков, рынки сбыта которых не пересекаются. В нашу группу входят компании из Турции, Бразилии и Индонезии. Все вместе мы занимаемся разработкой (для повышения рентабельности затраты на разработку надо «размазать» по максимально большему количеству устройств), размещаем заказы, торгуемся по стоимости комплектующих. А затем каждая компания, в зависимости от степени участия в разработках, продает свою часть продукции на своем рынке.
И мы благодаря наличию собственной розницы гораздо лучше понимаем, что же действительно нужно покупателям. В нашем случае информационная цепочка от потребителя до производства немного короче, чем, например, у тех же международных компаний, поэтому мы более оперативно реагируем на потребности рынка, быстрее, чем они перестраиваемся и выпускаем нужную востребованную продукцию.
CRN/RE: И что же, по вашим наблюдениям, сейчас востребовано на рынке?
Д. А: Сейчас хорошо продаются моноблоки. Но можно сделать так, чтобы спрос на них стал еще больше. Например, пока еще никто не делает моноблоков с мощной графикой — существуют некоторые технологические ограничения. Значит, надо решать эту проблему. Охотно покупают неттопы. Но вообще-то «популярность» конкретного типа продуктов зависит от того, о какой рыночной нише мы говорим.
А общие тенденции заключаются в том, что век компьютерных компаний образца 90-х годов прошлого века закончился, они умирают.
Что я имею в виду? Раньше в основе компьютерного бизнеса лежала модель, которую пропагандировала Intel и которая опиралась на такие понятия, как «системные платы и процессоры», «скрутили, собрали». Но сейчас это неактуально, несовременно и никому не интересно. Да и большие железные ящики, которые шумят и греются, тоже уже никому не нужны. Мир изменился, компьютеры стали миниатюрными: ноутбуки, нетбуки, моноблоки, смартфоны.
Каким основным конкурентным преимуществом обладали «старые» компьютерные фирмы? Они умели собирать системы. И может быть, такое умение еще кому-то понадобится в будущем. Но это уже не массовые продажи, а работа в нише, причем в постоянно сокращающейся. Как в случае с виниловыми пластинками: их до сих пор можно купить, и проигрыватели для них тоже продаются. Но большинство потребителей уже и CD-то не покупают. Все на MP3-музыку перешли. То же самое и с компьютерами: как только «умение собирать» перестало быть главным конкурентным преимуществом, на рынок пришли традиционные бытовые сети, такие как «М.Видео», «Эльдорадо» и «Медиа Маркт». А продавать коробки они умеют гораздо лучше других, и маленькой компании из Владивостока конкурировать с ними бесполезно. Собственно, как и любой другой региональной компании. У нас слишком разные подходы к бизнесу.
CRN/RE: На чем же тогда строить бизнес?
Д. А: У каждой компании на этот вопрос должен быть свой ответ. Для нас самая правильная модель — «а-ля розничный Dell». Мы и производством-то продолжаем заниматься только потому, что оно изменилось, стало другим. Сейчас, чтобы быть производителем, надо уметь делать ноутбуки, а не десктопы. А в России сейчас, кроме нас, практически никто этого делать не умеет. Я убежден, что компьютер должен выглядеть по-другому. Непонятно, кому нужен этот анахронизм — огромный железный ящик. Сейчас все уже умещается в плоский монитор и получается моноблок.
Я считаю, что пора отказаться от словосочетания «компьютерный бизнес» или «компьютерный рынок». Это уже не «компьютерное», а что-то другое, и чем дальше, тем больше будет проявляться. Многие наши коллеги отказываются от сборки, которой занимались раньше, просто потому, что рынок сбыта их продукции перестал существовать. «Компьютеры» уходят в нишу, и мы давно поняли, что, если хочешь производить, надо что-то менять. Примерно три года назад мы стали собирать ноутбуки. Еще тогда я говорил: те, которые не научатся собирать ноутбуки, перестанут быть компьютерной компанией. И что? Сейчас компьютеры гораздо больше похожи на ноутбуки, чем на старые десктопы. Их производство стало гораздо более технологичным. Это — определенные знания и умения, которые нельзя получить за год. Мы тоже находимся в начале этого пути, но думаю, что у нас все получится. Современное производство требует к себе другого подхода. Это уже не «купил 10 комплектующих, скрутил, продал», оно больше похоже на настоящее производство, в нем самое главное — это R&D.
И не надо думать, что больше нечего изобретать. Сколько всего интересного лежит на поверхности, но из-за инертности индустрии этим никто не занимается. Меня давно мучает вопрос: почему в автомобилях нет встроенного смартфона? Это же — очевидно. Нужно сделать одно встроенное устройство, которое и магнитолой будет, и навигатором, и телефоном. Просто взять и сделать, даже выдумывать ничего не надо. Уже все придумано: и технологии, и софт. Все придумали до нас. Только пока еще ничего не сделали. Все только начинается. Поэтому мы хотим сделать хотя бы то, что уже придумано. Мы не претендуем на то, что мы создадим что-то абсолютно новое. Но кто знает?
CRN/RE: Но чуть раньше вы говорили, что до сих пор производите те самые «железные ящики». А сейчас утверждаете, что заниматься этим не следует.
Д. А: Да, мы производим десктопы. Просто потому, что их все еще покупают. Нельзя в один момент взять и перестать. Не получается. Если люди готовы их покупать, то почему бы их не делать? Но кроме ящиков мы делаем и другую технику, о которой я уже говорил. И будем делать еще больше. Например, ноутбуков мы уже сейчас собираем больше, чем «железных ящиков».
CRN/RE: Итак, вы планируете перенести выпуск продукции в Россию?
Д. А: Мы хотим это сделать. Для нас и с точки зрения информационной логистики, и с точки зрения понимания процесса российское производство удобнее, чем китайское. Когда вся продукция выпускается на собственном заводе, гораздо проще контролировать ее качество, да и продакт-менеджеров есть куда привезти, чтобы показать процесс, рассказать о технологических особенностях. А китайское производство — это чаще всего некий черный ящик, в котором непонятно, что происходит. И еще: с точки зрения информационной логистики (понимания, что и как сделать) и возможности быстро что-то изменить собственное производство более гибкое, чем ОЕМ. Поэтому мы будем постепенно переносить сборку техники в Россию. Просто чтобы лучше понимать, что и как ускорить, улучшить и сделать качественнее.
CRN/RE: А о каких объемах идет речь? Сколько вы уже сейчас можете собирать в России?
Д. А: Проблемы «собирать» не существует. У нас есть производственные площади во Владивостоке, Новосибирске, в Подмосковье. Эти «точки на карте» были выбраны для упрощения логистики. Страна у нас большая: есть Дальний Восток, Сибирь и большой логистический «паук» — Подмосковье. Наиболее технологичные вещи собираются во Владивостоке. Этот завод ближе к головному офису, есть возможность оперативно влиять на производство. А когда все процессы уже отработаны, технология передается на другие площадки.
Кроме того, сейчас под Владивостоком мы строим собственный завод. Надеюсь, что летом его запустим, он станет самым крупным в Европе. Но строим мы его не только для увеличения объема производства. Просто для более технологичной сборки нужны другие условия работы, например уровень чистоты помещения. Но выдержать все это в арендованном помещении очень сложно. А значит, страдает стабильность процесса. Кроме того, во Владивостоке вообще плохо с производственными площадями. Вот мы и решили построить собственный завод.
CRN/RE: Но, продавая продукцию только в собственных магазинах, вы искусственно ограничиваете объемы. Не планируете ли вы менять структуру канала и начать продавать через партнеров?
Д. А: Да, объемы продаж и, как следствие, производства ограничиваются количеством наших торговых точек. Но их число постоянно растет. Уже сейчас их 409, а к концу года будет около 500. Поэтому перестраивать канал сбыта мы не собираемся: вся собранная нами техника и в будущем будет продаваться только через наши розничные магазины. Дело в том, что построение партнерской сети — это уже совсем другая модель бизнеса. И я не уверен, что нам удастся сделать ее такой же успешной, как ту, что мы уже построили.
CRN/RE: Т. е. желания стать классическим вендором у вас нет?
Д. А: Нет. Мы лучше продолжим развивать розницу для производства, а производство для розницы.
CRN-IT. Заместитель главного редактора CRN/RE Светлана Белова.
У Вас в браузере заблокирован JavaScript. Разрешите JavaScript для работы сайта!
В моей экспертно-судебной практике стали встречаться запросы, связанные с историей использования домена. Данный материал поможет пользователям и другим экспертам в получении информации об истории сайта.
Основные источники информации:
whoishistory.ru/simplesearch?sbmt=start&domainsimple=htmlweb.rucache:URLcache:https://htmlweb.ru/http://1stat.ru/neighbours?show=neighbours&search_name=htmlweb.ruhttps://www.linkpad.ru/?search=htmlweb.ruhttps://www.alexa.com/siteinfo/htmlweb.ruПредставить современную всемирную паутину без доменного имени сайта просто невозможно. Сегодня это один из столпов интернета.
В 80-х годах прошлого столетия была такая фирма — SRI. Она и рулила всеми названиями сайтов. Что нужно сделать, чтобы получить имя своему сайту? Надо было позвонить в SRI и попросить: ‘хочу назвать сайт — веселый попугай’. И все, вопрос решен.
Но т.к. это обычная компания — работала она как сегодня офисные работники — до 5-6 вечера, праздники — выходной. А если с вашим сайтом приключилась беда 31 декабря вечером, ждите окончания праздников и звоните в 9.00 2 января.
Понятно, что такая система работы очень неудобная. Вывод — надо придумать что-то другое. Какие требования предъявлялись к разрабатываемой технологии:
И постепенно придумали DNS. Если кратко: вначале родилась идея использования нескольких рабочих компьютеров для решения каких-либой сложных задач, предназначеных для мощного компа (некое подобие современной облачной системы). Сообщение на компьютеры посылались по их именам (а не на адрес машины). Т.е. родилась идея присваивать имена рабочим станциям внутри распределенных систем. И создали спец. ось для хранения этих имен. Вначале создали двухуровневую систему имен, но этого оказалось мало — придумали многоуровневую (сейчас можно использовать много поддоменов).
Это все хорошо, технология работала. А если один сервак внутри распределенной сети со всеми именами сайтов сгорит или ‘упадет’ (зависнет)? В результате пришли к необходимости использования резервных серверов. В 1990-е гг. интернет-протоколы работали так: если ответ от сервера не получен (например, он сгорел), снова идет запрос, потом снова и снова, пока не получим ответ. И безрезультатно. Вот для чего резервные серваки.
Пример структуры доменного имени
DNS (англ. Domain Name System «система доменных имён») — компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста (компьютера или устройства), получения информации о маршрутизации почты и/или обслуживающих узлах для протоколов в домене (SRV-запись).
Распределённая база данных DNS поддерживается с помощью иерархии DNS-серверов, взаимодействующих по определённому протоколу.
Основой DNS является представление об иерархической структуре имени и зонах. Каждый сервер, отвечающий за имя, может делегировать ответственность за дальнейшую часть домена другому серверу (с административной точки зрения — другой организации или человеку), что позволяет возложить ответственность за актуальность информации на серверы различных организаций (людей), отвечающих только за «свою» часть доменного имени.
Начиная с 2010 года в систему DNS внедряются средства проверки целостности передаваемых данных, называемые DNS Security Extensions (DNSSEC). Передаваемые данные не шифруются, но их достоверность проверяется криптографическими способами. Внедряемый стандарт DANE обеспечивает передачу средствами DNS достоверной криптографической информации (сертификатов), используемых для установления безопасных и защищённых соединений транспортного и прикладного уровней.
1/5
Просмотров:897 526
6 568
18 978
290 081
839 810
✪ ЖЕЛЕЗНЫЙ РЕВИЗОР / СБОРКА ИГРОВОГО ПК В DNS? СЕРЬЕЗНО?
✪ Сборка компьютера в DNS сравнение со стоковым компьютером в DNS
✪ Система доменных имен DNS | Курс «Компьютерные сети»
✪ ЖЕЛЕЗНЫЙ РЕВИЗОР / НОУТБУК — ПЛАНШЕТ ДЛЯ ХОМЯЧКОВ
✪ ЖЕЛЕЗНЫЙ РЕВИЗОР / СБОРКА ПК У КОНСУЛЬТАНТОВ ДНС?
DNS обладает следующими характеристиками:
DNS важна для работы Интернета, так как для соединения с узлом необходима информация о его IP-адресе, а для людей проще запоминать буквенные (обычно осмысленные) адреса, чем последовательность цифр IP-адреса. В некоторых случаях это позволяет использовать виртуальные серверы, например, HTTP-серверы, различая их по имени запроса. Первоначально преобразование между доменными и IP-адресами производилось с использованием специального текстового файла hosts, который составлялся централизованно и автоматически рассылался на каждую из машин в своей локальной сети. С ростом Сети возникла необходимость в эффективном, автоматизированном механизме, которым и стала DNS.
DNS была разработана Полом Мокапетрисом в 1983 году; оригинальное описание механизмов работы содержится в RFC 882 и RFC 883. В 1987 публикация RFC 1034 и RFC 1035 изменила спецификацию DNS и отменила RFC 882, RFC 883 и RFC 973 как устаревшие.
Использование более простого и запоминающегося имени вместо числового адреса хоста относится к эпохе ARPANET. Стэнфордский исследовательский институт (теперь SRI International) поддерживал текстовый файл HOSTS.TXT, который сопоставлял имена узлов с числовыми адресами компьютеров в ARPANET. Поддержание числовых адресов, называемых списком присвоенных номеров, было обработано Джоном Постелем в Институте информационных наук Университета Южной Калифорнии (ISI), команда которого тесно сотрудничала с НИИ.[1]
Адреса назначались вручную. Чтобы запросить имя хоста и адрес и добавить компьютер в главный файл, пользователи связывались с сетевым информационным центром (NIC) SRI, руководимым Элизабет Фейнлер, по телефону в рабочее время.
К началу 1980-х годов поддержание единой централизованной таблицы хостов стало медленным и громоздким, а развивающейся сети требовалась автоматическая система именования для решения технических и кадровых вопросов. Постел поставил перед собой задачу выработать компромисс между пятью конкурирующими предложениями для решения задачи, сформулированной Полом Мокапетрисом. Мокапетрис вместо этого создал концепцию иерархической системы доменных имен.
Рабочая группа IETF опубликовала оригинальные спецификации в RFC 882 и RFC 883 в ноябре 1983 года.
В 1984 году четыре студента UC Berkeley, Дуглас Терри, Марк Пейнтер, Дэвид Риггл и Сонгниан Чжоу, написали первую версию сервера имен BIND (Berkeley Internet Name Daemon). В 1985 году Кевин Данлэп из DEC существенно пересмотрел реализацию DNS. Майк Карел, Фил Альмквист и Пол Викси поддерживали BIND с тех пор. В начале 1990-х годов BIND был перенесен на платформу Windows NT. Он широко распространен, особенно в Unix-системах, и по-прежнему является наиболее широко используемым программным обеспечением DNS в Интернете.
В ноябре 1987 года были приняты спецификации DNS — RFC 1034 и RFC 1035. После этого были приняты сотни RFC, изменяющих и дополняющих DNS.
Первоначально проблемы безопасности не были основными соображениями при разработке программного обеспечения DNS или любого программного обеспечения для развёртывания в раннем Интернете, поскольку сеть не была открыта для широкой общественности. Однако рост Интернета в коммерческом секторе в 1990-х годах изменил требования к мерам безопасности для защиты целостности данных и аутентификации пользователей.
Несколько уязвимостей были обнаружены и использованы злоумышленниками. Одной из таких проблем является отравление кэша DNS, в котором данные распространяются на кэширующие преобразователи под предлогом того, что они являются авторитетным сервером происхождения, тем самым загрязняя хранилище данных потенциально ложной информацией и длительными сроками действия (время жизни). Впоследствии, запросы легитимных приложений могут быть перенаправлены на сетевые хосты, контролируемые злоумышленником.
DNS-ответы ранее не имели криптографической подписи, что давало возможность для множества вариантов атаки. Современные расширения системы безопасности доменных имен (DNSSEC) изменяют DNS, чтобы добавить поддержку криптографически подписанных ответов. Другие расширения, такие как TSIG, добавляют поддержку криптографической аутентификации между доверенными одноранговыми узлами и обычно используются для авторизации передачи зоны или операций динамического обновления.
Некоторые доменные имена могут использоваться для достижения эффектов спуфинга. Например, paypal.com и paypa1.com — это разные имена, но пользователи могут не различать их в графическом пользовательском интерфейсе в зависимости от выбранного шрифта пользователя. Во многих шрифтах буква l и цифра 1 выглядят очень похожими или даже идентичными. Эта проблема остро стоит в системах, которые поддерживают интернационализированные доменные имена, поскольку многие коды символов в ISO 10646 могут отображаться на типичных экранах компьютеров. Эта уязвимость иногда используется в фишинге.
Для подтверждения результатов DNS также могут использоваться такие методы, как обратный DNS с подтверждением прямых записей, но криптографически достоверными они не являются; при этом не учитывается вариант подмены маршрутной информации (англ. BGP hijacking).
Ключевыми понятиями DNS являются:
.»(точка)), ниже идут домены первого уровня (доменные зоны), затем — домены второго уровня, третьего и т. д. (например, для адреса ru.wikipedia.org. домен первого уровня — org, второго — wikipedia, третьего — ru). DNS позволяет не указывать точку корневого домена.wikipedia.org — поддомен домена org, а ru.wikipedia.org — домена wikipedia.org). Теоретически такое деление может достигать глубины 127 уровней, а каждая метка может содержать до 63 символов, пока общая длина вместе с точками не достигнет 254 символов. Но на практике регистраторы доменных имён используют более строгие ограничения. Например, если у вас есть домен вида mydomain.ru, вы можете создать для него различные поддомены вида mysite1.mydomain.ru, mysite2.mydomain.ru и т. д.Система DNS содержит иерархию DNS-серверов, соответствующую иерархии зон. Каждая зона поддерживается как минимум одним авторитетным сервером DNS (от англ. authoritative — авторитетный), на котором расположена информация о домене.
Имя и IP-адрес не тождественны — один IP-адрес может иметь множество имён, что позволяет поддерживать на одном компьютере множество веб-сайтов (это называется виртуальный хостинг). Обратное тоже справедливо — одному имени может быть сопоставлено множество IP-адресов: это позволяет создавать балансировку нагрузки.
Для повышения устойчивости системы используется множество серверов, содержащих идентичную информацию, а в протоколе есть средства, позволяющие поддерживать синхронность информации, расположенной на разных серверах. Существует 13 корневых серверов, их адреса практически не изменяются.[2]
Протокол DNS использует для работы TCP- или UDP-порт 53 для ответов на запросы. Традиционно запросы и ответы отправляются в виде одной UDP-датаграммы. TCP используется, когда размер данных ответа превышает 512 байт, и для AXFR-запросов.
Термином рекурсия в DNS обозначают алгоритм поведения DNS-сервера: «выполнить от имени клиента полный поиск нужной информации во всей системе DNS, при необходимости обращаясь к другим DNS-серверам».
DNS-запрос может быть рекурсивным — требующим полного поиска, — и нерекурсивным (или итеративным) — не требующим полного поиска.
Аналогично — DNS-сервер может быть рекурсивным (умеющим выполнять полный поиск) и нерекурсивным (не умеющим выполнять полный поиск). Некоторые программы DNS-серверов, например, BIND, можно сконфигурировать так, чтобы запросы одних клиентов выполнялись рекурсивно, а запросы других — нерекурсивно.
При ответе на нерекурсивный запрос, а также при неумении или запрете выполнять рекурсивные запросы, DNS-сервер либо возвращает данные о зоне, за которую он ответственен, либо возвращает ошибку. Настройки нерекурсивного сервера, когда при ответе выдаются адреса серверов, которые обладают большим объёмом информации о запрошенной зоне, чем отвечающий сервер (чаще всего — адреса корневых серверов), являются некорректными, и такой сервер может быть использован для организации DoS-атак.
В случае рекурсивного запроса DNS-сервер опрашивает серверы (в порядке убывания уровня зон в имени), пока не найдёт ответ или не обнаружит, что домен не существует (на практике поиск начинается с наиболее близких к искомому DNS-серверов, если информация о них есть в кэше и не устарела, сервер может не запрашивать другие DNS-серверы).
Рассмотрим на примере работу всей системы.
Предположим, мы набрали в браузере адрес ru.wikipedia.org. Браузер ищет соответствие этого адреса IP-адресу в файле hosts. Если файл не содержит соответствия, то далее браузер спрашивает у сервера DNS: «какой IP-адрес у ru.wikipedia.org»?
Однако сервер DNS может ничего не знать не только о запрошенном имени, но и даже обо всём домене wikipedia.org.
В этом случае сервер обращается к корневому серверу — например, 198.41.0.4. Этот сервер сообщает — «У меня нет информации о данном адресе, но я знаю, что 204.74.112.1 является ответственным за зону org.» Тогда сервер DNS направляет свой запрос к 204.74.112.1, но тот отвечает «У меня нет информации о данном сервере, но я знаю, что 207.142.131.234 является ответственным за зону wikipedia.org.» Наконец, тот же запрос отправляется к третьему DNS-серверу и получает ответ — IP-адрес, который и передаётся клиенту — браузеру.
В данном случае при разрешении имени, то есть в процессе поиска IP по имени:
Иногда допускается, чтобы запрошенный сервер передавал рекурсивный запрос «вышестоящему» DNS-серверу и дожидался готового ответа.
При рекурсивной обработке запросов все ответы проходят через DNS-сервер, и он получает возможность кэшировать их. Повторный запрос на те же имена обычно не идёт дальше кэша сервера, обращения к другим серверам не происходит вообще. Допустимое время хранения ответов в кэше приходит вместе с ответами (поле TTL ресурсной записи).
Рекурсивные запросы требуют больше ресурсов от сервера (и создают больше трафика), так что обычно принимаются от «известных» владельцу сервера узлов (например, провайдер предоставляет возможность делать рекурсивные запросы только своим клиентам, в корпоративной сети рекурсивные запросы принимаются только из локального сегмента). Нерекурсивные запросы обычно принимаются ото всех узлов сети (и содержательный ответ даётся только на запросы о зоне, которая размещена на узле, на DNS-запрос о других зонах обычно возвращаются адреса других серверов).
DNS используется в первую очередь для преобразования символьных имён в IP-адреса, но он также может выполнять обратный процесс. Для этого используются уже имеющиеся средства DNS. Дело в том, что с записью DNS могут быть сопоставлены различные данные, в том числе и какое-либо символьное имя. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя. Обратный порядок записи частей IP-адреса объясняется тем, что в IP-адресах старшие биты расположены в начале, а в символьных DNS-именах старшие (находящиеся ближе к корню) части расположены в конце.
Записи DNS, или ресурсные записи (англ. resource records, RR), — единицы хранения и передачи информации в DNS. Каждая ресурсная запись состоит из следующих полей[3]:
Наиболее важные типы DNS-записей:
referrals.icann.org вернёт его IPv4-адрес — 192.0.34.164.K.ROOT-SERVERS.NET вернёт его IPv6-адрес — 2001:7fd::1.in-addr.arpa на IP-адрес хоста в reverse-форме вернёт имя (FQDN) данного хоста (см. Обратный DNS-запрос). Например (на момент написания), для IP-адреса 192.0.34.164 запрос записи PTR 164.34.0.192.in-addr.arpa вернёт его каноническое имя referrals.icann.org. В целях уменьшения объёма нежелательной корреспонденции (спама) многие серверы-получатели электронной почты могут проверять наличие PTR-записи для хоста, с которого происходит отправка. В этом случае PTR-запись для IP-адреса должна соответствовать имени отправляющего почтового сервера, которым он представляется в процессе SMTP-сессии.Документ RFC 2606 (Reserved Top Level DNS Names — Зарезервированные имена доменов верхнего уровня) определяет названия доменов, которые следует использовать в качестве примеров (например, в документации), а также для тестирования. Кроме example.com, example.org и example.net, в эту группу также входят test, invalid и др.
Доменное имя может состоять только из ограниченного набора ASCII-символов, позволяя набрать адрес домена независимо от языка пользователя. ICANN утвердил основанную на Punycode систему IDNA, преобразующую любую строку в кодировке Unicode в допустимый DNS набор символов.
Серверы имен:
/ фото James Cridland CC
Изначально, до распространения интернета, адреса преобразовывались согласно содержимому файла hosts, рассылаемого на каждую из машин в сети. Однако по мере её роста такой метод перестал оправдывать себя – появилась потребность в новом механизме, которым и стала DNS, разработанная в 1983 году Полом Мокапетрисом (Paul Mockapetris).
DNS состоит из распределенной базы имен, чья структура напоминает логическое дерево, называемое пространством имен домена. Каждый узел в этом пространстве имеет свое уникальное имя. Это логическое дерево «растет» из корневого домена, который является самым верхним уровнем иерархии DNS и обозначается символом – точкой. А уже от корневого элемента ответвляются поддоменые зоны или узлы (компьютеры).
В иерархическом же пространстве имен каждое имя составлено из нескольких частей: например, домена первого уровня .ru, домена второго уровня 1cloud.ru, домена третьего уровня panel.1cloud.ru и т. д. Этот тип пространства имен позволяет легко проводить проверки на дубликаты, и при этом организациям не нужно беспокоиться, что префикс, выбранный для хоста, занят кем-то другим – полный адрес будет отличаться.
Затем запрос начинает свое путешествие – корневой сервер пересылает его серверу первого уровня (поддерживающего зону .ru). Тот – серверу второго уровня (1cloud) и так далее, пока не найдется сервер, который точно знает запрошенное имя и адрес, либо знает, что такого имени не существует. После этого запрос начинает движение обратно. Чтобы наглядно объяснить, как это работает, ребята из dnssimple подготовили красочный комикс, который вы можете найти по ссылке.
Также стоит пару слов сказать про процедуру обратного сопоставления – получение имени по предоставленному IP-адресу. Это происходит, например, при проверках сервера электронной почты. Существует специальный домен in-addr.arpa, записи в котором используются для преобразования IP-адресов в символьные имена. Например, для получения DNS-имени для адреса 11.22.33.44 можно запросить у DNS-сервера запись 44.33.22.11.in-addr.arpa, и тот вернёт соответствующее символьное имя.
Каждый из этих операторов предоставляет данную услугу бесплатно, а также обеспечивает бесперебойную работу, поскольку при отказе любого из этих серверов станут недоступны целые зоны интернета. Ранее корневые DNS-серверы, являющиеся основой для обработки всех запросов о доменных именах в интернете, располагались в Северной Америке. Однако с внедрением технологии альтернативной адресации они «распространились» по всему миру, и фактически их число увеличилось с 13 до 123, что позволило повысить надёжность фундамента DNS.
Например, в Северной Америке находятся 40 серверов (32,5%), в Европе – 35 (28,5%), еще 6 серверов располагаются в Южной Америке (4,9%) и 3 – в Африке (2,4%). Если взглянуть на карту, то DNS-серверы расположены согласно интенсивности использования интернет-инфраструктуры.
«В прошлом уже происходили атаки на DNS-сервера, приводящие к массовым сбоям. Как-то из-за подмены DNS-записи в течение часа для пользователей был недоступен известный всем сервис Twitter, – рассказывает Алексей Шевченко, руководитель направления инфраструктурных решений российского представительства ESET. – Но куда опаснее атаки на корневые DNS-сервера. В частности, широкую огласку получили атаки в октябре 2002 года, когда неизвестные пытались провести DDoS-атаку на 10 из 13 DNS-серверов верхнего уровня».
Протокол DNS использует для работы TCP- или UDP-порт для ответов на запросы. Традиционно они отправляются в виде одной UDP-датаграммы. Однако UDP является протоколом без установления соединения и поэтому обладает уязвимостями, связанными с подделкой адресов – многие из атак, проводимых на DNS-сервера, полагаются на подмену. Чтобы этому препятствовать, используют ряд методик, направленных на повышение безопасности.
Одним из вариантов может служить технология uRPF (Unicast Reverse Path Forwarding), идея которой заключается в определении того, может ли пакет с определенным адресом отправителя быть принят на конкретном сетевом интерфейсе. Если пакет получен с сетевого интерфейса, который используется для передачи данных, адресованных отправителю этого пакета, то пакет считается прошедшим проверку. В противном случае он отбрасывается.
Несмотря на то что, данная функция может помочь обнаружить и отфильтровать некоторую часть поддельного трафика, uRPF не обеспечивает полную защиту от подмены. uRPF предполагает, что прием и передача данных для конкретного адреса производится через один и тот же интерфейс, а это усложняет положение вещей в случае нескольких провайдеров. Более подробную информацию о uRPF можно найти здесь.
Еще один вариант – использование функции IP Source Guard. Она основывается на технологии uRPF и отслеживании DHCP-пакетов для фильтрации поддельного трафика на отдельных портах коммутатора. IP Source Guard проверяет DHCP-трафик в сети и определяет, какие IP-адреса были назначены сетевым устройствам.
После того как эта информация была собрана и сохранена в таблице объединения отслеживания DHCP-пакетов, IP Source Guard может использовать ее для фильтрации IP-пакетов, полученных сетевым устройством. Если пакет получен с IP-адресом источника, который не соответствует таблице объединения отслеживания DHCP-пакетов, то пакет отбрасывается.
Также стоит отметить утилиту dns-validator, которая наблюдает за передачей всех пакетов DNS, сопоставляет каждый запрос с ответом и в случае несовпадения заголовков уведомляет об этом пользователя. Подробная информация доступна в репозитории на GitHub.
Постоянно ведутся работы по повышению надежности, чтобы сделать систему менее чувствительной к сбоям (стихийные бедствия, отключения электросети и т. д.), и это очень важно, поскольку интернет стал неотъемлемой частью нашей жизни, и «терять» его, даже на пару минут, совершенно не хочется.
Кстати, компания 1cloud предлагает своим пользователям VPS бесплатную услугу «DNS-хостинг» – инструмент, упрощающий администрирование ваших проектов за счет работы с общим интерфейсом для управления хостами и ссылающимися на них доменами.
О чем еще мы пишем:
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.
DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Вот и все. Правда. Вы или ваш браузер запрашивает значение для ключа www.example.com, и получает в ответ 1.2.3.4.
Большой плюс DNS в том, что это публичная услуга, и можно потыкать в сервера если хочется разобраться. Давайте попробуем. У меня есть домен petekeen.net, который хостится на машине web01.bugsplat.info. Команды, используемые ниже, можно запустить из командной строки OS X (ой, то есть macOS, — прим. пер.).
Давайте взглянем на маппинг между именем и адресом:
$ dig web01.bugsplat.info
Команда dig это такой швейцарский армейский нож для DNS-запросов. Крутой, многофункциональный инструмент. Вот первая часть ответа:
; <<>> DiG 9.7.6-P1 <<>> web01.bugsplat.info
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51539
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
;; QUESTION SECTION:
;web01.bugsplat.info. IN A
dig по-умолчанию запрашивает A-записи. A это address (адрес), и это один из фундаментальных видов записей в DNS. A содержит один IPv4-адрес. Есть эквивалент для IPv6-адресов — AAAA. Давайте взглянем на ответ:
;; ANSWER SECTION:
web01.bugsplat.info. 300 IN A 192.241.250.244
Тут говорится, что у хоста web01.bugsplat.info. есть один адрес A: 192.241.250.244. Число 300 это TTL, или time to live (время жизни). Столько секунд можно держать значение в кэше до повторной проверки. Слово IN означает Internet. Так сложилось исторически, это нужно для разделения типов сетей. Подробнее об этом можно почитать в документе IANA’s DNS Parameters.
Оставшаяся часть ответа описывает сам ответ:
;; Query time: 20 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:01:16 2013
;; MSG SIZE rcvd: 56
В частности, здесь говорится, как долго сервер откликался, какой у сервера IP-адрес (192.168.1.1), на какой порт стучался dig (53, DNS-порт по-умолчанию), когда запрос был завершен и сколько байтов было в ответе.
Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз, когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Но в этом примере не видно, что DNS-сервер 192.168.1.1 связался с кучей других серверов чтобы ответить на простой вопрос: «куда указывает адрес web01.bugsplat.info?». Давайте запустим трейс чтобы узнать о всей возможной цепочке, которую пришлось бы пройти dig‘у, если бы информация не был закэширована:
$ dig +trace web01.bugsplat.info
; <<>> DiG 9.7.6-P1 <<>> +trace web01.bugsplat.info
;; global options: +cmd
. 137375 IN NS l.root-servers.net.
. 137375 IN NS m.root-servers.net.
. 137375 IN NS a.root-servers.net.
. 137375 IN NS b.root-servers.net.
. 137375 IN NS c.root-servers.net.
. 137375 IN NS d.root-servers.net.
. 137375 IN NS e.root-servers.net.
. 137375 IN NS f.root-servers.net.
. 137375 IN NS g.root-servers.net.
. 137375 IN NS h.root-servers.net.
. 137375 IN NS i.root-servers.net.
. 137375 IN NS j.root-servers.net.
. 137375 IN NS k.root-servers.net.
;; Received 512 bytes from 192.168.1.1#53(192.168.1.1) in 189 ms
info. 172800 IN NS c0.info.afilias-nst.info.
info. 172800 IN NS a2.info.afilias-nst.info.
info. 172800 IN NS d0.info.afilias-nst.org.
info. 172800 IN NS b2.info.afilias-nst.org.
info. 172800 IN NS b0.info.afilias-nst.org.
info. 172800 IN NS a0.info.afilias-nst.info.
;; Received 443 bytes from 192.5.5.241#53(192.5.5.241) in 1224 ms
bugsplat.info. 86400 IN NS ns-1356.awsdns-41.org.
bugsplat.info. 86400 IN NS ns-212.awsdns-26.com.
bugsplat.info. 86400 IN NS ns-1580.awsdns-05.co.uk.
bugsplat.info. 86400 IN NS ns-911.awsdns-49.net.
;; Received 180 bytes from 199.254.48.1#53(199.254.48.1) in 239 ms
web01.bugsplat.info. 300 IN A 192.241.250.244
bugsplat.info. 172800 IN NS ns-1356.awsdns-41.org.
bugsplat.info. 172800 IN NS ns-1580.awsdns-05.co.uk.
bugsplat.info. 172800 IN NS ns-212.awsdns-26.com.
bugsplat.info. 172800 IN NS ns-911.awsdns-49.net.
;; Received 196 bytes from 205.251.195.143#53(205.251.195.143) in 15 ms
Информация выводится в иерархической последовательности. Помните как dig вставил точку . после хоста, web01.bugsplat.info? Так вот, точка . это важная деталь, и она означает корень иерархии.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Итак, в самом верху трейса находятся корневые сервера, каждый определен с помощью NS-записи. NS-запись связывает доменное имя (в данном случае, корневой домен) с DNS-сервером. Когда вы регистрируете доменное имя у регистратора типа Namecheap или Godaddy, они создают NS-записи для вас.
В следующем блоке видно, как dig выбрал случайный корневой сервер, и запросил у него A-запись для web01.bugsplat.info. Видно только IP-адрес корневого сервера (192.5.5.241). Так какой именно корневой сервер это был? Давайте узнаем!
$ dig -x 192.5.5.241
; <<>> DiG 9.8.3-P1 <<>> -x 192.5.5.241
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2862
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;241.5.5.192.in-addr.arpa. IN PTR
;; ANSWER SECTION:
241.5.5.192.in-addr.arpa. 3261 IN PTR f.root-servers.net.Флаг -x заставляет dig провести обратный поиск по IP-адресу. DNS отвечает записью PTR, которая соединяет IP и хост, в данном случае — f.root-servers.net.
Возвращаясь к нашему начальному запросу: корневой сервер F вернул другой набор NS-серверов. Он отвечает за домен верхнего уровня info. dig запрашивает у одного из этих серверов запись A для web01.bugsplat.info, и получает в ответ еще один набор NS-серверов, и потом запрашивает у одного из этих серверов запись A для web01.bugsplat.info.. И, наконец, получает ответ!
Уф! Сгенерировалось бы много трафика, но почти все эти записи были надолго закэшированы каждым сервером в цепочке. Ваш компьютер тоже кэширует эти данные, как и ваш браузер. Чаще всего DNS-запросы никогда не доходят до корневых серверов, потому что их IP-адреса почти никогда не изменяются («Наверно все таки речь идет о большом TTL для записей в их базе. Если у DNS сервера IP адрес вообще ни разу не изменялся, то это не означает, что его база навечно закеширована» — прим. от rrrav). Домены верхнего уровня com, net, org, и т.д. тоже обычно сильно закэшированы.
Есть еще несколько типов, о которых стоит знать. Первый это MX. Он соединяет доменное имя с одним или несколькими почтовыми серверами. Электронная почта настолько важна, что у нее есть свой тип DNS-записи. Вот значения MX для petekeen.net:
$ dig petekeen.net mx
; <<>> DiG 9.7.6-P1 <<>> petekeen.net mx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18765
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;petekeen.net. IN MX
;; ANSWER SECTION:
petekeen.net. 86400 IN MX 60 web01.bugsplat.info.
;; Query time: 272 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:33:43 2013
;; MSG SIZE rcvd: 93Заметьте, что MX-запись указывает на имя, а не на IP-адрес.
Еще один тип, который вам скорее всего знаком, это CNAME. Расшифровываетя как Canonical Name (каноническое имя). Он связывает одно имя с другим. Давайте посмотрим на ответ:
$ dig www.petekeen.net
; <<>> DiG 9.7.6-P1 <<>> www.petekeen.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16785
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.petekeen.net. IN A
;; ANSWER SECTION:
www.petekeen.net. 86400 IN CNAME web01.bugsplat.info.
web01.bugsplat.info. 300 IN A 192.241.250.244
;; Query time: 63 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Jul 19 20:36:58 2013
;; MSG SIZE rcvd: 86Сразу видно, что мы получили два ответа. Первый говорит, что www.petekeen.net указывает на web01.bugsplat.info. Второй возвращает запись A для того сервера. Можно считать, что CNAME это псевдоним (или алиас) для другого сервера.
Записи CNAME очень полезны, но есть важный момент: если есть CNAME с каким-то именем, то нельзя создать другую запись с таким же именем. Ни MX, ни A, ни NS, ничего.
Причина в том, что DNS производит замену таким образом, что все записи того места, куда указывает CNAME, также валидны для CNAME. В нашем примере, записи у www.petekeen.net и web01.bugsplat.info будут совпадать.
Поэтому нельзя делать CNAME на корневом домене вроде petekeen.net, потому что обычно там нужны другие записи, например, MX.
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
$ dig www.petekeen.net @8.8.8.8Символ @ с IP-адресом или хостом заставляет dig прозводить запрос к указанному серверу через порт по-умолчанию. Можно использовать публичный DNS-сервер Гугла или почти-публичный-сервер Level 3 по адресу 4.2.2.2.
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Часто нужно сделать редирект домена iskettlemanstillopen.com на www.iskettlemanstillopen.com. Регистраторы типа Namecheap или DNSimple называют это URL Redirect. Вот пример из админки Namecheap:
Символ @ означает корневой домен iskettlemanstillopen.com. Давайте посмотрим на запись A у этого домена:
$ dig iskettlemanstillopen.com
;; QUESTION SECTION:
;iskettlemanstillopen.com. IN A
;; ANSWER SECTION:
iskettlemanstillopen.com. 500 IN A 192.64.119.118
Этот IP принадлежит Namecheap’у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com:
$ curl -I iskettlemanstillopen.com
curl -I iskettlemanstillopen.com
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 19 Jul 2013 23:53:21 GMT
Content-Type: text/html
Connection: keep-alive
Content-Length: 154
Location: http://www.iskettlemanstillopen.com/
Взгляните на скриншот выше. На второй строке там CNAME. В этом случае www.iskettlemanstillopen.com указывает на приложение, запущенное на Heroku.
$ heroku domains
=== warm-journey-3906 Domain Names
warm-journey-3906.herokuapp.com
www.iskettlemanstillopen.com
С Github похожая история, но там нужно создать специальный файл в корне репозитория, и назвать его CNAME. См. документацию.
Большинство DNS-серверов поддерживают шаблоны (wildcards). Например, есть wildcard CNAME для *.web01.bugsplat.info указывает на web01.bugsplat.info. Тогда любой хост на web01 будет указывать на web01.bugsplat.info и не нужно создавать новые записи:
$ dig randomapp.web01.bugsplat.info
;; QUESTION SECTION:
;randomapp.web01.bugsplat.info. IN A
;; ANSWER SECTION:
randomapp.web01.bugsplat.info. 300 IN CNAME web01.bugsplat.info.
web01.bugsplat.info. 15 IN A 192.241.250.244
Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:
Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.
Работая с клиентами на протяжении многих лет, всегда есть вероятность, что кто-то изменит запись DNS на веб-сайте, а затем потребуется изменить ее обратно. Иногда люди забывают что-то задокументировать, и вы можете попасть в ситуацию, когда пытаетесь выяснить, какими были старые серверы имен или на какие IP-адреса указывали ваши пользовательские серверы имен.
Ниже приведены несколько веб-сайтов, которые бесплатно покажут вам историю DNS и премиальную альтернативу, если вам нужно копнуть еще глубже.
SecurityTrails (ранее DNS Trails) — отличное бесплатное решение для поиска истории DNS. Этот сайт содержит доступ к базе данных, содержащей примерно 3,4 триллиона записей DNS, 3 миллиарда записей WHOIS и 418 миллионов имен хостов. Все это собиралось ежедневно с середины 2008 года.
SecurityTrails — наш личный фаворит, который, кажется, имеет самые точные записи истории DNS. Это также должно вернуть больше данных для вас .
SecurityTrails исторические данные DNSПримечание: Для доступа к большему количеству данных вам потребуется создать бесплатную учетную запись. Их бесплатный уровень включает 50 запросов API для получения текущих записей DNS, 12 лет исторических записей DNS с ежедневной детализацией и поддоменов для любого заданного домена.
Complete DNS — отличный быстрый, простой и бесплатный способ легко увидеть изменения на ваших серверах имен и т. Д. У них более 2,2 миллиарда записей об изменениях серверов имен. Примечание: они ограничивают вас 3 бесплатными поисками в течение определенного периода времени.
WhoISrequest — это сайт, который, как мы обнаружили, обеспечивает хорошее представление истории DNS домена в отношении серверов имен. Фактически, они отслеживают изменения серверов имен с 2002 года.Примечание: они ограничивают вас 5 бесплатными поисками в течение определенного периода времени.
WhoISrequest История DNSDNS History сканирует записи DNS с 2009 года. Их база данных в настоящее время содержит более 650 миллионов доменов и более 2 миллиардов записей DNS.
По нашему мнению, данные не так точны, но могут служить еще одним хорошим ориентиром.
История DNSМы всегда находим то, что нам нужно, среди других бесплатных сайтов, упомянутых выше.Но если по какой-то причине вы не можете этого сделать, есть также премиум-сервис от Domain Tools, в котором вы можете заказать отчет «История хостинга». Это позволяет вам просматривать историю IP-адресов, серверов имен и регистраторов.
Отчет об истории хостинга DomainToolsУ вас есть другой инструмент истории DNS, который вы используете? Я хотел бы услышать, что это такое. Как всегда, не стесняйтесь оставлять свои комментарии ниже!
.Когда DNS-сервер получает запрос извне домена для получения информации об адресе или имени внутри домена, он предоставляет достоверный ответ. Когда сервер получает запрос из своего собственного домена на информацию об адресе или имени за пределами этого домена, он затем передает запрос другому серверу, который в основном находится под управлением его интернет-провайдера.Если этот сервер не знает ответа или авторитетного источника ответа, он затем перейдет к DNS-серверам для домена верхнего уровня. За этим следует передача запроса на полномочный сервер для определенного домена. Затем ответ возвращается по тому же пути.
При обычном поиске в DNS могут возникать запросы трех типов:
Просмотр истории DNS
Если у вас очень хорошая история работы с одними и теми же клиентами в течение многих лет, всегда есть вероятность того, что кто-то изменит запись DNS на веб-сайте, а затем этот человек может также захотеть изменить ее обратно.Иногда люди просто забывают что-то задокументировать, и вы можете оказаться в ситуации, когда вы пытаетесь узнать, какие IP-адреса были установлены для ваших пользовательских серверов имен или каковы были старые серверы имен.
DNS и доменные имена используются для законной деятельности, в то время как есть также те, кто сосредоточен на темной стороне Интернета, разработке бот-сетей DDOS, настройке фишинговых доменов, рассылке спама, распространении вирусов и вредоносных программ или просто запуске любых других незаконных цифровых Сервисы.
Чтобы отследить этих коррумпированных лиц, эксперты по безопасности из частных и государственных агентств работают вместе, чтобы анализировать различные интернет-сервисы и собирать детали, которые могут помочь отслеживать их действия. Ниже приведены некоторые из ключевых областей, которые следует изучить при выполнении аудита доменного имени и DNS:
Для повышения эффективности серверы могут кэшировать полученные ответы на определенный период времени.Это позволяет им быстрее отвечать в следующий раз, когда поступит запрос на такой же поиск. Например, если все в офисе хотят получить доступ к одному и тому же обучающему видео на определенном веб-сайте в тот же день, локальный DNS-сервер просто нужно будет разрешить имя один раз, и тогда он сможет обслуживать все остальные запросы из своего кеша. Продолжительность хранения записи настраивается; более длинные значения снижают нагрузку на серверы, а более короткие значения гарантируют наиболее точные ответы.
Comodo cWatch Web считается единственным доступным решением, которое предлагает полный стек веб-безопасности, который включает в себя больше, чем просто управляемый CDN и DNS. Этот инструмент веб-безопасности доступен со следующими ключевыми функциями веб-безопасности:
Веб-безопасность Как изучают хакеры
Лучшая безопасность веб-сайтов
Сканер уязвимостей веб-сайтов
Проверка веб-сайтов
.Рейтинги пользователей:
[Всего: 0 Среднее: 0/5]В этом посте я расскажу о бесплатных веб-сайтах, чтобы увидеть историю DNS . На этих веб-сайтах вы можете запросить историю DNS любого домена и просмотреть данные. Вы можете указать практически любое доменное имя на этих веб-сайтах, и они покажут вам исторические данные сервера имен в соответствии с различными датами.Вы можете видеть IP-адреса веб-сайтов в течение каждой даты и анализировать, сколько раз IP-адреса веб-сайтов менялись. Если вы хотите узнать какой-либо предыдущий сервер имен, который был назначен вашему веб-сайту, эти веб-сайты вам пригодятся. Все, что они просят, — это ввести доменное имя целевого веб-сайта. И они покажут вам историю DNS. Однако ни на одном из этих веб-сайтов вы не можете экспортировать данные истории DNS в файл.
Могут возникнуть ситуации, когда вам понадобится IP-адрес, который был назначен вашим веб-сайтам ранее.Это сделать нелегко, поэтому вам пригодятся следующие веб-сайты для просмотра истории DNS. Они содержат историю DNS почти всех доменов, зарегистрированных их владельцами. И вам просто нужно поискать их на этих веб-сайтах, чтобы увидеть соответствующую историю серверов имен.
Security Trials — один из лучших веб-сайтов для более подробного просмотра истории серверов имен.Это мощный веб-сайт, который имеет 3,4 триллиона исторических запросов DNS, 3 миллиарда исторических записей whois и отслеживает 418 миллионов имен хостов. И именно поэтому это самые мощные веб-сайты в этом списке, позволяющие просматривать историю DNS любого действительного домена. Он показывает результат в виде таблицы, и вы можете это проанализировать. Хотя вы можете использовать его без создания учетной записи. Если вы зарегистрируетесь, то в бесплатном плане он предлагает вам 30 просмотров в месяц. А чтобы увидеть историю DNS домена, вам просто нужно извлечь его IP-адрес или доменное имя.
Использовать этот веб-сайт для просмотра истории серверов имен очень просто. Просто перейдите на этот веб-сайт по ссылке выше, и тогда вы сможете начать использовать этот веб-сайт для просмотра истории DNS. В его интерфейсе просто введите доменное имя целевого веб-сайта. Отправьте запрос, и он начнет сбор данных для ваших результатов. Через 2-3 секунды вы увидите подробности истории DNS, которые вы сможете проанализировать. В результате он в основном показывает IP-адрес, время последнего посещения, первого посещения и продолжительность просмотра. Вы можете увидеть скриншот выше.
DNSHistory.org — еще один бесплатный веб-сайт в моем списке, который вы используете для просмотра истории DNS или сервера имен любого домена. Он создает простой отчет об исторических серверах имен, и вы можете анализировать полученные данные. Он генерирует исторические данные по годам и показывает это на своем интерфейсе. Вы можете анализировать различные записи истории DNS, которые он показывает. Кроме того, записи истории, которые он показывает, находятся в группе. Он создает группы истории DNS, такие как MX, SOA, NS, A и т. Д.Вы можете выбрать любую группу и просмотреть соответствующие исторические данные. Однако вы не сможете экспортировать или скачать это.
Перейдите на домашнюю страницу веб-сайтов и затем с правой стороны введите имя целевого домена, историю DNS которого вы хотите запросить. После этого подождите пару секунд, чтобы увидеть исторические данные DNS, которые должны отображаться на этих веб-сайтах. Он возвращает историю DNS в группах, и вы можете открыть любую группу, чтобы увидеть соответствующую историю DNS. Кроме того, вы заметите, что он упорядочивает историю DNS в соответствии с датами, что упрощает поиск определенной истории сервера имен.
Complete DNS — еще один бесплатный веб-сайт для просмотра истории DNS любого домена. Он создает отчет истории DNS по годам, и вы можете анализировать исторические данные, которые он производит. И перед запуском отчета он добавляет общий статус сервера имен веб-сайтов с момента его регистрации. В истории DNS вы можете увидеть различные серверы имен, которые были назначены вашим веб-сайтам, а также устаревшие и их доменные имена.Вы можете анализировать весь исторический отчет, который он генерирует, и делать все, что захотите. В бесплатном плане этот веб-сайт позволяет просматривать отчеты об истории 100 серверов имен. Однако вы не можете экспортировать отображаемые данные.
Начало работы с этим веб-сайтом ничем не отличается от любого другого веб-сайта в этом списке. Просто перейдите на его домашнюю страницу и затем введите домен целевого веб-сайта, историю DNS которого вы хотите увидеть. После этого вы можете увидеть, что он показывает историю DNS за время с момента создания целевого веб-сайта.Вы можете проанализировать результат, который он дает, и посмотреть, когда менялись DNS для веб-сайтов.
Это лучших бесплатных веб-сайтов для просмотра истории DNS для домена . Вы можете использовать любые веб-сайты из этого списка и просматривать историю серверов имен. На мой взгляд, тогда сайты для просмотра истории серверов имен — это Security Trials . Вы также можете использовать другие сайты, если вам нужны простые исторические данные.
.Некоторые люди используют DNS и доменные имена для законной деятельности, в то время как другие сосредотачиваются на темной стороне Интернета, создавая бот-сети DDOS, распространяя вредоносное ПО и вирусы, настраивая фишинговые домены, рассылая СПАМ или просто запуская любые другие незаконные цифровые сервисы.
Чтобы поймать плохих парней, к работе привлекается множество экспертов по безопасности (как из государственных, так и из частных агентств), которые анализируют различные интернет-сервисы для сбора информации и отслеживания их действий.Однако даже в области кибербезопасности не все эксперты сосредотачиваются на анализе DNS и доменных служб, а также всей их информации, когда речь идет о цифровой криминалистике.
Есть несколько способов запустить криминалистический анализ DNS. Возвращаясь к нашей предыдущей статье «Топ-20 OSINT Tools», мы рассмотрели несколько инструментов для сбора информации о любой цели, но мы не сосредоточились на такой важной службе, как DNS.
Хотя некоторые из упомянутых инструментов могут помочь вам собрать некоторую информацию о домене, криминалистический анализ DNS может выполняться с использованием других внешних инструментов, таких как DNSRecon, DNSTracer или DNSMap.Однако, хотя эти инструменты довольно полезны в определенных случаях, они могут занимать много времени, а когда дело доходит до кибербезопасности, важна каждая секунда. Использование этих инструментов домена может занять несколько дней или даже недель, чтобы собрать необходимую информацию, а вам понадобится больше времени, чтобы объединить их результаты. Это может занять особенно много времени при расследовании более чем одного киберпреступника или когда задействовано несколько служб и доменных имен.
Когда вы выполняете аудит доменного имени и DNS, есть ключевые области для изучения, например:
Давайте посмотрим, как вы можете расширить возможности своей судебной экспертизы и аудита безопасности с помощью нашей платформы кибербезопасности SecurityTrails, сочетания всех известных инструментов DNS, упомянутых выше, а также многого другого.
Исторические данные DNS могут помочь вам узнать другие интересные подробности о текущем хостинг-провайдере, а также рассказать, кем были прошлые провайдеры веб-хостинга.Это становится особенно полезным, когда вам нужно отследить защищенные прокси-сервером домены, такие как, например, домены, стоящие за Cloudflare, как мы уже рассказывали в статье: Поиск IP-адреса веб-сайта за Cloudflare.
Обнаружение всех поддоменов, стоящих за доменным именем, является одной из ключевых задач проведения аудита DNS. В следующем примере вы заметите, как наша платформа может собирать все существующие поддомены для данного домена, как мы это сделали здесь для oracle.ком.
Если вы используете наш API, его можно даже получить с помощью простой команды CURL с любого терминала:
url --request GET \
--url 'https://api.securitytrails.com/v1/domain/oracle.com/subdomains?apikey=your_api_key' Замените your_api_key своим собственным ключом API.
Инструмент обнаружения соседних IP-адресов позволяет идентифицировать соседей по хосту для определенного IP-адреса.
Как я могу найти соседей по IP для любого IP-адреса? Выполните следующие действия:
Вы должны увидеть, какие домены размещены на одном IP-адресе, как показано на следующем снимке экрана:
Никогда не знаешь, что найдешь, когда исследуешь одно-единственное доменное имя, особенно когда начинаешь получать связанные с ним доменные имена.Большой сюрприз, похоже, что вы сможете узнать не только все подробности об основном доменном имени плохого парня, но и обо всех связанных с ним доменах.
Это можно сделать с помощью нашего API, как вы можете видеть здесь:
curl --request GET \
--url 'https://api.securitytrails.com/v1/domain/google.com/associated?apikey=your_api_key' Еще один способ получить связанные домены — это фильтровать по адресу электронной почты с помощью нашего основного интерфейса.Наша мощная платформа также позволяет узнать, какие адреса электронной почты связаны с любыми доменными именами. Просто введите любой адрес электронной почты, чтобы узнать, сколько доменов связано с ним; см. пример ниже:
может помочь вам идентифицировать текущие и старые DNS-серверы, а также личные или корпоративные данные. Это действительно полезно для отслеживания изменений WHOIS на любой временной шкале. Поскольку наш API поддерживает несколько языков программирования, в этом случае мы будем использовать Ruby, чтобы показать вам, как можно легко выполнить сложную задачу, такую как получение истории WHOIS, с помощью нашего API истории домена; см. ниже:
требуется 'uri'
требуется 'net / http'
url = URI ("https: // api.securitytrails.com/v1/history/symantec.com/whois?apikey=your_api_key ")
http = Net :: HTTP.new (url.host, url.port)
http.use_ssl = true
request = Net :: HTTP :: Get.new (URL)
response = http.request (запрос)
ставит response.read_body Здесь будут показаны полные исторические результаты WHOIS, которые можно легко интегрировать с вашими повседневными задачами судебной экспертизы:
{
"результат": {
"Предметы": [
{
«updatedDate»: 1464160006589,
"tld": "com",
"положение дел": [
"clientDeleteProhibited https: // icann.org / epp # clientDeleteProhibited ",
"clientTransferProhibited https://icann.org/epp#clientTransferProhibited",
"clientUpdateProhibited https://icann.org/epp#clientUpdateProhibited",
"serverDeleteProhibited https://icann.org/epp#serverDeleteProhibited",
"serverTransferProhibited https://icann.org/epp#serverTransferProhibited",
"serverUpdateProhibited https://icann.org/epp#serverUpdateProhibited"
],
«началось»: 1472708410412,
"registrarName": "MARKMONITOR INC.",
"nameServers": [
"PDNS1.ULTRADNS.NET",
«ПДНС2.ULTRADNS.NET ",
"PDNS3.ULTRADNS.ORG",
"PDNS4.ULTRADNS.ORG",
"PDNS5.ULTRADNS.INFO",
"PDNS6.ULTRADNS.CO.UK",
"UDNS1.ULTRADNS.NET",
"UDNS2.ULTRADNS.NET"
],
"expiresDate": 1763881606589,
"закончился": 1512131429698,
"домен": "symantec.com",
createdDate: 722588806589,
"contactEmail": "[email protected]",
"контакт": [
{
"тип": "регистрант",
«телефон»: «16505278000»,
"street1": "350 Ellis Street,",
"состояние": "CA",
"postalCode": "94043",
"организация": "Symantec Corporation",
"name": "Менеджер домена",
«факс»: «16505275693»,
"электронная почта": "домены @ symantec.com ",
"страна": "США",
"город": "Маунтин-Вью"
},
{
"тип": "административный контакт",
«телефон»: «16505278000»,
"street1": "350 Ellis Street,",
"состояние": "CA",
"postalCode": "94043",
"организация": "Symantec Corporation",
"name": "Менеджер домена",
«факс»: «16505275693»,
"электронная почта": "[email protected]",
"страна": "США",
"город": "Маунтин-Вью"
},
{
"тип": "административный контакт",
«телефон»: «16505278000»,
"street1": "350 Ellis Street,",
"состояние": "CA",
"postalCode": "94043",
"организация": "Symantec Corporation",
"name": "Менеджер домена",
«факс»: «16505275693»,
"электронная почта": "домены @ symantec.com ",
"страна": "США",
"город": "Маунтин-Вью"
},
{
"тип": "технический контакт",
«телефон»: «16505278000»,
"street1": "350 Ellis Street,",
"состояние": "CA",
"postalCode": "94043",
"организация": "Symantec Corporation",
"name": "Менеджер домена",
«факс»: «16505275693»,
"электронная почта": "[email protected]",
"страна": "США",
"город": "Маунтин-Вью"
}
]
}, Конечная точка истории записей DNS позволяет получить полный доступ к текущим и историческим данным о записях DNS для любого данного доменного имени.
Доступ к нему можно получить с помощью нашего онлайн-обозревателя DNS SecurityTrails или с помощью нашего мощного API, который можно интегрировать с несколькими современными языками программирования, такими как Node, Javascript, PHP или Python.
Получить историю DNS с помощью Python довольно просто; см. ниже:
запросов на импорт
url = "https://api.securitytrails.com/v1/history/microsoft.com/dns/a"
querystring = {"apikey": "your_api_key"}
response = requests.request ("ПОЛУЧИТЬ", url, params = querystring)
печать (ответ.текст) Результат будет примерно таким:
{
"тип": "а / ipv4",
"записи": [
{
"ценности": [
{
"ip_count": 428,
"ip": "23.96.52.53"
},
{
"ip_count": 430,
"ip": "23.100.122.175"
},
{
"ip_count": 427,
"ip": "191.239.213.197"
},
{
"ip_count": 428,
"ip": "104.43.195.251"
},
{
"ip_count": 434,
"ip": "104.40.211.35"
}
],
"наберите "А",
"организации": [
"Корпорация Майкрософт"
],
"last_seen": ноль,
"first_seen": "2015-11-19"
}, Вы даже можете использовать CURL из командной строки, если хотите:
curl --request GET \
--url 'https: // api.securitytrails.com/v1/history/microsoft.com/dns/a?apikey=your_api_key ' Мы все знаем одно: киберпреступники не могут совершать преступления в Интернете без DNS и доменных имен.
И хотя некоторые специальные инструменты для DNS и исследования домена могут быть полезны при выполнении задач судебной экспертизы и аудита, использование инструментария SecurityTrails является наиболее эффективным вариантом для сбора и объединения всей необходимой информации с действительно быстрыми результатами.Этот инструментарий поднимет ваш кибер-интеллект и сбор данных на новый уровень.
Наша мощная централизованная платформа позволит вам отслеживать каждый шаг плохих парней, которые пытаются остаться незамеченными, но невольно оставили свои следы на своем пути.
Готовы ли вы расширить возможности своей работы по криминалистике домена и DNS? Получите бесплатную учетную запись API, чтобы автоматизировать все ваши ежедневные задачи информационной безопасности.
ЭСТЕБАН БОРДЖЭстебан — опытный исследователь и специалист по кибербезопасности с более чем 15-летним опытом.С момента присоединения к SecurityTrails в 2017 году он был нашим специалистом по технической безопасности серверов и информации об источниках.
.