понедельник, 16 мая 2011 г.

Фокусы с DNS, или *.ru = *.local

imageЧасто мы имеем дело с ситуацией, когда в локальной сети предприятия используется именование домена вида *.local, а в сети Интернет домен этой же организации имеет вид *.ru. Сейчас я не буду рассуждать на тему того как правильно, а как нет, просто предложу вариант, когда в локальной сети сотрудники смогут использовать точно такие же URL-ы, как и во внешней, и при этом трафик не будет делать петлю через Интернет-шлюз, чтобы попасть на сервер, который находится прямо «под боком».

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

Итак, мы предполагаем, что локальный домен у нас называется alexxhost.local, а внешний соответственно alexxhost.ru. Для примера рассмотрим веб-сервисы сервера Exchange. В этом случае, внешние пользователи открывают Outlook Web App по ссылке https://mail.alexxhost.ru/owa, в то время как внутренние используют адрес https://e2010sp1.alexxhost.local/owa. Задача заключается в том, чтобы внутренние и внешние клиенты набирали в браузере один и тот же адрес и при этом попадали бы на сервер Exchange по кратчайшему маршруту.

Решение

Логично, что общим адресом для всех следует сделать адрес https://mail.alexxhost.ru/owa, т.к. внешние пользователи не смогут разрешить локальное имя, а вот внутренних мы можем «послать» туда, куда нам нужно. Также очевидно, что для решения подобного рода задач нам необходимо внести некоторые коррективы в настройки локального DNS сервера.

Итак, что же нужно сделать:

  • Создаем дополнительную зону alexxhost.ru на локальном DNS-сервере.

Для этого выбираем раздел Зоны прямого просмотра (Forward Lookup Zone)Создать новую зону (New Zone…) и отвечаем на пару несложные вопросы мастера:

clip_image002

Рис.1: Создаем новую DNS-зону.

  • После создания зоны, её нужно «заполнить».

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

1. Перенаправим «внешние» запросы пользователей на внутренние сервера, для этого создадим соответствующие CNAME, либо А-записи: (рис.2)

  1. CNAME – mail указывающую на узел e2010sp1.alexxhost.local

2. Настроим доступ к узлам, которые находятся вне локальной сети следующим образом:

  1. Настроим делегирование на внешний NS-сервер для всех записей, которые расположены снаружи (у меня это www и portal). Для этого нажмем правой кнопкой мыши на имени зоны – Создать делегирование… (New Delegation). Далее пройдем по шагам мастера (см. рис.3-4)
  2. Сделаем так, чтобы локальные пользователи могли ходить на внешний сайт без www, для этого создадим корневую А-запись (как папка верхнего уровня), указывающую на IP внешнего сайта.

clip_image004

Рис.2: Создаем нужные записи в новой зоне.

clip_image006

Рис.3: Указываем имя субдомена.

clip_image008

Рис.4: Указываем NS сервер, на котором есть запись для этого субдомена.

В результате:

Настройки локального DNS сервера будут выглядеть примерно следующим образом (рис.5):

clip_image010

Рис.5: Результирующая картина.

И это приведет к тому, что все запросы локальных пользователей к внешнему сайту http://www.alexxhost.ru либо просто http://alexxhsot.ru пойдут на внешний IP, а вот запросы на mail.alexxhost.ru будут сопоставлены через запись CNAME с действительным именем сервера Exchange – e2010sp1.alexxhost.local, важно – при такой реализации будет работать даже Kerberos. При этом, для разрешения запросов вида www.alexxhost.ru и portal.alexxhost.ru, наш DNS сервер будет обращаться к вышестоящему серверу имен, который мы указали в настройках делегирования.

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

Заключение

На этом пожалуй все, что я хотел рассказать про DNS.

PS. Виновником написания статьи является Станкевич Александр (Stanky). Именно ему и хочет выразить особую благодарность за помощь в технических деталях.

50 комментариев:

Aleksandr комментирует...

