Вот пример реализации с использованием DNS-запросов и Whois только при отсутствии записи SOA:

#!/usr/bin/env bash

for z in {com,org,io}; do
  for y in {0..9}; do
    for x in {a..z}; do

      # Compose domain as xxxyyy.z
      domain="$x$x$x$y$y$y.$z"

      # If domain has no SOA DNS record, chances are it is available.
      if [ -z "$(dig +keepopen +short -q "$domain" -t SOA)" ]; then

        # To be sure a domain without SOA DNS record is really available:
        # check it has no whois record either
        if ! whois "$domain" >/dev/null; then
          printf 'Domain %s is available\n' "$domain"
        else
          printf 'Domain %s has no DNS SOA but has a whois record\n' "$domain"
        fi
      else
        printf 'An SOA record exist for domain %s.\nIt may not be available.\n' "$domain"
      fi
    done
  done
done

Пример первых строк вывода:

Domain aaa000.com has no DNS SOA but has a whois record
An SOA record exist for domain bbb000.com.
It may not be available.
An SOA record exist for domain ccc000.com.
It may not be available.
Domain ddd000.com has no DNS SOA but has a whois record
An SOA record exist for domain eee000.com.
It may not be available.
An SOA record exist for domain fff000.com.
It may not be available.
An SOA record exist for domain ggg000.com.
It may not be available.

Пожалуйста, не делайте этого ниже:

Я не могу понять, как проверить доступность всего набора доменов, соответствующих критериям, например XXX YYY.Z. где X — любые 3 буквы, Y — любые 3 цифры, а Z — любая из com, org или io.

Причина в том, что это будет означать проверку доступности 52728000 отдельных доменных имен, нереальное количество запросов даже для служб DNS, а не для служб Whois.

Арифметика позади:

• XXX где X — любые 3 буквы: 26 букв → 26×26×26=17576 комбинаций.
• YYY где Y — любые 3 числа: 10 чисел → 10×10×10=1000 комбинаций.
• Z где Z — любой из com, org или io: 3 TLD → 3 комбинации

→ XXXYYY.Z: 17576×1000×3 → 52728000 комбинаций

Давайте вычислим этот объем доменов с использованием циклов, а не целых выражений скобок Bash для их генерации, потому что он не поместится в память только с скобкой-exp:

#!/usr/bin/env bash

for Z in {com,org,io}; do
  for YYY in {0..9}{0..9}{0..9}; do
    for XXX in {a..z}{a..z}{a..z}; do
      printf '%s%s.%s\n' "$XXX" "$YYY" "$Z"
    done
  done
done

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

Существует по крайней мере один возможный ярлык (с использованием файлов зон), но ваш вопрос недостаточно детализирован, чтобы быть уверенным, что он подходит, но см. ниже. Это может работать лучше/быстрее, чем использование DNS, в зависимости от вашего варианта использования. Он имеет преимущества и недостатки.

Я также рассмотрю другие моменты, чтобы представить ситуацию в перспективе, и мой ответ носит общий характер (применяется к нескольким ДВУ и разными способами). Но это не даст вам готовый сценарий для простого использования, так как этот веб-сайт не является доской для письма, и ваша проблема с некоторыми изложенными конкретными ограничениями слишком велика.

Я не буду повторять решение, основанное на DNS-запросах, поскольку оно уже было дано, даже если данный ответ можно улучшить (вам обязательно нужно обращаться к серверам имен реестра, а не к рекурсивным!)

RDAP

Сначала небольшая скобка: в настоящее время, особенно в рДВУ, RDAP должен стать новым стандартом. Это намного лучше, чем whois, поскольку это JSON поверх HTTPS, что позволяет вам получать обратно структурированные данные. Это также включает в себя разницу между поиском и запросом, которой нет у whois (в некоторых реестрах есть «проверка доступности домена», например, с помощью finger; для этого был протокол IETF, называемый IRIS D-CHK, но это было не более чем реализован двумя реестрами и, будучи сжатым XML через UDP, никогда не получал поддержки).

См. RFC 7480 §4:

Клиенты используют метод GET для извлечения тела ответа и используют метод
HEAD для определения наличия данных на сервере.

Пример:

$ curl --head https://rdap.verisign.com/com/v1/domain/stackoverflow.com
HTTP/1.1 200 OK
Content-Length: 2264
Content-Type: application/rdap+json
Access-Control-Allow-Origin: *
Strict-Transport-Security: max-age=15768000; includeSubDomains; preload

$ curl --head https://rdap.verisign.com/com/v1/domain/stackoverflow-but-does-not-exist.com
HTTP/1.1 404 Not Found
Content-Type: application/rdap+json
Access-Control-Allow-Origin: *
Strict-Transport-Security: max-age=15768000; includeSubDomains; preload

(если вы сделаете GET в первом случае, вы получите документ JSON, который вы можете обработать с помощью jq или эквивалентного).

Также обратите внимание, что в этом новом протоколе встроен «частичный поиск», см. 4.1. Частичный поиск строки. Это очень простой случай, а не регулярное выражение: вы можете просто использовать подстановочный знак. Конечно, серверы RDAP реестра не обязаны его реализовывать.

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

Вы можете узнать больше о RDAP:

