Регистрация домена .wiki — Зарегистрировать доменное имя .wiki

Политика была изменена Советом Директоров ICANN 7-го ноября 2008 года и вступила в силу 15-го марта 2009 года. Ознакомьтесь с новой версией Политики.

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

1. Убедитесь в корректности указанного адреса электронной почты для административного контакта (admin) в базе данных Whois для Вашего домена .wiki. При осуществлении перемещения домена, оба регистратора будут использовать этот адрес электронной почты для пересылки важной информации о производимом трансфере. Если электронный адрес является некорректным, свяжитесь со своим текущим регистратором для его исправления.
2. Разблокируйте Ваше доменное имя .wiki cpr144449003101 у текущего регистратора до начала перемещения.
3. Получите код авторизации (также известный как EPP код или код трасфера) у Вашего текущего регистратора, если это необходимо. Некоторые расширения доменных имен, как правило национальные домены верхнего уровня (ccTLD), не требуют такого кода авторизации.
4. Дайте разрешение на начало перемещения доменного имени .wiki

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

Домен оплачен, но не работает | Вопросы-ответы на Wiki

Статья актуальна для следующих ситуаций:

В системе DNS существует ситуация, когда какой либо сервер кеширует данные и состояние домена на определенный период, заданный TTL (time-to-live) или же в рамках самого сервера, после чего информация обновляется. Максимальный срок кеширования может составлять до 72 часов. С подобным кешированием можно столкнуться, когда были изменены NS сервера, A (Ip на который направлен домен) или другие записи, а также после регистрации или восстановления домена.

Принцип работы системы доменных имён в интернете:

До регистрации доменного имени Вы вводите доменное имя example.com на вашем устройстве. Происходят следующие операции:

1. Ваше устройство отправляет запрос на DNS-сервер интернет-провайдера.
2. DNS-сервер интернет-провайдера отправляет запрос на DNS-сервер доменной зоны (в данном случае это DNS сервер .COM).
3. DNS-сервер доменой зоны отвечает DNS-серверу интернет-провайдера, что домен не существует.
4. DNS-сервер интернет-провайдера отвечает вашему устройству, что домен не существует.
5. DNS-сервер сохраняет эту информацию у себя, на случай дальнейшего использования (период хранения этой информации довольно продолжительный и может занимать несколько часов).

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

1. Ваше устройство отправляет запрос на DNS-сервер интернет-провайдера.
2. DNS-сервер интернет-провайдера отвечает вашему устройству, что домен не существует.
   Обратите внимание: DNS-сервер интернет-провайдера теперь не отсылает запрос DNS-серверу .COM, который уже знает про существование домена example.com. Это связано с тем, что DNS-сервер интернет-провайдера запомнил, что такого домена нет, и помнить он это будет от 1 до 24 часов.

Аналогичная ситуация происходит при изменении доменных записей, но в отличие от предыдущей — ответ от DNS-серверов доменной зоны (.COM или другие) приходит с указанием сервера, на котором размещаются доменные записи запрошенного адреса, чаще всего это NS сервера провайдера. В таком случае процедура получения записей для домена example.com

1. Ваше устройство отправляет запрос на DNS-сервер интернет-провайдера.
2. DNS-сервер интернет-провайдера отправляет запрос на DNS-сервер доменной зоны (в данном случае это DNS сервер .COM).
3. DNS-сервер доменой зоны отвечает DNS-серверу интернет-провайдера, что данные домена размещены на следующих NS.
4. DNS-сервер интернет провайдера производит запрос к NS серверам, на которые указал DNS сервер доменной зоны.
5. DNS-сервер интернет-провайдера получает данные домена и передает на Ваше устройство.
6. DNS-сервер интернет-провайдера сохраняет эту информацию у себя, для дальнейшего использования (период хранения этой информации обычно равен значению TTL записи).

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

Российская «Википедия» борется за домены | Статьи

Владелец свободной онлайн-энциклопедии, американская некоммерческая организация Wikimedia Foundation, регистрирует в России товарный знак «Википедия». Как рассказал «Известиям» исполнительный директор российского представительства организации (НП «Викимедия.Ру») Станислав Козловский, это позволит защитить бренд от недобросовестного использования и получить контроль над находящимися сейчас в чужих руках доменами wikipedia.ru и «википедия.рф».

— Система управления сайтом «Википедии» и ее контент — бесплатные и свободные. Но не имеющие отношения к нашему проекту люди создавали собственные сайты и называли их «Википедией», — поясняет Козловский. — В результате размывается бренд. У некоторых таких сайтов контент платный, и это, по сути, компрометирует идею свободной энциклопедии. Было принято решение зарегистрировать бренд, чтобы его никто не смог использовать для целей, не связанных с интересами сообщества.

Русскоязычная версия «Википедии» размещается по адресу ru.wikipedia.org. Домен wikipedia.ru был в 2004 году — через три года после старта англоязычной энциклопедии — зарегистрирован людьми, не имеющими отношения к международному проекту. По словам Козловского, там вначале размещалась еще одна свободная энциклопедия.

— Мы владельцу сказали, что так делать нехорошо. Он к нам прислушался. Вначале ресурс был переименован в «ВикиЗнания», а затем домен был перепродан киберсквоттерам. Сейчас там какая-то реклама, — вспоминает Козловский.