Огромное спасибо за статью) очень полезно и как раз то что мне нужно было. Алексей, вопрос такой, можешь ли написать статью про федерализацию календарей, как использовать к примеру один общий календарь для предприятия? Если есть время и возможность можешь сделать статью такую плиз.

Baf комментирует...

А если у меня куча субдоменов типа www.xxx.ru mail.xxx.ru moscow.xxx.ru и т.д - мне прийдётся на них все создавать делегирование?

P.S> только у меня не работает отправка комментария с помощью google account?

Алексей Богомолов (Alexx) комментирует...

>на них все создавать делегирование?
Ну да, конечно, ведь вам же нужно, чтобы внутренние пользователи имели к ним доступ? И вы же не хотите руками править локальную зону каждый раз, когда изменяете их настройки на внешнем DNS-сервере?

Баф комментирует...

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

Баф комментирует...

Хотя, на ум приходит следующий вариант:
Синхронизировать 2 DNS сервера
На локальном ДНС сервере отредактировать файл с DNS зоной, возможно с помощью Excel'a или ещё как :)

Но новые записи в любом случае прийдётся заводить в двух местах

Art комментирует...

Доброе время суток. Честно, как полному чайнику, мне ваши статьи и подкасты очень помогли. Развернул локальный/внешний почтовик. Как бы почти всё работает, однако слегка не так, как хотелось бы. Не нашёл как поступить в моём случае, когда всего 1 ip внешний. Если будет секунда – плиз подскажите.
Есть небольшая организация 25-30 чел в офисе и где то 200 за его границами. Есть пока один сервер. На нём поднята exsi. На ней уже есть 5 виртуальных машин:
1) RRAS. mydomain.ru на базе win2k8 r2 с двумя сетевыми, одна в офис, вторая на модем (PPPoE, 1 внешний статический ip для всего домена) (как я понял, его лучше вывести с домена) 192.168.100.2
2) DC. mydomain.ru на базе win2k8 r2 c AD, DNS, DHCP, сервером сертификации 192.168.100.1
3) Mail. mydomain.ru на базе win2k8 r2 c Exchange 2010, с iis 192.168.100.3. Всё на нём, edge не ставил.
4) Web server (имя «web») на базе centos 192.168.100.4
5) 1С. mydomain.ru на базе win2k8 r2 192.168.100.10
Локальный домен по названию соответствует внешнему. Есть только 1 внешний ip!
Внешним днс указан один из серверов freedns.ws. Второй на ns1.mydomen.ru (по сути этого днс сервера нет).
Доступ к веб серверу, так же как и к mail сделал пробросом через порты в nat на интерфейсе тунеля. Но понятно, что это не правильно.
Вот как бы в чём и просьба, объясните плиз, как правильно разместить второй днс сервер (я так понимаю что только на шлюзе или же взять второй у того же freedns.ws) и как прописать сами записи. Что делать с одинаковыми наименованиями внутреннего и внешнего домена? (или лучше всего переименовать внутренний). И снаружи и внутри нужен веб доступ и к сайту и к почте. А для каждой машины нет внешнего отдельного ip.
С уважением …

Алексей Богомолов (Alexx) комментирует...

Не совсем понял зачем вам второй DNS, если зона уже активна и все хорошо?
В любом случае, вам достаточно 1 внешнего IP. Просто у вас будет несколько А-записей во внешней зоне:
1. NS.mydomain.ru - для DNS
2. mail.mydomain.ru - для почта
3. пустая (как папка верхнего уровня) - для сайта.
Я бы на вашем месте прокинул внешний IP до RRAS сервера, поставил бы там TMG/ISA, настроил разные прослушиватели и опубликовал бы все нужные сервисы.
Общая схема такая - запрос приходит на нужную А-запись и TMG его редиректит на нужный локальный сервер.
Лучше поставить на RRAS сервере ещё один DNS, где настроить зону mydomain.ru чисто для внешних хостов, т.е. по большому счету, в ней у вас будут только записи, указанные в самом начале. Это DNS сервер вы опубликуете в интернет. При этом старый DNS сервер у вас останется и будет обслуживать внутренних пользователей, снабжая их уже локальными IP адресами служб.

