Я читал, что домен может появляться в файле ежедневной зоны в течение нескольких дней после некоторых изменений в записи DNS. К сожалению, источник не объяснил обстоятельства, когда он появился в ежедневном файле. Может ли кто-нибудь просветить меня по этому поводу?
Кроме того, (поправьте меня, если я ошибаюсь), когда у вас есть полный файл зоны, вы затем используете ежедневные файлы, чтобы поддерживать локальную копию в актуальном состоянии. Какой механизм можно использовать, чтобы определить, когда следует удалить запись?
В качестве примера ... у меня есть большой список ключевых слов. Для начала мне нужно найти домены, содержащие эти ключевые слова или похожие на них. В дальнейшем мне нужно иметь возможность выполнять меньший поиск ключевых слов только по новым доменам. Список ключевых слов может быть добавлен, и новые ключевые слова нужно будет искать исторически и в будущем. Итак, мне понадобится локальная база данных доменов, которая будет содержать только домены, которые действительно существуют, без необходимости запрашивать какой-либо сервер имен для проверки его существования.
Я считаю, что регистраторы предоставляют ежедневные дельты, но я не знаю, как представлены просроченные домены.
Надеюсь, этот пример проясняет то, что я пытаюсь сделать.
Возможно, я только что нашел свой ответ ... http://bestwhois.org/domain_name_data/docs/README_01_document.html#sec12 У них есть 2 канала - один для недавно зарегистрированных доменов, а другой для удаленных доменов.
Если кто-нибудь может увидеть что-то, что я упустил, дайте мне знать.
Спасибо!
Доменное имя может отсутствовать в файле зоны по ряду причин:
Таким образом, если у вас есть доменное имя (скажем, от коммерческого поставщика), и вы удалите все серверы имен, оно больше не будет предоставлено в файле зоны и не будет разрешено.
Сначала несколько общих объяснений, чтобы устранить некоторые затруднения, которые могут у вас возникнуть.
Домены существуют в TLD. gTLD находятся по контракту с ICANN. Домен появляется в файле зоны. Реестры (менеджеры TLD) решают, публикуют они файлы зон или нет. Большинство, особенно ccTLD, не будут этого делать, учитывая, что это и частные данные, и они несут за это ответственность. Однако gTLD вынуждены публиковать их из-за правил ICANN. Вы можете узнать все об этом на https://czds.icann.org/
Короче говоря, вы создаете учетную запись один раз, а затем сможете загружать файлы зоны.
gTLD ежедневно публикуют файлы зон. Следовательно, однажды домен появится, если он начал регистрироваться (и с серверами имен), или если у него не было серверов имен, а теперь есть, или, как @Anonymous указано в его ответе, когда он будет приостановлен или удален ( до или после истечения срока действия) или изменить, чтобы удалить все серверы имен.
Некоторые другие реестры могут разрешать запросы DNS AXFR, что означает, что вы сможете динамически возвращать полный файл зоны по запросу, но это делают только дюжина или около того TLD.
Также некоторые другие реестры предоставляют услуги «открытых данных», с помощью которых вы также можете получить файлы зон или аналогичные. Некоторые также ежедневно публикуют на своих веб-сайтах новые зарегистрированные имена, которые не являются файлом зоны, но если вы будете получать эти данные день за днем, в какой-то момент вы будете близки к тому, чтобы иметь полный файл зоны. AFNIC, например, в этих двух случаях используется реестр .FR.
А теперь вернемся к вашим вопросам:
Я читал, что домен может появляться в файле ежедневной зоны в течение нескольких дней после некоторых изменений в записи DNS. К сожалению, источник не объяснил обстоятельства, когда он появился в ежедневном файле.
Теперь это должно быть ясно из вышеизложенного. Домен публикуется (в файле зоны) после того, как он существует (зарегистрирован), имеет серверы имен и не удерживается. Если он перестанет существовать, больше не имеет серверов имен или будет приостановлен, то он исчезнет из файла зоны.
Кроме того, (поправьте меня, если я ошибаюсь), когда у вас есть полный файл зоны, вы затем используете ежедневные файлы, чтобы поддерживать локальную копию в актуальном состоянии. Какой механизм можно использовать, чтобы определить, когда следует удалить запись?
gTLD публикуют полный файл зоны каждый день. Вы можете бесплатно загрузить его, а затем обработать так, как хотите, в соответствии с вашим контрактом, подписанным на CZDS. Другие реестры могут устанавливать и другие условия.
Если домен A находится во вчерашнем файле зоны, но не в сегодняшнем, то вы знаете, что домен был удален, или его сервер имен удален, или он был приостановлен. Если вы выполните запрос whois (или RDAP), вы увидите, существует ли домен или нет, и находится ли он в дыре или нет.
В качестве примера ... у меня есть большой список ключевых слов. Для начала мне нужно найти домены, содержащие эти ключевые слова или похожие на них. В дальнейшем мне нужно иметь возможность выполнять меньший поиск ключевых слов только по новым доменам. Список ключевых слов может быть добавлен, и новые ключевые слова нужно будет искать исторически и в будущем. Итак, мне понадобится локальная база данных доменов, которая будет содержать только домены, которые действительно существуют, без необходимости запрашивать какой-либо сервер имен для проверки его существования.
Многие онлайн-сервисы делают это. Но в основном вы загружаете файлы зон и обрабатываете их на своей стороне в соответствии с подписанным контрактом и технически, чтобы вы могли использовать их так, как вам нужно. Поиск по ключевым словам и все остальное должны выполняться вами.
Я считаю, что регистраторы предоставляют ежедневные дельты, но я не знаю, как представлены просроченные домены.
Первые регистраторы могут предоставлять только те данные, которые у них есть, следовательно, на своих доменах не на всех. Итак, я думаю, вы ссылаетесь на реестры больше, и так см. Выше.
Во-вторых, истечение срока действия доменного имени - сложный процесс, который зависит от TLD. Вот общие правила:
Возможно, я только что нашел свой ответ ... http://bestwhois.org/domain_name_data/docs/README_01_document.html#sec12 У них есть 2 канала - один для недавно зарегистрированных доменов, а другой для удаленных доменов.
Любой, кто загружает файлы зоны, легко сможет предоставить различия:
Выполнив whois-запрос, вы можете увидеть, зарегистрирован ли домен по-прежнему, и вы увидите, приостановлен он или нет. Следовательно, вы сможете различать все вышеперечисленные случаи.
Здесь нет ничего сложного, кроме:
Хммм, я не уверен в вашей формулировке - ежедневные файлы ...
В любом случае давай проверим в общем. Есть несколько TTL (Твремя То Live) параметр, относящийся к файлу зоны. Некоторые из них находятся в SOA (Sпирог Озона f Афайл uthority):
<domain> IN SOA <primary master FQDN> <administrator contact> (
<serial> ;
<refresh> ;
<retry> ;
<expire> ;
<TTL / minimum>
)
refresh - период времени в секундах, когда DNS-сервер в роли ведомого должен проверять ведущее устройство на наличие обновлений ("бэкэнд" материал между авторитетными серверами)
retry - в случае сбоя подчиненного сервера при проверке обновлений, когда повторять попытку проверки ("бэкэнд" материал между авторитетными серверами)
expire - в случае, если ведомый сервер не может проверить состояние зоны на главном сервере, как долго он может давать достоверные ответы. По истечении этого периода времени файл зоны на ведомом устройстве истечет, и служба перестанет отвечать на запросы, относящиеся к этой зоне («бэкэнд» материал между авторитетными серверами)
TTL / minimum - В случае, если кто-то запрашивает RR (запись DNS), которая не существует, отрицательный ответ будет прикреплен к SOA (включая эту информацию), чтобы клиент (преобразователь DNS) кэшировал отрицательный ответ на этот период. Таким образом, один и тот же ответ (даже без повторной проверки в течение этого периода) будет предоставлен на все запросы, заканчивающиеся на одном сервере разрешения DNS.
Пример записи RR:
<name> <TTL> IN A <IP>
После того, как вы запросите действительную запись DNS, вы получите индивидуальный TTL для записи, которая будет использоваться для целей локального кэширования. Вы получаете ТОЛЬКО запрошенные записи DNS, а не весь файл зоны. Для этого есть исключение в виде «подсказки» или дополнительных записей, которые могут быть прикреплены для целей инфраструктуры, но это далеко не «вся зона».
«Файл всей зоны», который вы использовали в вопросе, можно запросить только с помощью специального запроса (запрос передачи зоны), который разрешен только ограниченному серверу. Он используется для внутренних целей для распределения содержимого файла зоны между действительными уполномоченными серверами в ролях главный - подчиненный. Обычному пользователю / клиенту будет отказано в запросе передачи зоны.
Таким образом, как «нормальный» пользователь вы можете получить только конкретные ответы / записи RR (необязательно сопровождаемые «подсказками») или отрицательный ответ. В обоих случаях для этого ответа следует TTL, который может быть ниже или даже выше, чем просто день (24 часа - 86400 секунд). В течение этого периода используется кэшированное значение (как отрицательное, так и положительное) вместо запроса авторитетного DNS-сервера.
После изменения в зоне DNS клиенты, которые недавно (не понимали в отношении TTL) запрашивали его на полномочном сервере, увидят непосредственно новое значение, а клиенты, которые недавно запросили его, увидят кешированные значения. Это можно назвать задержкой распространения нового значения. «Проблема» в этом случае не на стороне авторитетных серверов, а на кешированных значениях на стороне клиента ... Процесс очистки кеша (выборочно для домена или всех / без условий) на сервере называется FLUSHing of the кеш (это может сделать администратор). Обычный способ удаления «устаревшего» значения со стороны клиента - это дождаться истечения этого времени - как только истечет TTL, кэширующий сервер аннулирует значение, и при следующем запросе его нет (удаляется) или по крайней мере, просто игнорируется, поэтому выполняется правильный запрос к авторитетному серверу ...