Ниже представлена схема того, как запрос в браузере “claude.ai” превращается в нужный IP-адрес:

  1. Браузер смотрит у себя в кэше: может быть, сайт уже посещался и информация о его IP уже была записана. Если нет, то он направляет запрос “what’s IP for claude.ai” к операционной системе.

  2. ОС смотрит у себя в кэше. Если и там нет записи, запрос передаётся resolver’у у интернет-провайдера.

  3. Resolver смотрит у себя в кэше. Если нет нужной записи, он обращается к одному из 13-ти распределённых (т.е. физических серверов гораздо больше, чем 13) root-серверов: например, к c.root-servers.net.

  4. Единственная задача root-сервера — направить нас к нужному TLD-серверу (в нашем случае к .ai-TLD).

    <aside> 💡

    TLD-серверов для одного домена может быть несколько. Например, 13 серверов хранят базу для .com: от a.gtld-servers.net до m.gtld-servers.net. Каждый сервер хранит одни и те же данные (~160 млн. записей).

    </aside>

  5. Получив адрес TLD-сервера, resolver обращается к нему: среди всех записей на этом сервере точно найдётся одна с адресами name-серверов для claude.ai:

    X.ai -> name_servers: [...]
Y.ai -> name_servers: [...]
...
claude.ai -> name_servers: ["ns1.anthropic.com" (198.241.10.51), "ns2.anthropic.com" (162.159.25.4), ...]
...

  6. Получив адреса name-серверов, resolver обращается к одному из этих серверов, соответственно. Так как у одного домена может быть несколько адресов (например, гугл использует много-много серверов по всему миру, чтобы время отклика у пользователей было небольшим), то для определения конкретного IP и требуются отдельные именные серверы. Они на основе IP у resolver’а вычисляют его географическое положение и понимают, адрес какого ближайшего к этому положению сервера claude.ai стоит выдать.

Выходит, схема примерно такая:

ПК ←→ resolver (ISP) ←→ root-serv

              ←→ TLD-serv

           ←→ ns1.anthropic.com