<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>toha.name &#187; DNS</title>
	<atom:link href="https://toha.name/tag/dns/feed/" rel="self" type="application/rss+xml" />
	<link>https://toha.name</link>
	<description>Antoshka&#039;s Homepage</description>
	<lastBuildDate>Wed, 31 Dec 2025 19:10:54 +0000</lastBuildDate>
	<language>ru-RU</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.6.1</generator>
		<item>
		<title>Чего только не придумают!</title>
		<link>https://toha.name/20-03-2011/dns/</link>
		<comments>https://toha.name/20-03-2011/dns/#comments</comments>
		<pubDate>Sun, 20 Mar 2011 00:58:21 +0000</pubDate>
		<dc:creator>Антошка</dc:creator>
				<category><![CDATA[домены]]></category>
		<category><![CDATA[DNS]]></category>

		<guid isPermaLink="false">http://toha.name/?p=204</guid>
		<description><![CDATA[На днях я начитался ужастиков про DNS. Domain name system &#8212; DNS &#8212; это такая мировая система по управлению доменными именами, а доменные имена &#8212; это те адреса, что вы используете при доступе к любым сайтам, например yandex.ru &#8212; доменное имя, и оно управляется NS Яндекса. А NS &#8212; name server &#8212; входят в состав [&#8230;]]]></description>
				<content:encoded><![CDATA[<p>На днях я начитался ужастиков про DNS. Domain name system &#8212; DNS &#8212; это такая мировая система по управлению доменными именами, а доменные имена &#8212; это те адреса, что вы используете при доступе к любым сайтам, например yandex.ru &#8212; доменное имя, и оно управляется NS Яндекса. А NS &#8212; name server &#8212; входят в состав DNS. Ну а дальше будет много непонятного, что наверное уже не будет так подробно расшифровано. Так что, внимание, далее <strong>научный контент!!</strong></p>
<p>У меня появилась мысль, что возможно изменение по одиночке записей на различных slave NS-серверах, несвязанных между собой. Да и неграмотные DNS &#8212; вообще, оказывается, брешь в системе безопасности вашей локальной сети, домена, почты, сайта (да-да, так много вещей сразу попадает под удар), если эти DNS настроены плохо или не контролируются вами.</p>
<p><span style="text-decoration: underline;">Случай первый. Безопасность почты.</span> Давайте предположим, что у нас есть домен wikileaks.ltd, который добавлен на три DNS &#8212; два из них вторичные (slave) и один &#8212; первичный (master). slave-1 стоит в Москве, а slave-2 &#8212; в Чикаго. Внезапно master выходит из строя на долгий срок, нигде в мире на DNS не сохранился кэш, либо его срок действия уже истек, зону начинают обрабатывать только slave сервера. В этот же момент хакер проник на один из slave-серверов, допустим на тот, что в Чикаго (slave-2), и изменил зону домена, теперь MX записи у него стали не от Google Apps, а от Яндекс.Почты. Итак, получилась ситуация, что домен есть на двух вторичных NS, но на одном у нас MX Google (как и должно быть), а на другом &#8212; Яндекс (что неверно). Хакер запарковал домен в почту Яндекса и ждет двух важных и секретных писем &#8212; одно отправлят с сервера в Бразилии, а другое &#8212; с сервера в Казахстане. Получит ли хакер секретные письма? Оба, только одно или все-таки ни одного? Или почта раздвоится и будет отправлена и в Google, и в Яндекс?</p>
<p>По непроверенной информации, есть шанс, что Google настолько продвинут, что поддержит зону своим кэшем не один день. Но и Яндекс не лыком шит, думаю, что-то придумал. Но вот если MX записи у нас будут ни Google или Яндекс, а хостинг-1 и хостинг-2 с минималистическим кэшем, да и NS у такого хостинга почему-то по одному, проще говоря &#8212; пара VPS на разных континентах, где есть только один NS. Безусловно можно протестировать такую схему, но трудозатраты тут большие, но секретные письма из Бразилии и Казахстана этого могут стоить <img src='https://toha.name/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /> </p>
<p><span style="text-decoration: underline;">Случай второй. Безопасность локальной сети.</span> Это вариант для тех, у кого есть свои DNS, есть своя локальная сеть, компьютеры в ней и есть что из этой сети тащить. Здесь DNS нам тоже предлагает брешь, все дело в том, что при неправильной настройке сервера NS, с него можно стащить зонный файл и узнать записи домена, т.е. компьютеры, субдомены, IP. Далее я просто процитирую буквы из другой статьи, там все понятно:</p>
<blockquote><p><span style="color: #008000;">Конфигурируя сервер, администраторы часто забывают правильно настроить службу  DNS . После такой настройки служба  DNS  работает корректно: IP-адреса разрешаются в имена компьютеров, а символьные имена без проблем преобразуются в IP-адреса. На этом большинство администраторов и останавливаются: главное, чтобы работало. Работать-то оно работает, но неправильно настроенный сервер  DNS  может стать огромной дырой в системе безопасности компании. Одно дело, когда сервер  DNS  обслуживает локальную сеть без выхода в Интернет: даже, если кто-то и попытается &#171;взломать&#187; сервер, то вычислить &#171;хакера&#187; довольно просто. А вот, если сеть предприятия подключена к Интернет, то узнать, кто же пытался взломать (или взломал) вашу сеть довольно сложно. Ущерб от взлома может обойтись компании в кругленькую сумму.</span><br />
<span style="color: #008000;"> Прежде, чем приступить к взлому сети или отдельной системы злоумышленник (или группа злоумышленников) пытается собрать как можно больше информации: имена компьютеров сети, имена пользователей, версии установленного программного обеспечения. Целой кладовой полезной для взломщика информации станет неправильно настроенная служба  DNS  (BIND). Рассмотрим небольшой пример: запустите программу nslookup и введите команду:</span><br />
<span style="color: #008000;"> <em>ls server.com</em></span><br />
<span style="color: #008000;"> Если администратор забыл правильно настроить трансфер зоны, то кто угодно получит список компьютеров нашей сети:</span><br />
<span style="color: #008000;"> <em>[comp2.server.com]<br />
server.com. 323.111.200.2<br />
server.com. server = comp1.server.com<br />
server.com. server = comp2.server.com<br />
server.com. server = comp3.server.com<br />
mail 323.111.200.17<br />
gold 323.111.200.22<br />
www.ie 323.111.200.11<br />
jersild 323.111.200.25<br />
comp1 323.111.200.1<br />
comp3 323.111.200.3<br />
parasit3 323.111.200.20<br />
www.press 323.111.200.30<br />
comp1 323.111.200.1<br />
www 323.111.200.2</em></span><br />
<span style="color: #008000;"> Примечание. Чтобы не было недоразумений, указаны несуществующие IP-адреса</span></p>
<p><span style="color: #008000;">Дабы не случилось непоправимого, разрешите передачу зону только одному компьютеру &#8212; вторичному серверу  DNS  вашей компании, если такой, конечно, имеется. В файле конфигурации сервиса named &#8212; /etc/named.conf &#8212; измените секцию options следующим образом:</span><br />
<span style="color: #008000;"> <em>options{</em></span><br />
<span style="color: #008000;"> <em> allow-transfer</em></span><br />
<span style="color: #008000;"> <em> {</em></span><br />
<span style="color: #008000;"> <em> 192.168.1.2;</em></span><br />
<span style="color: #008000;"> <em> };</em></span><br />
<span style="color: #008000;"> <em> };</em></span><br />
<span style="color: #008000;"> Вторичный сервер  DNS , как правило, не передает никакой информации о зоне, поэтому обязательно укажите следующую строку в его файле конфигурации /etc/named.conf (в секции options):</span><br />
<span style="color: #008000;"> <em>allow-transfer  { none; }</em></span><br />
<span style="color: #008000;"> Если у вас нет вторичного сервера  DNS , добавьте вышеуказанную строку в файл конфигурации основного сервера  DNS .</span><br />
<span style="color: #008000;"> Как любой хороший администратор, вы хотите, чтобы ваш сервер  DNS  быстро обслуживал запросы клиентов. Но к вашему серверу могут подключаться пользователи не из вашей сети, например, из сети конкурирующего провайдера. Тогда вас сервер будет обслуживать &#171;чужих&#187; клиентов. Непорядок! Опция allow-query позволяет указать адреса узлов и сетей, которым можно использовать наш сервер  DNS:</span><br />
<span style="color: #008000;"> <em>allow-query { 192.168.1.0/24; localhost; };</em></span><br />
<span style="color: #008000;"> В данном примере мы позволяем использовать наш сервер узлам из сети 192.168.1.0 и узлу localhost. Целесообразно разрешить рекурсивные запросы только из сети 192.168.1.0 и узлу localhost:</span><br />
<span style="color: #008000;"> <em>allow-recursion { 192.168.1.0/24; localhost; };</em></span><br />
<span style="color: #008000;"> Обычно взлом любой сети начинается со сбора информации &#8212; о структуре сети, об установленном программном обеспечении и версиях этого ПО и т.д. Мы можем заставить сервер  DNS  сообщать не номер своей версии, а произвольное сообщение:</span><br />
<span style="color: #008000;"> <em>version &#171;Made in USSR&#187;;</em></span><br />
<span style="color: #008000;"> Все вышеперечисленные опции должны быть указаны в секции options файла конфигурации named.conf:</span><br />
<span style="color: #008000;"> <em>options {</em></span><br />
<span style="color: #008000;"> <em>allow-query { 192.168.1.0/24; localhost; };</em></span><br />
<span style="color: #008000;"> <em>allow-recursion { 192.168.1.0/24; localhost; };</em></span><br />
<span style="color: #008000;"> <em> allow-transfer  { 192.168.1.2; };</em></span><br />
<span style="color: #008000;"> <em>version &#171;Made in USSR&#187;;</em></span><br />
<span style="color: #008000;"> <em>}</em></span></p></blockquote>
<p><span style="color: #008000;"><em></em></span><span style="color: #000000;">Ну и на последок даю список бесплатных DNS хостингов. Для чего? Дабы, во-первых, парковать туда свои домены и быть он-лайн в своей почте, во-вторых, быстро (&#171;на горячую&#187;) менять A-запись для домена, а не ждать обновления NS у регистратора. (В 21-м веке &#171;на горячую&#187; смена происходит уже не только HDD-дисков, но и местоположения сайта.)</span></p>
<p><span style="color: #000000;">netbreeze.net/dns &#8212; максимум одна зона в бесплатном пакете, есть одномегабайтный хостинг (под визитку или редирект), суппорт может настроить трансфер зоны, три NS</span><br />
<span style="color: #000000;">pdd.yandex.ru/help/section9/ &#8212; два NS от Яндекса</span><br />
<span style="color: #000000;">ypdns.com &#8212; пять NS, 10 бесплатных зон</span><br />
<span style="color: #000000;">cloudns.net &#8212; три зоны, четыре NS, в бесплатном варианте много ограничений, но работать с этим вполне реально </span><br />
<span style="color: #000000;">freedns.ws </span><br />
<span style="color: #000000;">freedns.afraid.org &#8212; есть редактор</span><br />
<span style="color: #000000;">everydns.com</span><br />
<span style="color: #000000;">zoneedit.com &#8212; держит зону *.gov, нет редактора зоны, бесплатно 5 зон</span><br />
<span style="color: #000000;">editdns.net</span><br />
<span style="color: #000000;">xname.org</span><br />
<span style="color: #000000;">ns2.trifle.net &#8212; только вторичный NS </span></p>
]]></content:encoded>
			<wfw:commentRss>https://toha.name/20-03-2011/dns/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