Анонимный комментирует...

Здравствуйте Алексей. В чем может быть проблема? При отправке почты на скажем ...@gmail.com все сообщения приходят туда и от туда так же прекрасно уходят. вроде бы все впорядке. Но недавно столкнулся с ситуацией когда отправляя почту на адрес ...@beeline.ru получаю на жлюзе в очереди сообщение типа 450 4.7.1 Client host rejected: cannot find your hostname [внешний IP шлюза].

Алексей Богомолов (Alexx) комментирует...

А PTR запись во внешней зоне есть? (у провайдера прописывается)

Анонимный комментирует...

Записи нет уже письмо написал чтоб внесли. Спасибо.

Анонимный комментирует...

Алексей, здравствуйте!

Очень полезная статья, собираемся в своей компании сделать точно так же.
Есть недопонимание в теоретической части:

Если мы делегируем обслуживание зоны другому днс-серверу, каким образом получается так, что некоторые записи (которые мы добавили в зону самостоятельно) продолжает обслуживать наш собственный днс? Не должен ли он при запросе клиента сразу отдавать имя другого днс, которому делегированы права на управление данной зоной? И при этом не проводить поиск по записям (тем, которые у него есть) в делегированной зоне?

Алексей Богомолов (Alexx) комментирует...

Немого не понял вопроса. Но всетаки попробую ответить. Делегирование мы делаем в данном случае только для поддоменов www и portal. Вот для разрешения этих имен и для их поддоменов произойдет обращение к NS серверу прописанному в делегировании. Что касается корневого домена alexxhost.ru, то его записями будем управлять мы на локальном сервере и обращений к внешнему NS-y (где действительно лежат его внешние записи) происходить не будет! Именно для этого мы делаем А-запись сайта с внешним IP, иначе его локальные клиенты просто не найдут.

Анонимный комментирует...

"Именно для этого мы делаем А-запись сайта с внешним IP, иначе его локальные клиенты просто не найдут"
Что-то не пойму почему из локальной сети пользователи не найдут сайт alexxhost.ru если присвоить папке верхнего уровня внутренний ИП?..

Алексей Богомолов (Alexx) комментирует...

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

Анонимный комментирует...

Как быть с несколькими почтовыми доменами?
Получение проходит на ура. А вот отправка через один шлюз, где один внешний IP и PTR запись часто возвращает 450 4.7.1 Client host rejected: cannot find your hostname [внешний IP шлюза]. Как разделить на два внешних IP? Или как-то иначе надо?

Алексей Богомолов (Alexx) комментирует...

Надо для каждого домена создать А и МХ запись, указывающие на один внешний IP.

Алексей Богомолов (Alexx) комментирует...

Я имею ввиду внешнюю DNS зону!

Анонимный комментирует...

В домене Exchange 2010 (10.0.0.10), TMG (10.0.0.3), основной шлюз с RRAS (10.0.0.1).
450 4.7.1 Client host rejected: cannot find your hostname получаю на внешний IP RRAS.

Перенаправление почты через TMG получится только с установкой Edge роли? Я так понимаю, Exchange направляет почту через RRAS.

Анонимный комментирует...

PTR запись только под один домен. Проблема.

Алексей Богомолов (Alexx) комментирует...