• на веб-сайте ICANN: https://www.icann.org/rdap
• на каком-то внешнем ресурсе: https://about.rdap.org/

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

API регистраторов

Различные регистраторы предоставляют вам доступ к API, который будет включать в себя поиск доступных доменных имен и/или получение списка некоторых доменных имен (например, удаление имен и т. д.). То, что предоставляет каждый регистратор и при каких ограничениях, конечно, будет различаться, поэтому невозможно ответить вам там. Но для любого серьезного исследования это было бы первой остановкой: обратитесь к предпочитаемому вами регистратору и спросите его, какие услуги он может оказать вам в вашем случае.

Очевидно, это будет зависеть от того, в каких ДВУ аккредитован регистратор: регистраторы, аккредитованные в реестре, имеют открытый закрытый канал — с использованием протокола EPP — для проверки существования доменных имен.

Массовый доступ к Whois

Это существует, но в большинстве случаев почти невозможно использовать. Что касается рДВУ, регистраторы заключают договор с ICANN. Если вы прочитали их контракт вы видите это:

3.3.6 [..] Регистратор должен предоставить третьей стороне массовый доступ к данным, подлежащим публичному доступу в соответствии с подразделом 3.3.1, на следующих условиях:

3.3.6.1 Регистратор должен предоставлять полную электронную копию данных не реже одного (1) раза в неделю для загрузки третьими лицами, заключившими с Регистратором соглашение о массовом доступе.

3.3.6.2 Регистратор может взимать ежегодную плату, не превышающую 10 000 долларов США, за такой массовый доступ к данным.

Итак, теоретически вы можете подойти к каждому регистратору и попросить его у провайдера «массовый доступ к whois», что означает более или менее полный дамп данных, но:

• как написано в договоре выше, это может быть затратно (регистраторов более 1000, и так как вы не можете знать заранее, где зарегистрирован домен, вам нужно будет получить их всех)
• данные не будут свежими
• что касается файлов зон ниже, это не живой запрос/ответ, вам нужно будет загрузить все данные, сохранить их, обработать и использовать.

Файлы зон (gTLD)

Опять же, это в основном относится к рДВУ по причинам, объясненным ниже, но см. следующий раздел для других случаев.

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

Но это «самое простое» и широкое решение вашей проблемы.

В соответствии с договором с ICANN все реестры рДВУ обязаны предоставлять свободный доступ к своим файлам зон. Файл зоны будет содержать все опубликованные доменные имена в данном TLD. Это подмножество всех зарегистрированных имен (трудно сказать на сколько, но в диапазоне однозначных процентов, если даже так), потому что вы можете зарегистрировать доменное имя без серверов имен (поэтому оно не публикуется) или домен может быть поставлены "на удержание" по разным причинам и, следовательно, исчезнуть из файла зоны. Таким образом, вы получите такое же количество ложных срабатываний, как и при использовании живых DNS-запросов: вы не получите данных (фактически NXDOMAIN) для некоторых доменов, но на самом деле они зарегистрированы (и, следовательно, снова не доступны для регистрации).

Итак, все начинается здесь: https://www.icann.org/resources/pages/czds-2014-03-03-en и раздел справки для пользователей: https://czds.icann.org/help

Вам нужно будет создать учетную запись, подписать контракт, в котором будет указано, что вы можете и чего не можете делать с этими данными, после чего вы сможете загружать ежедневные файлы зон для каждого TLD. Большинство, если не все рДВУ, помещают туда свои файлы зон. Возможно, некоторые делают по-другому, поэтому вам нужно будет поискать.

Файл зоны будет иметь формат «главного файла зоны» DNS. Так вы увидите в них записи DNS. Вам нужно обработать только «NS», и вы увидите все доменные имена. Вам нужно обязательно нормализовать их (обложку, конечную точку и т. д.), поскольку содержимое может варьироваться от одного файла к другому.

Когда у вас есть ежедневный список доменных имен, вы можете применять любой инструмент для поиска в них, включая регулярные выражения. Однако будьте осторожны с ограничениями ЦП и ОЗУ, которые вы можете создать, в зависимости от того, как вы храните данные. Например, необработанный файл зоны .com имеет размер 13 ГБ.

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

Zonefiles (не gTLD)

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

Однако есть и встречные примеры:

• хотя сейчас у меня нет примеров, я почти уверен, что некоторые нДВУ все еще могут разрешать доступ к файлу зоны (будет определено)
• также иногда случается, что некоторые серверы имен настроены неправильно и, следовательно, принимают ответы DNS AXFR, что означает в основном загрузку файла зоны.
• у некоторых реестров есть инициатива «открытых данных», поэтому вы можете получить список всех доменных имен, но, возможно, устаревший по состоянию на несколько месяцев. AFNIC (.fr) — один из таких случаев: https://www.afnic.fr/en/about-afnic/news/general-news/9522/show/opendata-data-from-the-fr-tld-to-serve-innovation.html
• некоторые реестры публикуют такие сообщения, как «новые домены за последние 24 часа» или что-то в этом роде. Если вы загружаете список «регулярно», в какой-то момент вы получаете все данные. Опять же, AFNIC делает это: https://www.afnic.fr/en/products-and-services/services/daily-list-of-registered-domain-names/ (даже если это изображение, а не текст список, но это не мешает никому получать из него настоящие данные)

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