Во время старта открытой регистрации доменов в зоне «.рф» в ноябре 2010 года «Викимедия.Ру» пыталась получить доменное имя «википедия.рф». Но этого сделать не удалось.

— Мы тогда подали несколько заявок — на «википедия.рф», «викиновости.рф», «викисклад.рф» и т.д. Некоторые заявки были удовлетворены. А вот «википедия.рф» попала на аукцион и в результате досталась кому-то другому, — рассказывает Козловский.

Представитель компании-регистратора Ru-Center Андрей Воробьев пояснил «Известиям», что поскольку «Викимедия.Ру» в 2010 году не владела товарным знаком «Википедия», эта организация не могла подать заявку на соответствующий домен до начала их свободной регистрации. Когда же она началась, на «википедия.рф» нашлось несколько претендентов — а в таких случаях назначается аукцион.

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

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

Процесс регистрации товарного знака в России обычно длится около полутора лет. После этого, по мнению доменного брокера Павла Гросс-Днепрова, «Викимедия.Ру» лучше попробовать договориться о передачи доменов во внесудебном порядке.

— В случае регистрации торговой марки в России можно будет подать в суд на владельцев wikipedia.ru и «википедия.рф». Но думаю, что владельцы смогут договориться с «Википедией», — говорит он.

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

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

Администраторы wikipedia.ru и «википедия.рф» не ответили на запросы «Известий».

Руководство по настройке интеграции с Active Directory [Wiki]

Один домен

Общая информация

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

Интеграционное решение ориентировано на компоненты Active Directory:

1. Служба федерации Active Directory (AD FS).

2. Служба каталогов Active Directory; доступ к ней осуществляется по LDAP.