Можно и через Edge, а можно просто сделать для Exch`a дефолтным шлюзом TMG (или прописать маршрут) и на TMG настроить правило проброса (SMTP).
Зачем вам RRAS в этой схеме? Или у TMG прямого выхода в интернет?

Анонимный комментирует...

на RRAS записи под mail.firma1.ru
на TMG записи под mail.firma2.ru
типа A, MX, PTR
DNS внешний

Анонимный комментирует...

На RRAS висит доступ к лесу. Настраивали до меня. TMG поднял недавно. Он в корне домена с почтой, IP телефонией и тд.

Ставлю дефолтным шлюзом на EXchange ip TMG и у всех Outlook просит пароль при запуске. Видимо Exchange теряет доступ к AD.

Алексей Богомолов (Alexx) комментирует...

Если нельзя сделать несоклько PTR, то предлагаю сделать одну А-запись и несоклько МХ-записей, указывающих на одну А. Думаю что это решит вашу проблему.

Анонимный комментирует...

Прописал на Exchange основной шлюз с ip TMG, добавил в "дополнительно" шлюз с ip RRAS.

Во внешний DNS добавил домены. Затем в каждом прописал A и MX запись с внешнем IP TMG, в соответствии с именем домена. Как предлагалось.

Спасибо!

Анонимный комментирует...

Да! PTR запись сделал на основной домен компании. Вроде с него все заработало. Как поведут себя остальные - буду тестить. Если будут ошибки, то вижу только вариант с кучей сетевых карт на TMG для индивидуалных PTR. И это как-то не радует... скорее всего, я что-то недопонимаю :)

Анонимный комментирует...

Добрый день!

А есть ли решение проблемы "*.ru = *.local" в случае если внешний DNS расположен на том же сервере что и *.local ?

Заранее спасибо за ответ.

slepnoga комментирует...

мдя, жаль, но split gorizont на MS DNS до сих пор через одно место ;(
При этом бинд умеет тоже самое спопкон веку; поэтому на шлюзе он обычно и стоит, являясь внешним DNS. Внутри конечно MS для SD

Unknown комментирует...

Здравствуйте, мой провайдер beeline отказывается прописать PTR запись, что в этом случае делать?

Алексей Богомолов (Alexx) комментирует...

менять провайдера, к сожалению больше ни как...

Анонимный комментирует...

добрый день.
Алексей, подскажите, имеется exchange 2013, все настроено, виртуальные каталоги имеют как external так и internal адреса, проблема в том, что внутри все работает на ура, а вот подключая клиента снаружи он цепляется без ошибок, но потом, не проходит синхронизация папок и OAB. если выставить в internal путях также domain.com, тогда начинает все работать снаружи, но не работает внутри) уже не знаю что делать. и вот теперь думаю может есть какой-то способ применить данную статью, чтобы внутренние клиенты также понимали что такое mail.domian.com. если сталкивались с таким, буду признателен за любую подсказку. заранее спасибо.

Анонимный комментирует...

Добрый день Алексей! У нас проблема такая:
Есть сайт www.test.ru и есть внутренний выделенный корневой домен с именем test.ru и его дочерний main.test.ru .Проблема в следующем: из локального домена набирая в браузере просто строчку http://test.ru сайт не работает, только при условии ввода www.test.ru.
Вопрос:
Что здесь можно предпринять ?
Спасибо!

Алексей Богомолов (Alexx) комментирует...

фактически ни чего, т.к. test.ru для вашего АД домена это папка верхнего уровня и имя test должено резолвиться в одни из контроллеров домена

Unknown комментирует...

Добрый день! Алексей, есть одна задача - в ходе решения наткнулся на вашу статью.
Есть локальный домен name.ru (знаю, что лучше таких имен не давать - сделано до меня), и есть сайт name.ru, так вот с локальной сети нельзя открыть домен - обращение идет на локальный DC - на котором конечно же нет никакого сайта.
ЧТО СДЕЛАЛ:
по вашему примеру настроил делегирование www на внешний ip + создал запись A для имя www с внешним ip. Пока не помогло, подскажите советом как сделать так, чтобы сайт можно было открыть с локальной сети домена name.ru ?

Алексей Богомолов (Alexx) комментирует...

Добрый день, Александр. К сожалению чудес не бывает, и если у вас имя name.ru = корневому домену, то это имя должно резолвится в один из контроллеров домена, в противном случае все сломается вообще. Как выход из ситуации - научить пользователей из локальной сети ходит на сайт не по http://name,ru, а по http://www.name.ru, при этом в DNS A-запись www.name.RU = IP внешнего сайта. В таком случае все должно работать.

Анонимный комментирует...

Такой вопрос, а после такой настройки ДНС, в самом эксчендже , нужно ли прописывать разные внешние и внутренние урлы, или нет.

Алексей Богомолов (Alexx) комментирует...

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

Анонимный комментирует...

Алексей а не посоветуете что делать в такой ситуации:
внутри домен .loc снаружи .ru При попытке настроить outlook anywhere outlook авторизуется с именем user@domen.ru. И приходиться вручную указывать что нужно использовать учетку domen.loc\user так как контроллер домена авторизует пользователей из домена domen.loc. Можно как-то побороть?

Анонимный комментирует...

Присоединяюсь к предыдущему вопросу.

Анонимный комментирует...

Доброго времени суток! Столкнулся с вышеописанной ситуацией. Сделал все аналогично вашей инструкции. Но к сожалению не получилось то ли лыжи не едут то ли я не такой :). Дело в том что есть домен domain.local и соответственно domain.ru где висит сайт. В сети поднято два домена с разными подсетями, между собой связаны по VPN с одной стороны 1,1 с другой 2,1 на обоих концах DNS. На стороне 2,1 поднят почтовый сервер. При попытки создания зоны domain.ru и прописывании по вашей инструкции ни как не хочет заводиться внешний domain.ru почтарь при этом начинает отзываться на mail.domain.ru. Перепробовал множество вариантов но так и не смог добиться работы. Не могли бы подсказать что я еще не так сделал?

Unknown комментирует...

у меня подобная проблема, но только с сертификатами. Получил сертификат на внешний домен, xxxxxx.ru, mail.xxxxxx.ru, autodiscover.xxxxxx.ru, установил его на exchange 2013, точнее через exchange он установился на IIS. Извне пользователи outlook спокойно подключаются, но внутренний домен xxx.lan, сервер hhh.xxx.lan, outlook внутри этой сети ругается что в сертификате нет записи hhh.xxx.lan, 2 разных сертификата установить не получается, добавить внутренний домен во внешний сертификат тоже нельзя. прописал CNAME как в статье, не помогло, outlook упорно лезет на hhh.xxx.lan

Алексей Богомолов (Alexx) комментирует...

Outlook упорно лезет скорее всего на autodiscover, проверьте, что все сервисы Вы перенесли на имя mail.xxxx.ru
get-AutodiscoverVirtualDirectory
get-ClientAccessServer
get-webservicesvirtualdirectory
get-oabvirtualdirectory
get-owavirtualdirectory
get-ecpvirtualdirectory
get-ActiveSyncVirtualDirectory
Чтобы поменять:
For internal URLs:
$urlpath = Read-Host "Type internal Client Access FQDN starting with http:// or https://"
Set-ClientAccessServer –Identity * –AutodiscoverServiceInternalUri “$urlpath/autodiscover/autodiscover.xml”
Set-webservicesvirtualdirectory –Identity * –internalurl “$urlpath/ews/exchange.asmx”
Set-oabvirtualdirectory –Identity * –internalurl “$urlpath/oab”
Set-owavirtualdirectory –Identity * –internalurl “$urlpath/owa”
Set-ecpvirtualdirectory –Identity * –internalurl “$urlpath/ecp”
Set-ActiveSyncVirtualDirectory -Identity * -InternalUrl "$urlpath/Microsoft-Server-ActiveSync"
External URLs:
Set-ClientAccessServer –Identity * –AutodiscoverServiceExternalUri “$urlpath/autodiscover/autodiscover.xml”
Set-webservicesvirtualdirectory –Identity * -ExternalUrl “$urlpath/ews/exchange.asmx”
Set-oabvirtualdirectory –Identity * –ExternalUrl “$urlpath/oab”
Set-owavirtualdirectory –Identity * –ExternalUrl “$urlpath/owa”
Set-ecpvirtualdirectory –Identity * –ExternalUrl “$urlpath/ecp”
Set-ActiveSyncVirtualDirectory -Identity * -ExternalUrl "$urlpath/Microsoft-Server-ActiveSync"

MeJustMe комментирует...

Добрый вечер, Алексей. Часто читаю ваши посты по теме Exchange -по ним, собственно, и настраивал. Но вот теперь такой вопрос возник: в ноября, кажется, сертификаты на domain.local больше выдаваться не будут. А у нашего Exchange и внешний есть .ru и внутренний .local. И предыдущий сертификат нам выдавали на оба и всё работало. Теперь продлеваем его - приходит сертификат только на mail.domail.ru (.local нету), соответственно, начинается ругань у пользователей как Outlook, так и OWA. Как нам быть ?

Алексей Богомолов (Alexx) комментирует...

Тут два варианта. 1 - на Exch`e сделать свой собственный сертификат (через локальный центр сертификации, если есть) , а купленный оставить только на шлюзе для внешних подключений. 2. Привести все URL адреса к общему знаменателю, т.е. InternalURL и ExternalURL сделать mail.domain.ru + создать соответствующие записи в локальном DNS, чтобы локальные пользователи не делали петлю через шлюз.

