как узнать ttl dns записи
Что такое TTL в DNS-записях и зачем оно нужно
Старый вопрос, который меня интересовал, о чём напоминает тема на CyberForum.Ru; но со временем все мы становимся опытней и глядя на или вспоминая подобные вопросы невольно улыбаемся ☺. Хотя, по сути, я там дал выдержку из Wikipedia, которая всё объясняет, однако почему-то всё равно возникли вопросы. Ладно, давайте разберёмся.
Управлять DNS-записями домена можно непосредственно через панель управления регистратора (если DNS-серверами домена являются его сервера; по умолчанию); или через панель управления хостинг-провайдера, если регистратор и хостинг-провайдер это поддерживают и в качестве DNS-серверов домена указаны сервера последнего (хостинг-провайдера). Далее я буду опираться на то, что DNS-серверами домена являются сервера регистратора, чтобы не описывать одно и то же дважды. Кстати, некоторые регистраторы не позволяют передать управление доменом третьим лицам (коими являются хостинг-провайдеры); например, Agava.Ru.
Ну так вот, представьте: у вас есть сайт (именно сайт как проект, а не место на сервере), доменное имя которого Example.Com; он находится (хостится) на некотором сервере с IP-адресом 111.111.111.111 ; на всех DNS-серверах лежит соответствующая запись:
Некоторые регистраторы, чтобы не вводить в заблуждение своих клиентов, не знающих что такое TTL, просто не предоставляют доступа к данной записи, а сообщают, что изменения вступят в течение 24 часов; однако некоторые, например Hostinger, предоставляют, но сообщение о вступлении в силу изменений в течение 24-х часов показывают всё равно. О чём это говорит. Правильно — о том, что TTL-запись может попросту игнорироваться другими DNS-серверами.
Вывод
Особой важности TTL-запись не несёт, так как может игнорироваться и основную роль она может сыграть при смене IP-адреса домена: для быстрого вступления в силу изменений. Однако я бы не рекомендовал устанавливать её значение слишком маленьким, так как если вы позже не установите значение побольше, то те DNS-сервера, которые её учитывают, будут слишком часто обращаться за обновлением к DNS-серверам регистратора, а это абсолютно бесполезная операция. В общем оставьте значение по умолчанию, если оно определено, или смело установите 84600 секунд (сутки).
Хватит использовать смехотворно малый TTL для DNS
Низкая задержка DNS — ключевой фактор для быстрой работы в интернете. Чтобы её минимизировать, важно тщательно подобрать DNS-серверы и анонимные рилеи. Но первым делом следует избавиться от бесполезных запросов.
Именно поэтому DNS изначально создавался как сильно кэшируемый протокол. Администраторы зон устанавливают время жизни (TTL) для отдельных записей, а резолверы используют эту информацию при хранении записей в памяти, чтобы избежать ненужного трафика.
Эффективно ли кэширование? Пару лет назад моё небольшое исследование показало, что оно не идеально. Взглянем на нынешнее положение дел.
Для сбора информации я пропатчил Encrypted DNS Server для сохранения значения TTL для ответа. Оно определяется как минимальное TTL его записей, для каждого входящего запроса. Это даёт хороший обзор распределения TTL реального трафика, а также учитывает популярность отдельных запросов. Пропатченная версия сервера работала несколько часов.
Результирующий набор данных состоит из 1 583 579 записей (name, qtype, TTL, timestamp). Вот общее распределение TTL (ось X — это TTL в секундах):
Если не считать незначительного бугра на 86 400 (в основном, для записей SOA), довольно очевидно, что TTL находятся в низком диапазоне. Посмотрим ближе:
Хорошо, TTL более 1 часа статистически не значимы. Тогда сосредоточимся на диапазоне 0−3600:
Большинство TTL от 0 до 15 минут:
Подавляющее большинство от 0 до 5 минут:
Это не очень хорошо.
Накопительное распределение делает проблему ещё более очевидной:
В половине DNS-ответов TTL составляет 1 минуту или меньше, а у трёх четвертей — 5 минут или меньше.
Но подождите, на самом деле всё ещё хуже. Ведь это TTL от авторитативных серверов. Однако клиентские резолверы (например, маршрутизаторы, локальные кэши) получают TTL от вышестоящих резолверов, и он уменьшается каждую секунду.
Таким образом, клиент фактически может использовать каждую запись, в среднем, в течение половины исходного TTL, после чего отправит новый запрос.
Может, эти очень низкие TTL касаются только необычных запросов, а не популярных веб-сайтов и API? Давайте посмотрим:
Ось X — это TTL, ось Y — популярность запросов.
К сожалению, самые популярные запросы также и хуже всего кэшируются.
Вердикт: всё действительно плохо. Уже и раньше было плохо, а стало ещё хуже. Кэширование DNS стало практически бесполезным. Поскольку всё меньше людей используют DNS-резолвер своего провайдера (по уважительным причинам), увеличение задержки становится более заметной.
Кэширование DNS стало полезным только для контента, который никто не посещает.
Также обратите внимание, что программное обеспечение может по-разному интерпретировать низкие TTL.
Почему так?
Почему для записей DNS устанавливается такой малый TTL?
Кроме того, минутный TTL означает, что если авторитетные DNS-серверы будут заблокированы более чем на 1 минуту, никто больше не сможет получить доступ к зависимым службам. И избыточность не поможет, если причиной является ошибка конфигурации или взлом. С другой стороны, с разумными TTL много клиентов продолжат использовать предыдущую конфигурацию и никогда ничего не заметят.
В низких TTL в значительной степени виноваты cервисы CDN и балансировщики нагрузки, особенно когда они объединяют CNAME с малыми TTL и записи с такими же малыми (но независимыми) TTL:
Всякий раз, когда истекает CNAME или любая из записей A, приходится отправлять новый запрос. У обоих 30-секундный TTL, но он не совпадает. Фактический средний TTL будет 15 секунд.
Но подождите! Всё еще хуже. Некоторые резолверы очень плохо себя ведут в такой ситуации с двумя связанными низкими TTL:
Резолвер Level3, наверное, работает на BIND. Если вы продолжите отправлять этот запрос, всегда будет возвращаться TTL, равный 1. По существу, raw.githubusercontent.com никогда не кэшируется.
Вот ещё один пример такой ситуации с очень популярным доменом:
Не менее трёх записей CNAME. Ай. У одной приличный TTL, но это совершенно бесполезно. В других CNAME первоначальный TTL составляет 60 секунд, но для доменов akamai.net максимальный TTL составляет 20 секунд, и ни один из них не в фазе.
Как насчёт доменов, которые постоянно опрашивают устройства Apple?
Та же проблема, что у Firefox, и TTL большую часть времени застрянет на 1 секунде при использовании резолвера Level3.
У записи safebrowsing.googleapis.com значение TTL 60 секунд, как и у доменов Facebook. И, опять же, с точки зрения клиента, эти значения уменьшаются вдвое.
Как насчёт установки минимального TTL?
Используя имя, тип запроса, TTL и изначально сохранённую временную метку, я написал скрипт для имитации 1,5 миллиона запросов, проходящих через кэширующий резолвер, чтобы оценить объём лишних запросов, отправленных из-за просроченной записи кэша.
47,4% запросов были сделаны после истечения срока действия существующей записи. Это неоправданно высоко.
Каково будет влияние на кэширование, если установлен минимальный TTL?
Ось X — это минимальные значения TTL. Записи с исходными TTL выше этого значения не затронуты.
Ось Y — процент запросов от клиента, у которого уже есть кэшированная запись, но её срок действия истёк и он делает новый запрос.
Доля «лишних» запросов снижается с 47% до 36% простой установкой минимального TTL в 5 минут. При установке минимального TTL в 15 минут количество этих запросов снижается до 29%. Минимальный TTL в 1 час снижает их до 17%. Существенная разница!
Как насчёт того, чтобы ничего не менять на стороне сервера, а вместо этого установить минимальные TTL в клиентских DNS-кэшах (маршрутизаторы, локальные резолверы)?
Количество требуемых запросов снижается с 47% до 34% при установке минимального TTL в 5 минут, до 25% с минимумом в 15 минут и до 13% с минимумом в 1 час. Возможно, оптимальное значение 40 минут.
Влияние этого минимального изменения огромно.
Каковы последствия?
Конечно, сервис можно перевести на нового облачного провайдера, новый сервер, новую сеть, требуя от клиентов использовать последние записи DNS. И достаточно малый TTL помогает плавно и незаметно осуществить такой переход. Но с переходом на новую инфраструктуру никто не ожидает, что клиенты перейдут на новые записи DNS в течение 1 минуты, 5 минут или 15 минут. Установка минимального срока жизни в 40 минут вместо 5 минут не помешает пользователям получить доступ к сервису.
Однако это позволит значительно сократить задержку и повысить конфиденциальность и надёжность, избегая ненужных запросов.
Конечно, RFC говорят, что нужно строго соблюдать TTL. Но реальность такова, что система DNS стала слишком неэффективной.
Если вы работаете с авторитативными DNS-серверами, пожалуйста, проверьте свои TTL. Вам действительно нужны такие смехотворно низкие значения?
Конечно, есть веские причины установки малых TTL для DNS-записей. Но не для 75% трафика DNS, который практически не меняется.
И если по каким-то причинам вам действительно нужно использовать низкие TTL для DNS, заодно убедитесь, что на вашем сайте не включено кэширование. По тем же причинам.
Если у вас работает локальный DNS-кэш, такой как dnscrypt-proxy, который позволяет устанавливать минимальные TTL, используйте эту функцию. Это нормально. Ничего плохого не случится. Установите минимальный TTL примерно между 40 минутами (2400 секунд) и 1 часом. Вполне разумный диапазон.
Как правильно настроить TTL домена
TTL означает «время жизни» и указывает, как долго ваши настройки DNS должны храниться в кэше, прежде чем они будут автоматически обновлены.
Когда происходит изменение DNS, остальной части Интернета требуется время, чтобы это заметить. Некоторые примеры таких изменений: обновление IP-адреса сервера, обновление записи MX для размещения вашей электронной почты в новом месте или добавление нового веб-сайта. Параметр TTL сообщает Интернету, как долго ждать, прежде чем вернуться для проверки вашей записи DNS на предмет потенциально новой информации.
Если для параметра TTL DNS установлено значение 12 часов, ваши записи DNS будут кэшироваться в течение 12 часов, прежде чем срок их действия истечет, и новая информация вступит в силу.
TTL на доменах IONOS устанавливается на срок до 1 часа для всех записей A, AAA, MX, TXT и CNAME.
Как долго длится TTL?
TTL указывается в секундах. Типичное значение по умолчанию обычно составляет 12 часов (43200 секунд) или 24 часа (86400 секунд). Например — сайт переезжает на новый сервер; или вы добавляете новый URL на свой сервер. Новые изменения DNS вступят в силу через 12–24 часа.
Обратите внимание, что даже если вы измените TTL для своего доменного имени, это не означает, что автоматически каждая сеть в Интернете будет соблюдать это значение. Многие поставщики интернет-услуг (ISP) игнорируют настройки TTL и проверяют внешние записи DNS по своему собственному расписанию.
Лучшие практики DNS TTL
По большей части нет необходимости изменять TTL. Однако, если вы знаете, что скоро внесете большое изменение в DNS, и хотите, чтобы изменения вступили в силу быстро, вы можете изменить свой TTL заранее.
По крайней мере, за 24 часа до начала обновите TTL до более короткого значения. Например, вы можете изменить его на 3600 (1 час).
Когда ваша работа будет сделана, обязательно вернитесь и верните свои настройки TTL к исходным значениям. Кэширование DNS — важный способ снизить нагрузку на серверы, и лучше всего поддерживать низкий уровень этого трафика.
Минимальное значение TTL DNS
Если вы планируете в ближайшее время внести изменения в DNS, вам следует начать с установки низкого значения TTL. Это помогает обеспечить более быстрое распространение ваших изменений и их распознавание в Интернете.
Установите для минимального значения TTL DNS значение больше 0. Никогда не устанавливайте для TTL DNS значение 0. Число 0 не определено в стандарте, и это может привести к игнорированию или отклонению вашей информации DNS.
Рекомендация : 3600 (1 час) — хорошее минимальное значение. Он достаточно низкий, чтобы изменения вступили в силу быстро, но не настолько низкий, чтобы DNS-серверы были перегружены.
Максимальное значение TTL DNS
Максимальное значение TTL — 604800 (7 дней). Хотя технически не существует максимального значения TTL для DNS, значения более 7 дней будут автоматически округляться до 7 дней.
Рекомендация: для большинства пользователей максимальное значение TTL для DNS 86400 (24 часа) является хорошим выбором.
Динамический DNS TTL
Динамический DNS (DDNS) — отличный способ указать доменные имена на нестатический IP-адрес.
Например, предположим, что вам принадлежит доменное имя example.com. Вы хотите указать home.example.com на сервер в вашей домашней сети; однако у вас нет статического IP-адреса от вашего интернет-провайдера. Это означает, что внешний IP-адрес вашего домашнего сервера будет периодически меняться.
Сервисы динамического DNS могут указывать доменное имя (например, home.example.com) на переменный IP. Каждый раз при изменении IP-адреса ваш DNS автоматически обновляется, поэтому изменение вступает в силу быстро.
Если вы настроили динамический DNS для доменного имени, вас могут попросить указать TTL для записей. Однозначного ответа на вопрос о значении TTL, которое следует использовать для динамической записи DNS, не существует. Частично это будет зависеть от того, как долго находится аренда IP-адреса. Чем чаще меняется IP-адрес, тем ниже TTL, который вам следует использовать.
Рекомендация. Хорошее практическое правило — сделать TTL DDNS вдвое меньше, чем аренда DHCP. Если аренда IP-адреса установлена на 60 (1 минута), установите TTL на 30 (30 секунд). Если IP-адрес 3600 (1 час), установите TTL на 1800 (30 минут).
Как выполнить поиск в DNS TTL
Узнайте, как проверить настройки TTL для вашего веб-сайта.
Linux, Unix или Mac OS X
Самый простой способ узнать настройки TTL — использовать digутилиту, доступную в Linux, Unix и Mac OS X.
В оболочке (командной строке) введите:
Это вернет информацию DNS (включая значения TTL) для имени домена:
Значение «7728» — это TTL для записи в секундах (7 728 секунд = 2 часа 8 минут).
Windows
В Windows вы можете использовать эту nslookupутилиту для проверки значений TTL DNS для веб-сайта.
Сначала откройте окно командной строки.
Чтобы запустить nslookup и получить значения TTL, введите:
Это вернет информацию авторитетного сервера имен для этого домена, включая TTL по умолчанию в секундах и часах.
В этом случае TTL веб-сайта установлен на 3600 секунд (1 час).
В сети
Есть несколько веб-сайтов, которые позволяют использовать утилиту dig для бесплатного поиска DNS TTL.
Как видите, значение TTL DNS для записей этого домена установлено на 21599 секунд (6 часов).
Как изменить TTL, если у вас есть собственный DNS
Если вы используете собственный DNS-сервер, для изменения TTL достаточно отредактировать файл зоны и убедиться, что ваша DNS-служба принимает изменения. Специфика будет зависеть от того, какую службу DNS вы используете, а в некоторых случаях от того, какую версию Linux или Unix вы используете.
После внесения изменений вы можете проверить, вступили ли они в силу, запросив у вашего сервера новую информацию DNS с помощью команды:
Поиск файла зоны: Red Hat и CentOS
При типичной установке BIND в Red Hat или CentOS файл зоны веб-сайта будет выглядеть примерно так /var/named/[domain name].dbили /var/named/[domain name].zone. Например, чтобы отредактировать файл для example.com в типичной настройке по умолчанию, введите следующую команду:
Поиск файла зоны: Debian и Ubuntu
В типичной установке BIND в Debian или Ubuntu файл зоны веб-сайта будет выглядеть примерно так /etc/bind/[domain name].db. Например, чтобы отредактировать файл для example.com в типичной настройке по умолчанию, введите следующую команду:
Редактирование файла зоны
В файле зоны вам нужно будет отредактировать две строки: TTL и серийный номер.
TTL будет первой строкой файла и будет выглядеть примерно так:
Просто измените число на значение TTL, которое вы хотите установить, в секундах.
Обновление серийного номера
В типичной конфигурации серийный номер нужно просто увеличить. Например, серийный номер 1234будет обновлен до 1235.
Некоторые системные администраторы могут использовать метку времени, номер версии или иметь системы для автоматического увеличения серийного номера. Если вы не уверены, какая система используется для серийных номеров BIND, обратитесь к администратору вашего сервера.
Сохраните и выйдите из файла.
Перед тем, как перезагрузить изменения, проверьте синтаксис основной конфигурации BIND с помощью команды:
Если все в порядке, проверьте синтаксис только что отредактированного файла зоны с помощью команды:
Например, если вы изменили TTL для example.com в файле, /var/named/example.com.dbкоманда будет выглядеть так:
Если файлы проходят проверку синтаксиса, перезагрузите файл зоны в BIND с помощью команды:
Необязательно: в Red Hat и CentOS, если systemctlон был настроен, вы можете перезапустить BIND вместо этого, используя команду:
Несвязанный
Unbound недавно заменил BIND в качестве DNS-сервера по умолчанию во многих системах BSD, включая FreeBSD 10 и выше и OpenBSD 5.6 и выше.
По умолчанию в большинстве систем файл конфигурации находится по адресу:
В файле конфигурации Unbound по умолчанию не указаны значения TTL. Вы можете добавить TTL в файл несвязанной зоны со следующими атрибутами:
Чтобы изменить или установить TTL, отредактируйте unbound.conf файл:
Проверьте файл для cache-max-ttl и cache-min-ttl атрибутов. Если они уже существуют, вы будете их редактировать. Если их нет, вам нужно будет добавить их:
Поместите эти конфигурации в основной блок команд сервера, затем сохраните и выйдите из файла.
После редактирования файла конфигурации вы можете протестировать конфигурацию с помощью команды:
Наконец, перезапустите Unbound, чтобы изменения вступили в силу с помощью команды:
Давайте уже разберемся в DNS
Внимательный читатель найдет на этой картинке IPv6
Люди часто озадачены доменами. Почему мой сайт не работает? Почему эта хрень поломана, ничего не помогает, я просто хочу, чтобы это работало! Обычно, вопрошающий или не знает про DNS, или не понимает фундаментальных идей. Для многих DNS — страшная и непонятная штука. Эта статья — попытка развеять такой страх. DNS — это просто, если понять несколько базовых концепций.
Что такое DNS
DNS расшифровывается как Domain Name System. Это глобальное распределенное хранилище ключей и значений. Сервера по всему миру могут предоставить вам значение по ключу, а если им неизвестен ключ, то они попросят помощи у другого сервера.
Базовые штуки
Давайте взглянем на маппинг между именем и адресом:
Здесь есть только одна интересная деталь: информация о самом запросе. Говорится, что мы запросили запись и получили ровно один ответ. Вот:
Оставшаяся часть ответа описывает сам ответ:
Как видите, при обычном DNS-запросе происходит куча всего. Каждый раз, когда вы открываете веб-страницу, браузер делает десятки таких запросов, в том числе для загрузки всех внешних ресурсов вроде картинок и скриптов. Каждый ресурс отвечает за минимум один новый DNS-запрос, и если бы DNS не был рассчитан на сильное кэширование, то трафика генерировалось бы очень много.
Корневые DNS-сервера обслуживаются различными компаниями и государствами по всему миру. Изначально их было мало, но интернет рос, и сейчас их 13 штук. Но у каждого из серверов есть десятки или сотни физических машин, которые прячутся за одним IP.
Другие типы
Что не так с CNAME
Запросы к другим серверам
Давайте представим, что конфигурация DNS испорчена. Вам кажется, что вы исправили проблему, но не хотите ждать когда обновится кэш чтобы удостовериться. С помощью dig можно сделать запрос к публичному DNS-серверу вместо своего дефолтного, вот так:
Типичные ситуации
Давайте рассмотрим типичные ситуации, знакомые многим веб-разработчикам.
Редирект домена на www
Этот IP принадлежит Namecheap’у, и там крутится маленький веб-сервер, который просто делает перенаправление на уровне HTTP на адрес http://www.iskettlemanstillopen.com :
CNAME для Heroku или Github
Wildcards
Заключение
Надеюсь, теперь у вас есть базовое понимание DNS. Все стандарты описаны в документах:
Есть еще пара интересных RFC, в том числе 4034, который описывает стандарт DNSSEC и 5321, который описывает взаимосвязь DNS и email. Их интересно почитать для общего развития.
Как изменить TTL в Windows 10 и раздать безлимитный интернет со смартфона на компьютер
Любой современный смартфон может выступать в качестве Wi-Fi роутера, способного раздавать интернет для другого устройства. Воспользоваться подобным функционалом разрешено всем владельцам, но бесплатно такая опция предоставляется далеко не каждому. Часто бывает, что мобильный оператор ограничивает «безлимитный» тариф и взимает дополнительную плату за раздачу интернета со смартфона. Происходит это благодаря TTL, который хорошо контролируется оператором.
Что это за технология и как обойти ограничения – поговорим в сегодняшней статье.
Что такое TTL и зачем он нужен
TTL – это специальный показатель, который встроен в каждое устройство, способное выходить в интернет. Сама аббревиатура расшифровывается как Time To Live – «время жизни IP-пакета». Это набор данных, который передается от пользователя к серверу и обратно. Время в данном случае означает то, сколько может просуществовать пакет без потери информации. Изначально TTL хотели измерять в секундах, откуда и пошло определение.
Значение TTL в компьютерных сетях находится в диапазоне от 0 до 255. Перемещаясь между различными маршрутизаторами, параметр постоянно меняется. Для владельцев устройств на базе iOS и Android начальное значение обычно равняется 64, для Windows – 128. Каждый переход через беспроводной канал уменьшает показатель на 1 единицу. Если произойдет множество скачков от одного клиента к другому, значение становится равным 0 – в таком случае все данные в пакете уничтожаются.
Точное число значений TTL всегда перенаправляется провайдеру, который всегда может узнать, был ли пропущен трафик через сторонние устройства или нет. Таким образом, сотовые операторы могут спокойно контролировать раздачу интернета своих клиентов. Когда владелец смартфона раздает интернет, его значение TTL уменьшается на единицу и равняется 63. Это сразу же становится известно оператору, который в свою очередь начинает принимать меры – обычно взимает дополнительную плату или перекрывает доступ в интернет.
Более детально это выглядит так:
Чтобы обойти блокировку оператора, необходимо увеличить значение TTL на 1 единицу. Так мы получим увеличенное число, которое будет снижаться до исходного. В таком случае оператор не сможет заподозрить клиента в раздаче интернета.
О том, как это сделать, поговорим далее.
Как узнать значение TTL на компьютере
Прежде чем переходить к изменению TTL, необходимо определить, чему оно равняется. В Windows 10 сделать это довольно просто – достаточно ввести нужную команду в командную строку, запущенную от имени администратора. Рассмотрим на примере:
Узнав нужное нам значение, можем переходить к его изменению.
Как изменить TTL в Windows 10
Для редактирования TTL нам потребуется обратиться к редактору реестра – это встроенная утилита, позволяющая корректировать системные настройки. Если вы никогда с ней не работали, то будьте бдительны – корректировка различных параметров может привести к проблемам с Windows.
Перейдем к настройке:
Осталось перезагрузить компьютер, и значение TTL будет изменено на 65. При передаче интернета со смартфона оно изменится на стандартное 64. Оператор сотовой связи ничего не заподозрит, а вы сможете пользоваться раздачей интернета как ни в чем не бывало.
Как раздать интернет на Android-смартфоне
Есть три способа раздачи интернета – через мобильную точку доступа, USB или Bluetooth.
Мобильная точка доступа
Алгоритм действий следующий:
В моем случае выполняется раздача Wi-Fi под именем «Frank» с паролем «12345678». На вашем смартфоне будут указаны другие параметры, но вы всегда можете их поменять. Также в настройках можно отключить вход по паролю – для этого необходимо в верхнем правом углу нажать на троеточие и выбрать «Настройки точки доступа». Затем в блоке «Безопасность» изменить значение на «Открытый».
Раздаем интернет через Bluetooth
Подключиться через Bluetooth вы сможете только в том случае, если ваш ноутбук поддерживает данную технологию. Процесс подключения следующий:
Убедитесь, что ваш телефон и ноутбук не подключены к какой-либо другой сети.
Через USB—подключение
Для подключения через USB нам потребуется простой провод Type-A/C на Type-C/Micro B – в общем тот, который вы обычно используете для зарядки.
Подключаем телефон к компьютеру и выполняем следующие действия:
Вот такими несложными манипуляциями мы смогли подключиться к интернету, который раздается со смартфона на Android.
Как раздать интернет на iOS-устройстве
Раздать интернет на Mac, PC и другие устройства мы также можем через Bluetooth:
После изменения TTL вы можете пользоваться раздачей интернета без каких-либо проблем, если ранее они были. Удачи!