Службы федерации Active Directory используются для аутентификации пользователей. AD FS позволяет использовать технологию единого входа (SSO). В нашем случае важно, что AD FS использует Встроенную Аутентификацию Windows, что позволяет входить в систему без ввода логина и пароля (требует настройки в

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

Важно!

Установка службы федерации Active Directory (в домене клиента)

Важно!

Windows Server 2008R2

2. Запустите файл установки службы федерации Active Directory 2.0. Скачать можете здесь.
   Откроется мастер установки AD FS 2.0 → «Далее».

3. На шаге «Лицензионное соглашение» поставить чек-бокс «Я принимаю условия лицензионного соглашения

   » → «Далее».

4. На шаге «Роль сервера» выберите роль «Сервер федерации» → «Далее».

5. На шаге «Установка необходимого программного обеспечения» мастер установки автоматически проверит наличие необходимых для службы федерации компонентов. → «Далее».

6. После завершения работы мастера поставьте чек-бокс «Когда мастер закроется, запустить оснастку управления AD FS 2.0» для дальнейшей настройки службы. → «Готово».

Windows Server 2012

1. Откройте «Диспетчер серверов».

2. Управление → Добавить роли и компоненты

3. На шаге «Перед началом работы» (если такой появится) → «Далее».

4. На шаге «Тип установки» выберите «Установка ролей и компонентов» → «Далее».

5. На шаге «Выбор сервера» выберите сервер, на котором будет установлена служба федерации Active Directory → «Далее».

6. На шаге «Роли сервера» поставьте чек-бокс напротив роли «Службы федерации Active Directory».
   Мастер добавления ролей и компонентов предложит добавить компоненты, необходимые для Службы федерации Active Directory. → «Добавить компоненты» → «Далее»

7. Шаг «Компоненты» остаётся без изменений → «Далее».

8. На шаге «Службы федерации Active Directory (AD FS)» → «Далее».

9. В промежуточном шаге «Службы ролей» должен быть активен чек-бокс «Служба федерации» → «Далее».

10. В промежуточном шаге «Службы ролей» ничего не меняйте → «Далее».

11. На шаге «Подтверждение» → «Установить».

12. После установки необходимых компонентов закройте мастер установки.

Начальная настройка AD FS

Этап 1. В диспетчере служб IIS

Установите сертификат в Доверенные корневые центры сертификации через сервер ADFS или на сервере IIS.

Если IIS установлен, то сделать это можно так:

1. Запустите Диспетчер служб IIS.

2. Выберите локальный сервер.

3. На начальной странице локального сервера → меню «Сертификаты сервера».

4. На странице «Сертификаты сервера»:

   1. добавьте сертификат:

   2. В поле «Понятное имя сертификата» впишите имя, например: ADFS_Certificate

   3. В разделе «Выбрать хранилище сертификата для нового сертификата:» → «Личный».

   4. Закройте Диспетчер служб IIS.

Этап 2. Настройка на сервере

Windows Server 2008R2: После установки AD FS 2.0 оснастка управления должна была запуститься автоматически.
Если этого не произошло, запустите оснастку вручную: Пуск → Все программы → Администрирование → Управление AD FS 2.0.

Windows Server 2012: В диспетчере серверов нажмите на значок уведомлений (флаг с восклицательным знаком в треугольнике) → в окне «Конфигурация после развертывания» клик на «Запустить оснастку управления AD FS».

1. В открывшейся оснастке → «Мастер настройки сервера федерации AD FS».

2. На шаге «Добро пожаловать!» включите чек-бокс «Создать службу федерации» → «Далее».

3. На шаге «Выберите тип развертывания» → «Изолированный сервер федерации» → «Далее».

4. На шаге «Имя службы федерации» можно выбрать SSL-сертификат для веб-сайта.
   Т.к. ранее при настройках создавался только один сертификат (ADFS_Certificate), он подставится по умолчанию, без права выбора сертификатов.
   Если сертификатов больше, выберите нужный.
   → «Далее».

5. На шаге «Сводка» мастер настройки покажет, какие параметры будут настроены для служб AD FS. → «Далее» → «Закрыть»
   Если оснастка AD FS закрылась, запустите её заново.

6. В оснастке управления AD FS клик по ссылке «Обязательно: добавьте доверенную проверяющую сторону» → «Запустить».

7. На шаге «Выберите источник данных» включите чек-бокс «Ввод данных о проверяющей стороне вручную» → «Далее».

8. На шаге «Укажите отображаемое имя», в поле «Отображаемое имя:» введите имя для проверяющей стороны (например: advanta), и, при необходимости, любые примечания. → «Далее».

9. На шаге «Выберите профиль» установите значение напротив пункта «Профиль AD FS». → «Далее».

10. На шаге «Настройте сертификат» можно указать дополнительный сертификат шифрования маркера, если это необходимо. → «Далее».

11. На шаге «Настройте URL-адрес»:

12. На шаге «Настройте идентификаторы» в поле «Идентификатор отношения доверия проверяющей стороны:» введите адрес вашей системы (например: https://your.system.ru/streamline). → «Далее».

13. На шаге «Выберите правила авторизации выдачи» → «Разрешить доступ к этой проверяющей стороне всем пользователям».
    Или, после настройки мастера, настройте конкретных пользователей. → «Далее».

14. На шаге «Готовность для добавления отношения доверия» можете проверить все настройки и нажмите «Далее».

15. На шаге «Готово» включите чек-бокс «Открыть диалоговое окно «Изменение правил утверждений» для этого отношения доверия проверяющей стороны после закрытия мастера» → «Закрыть».

16. Откроется окно «Изменение правил утверждений для advanta (отображаемое имя, которое вы ввели ранее)».

    1. На вкладке «Правило Преобразования выдачи» → «Добавить правило…».

    2. В мастере добавления правила преобразования утверждения:

       1. на шаге «Выберите тип правила», выберите шаблон правила утверждения: «Отправка утверждений с помощью настраиваемого правила». → «Далее».

       2. на шаге «Настройте правило утверждения»:

17. После этого снова появится окно «Изменение правил утверждений для advanta» → «ОК».

Настройка службы каталогов Active Directory на сервере с установленной Адвантой (сервер IIS)

Прежде чем приступать к настройкам, проверьте наличие/добавьте на сервер приложения файл ADFS_Login.aspx в корень приложения.

Службы каталогов AD должны быть доступны для сервера IIS по LDAP. Для системы «Адванта» настройка службы выполняется в конфигурационных файлах, находящимися в папке с веб-контентом системы.

Настройки интеграции со службой AD FS

Только для Windows Server 2008R2

1. На сервере службы федерации в IIS перейти к сайту AD FS: Сайты –> Default Web Site –> AD FS → ls . Данный пункт актуален только для старых версий AD FS, начиная с версии службы федерации 3.0 в Windows Server 2012, IIS на сервер со службой федерации устанавливать необходимости нет.

2. На странице сайта раздел «Проверка подлинности» → включить компонент «Проверка подлинности Windows».

3. Перейти в дополнительные параметры данного компонента → в настройке «Расширенная защита» установить «Выключена».

для настройки ADFS нужно указать два параметра в client.config в секции <appSettings>:

<add key="AdfsRealm" value="https://system.a2test.local/streamline" />

<add key="AdfsIssuer" value="https://adfs.a2test.local" />

Также есть два дополнительных параметра:

Настройка LDAP в файле client.config

В главном разделе <configuration> после закрывающего тега </configSections> добавить следующее:

<ldapService ldapPath="LDAP://адрес сервера с AD FS/" baseDN="база поиска объектов в AD">
  <authenticationTypes>
     <add authenticationType="Secure" />
     <add authenticationType="Signing" />
     <add authenticationType="Sealing" />
   </authenticationTypes>
</ldapService>

В раздел <configSections> добавить тег:

<section name="ldapService" type="Config.LDAPConfigurationSection, smcorelib" />

Безопасность

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

Важно использовать заверенный сертификат для веб-сервисов AD FS (этот сертификат устанавливается в IIS). Это не тот сертификат, который используется для подписи и шифрования утверждений.

Настройка рабочих станций

1. Установить сертификат в Доверительные корневые центры сертификации.

2. Добавить систему в надежные сайты (Свойства браузера → Безопасность → Надежные сайты → Сайты → Добавить сайт https://имя системы в сертификате безопасности → Закрыть).

Настройка интеграции с AD в системе (AD FS)

После выполнения всех настроек, описанных выше, активируйте синхронизацию с AD в системе ADVANTA.

Для этого под учетными данными администратора системы:

1. перейти в пункт меню «Администрирование» → «Общие настройки» → «Настойки Active Directory»;

2. в портлете «Настройки связи с Active Directory (с использованием службы ADFS)» установить чек-бокс в «Разрешить проверку учетных данных в Active Directory (с использованием службы ADFS)».

Далее, чтобы в систему можно было заходить под доменными учетными данными пользователей, нужно загрузить этих пользователей из AD. Здесь два варианта:

1. Загрузка новых пользователей из AD в систему, в настройках Active Directory, после активации синхронизации, появится кнопка «Загрузить из Active Directory». С помощью этой кнопки можно загрузить всех необходимых пользователей в систему. В этом случае в системе создаются новые пользователи с привязкой к доменной учетной записи.

2. Привязка уже существующего пользователя системы к AD. Для этого, под учетными данными администратора системы, нужно перейти в пункт меню «Команда в лицах» — «Список». Выбрать необходимого пользователя из списка и перейти в карточку редактирования этого пользователя, нажав левой кнопкой мыши по ссылке данного пользователя. В портлете «Учетная запись Active Directory» необходимо нажать кнопку-ссылку «Задать», где можно будет выбрать необходимую доменную учетную запись для привязки пользователя.

Если сервер с системой не включен в домен, при нажатии кнопки «Загрузить из Active Directory» возникнет ошибка подключения к Active Directory. В этом случае необходимо нажать кнопку «учетная запись» и ввести в появившемся окне логин и пароль доменного пользователя. Логин должен вводиться в формате domain\user или [email protected].

Мультидоменность

ВНИМАНИЕ!

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

Мультидоменность работает по протоколу NTLM.

Настройки на сервере IIS

1. Для авторизации на сервере через AD необходимо установить службу «Windows – проверка подлинности» (Windows Authentication).

Windows Server 2008 R2:

1. Открыть диспетчер сервера.

2. Перейти в пункт «Роли».

3. На вкладке «Службы ролей» нажать на кнопку «Добавить службы ролей».

4. В пункте «Безопасность» включить пункт «Windows — проверка подлинности».

5. Нажать «Далее».

6. «Установить».

Windows Server 2012:

1. Открыть диспетчер серверов.

2. «Управление» → «Добавить роли и компоненты».

3. На шаге «Перед началом работы» нажать «Далее».

4. На шаге «Тип установки» выбрать «Установка ролей или компонентов» и нажать «Далее».

5. На шаге «Выбор сервера» выбрать текущий сервер.

6. Перейти в пункт «Роль веб-сервера(IIS)» → «Службы ролей».

7. В пункте «Безопасность» включить пункт «проверка подлинности Windows».

8. Нажать «Далее», затем «Установить».

После установки службы «Windows — проверка подлинности» откройте Диспетчер служб IIS:

1. Перейти в раздел «Сайты» → Default Web Site (сайт с установленной системой).

2. Затем перейти в подраздел «Проверка подлинности» (в области просмотра возможностей).

3. Включить компонент «Проверка подлинности Windows».

4. Включить компонент «Анонимная проверка подлинности».

5. Все остальные компоненты выключить, если они включены.

2. Настройка client.config:

где:

Для добавления нескольких доменов нужно добавить соответствующее количество строк, начинающихся с тега «add name…».

Ссылка на пример файла Client.config с настройками интеграции под NTLM

Настройка рабочих станций

Добавить систему в раздел Местная интрасеть (Свойства браузера → Безопасность → Местная интрасеть → Сайты → Добавить сайт с адресом системы → Закрыть).

Настройка интеграции с AD в системе (NTLM)

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

1. перейти в пункт меню «Администрирование» → «Общие настройки» → «Настойки Active Directory»;

2. в портлете «Настройки связи с Active Directory (с использованием NTLM)» поставить чек-бокс напротив «Разрешить проверку учетных данных в Active Directory (с использованием NTLM)» .

Далее, чтобы пользователи могли заходить в систему под своими доменными учетными записями, их нужно загрузить в систему из AD. Здесь два варианта:

1. Загрузка новых пользователей из AD в систему, в настройках Active Directory, после активации синхронизации, появится кнопка «Загрузить из Active Directory». С помощью этой кнопки можно загрузить всех необходимых пользователей в систему. В этом случае в системе создаются новые пользователи с привязкой к доменной учетной записи.

2. Привязка уже существующего пользователя системы к AD. Для этого, под учетными данными администратора системы, нужно перейти в пункт меню «Команда в лицах» — «Список». Выбрать необходимого пользователя из списка и перейти в карточку редактирования этого пользователя, нажав левой кнопкой мыши по ссылке данного пользователя. В портлете «Учетная запись Active Directory» необходимо нажать кнопку-ссылку «Задать», где можно будет выбрать необходимую доменную учетную запись для привязки пользователя.

Прокси-серверы DNS-over-TLS и DNS-over-HTTPS для шифрования DNS-запросов – Keenetic

Как известно, протокол DNS (Domain Name System, система доменных имён) не шифрует запросы и данные передаются в открытом виде. DNS-трафик уязвим перед злоумышленниками, т.к. появляется возможность «подслушать» канал связи и перехватить незащищенные персональные данные. Интернет-провайдеры могут осуществлять наблюдение за трафиком и собирать данные о том, какие сайты вы посещаете.

Для безопасности DNS-трафика были реализованы специальные протоколы DNS over TLS (DNS поверх TLS, DoT, RFC7858) и DNS over HTTPS (DNS поверх HTTPS, DoH, RFC8484). Их основная задача — зашифровать DNS-трафик для предотвращения перехвата и обеспечения дополнительной конфиденциальности и безопасности. В данной статье мы не будем подробно останавливаться на теории. Информацию о том как работают DoT и DoH вы найдете на следующих страницах:

Список публичных DNS-сервисов с поддержкой DoT/DoH:

Начиная с версии KeeneticOS 3.00 была добавлена поддержка протоколов DNS over TLS и DNS over HTTPS. Включив один из них, DNS-трафик от роутера будет передаваться в зашифрованном виде через Интернет.

NOTE: Важно! При включении протокола DoT/DoH все DNS-запросы будут направляться на указанный при настройке адрес сервера. Полученные ранее DNS-сервера от вашего интернет-провайдера и прописанные вручную DNS-сервера использоваться не будут.

Если включен один из интернет-фильтров AdGuard DNS, Яндекс.DNS или SkyDNS, то все DNS-запросы будут направляться на указанный адрес сервиса с назначенным профилем зарегистрированному устройству в домашней сети. При назначении профиля «Без фильтрации» все запросы будет направляться через включенные протоколы DoT/DoH.

Если вы хотите пользоваться только DNS over TLS, то достаточно будет удалить компонент «DNS-over-HTTPS proxy». Аналогично и с DNS over HTTPS, нужно удалить компонент «DNS-over-TLS».

Покажем пример настройки через веб-конфигуратор. Будем использовать бесплатный DNS-сервис компании Cloudflare, поддерживающий работу по протоколам DoT/DoH.

Для работы протокола DoT/DoH нужно в интернет-центре предварительно установить соответствующий компонент системы «Прокси-сервер DNS-over-TLS» или «Прокси-сервер DNS-over-HTTPS». Сделать это можно на странице «Общие настройки» в разделе «Обновления и компоненты», нажав на «Изменить набор компонентов».

Для дальнейшей настройки перейдите на страницу веб-конфигуратора «Интернет-фильтр».

DNS-over-TLS

Нажмите кнопку «Добавить сервер DNS-over-TLS». Появятся поля для заполнения определенных параметров. Укажите Адрес сервера DNS (в нашем примере это 1.1.1.1 и 1.0.0.1), Доменное имя TLS (в нашем примере это cloudflare-dns.com) и при необходимости интерфейс подключения (по умолчанию установлено значение «Любое»).

Например:

NOTE: Важно! Для стабильной работы DNS-резолвинга необходимо указывать несколько DoT/DoH-серверов одновременно, и лучше от разных DNS-служб. Например:

DNS-over-HTTPS

Нажмите кнопку «Добавить сервер DNS-over-HTTPS». Появятся поля для заполнения определенных параметров. Укажите имя сервера DNS, формат, DNS message и при необходимости укажите интерфейс подключения (по умолчанию установлено значение «Любое»). В нашем примере добавлены серверы https://cloudflare-dns.com/dns-query и https://dns.comss.one/dns-query

Например:

TIP: Примечание: Если в настройках роутера одновременно указаны несколько серверов DNS over TLS и DNS over HTTPS, приоритет будет у тех серверов, кто быстрее отвечает на DNS-запросы.
В Keenetic можно использовать не более 8 серверов DoT/DoH.

Проверка

Приведем пример проверки использования шифрования DNS-запросов для службы Cloudflare. Перейдите на страницу https://www.cloudflare.com/ssl/encrypted-sni/
Нажмите «Check My Browser» для запуска проверки.

При корректной настройке DoT/DoH тест должен завершиться успешно для «Secure DNS», «DNSSEC» и «TLS 1.3». Корректный вывод проверки работы DoT/DoH и безопасности браузера зависит от доступности DoT/DoH серверов/адресов в сети провайдера/оператора.

NOTE: Важно! В статье показан пример проверки работы DoT/DoH сервиса Cloudflare. При использовании других DNS-сервисов, проверка на сайте https://www.cloudflare.com/ssl/encrypted-sni/ может не проходить. Не пройдет он и в случае, если в настройках DHCP домашней сети Keenetic были указаны какие-либо адреса DNS. Ведь тогда подключенные к Keenetic устройства будут обращаться напрямую к этим DNS-серверам, а не к Keenetic с настроенными DoT/DoH. 

Для запуска повторного тестирования нажмите «Run the test again».

Если тест нет прошел, возможно ранее были прописаны сторонние DNS-сервера в IP-настройках сетевого адаптера в операционной системе Windows, Linux, macOS. В этом случае все DNS-запросы будут обрабатываться через сторонние DNS и работать DoT/DoH не будет. Удалите ранее указанные адреса сторонних DNS и повторите тест.

Также имейте ввиду, если вы указали несколько DoT/DoH-адресов, от разных сервисов, результат проверки зависит от того, какой сервер в настоящий момент в приоритете. Например, если указан DoH-сервер https://dns.google/dns-query в формате DNS message, то проверку «Secure DNS» он не проходит.

TIP: Совет: Если вы не хотите вручную настраивать работу проколов DoT/DoH, просто включите интернет-фильтр AdGuard DNS или Cloudflare DNS. В этом случае вам не потребуется выполнять дополнительную настройку. При включении AdGuard DNS или Cloudflare DNS автоматически включится поддержка DoT/DoH, но только в том случае если в интернет-центре установлены компоненты системы для поддержки DoT/DoH, иначе интернет-фильтр не будет использовать указанные протоколы шифрования.
Проверить поддержку DoT/DoH можно через интерфейс командной строки (CLI) роутера, выполнив команду show adguard-dns availability или show cloudflare-dns availability

При включенном AdGuard DNS и Cloudflare DNS не проходит проверка состояния работы сервиса на страницах https://adguard.com/ru/test.html и https://1.1.1.1/help
Это связано с тем, что при включенных интернет-фильтрах по умолчанию включается блокировка транзитного DoT/DoH, чтобы избежать утечки DNS-запросов. 

TIP: Примечание: Когда в Keenetic вручную указаны прокси-серверы DoT/DoH и включен один из интернет-фильтров Adguard DNS, Cloudflare DNS, SkyDNS или Яндекс.DNS, то резолвинг внутренних системных доменов и проверка Интернета проходит сначала через DNS-прокси, т.е. через DNS-адреса, которые указаны вручную.

Amazon Web Services (AWS) – Сервисы облачных вычислений

«Все на панель!» или несколько полезных приемов настройки панелей Xwiki / Хабр

В прошлой статье я предложил рассмотреть Xwiki, как бесплатную замену Confluence и заодно пообещал поделиться несколькими советами по настройке.

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

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

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

На текущий момент я планирую подготовить мини цикл из четырех — пяти статей про Xwiki.

В первой статье мы поговорим о простых вещах, которые не отнимут у нас много времени, а именно:

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

Весь материал статьи я проверял в версиях Xwiki 12.10.5 и 13.2 с установленной Demo Flavor. Также в статье подразумевается, что вы обладаете правами администратора.

Оглавление страницы в боковой панели

В админ-панели переходим в раздел Настройки интерфейса -> Мастер панелей и внизу страницы находим ссылку «Перейти к панелям». Ну или просто введите в адресную строку
{ваш домен с Xwiki}/bin/view/Panels/
В разделе «Создать новую панель»
Введите название панели (например, SideTOC} и нажмите кнопку «Создать»
Тип панели оставьте — «View«

Описание — на ваше усмотрение.

В поле Содержимое введите код:

{{velocity}}
{{context document="$services.model.serialize($doc.documentReference)" transformationContext="document"}}
#set ($hasHeaders = [])
#set ($mydoc = $doc.getDocument())
#foreach ($block in $mydoc.getXDOM().getBlocks('class:HeaderBlock', 'DESCENDANT'))
 #set ($discard = $hasHeaders.add($block))
#end

#if($hasHeaders.size()>0)
 #panelheader('Table of Contents')
 {{box cssClass="sidetoc"}}{{toc/}}{{/box}}
#end
{{/context}}
{{/velocity}}

Поясню для тех, кто только начал знакомство с данной Вики.

В Xwiki для автоматизации используется различные средства автоматизации и одно из них Apache Velocity. В данном случае весь код между тегами {{velocity}} {{/velocity}} будет обрабатываться как код на данном языке шаблонов.

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

#if($hasHeaders.size()>0) 
#panelheader('Table of Contents') 
{{box cssClass="sidetoc"}}{{toc/}}{{/box}} 
#end

Предотвращает нас от генерации пустой панели, в случае отсутствия заголовков.

Теперь не обходимо вставить нашу панель в верстку страницы.

Я решил разместить блок слева.

Чтобы сделать также в админ-панели перейдите на страницу Мастер панелей -> вкладка «Список панелей» и просто перетащите панель с названием SideTOC на панель слева (справа).

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

На вкладке «Макет страницы» в поле «ПАНЕЛИ СЛЕВА» (или справа) добавив «Panels.SideTOC».
например, Panels.Applications,Panels.Navigation,Panels.SideTOC

Не забудьте нажать кнопку «Сохранить«.

Выглядеть будет примерно так:

На странице без заголовков блок не будет видно.

Я специально сделал заголовок «Основы» заголовком второго уровня, чтобы показать уровни вложенности.

Возможно вы захотите немного изменить внешний вид панели, тогда вернемся к её редактированию.

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

Перейдите на страницу вашего профиля. Нажмите кнопку «Редактировать«

В разделе «Настройки» найдите пункт «Тип пользователя» и выберите значение : «Продвинутый» (Advanced). Теперь нам точно будет доступен редакторов объектов.

Откройте страницу созданной ранее панели, вы можете найти её на странице списка панелей или просто перейдя по адресу {домен}/bin/view/Panels/SideTOC.

Теперь у кнопки «Редактировать» доступен список с дополнительными вариантами.

Выберите пункт «Объекты«.

В поле «Новый объект» выберите StyleSheetExtension и нажмите кнопку «Добавить«

Xwiki очень функциональна и позволяет поменять css стили практически для любого элемента. В данном случае мы поменяем стиль класса siidetoc, который был указан в макросе {box}.
Введите любое название например sidetoc, а затем CSS код:

.sidetoc {
  border:0px;
  margin:0px;
  padding:0px;
  width:100%;
}
.sidetoc ul {
  padding-left:2px;
  list-style-type:disc;
  font-size:1em;
  padding:0px;
  margin-left:0px;
}
.sidetoc li {
  padding-left: 0px;
  margin-left:5px;
  list-style-type:disc;
}

В поле «Использовать это расширение» обязательно выберите «В этой вики» ,

Не забудьте сохранить страницу.
Проверяем нашу главную.
Теперь панель выглядит немного по другому:

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

Миссия выполнена можем переходить к следующему пункту.

Cвоя панель навигации справа / слева

Предположим, что стандартное меню навигации нас не устраивает и мы хотим сделать отдельную панель для очень важного раздела «Моя любимая пицца».

Для начала создадим сам раздел. Пусть он будет в корневом уровне сайта.

Перейдите на главную страницу и нажмите кнопку «Создать«.

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

Сейчас информация о нашей любимой пицце отображается в разделе «Навигация».

Мы хотим убрать эти страницы из раздела «Навигация» и перенести в свою собственную панель.
Для начала уберем ссылки на пиццу из стандартной панели навигации.

В админ-панели откройте раздел «Настройки интерфейса» — > «Панель навигации».

Перетащите раздел «Моя любимая пицца» в раздел «Исключенные страницы».

Теперь перейдите в соседний раздел «Меню» и нажмите кнопку «Добавить новую запись«.
Введите название панели, например, PizzaMenu.

Удаляем заглушку. Если у вас WYSIWIG редактор нажмите кнопку «Источник» и вставьте следующий код:

{{documentTree root="document:xwiki:Моя любимая пицца.WebHome" compact="true"/}}

Ну или вы можете просто вставить макрос «Дерево страниц» и добиться также настроек.

В поле «root» первая половина значения — document:xwiki: — это особенность структуры адресов Xwiki, Вы со временем разберетесь в тонкостях, а вот вторую часть: «Моя любимая пицца.WebHome», можно легко узнать перейдя на страницу «Моя любимая пицца.WebHome» и открыв внизу вкладку «Информация».

В поле «МЕСТО ОТОБРАЖЕНИЯ МЕНЮ» выберите — «Внутри левой панели«.
В поле «ОБЛАСТЬ ВИДИМОСТИ МЕНЮ» выберите — «Current Wiki«.
Не забудьте сохранить.

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

Перейдите на страницу Админ-панель -> Мастер панелей.
И добавить в левую панель строку: Menu.PizzaMenu.WebHome

Например, вот так:

Сохраняем и наслаждаемся меню (откройте главную страницу чтобы проверить).

Осталось немного навести марафет.

Давайте заменим заголовок панели.

Перейдите на страницу меню. Через админ-панель или просто по адресу:{домен}/bin/view/Menu/PizzaMenu/

Аналогично прошлому разделу откройте редактор объектов.

Разверните «UIExtensionClass» и в тег {{menu}} добавьте:.
Замените значение в «#panelheader(«PizzaMenu»), на то что вам больше по душе. Например так:

Если хотите можете аналогично примеру с оглавлением подредактировать CSS стиль блока (именно для этого мы и добавили).

Создайте объект для настройки стилей и введите:

#PizzaMenu ul.jstree-children{
  padding-left:0px !important;
}

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

Добавляем свои советы в панель подсказок

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

Для этого надо в любом месте создать страницу.

Я создам пустую страницу Tips в разделе Xwiki чтобы она не «мозолила» глаза.

Откройте редактор объектов и добавьте объект расширения интерфейса.

В поле «Extension Point ID» вставьте: «org.xwiki.platform.help.tipsPanel«.
В поле «Extension ID» введите любое название, например, «grammarHelp».
В поле «Extension Scope» выберите «Current Wiki».
В поле «Extension Parameters» введите:

tip = Чтобы воспользоваться исправлением опечатки нажмите Ctrl+ПКМ

Аналогичным образом создайте на странице еще одно расширение. См. скриншот.

Остается только сохранить изменения и дождаться появления советов.

Если честно я хотел добавить еще примеров, но статья итак получилась объемной.

Впереди у нас интеграция с Figma, GitLab, Swagger и кастомные DocumentThree!

Постараюсь не затягивать со следующим материалом.

.wiki — ICANNWiki

.wiki — это активный рДВУ, который был предложен в программе ICANN по новым рДВУ. Дизайн верхнего уровня является оператором реестра для данной строки и был единственным кандидатом.

Top Level Design подали в общей сложности 10 заявок; Компанию возглавляет Рэймонд Кинг, который особенно увлечен вики. ^[1] Предложенное приложение было делегировано в корневую зону 19 февраля 2014 года. ^[2]

Отрывок из заявки

Ниже приводится выдержка из ответа кандидата на вопрос № 18:

«Top Level Design, LLC» цель.wiki gTLD предназначен для создания специального Интернет-пространства для вики-сайтов. Этот TLD будет четко определять вики-сайты среди миллионов других веб-сайтов, населяющих Интернет, и позволит пользователям Интернета легко находить вики-сайты, соответствующие их интересам. Вики-сайты — это растущее явление в Интернете и инновационный, простой в использовании метод создания и представления информации. Они, как правило, открыты и редактируются и часто управляются сообществом; более того, отдельные вики-сайты и вики-платформа находятся в постоянном движении во многом так же, как и Интернет в целом.Вики, как и Интернет в целом, представляют собой хранилища информации, создание ценности которой зависит от каждого отдельного пользователя; они являются точками встречи и революционными способами обмена идеями и знаниями; и они оба должны быть расширены за счет реализации программы ICANN по новым рДВУ и, в частности, ДВУ .wiki. Мы считаем, что .wiki TLD — это интуитивно понятное и необходимое дополнение к коллекции новых gTLD, которые будут добавлены в результате программы New gTLD.

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

Top Level Design, LLC любит вики. Наш генеральный директор активно сотрудничал с изобретателем вики-технологии Уордом Каннингемом и, помимо того, что запустил довольно много вики-сайтов, в настоящее время управляет тремя другими вики-проектами: AboutUs Inc., WikiIndex.com и ICANNWiki.com. Последний зарекомендовал себя как основной источник нейтральной сторонней информации обо всех аспектах и ​​членах сообщества ICANN. Таким образом, мы являемся продуктивными и активными участниками как сообщества ICANN, так и сообщества вики, и наша цель — объединить революционные возможности программы New gTLD с инновационными возможностями обмена знаниями вики. .. .Wiki будет иметь открытую политику регистрации, ориентированную на владельцев вики, которые используют вики как способ создания и распространения информации по конкретному сектору.Мы надеемся привлечь как группы, так и отдельных лиц к разработке вики-страниц об их любимом хобби, деле или другом увлечении. Мы считаем, что термин «вики» и то, что подразумевается под этим понятием, широко понятны, и что среднестатистический пользователь Интернета поймет, что содержание домена .wiki будет в значительной степени заполнено этим новаторским представлением открытой, редактируемой информации ». ^{[ 3]}

Контракт подписан

7 ноября 2013 г. компания Top Level Design получила соглашение о реестре, подписанное ICANN для.wiki после прохождения всех необходимых процессов, необходимых для того, чтобы стать оператором реестра для строки. ^[4]

Делегирование и доступность

.wiki был делегирован в корневую зону DNS 19 февраля 2014 года, что привело к успешной подаче заявки на строку. ^[2]

.wiki имел период восхода с 3 марта 2014 г. по 5 мая 2014 г. Период преждевременного сбора последовал с 8 по 22 мая, и 27 мая TLD стал общедоступным. ^[5]

Список литературы

Давайте сотрудничать дальше.wiki: Посмотрите, кто регистрировал домены .wiki — Domain Name Wire

. В первый день число регистраций .Wiki превысило 3000.

Top Level Design выпустила свое первое новое доменное имя верхнего уровня вчера, когда .wiki попал на полки регистраторов.

Я насчитал 3166 доменов в файле зоны, обработанном прошлой ночью, что является надежным первым днем ​​для нового TLD.

Я проявляю особый интерес к .wiki из-за его уникальной природы, а также из-за моего существующего портфолио доменов.

.Wiki довольно уникален среди новых TLD по нескольким причинам.

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

Во-вторых, это не домен для нареканий, вроде .sucks или .exposed. Однако компании боятся того, что написано в вики, поэтому они хотят контролировать это.

С точки зрения моего собственного портфолио, мне интересно, потому что мне принадлежит около десятка гео-доменов, оканчивающихся на wiki.com. Если .wiki набирает обороты, я считаю, что это хорошо для моих соответствующих доменов somethingwiki.com.

Так как поживает .wiki?

Как и большинство новых TLD до сих пор, был один крупный инвестор, который забрал большой кусок доменов. По моим подсчетам, Innovation HQ зарегистрировала 497 доменов.

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

Кроме того, как и большинство новых TLD, запущенных до сих пор, был один парень, который не знаком с URS. Или просто плевать. Hyper Media Group зарегистрировала realtor.wiki, hyundai.wiki, toyota.wiki и pinterest.wiki, все из которых, вероятно, квалифицируются как киберсквоттинг.

Хотя это был хороший первый день, настоящий ключ к .wiki приходит от использования. Регистрантам домена должно быть легко начать использовать домены с помощью программного обеспечения вики. Это также поможет, если Фонд Викимедиа исполнит его желание и сможет использовать две буквы.wiki, чтобы указать на Википедию.

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

Тем не менее, я бы предпочел, чтобы кто-то создал отличный сайт на соответствующей основе.вики-домены.

.Wiki определенно будет интересно посмотреть. Его будущее будет связано с большим количеством редактирования.

 $ getent hosts  имя_домена 
 

 # chattr + i /etc/resolv.conf
 

 вариантов тайм-аута: 1
 

 опций по единому запросу
 

 домен example.org
 

 $ дрель @  сервер имен  TXT  домен