goldsmith комментирует...

Алекс, подскажите пжлсто. и после этой настройки Outlook можно будет прописать внешний домен и все будет работать, внутри т.е. не будет петли?

Алексей Богомолов (Alexx) комментирует...

Должно быть так. Но тут ещё есть такая штука, как настройки proxy-сервера в IE (именно ими пользуется Outlook). Надо проверять, что внешнее имя там открывается как локальный ресурс и веб-трафик не идет через шлюз (например TMG)

goldsmith комментирует...

т.е. надо будет на проксе еще завернуть с mail.domain.com на mail.domain.local ?

Алексей Богомолов (Alexx) комментирует...

нет, на проксе вообще ни чего делать не надо, на быть уверенным, что клиент, когда делает веб-запрос на mail.domain.com НЕ делает его через прокси сервер (настройки Internet Explorer`a надо крутить)

Анонимный комментирует...

Здравствуйте Алексей, такой вопрос. Имеем свой почтовый сервер - mail.123.ru. Соответственно юзеры отовсюду ходят на него по ссылке https://mail.123.ru. Все бы хорошо пока инет не ляжет. Внешние юзеры при этом понятно в пролете, а вот внутренние тоже стучатся по этой ссылке и не могут попасть естественно на почту. Как бы их перенаправлять на почтовик при отключенном инете? Проблема еще вот в чем, на имени mail.123.ru есть правильный сертификат, а вот при входе на почтовик по локальной ссылке https://192.168.55.2 получаем ругань на сертификат в браузере, хотя почта и работает.

Плюсом, еще одна проблема. Есть удаленные клиенты, сидящие через VPN. Дело в том что VPN клиент прописывает автоматом наш локальный DNS из нашей внутреней сети вместо своего провайдерского. И все имена сайтов при серфинге с включенным VPN клиентом резолвятся через него. Таким образом, если я правильно понял вашу статью, они тоже будут постоянно стучаться по локальному адресу https://192.168.55.2 вместо https://mail.123.ru

Alexey Bogomolov комментирует...

На мой взгляд, Вам нужно в локальном DNS просто завести зону 123.ru и создать там А-запись mail.123.ru=192.168.55.2. В результате все внутренние и VPN пользователи будут резолвить имя в локальный IP и ходить на прямую. Только есть нюанс - надо в настройках Internet Explorer добавить mail.123.ru в зону Local Intranet, или в настройках прокси добавить его в исключения, чтобы не ходить на него через проксю.
! Если так сделаете, то ваш DNS будет "отвечать" за зону 123.ru, соответственно если снаружи в ней есть другие записи А, CNAME и т.п., их нужно повторить у Вас.

Андрей комментирует...

Добрый день.
Пытаюсь настроить по вашему сценарию. Никак не могу разобраться.
Если я правильно понял, то:
1. На локально DNS сервере, где основная зона domain.local добавляем доп зону domain.ru.
2. В основной зоне внешнего DNS сервера, где основная зона domain.ru добавляем CNAME: mail.domain.com->mail.domain.local?
Итого всем пользователям видно, что сервер почты внутри имеет вид mail.domain.com, но им это без надобности, а пользователи изнутри не уходят во внешнюю сеть, а по CNAME сразу уходят на локальный сервер?

Отправить комментарий