Module 2 → Lesson 10 → Part 2 of 8
Как браузер находит сервер
Lesson contents
- Что происходит, когда вы открываете сайт
- Как браузер находит сервер
- Как устанавливается соединение
- Как начинается защищенное HTTPS-соединение
What you'll learn
Браузер знает имя. Сети нужен адрес
Emma Lee вводит https://academy.example.com.
Для человека это удобно.
Можно запомнить academy.example.com вместо чего-то вроде 203.0.113.20.
Но маршрутизация Интернета работает с сетевыми адресами.
Поэтому после разбора URL браузеру нужно решить задачу:
С каким IP-адресом связано имя `academy.example.com`?
И только после этого можно переходить к установлению сетевого соединения.
Имя и IP-адрес — разные вещи
Упрощенно: academy.example.com — это имя, а 203.0.113.20 — сетевой адрес.
Важно:
имя не является самим IP-адресом.
Между ними существует механизм сопоставления.
Для этого нужен DNS
Мы уже встретили DNS — Domain Name System.
На уровне этого урока нам достаточно одной функции:
DNS помогает узнать, какие сетевые адреса связаны с определенным доменным именем.
Упрощенно: academy.example.com → DNS → 203.0.113.20.
Но это еще не означает, что браузер каждый раз обязательно начинает новый DNS-запрос в Интернет.
Сначала браузер может уже знать ответ
Представим, что Emma открывала этот сайт несколько минут назад.
Система может уже помнить: academy.example.com → 203.0.113.20.
То есть прежде чем обращаться наружу, браузер или операционная система могут использовать сохраненную информацию.
Это DNS cache.
Его задача:
не выполнять одну и ту же работу заново без необходимости.
- 1Browser checks cached information — сначала браузер или операционная система смотрят, есть ли уже сохраненный ответ.
- 2Cached result found — если ответ уже есть, новый DNS-запрос не выполняется.
- 3DNS resolver — если подходящего кеша нет, отправляется запрос DNS-резолверу.
- 4IP address(es) — получен один или несколько сетевых адресов, связанных с именем.
Зачем кешировать DNS
Без кеша сценарий мог бы выглядеть так: открыла страницу → спросила DNS; обновила страницу → снова спросила DNS; открыла еще одну вкладку → опять спросила DNS.
Это создавало бы: лишние запросы; лишнюю задержку; дополнительную нагрузку.
Поэтому полученный результат некоторое время можно использовать повторно.
Но кеш не должен жить вечно
Сегодня имя может вести на 203.0.113.20, а завтра сервис может переместиться на 203.0.113.45.
Если хранить старый ответ бесконечно, браузер продолжит искать сервер там, где его уже может не быть.
Поэтому DNS-информация имеет ограниченный срок актуальности.
Позже, в Уроке 11, мы познакомимся с понятием DNS TTL.
Сейчас достаточно запомнить:
DNS-кеш временный.
Если ответа нет в кеше
Тогда системе нужно спросить DNS-резолвер.
Упрощенно: browser → operating system → DNS resolver → ответ → IP address.
В реальности детали зависят от устройства, браузера и настроек.
Кто предоставляет DNS resolver
Это может быть, например: интернет-провайдер; организация; публичный DNS-сервис; локальная инфраструктура; защищенный DNS-сервис, настроенный браузером или операционной системой.
Поэтому фраза:
«DNS всегда предоставляет мой провайдер»
не является универсальным правилом.
Браузер тоже может участвовать активнее
Современный браузер не обязательно просто говорит операционной системе:
«Разберись сама».
В зависимости от конфигурации он может: иметь собственный DNS-кеш; использовать системный resolver; использовать защищенный DNS-механизм; применять собственную логику выбора адресов.
Для новичка важно не то, какой компонент сделал конкретный запрос.
Важно понимать общую цепочку: имя → разрешение имени → сетевой адрес.
Что значит «разрешить имя»
Этот процесс часто называют name resolution, разрешение имени.
В нашем случае: academy.example.com → name resolution → IP address.
Ответ может содержать IPv4
Например: academy.example.com → 203.0.113.20.
Это IPv4-адрес.
Или IPv6
Например, система может получить адрес вида 2001:db8::20.
Это уже IPv6.
В Уроке 11 мы разберем IPv4 и IPv6 подробнее.
Сейчас нужно только понимать:
современный сайт может иметь IPv4, IPv6 или оба типа адресов.
У одного имени может быть несколько адресов
Например: academy.example.com → 203.0.113.20, 203.0.113.21, 203.0.113.22.
Это совершенно нормально.
Почему сервису может понадобиться несколько адресов?
Например: несколько серверов; распределение нагрузки; резервирование; разные точки присутствия.
Поэтому:
доменное имя ≠ обязательно один IP ≠ обязательно один физический сервер.
Один сайт может находиться ближе, чем кажется
Крупные сервисы часто используют CDN — Content Delivery Network.
Например, Emma находится в Европе.
Вместо загрузки изображения с сервера на другом континенте система может направить ее к более близкой точке CDN.
Концептуально: Emma → nearest suitable CDN location → content.
Это может уменьшать задержку
Мы уже знаем, что физическое расстояние и сетевой маршрут влияют на latency.
Если данные доступны ближе к пользователю, путь (Emma → nearby server) может оказаться короче, чем Emma → another continent → server.
Именно поэтому один и тот же глобальный сервис может фактически обслуживать разных пользователей из разных дата-центров.
- 1IP A — Server location A, один из возможных адресов имени.
- 2IP B — Server location B, другой возможный адрес того же имени.
- 3IP C — CDN location C, ближайшая к пользователю точка доставки контента. Конкретный ответ может зависеть от инфраструктуры сервиса и сетевой ситуации.
Два пользователя могут получить разные ответы
Emma спрашивает: Where is example.com? — и получает 203.0.113.20.
Alex в другой сети может получить 203.0.113.80.
Это не обязательно ошибка.
Сервис может учитывать: географическое размещение; сетевую топологию; балансировку; доступность инфраструктуры.
Значит ли IP-адрес, что мы нашли один физический сервер?
Нет.
За адресом может находиться: IP → Load Balancer → Server A, Server B, Server C.
Или: IP → CDN → distributed infrastructure.
Мы уже встречали это в Уроке 9.
Сетевой адрес — это точка сетевого взаимодействия.
Он не обязан раскрывать внутреннюю архитектуру сервиса.
И наоборот: один IP может обслуживать несколько сайтов
Представим 203.0.113.20.
На одной инфраструктуре могут работать: site-a.example, site-b.example, site-c.example.
То есть:
один IP ≠ обязательно один сайт.
Позже мы увидим, как HTTPS и HTTP помогают серверной инфраструктуре понимать, к какому имени обращается клиент.
Браузеру нужен не «сайт вообще», а конкретное имя
Это важно для безопасности.
Emma хочет открыть exchange.example.
Недостаточно получить:
какой-нибудь сервер в Интернете.
Браузер должен работать именно с инфраструктурой, связанной с запрошенным именем.
А при HTTPS позже понадобится еще и криптографически проверить:
сервер действительно имеет право представлять это имя?
Вот почему DNS и HTTPS решают разные задачи.
DNS отвечает не на вопрос «этому сайту можно доверять?»
DNS помогает получить сетевую информацию.
Но сам факт example.com → 203.0.113.20 не означает:
example.com — честная компания.
Мошеннический домен тоже может совершенно нормально разрешаться через DNS.
Поэтому:
техническая корректность адресации ≠ добросовестность ресурса.
А что если имя не удается разрешить
Представим: Browser → example.com → name resolution → ERROR.
Тогда браузер еще не дошел до стадии нормального соединения с веб-сервером.
Проблема возникла раньше.
Она может быть связана, например, с: ошибкой в имени; отсутствующей DNS-информацией; проблемой resolver; сетевой недоступностью DNS-сервиса; локальной конфигурацией.
Это важная диагностическая граница
Сравним два случая.
Случай A: Name resolution failed — браузер еще не получил подходящий сетевой адрес.
Случай B: IP found, затем connection failed — имя уже разрешено, проблема находится на следующем этапе.
Это разные ситуации.
Поэтому сообщение об ошибке полезно читать
Например, браузер может сообщить о проблеме, связанной с: DNS; соединением; TLS; HTTP.
Для пользователя все выглядит одинаково:
«сайт не открылся».
Но технически это четыре совершенно разных стадии.
И исправляются они тоже по-разному.
- 1Hostname — имя, которое ввел пользователь.
- 2Name resolution — DNS failure: адрес не получен.
- 3IP address — сетевой адрес найден.
- 4Connection — Connection failure: адрес получен, но транспортное соединение не установлено.
- 5TLS — TLS failure: транспорт есть, защищенное соединение не принято.
- 6HTTP — HTTP error: соединение работает, но веб-приложение вернуло ошибку. «Сайт не работает» — недостаточно точный технический диагноз.
А можно открыть сайт прямо по IP?
Иногда технически можно попробовать обратиться к https://203.0.113.20.
Но это не универсальная замена доменному имени.
Почему?
Потому что: один IP может обслуживать несколько сайтов; серверу может быть важно знать hostname; TLS-сертификат обычно проверяется относительно имени; инфраструктура может ожидать обращение именно по домену.
Поэтому IP-адрес и URL с доменным именем — не взаимозаменяемые сущности.
Name resolution еще не устанавливает соединение
Это еще одно важное разделение.
После получения example.com → 203.0.113.20 браузер пока только узнал:
куда можно попытаться подключиться.
Дальше еще нужно: IP address → transport connection → TLS → HTTP.
DNS не открывает сайт сам по себе.
Он помогает найти сетевое направление.
Вся Часть 2 в одной схеме
Emma вводит https://academy.example.com.
Дальше: browser checks available cached information → need new resolution? → DNS resolver → one or more IP addresses → browser selects suitable address → next stage: establish connection.
Именно на следующем этапе начинается настоящий транспортный обмен с удаленной системой.
Где здесь может находиться атака
Если пользователь вводит exchange.example, а его каким-то образом направляют не туда, куда ожидалось, это потенциально опасно.
Поэтому в реальных системах существуют дополнительные защитные механизмы.
В частности: HTTPS проверяет идентичность сервера относительно доменного имени; существуют защищенные варианты передачи DNS; существует DNSSEC для проверки подлинности определенных DNS-данных.
Но сейчас мы только отмечаем эти механизмы.
Подробно DNS-защиту разберем в Уроке 11, HTTPS — в Уроке 12.
Важно: защищенный DNS и HTTPS — не одно и то же
Защищенный DNS может помочь защитить сам DNS-обмен.
HTTPS решает другую задачу:
защищает соединение браузера с веб-сервисом и проверяет сертификат сервера.
Один механизм не заменяет другой.
Это хороший пример общего правила KRYPTAION:
сначала определяем, какую именно проблему решает механизм, и только потом оцениваем его защиту.
Главное, что нужно запомнить
- Браузеру недостаточно знать доменное имя — ему нужен сетевой адрес.
- Процесс получения сетевой информации по имени называется разрешением имени.
- DNS помогает сопоставлять доменные имена с сетевой информацией, включая IP-адреса.
- Браузер или операционная система могут использовать DNS-кеш и не выполнять новый запрос каждый раз.
- DNS-кеш хранится ограниченное время.
- DNS resolver обрабатывает запросы на получение DNS-информации.
- Сайт может иметь несколько IPv4- и IPv6-адресов.
- Разные пользователи могут получить разные адреса одного сервиса.
- CDN и распределенная инфраструктура позволяют обслуживать пользователей из разных сетевых точек.
- Один IP-адрес не обязательно соответствует одному физическому серверу.
- Один IP может обслуживать несколько доменных имен.
- DNS помогает найти сетевое назначение, но не доказывает добросовестность сайта.
- Ошибка DNS и ошибка сетевого соединения происходят на разных стадиях.
- Получение IP-адреса еще не означает, что соединение с сервером установлено.
- DNS и HTTPS решают разные задачи безопасности.
Что дальше
Теперь браузер получил подходящий адрес.
Например: academy.example.com → 203.0.113.20.
Но между:
«Я знаю адрес»
и:
«Я могу обмениваться данными с сервером»
есть еще один этап.
Браузеру нужно установить транспортное взаимодействие.
Что именно происходит при TCP connection?
Почему иногда браузер использует QUIC?
Что такое latency первого соединения?
И почему открытие сайта не начинается сразу с HTTP-запроса?
Продолжаем — в следующей части — «Как устанавливается соединение».
- Браузеру недостаточно знать доменное имя — ему нужен сетевой адрес.
- Процесс получения сетевой информации по имени называется разрешением имени.
- DNS помогает сопоставлять доменные имена с сетевой информацией, включая IP-адреса.
- Браузер или операционная система могут использовать DNS-кеш и не выполнять новый запрос каждый раз.
- DNS-кеш хранится ограниченное время.
- DNS resolver обрабатывает запросы на получение DNS-информации.
- Сайт может иметь несколько IPv4- и IPv6-адресов.
- Разные пользователи могут получить разные адреса одного сервиса.
- CDN и распределенная инфраструктура позволяют обслуживать пользователей из разных сетевых точек.
- Один IP-адрес не обязательно соответствует одному физическому серверу.
- Один IP может обслуживать несколько доменных имен.
- DNS помогает найти сетевое назначение, но не доказывает добросовестность сайта.
- Ошибка DNS и ошибка сетевого соединения происходят на разных стадиях.
- Получение IP-адреса еще не означает, что соединение с сервером установлено.
- DNS и HTTPS решают разные задачи безопасности.
The browser knows the name. The network needs an address
Emma Lee types https://academy.example.com.
For a human, this is convenient.
You can remember academy.example.com instead of something like 203.0.113.20.
But Internet routing works with network addresses.
So after parsing the URL, the browser needs to solve a task:
Which IP address is the name `academy.example.com` associated with?
Only after that can it move on to establishing a network connection.
Name and IP address are different things
Simplified: academy.example.com is a name, and 203.0.113.20 is a network address.
Important:
a name is not the IP address itself.
There is a matching mechanism between them.
This is what DNS is for
We already encountered DNS — Domain Name System.
At the level of this lesson, one function is enough for us:
DNS helps find out which network addresses are associated with a particular domain name.
Simplified: academy.example.com → DNS → 203.0.113.20.
But this doesn't yet mean that the browser necessarily starts a new DNS request out to the Internet every time.
First, the browser may already know the answer
Let's imagine that Emma opened this site a few minutes ago.
The system may already remember: academy.example.com → 203.0.113.20.
That is, before reaching outward, the browser or operating system can use stored information.
This is a DNS cache.
Its job:
not to do the same work again without need.
- 1Browser checks cached information — first, the browser or operating system checks whether a stored answer already exists.
- 2Cached result found — if an answer already exists, no new DNS request is made.
- 3DNS resolver — if no suitable cache exists, a request is sent to a DNS resolver.
- 4IP address(es) — one or more network addresses associated with the name are obtained.
Why cache DNS
Without a cache, the scenario might look like this: opened the page → asked DNS; refreshed the page → asked DNS again; opened another tab → asked DNS again.
This would create: extra requests; extra delay; additional load.
That's why the obtained result can be reused for some time.
But the cache should not live forever
Today the name might lead to 203.0.113.20, and tomorrow the service might move to 203.0.113.45.
If the old answer is kept indefinitely, the browser will keep looking for the server where it may no longer be.
That's why DNS information has a limited lifetime.
Later, in Lesson 11, we'll get acquainted with the concept of DNS TTL.
For now, it's enough to remember:
the DNS cache is temporary.
If there is no answer in the cache
Then the system needs to ask a DNS resolver.
Simplified: browser → operating system → DNS resolver → answer → IP address.
In reality, the details depend on the device, the browser, and the settings.
Who provides the DNS resolver
This can be, for example: an internet provider; an organization; a public DNS service; local infrastructure; a secure DNS service configured by the browser or operating system.
That's why the phrase:
"my provider always provides DNS"
is not a universal rule.
The browser can also participate more actively
A modern browser does not necessarily just tell the operating system:
"Handle it yourself."
Depending on the configuration, it can: have its own DNS cache; use the system resolver; use a secure DNS mechanism; apply its own address-selection logic.
For a beginner, what matters is not which component made a particular request.
What matters is understanding the overall chain: name → name resolution → network address.
What "resolving a name" means
This process is often called name resolution.
In our case: academy.example.com → name resolution → IP address.
The answer may contain IPv4
For example: academy.example.com → 203.0.113.20.
This is an IPv4 address.
Or IPv6
For example, the system might receive an address like 2001:db8::20.
This is already IPv6.
In Lesson 11 we'll go over IPv4 and IPv6 in more detail.
For now, you only need to understand:
a modern site may have IPv4, IPv6, or both types of addresses.
One name can have several addresses
For example: academy.example.com → 203.0.113.20, 203.0.113.21, 203.0.113.22.
This is completely normal.
Why might a service need several addresses?
For example: multiple servers; load distribution; redundancy; different points of presence.
That's why:
domain name ≠ necessarily one IP ≠ necessarily one physical server.
A site can be closer than it seems
Large services often use a CDN — Content Delivery Network.
For example, Emma is located in Europe.
Instead of loading an image from a server on another continent, the system might direct her to a closer CDN point.
Conceptually: Emma → nearest suitable CDN location → content.
This can reduce delay
We already know that physical distance and the network route affect latency.
If the data is available closer to the user, the path (Emma → nearby server) can turn out shorter than Emma → another continent → server.
That's exactly why the same global service can actually serve different users from different data centers.
- 1IP A — Server location A, one of the possible addresses of the name.
- 2IP B — Server location B, another possible address of the same name.
- 3IP C — CDN location C, the delivery point closest to the user. The specific answer may depend on the service's infrastructure and the network situation.
Two users can get different answers
Emma asks: Where is example.com? — and gets 203.0.113.20.
Alex, on a different network, might get 203.0.113.80.
This is not necessarily an error.
The service may take into account: geographic placement; network topology; load balancing; infrastructure availability.
Does an IP address mean we found one physical server?
No.
Behind the address there can be: IP → Load Balancer → Server A, Server B, Server C.
Or: IP → CDN → distributed infrastructure.
We already encountered this in Lesson 9.
A network address is a point of network interaction.
It is not obliged to reveal the internal architecture of the service.
And conversely: one IP can serve several sites
Let's imagine 203.0.113.20.
On the same infrastructure there might be running: site-a.example, site-b.example, site-c.example.
That is:
one IP ≠ necessarily one site.
Later we'll see how HTTPS and HTTP help server infrastructure understand which name the client is addressing.
The browser doesn't need "some site," it needs a specific name
This matters for security.
Emma wants to open exchange.example.
It's not enough to get:
some server on the Internet.
The browser must work specifically with the infrastructure associated with the requested name.
And with HTTPS, later it will also be necessary to cryptographically verify:
does the server really have the right to represent this name?
That's why DNS and HTTPS solve different tasks.
DNS does not answer the question "can this site be trusted?"
DNS helps obtain network information.
But the mere fact that example.com → 203.0.113.20 does not mean:
example.com is an honest company.
A scam domain can also resolve completely normally through DNS.
That's why:
technical correctness of addressing ≠ trustworthiness of the resource.
What if the name cannot be resolved
Let's imagine: Browser → example.com → name resolution → ERROR.
Then the browser hasn't even reached the stage of a normal connection to the web server yet.
The problem arose earlier.
It could be related, for example, to: an error in the name; missing DNS information; a resolver problem; network unavailability of the DNS service; local configuration.
This is an important diagnostic boundary
Let's compare two cases.
Case A: Name resolution failed — the browser has not yet obtained a suitable network address.
Case B: IP found, then connection failed — the name is already resolved, the problem is at the next stage.
These are different situations.
That's why it's useful to read the error message
For example, the browser might report a problem related to: DNS; the connection; TLS; HTTP.
To the user, everything looks the same:
"the site didn't open."
But technically these are four completely different stages.
And they are fixed differently, too.
- 1Hostname — the name the user entered.
- 2Name resolution — DNS failure: no address obtained.
- 3IP address — network address found.
- 4Connection — Connection failure: address obtained, but the transport connection was not established.
- 5TLS — TLS failure: transport exists, the secure connection was not accepted.
- 6HTTP — HTTP error: the connection works, but the web application returned an error. "The site isn't working" is not a sufficiently precise technical diagnosis.
Can you open a site directly by IP?
Sometimes it's technically possible to try reaching https://203.0.113.20.
But this is not a universal substitute for the domain name.
Why?
Because: one IP can serve several sites; the server may need to know the hostname; the TLS certificate is usually checked against a name; the infrastructure may expect access specifically by the domain.
That's why an IP address and a URL with a domain name are not interchangeable entities.
Name resolution does not yet establish a connection
This is another important distinction.
After obtaining example.com → 203.0.113.20, the browser has so far only learned:
where it can try to connect.
Next, it still needs: IP address → transport connection → TLS → HTTP.
DNS does not open the site by itself.
It helps find the network destination.
All of Part 2 in one diagram
Emma types https://academy.example.com.
Next: browser checks available cached information → need new resolution? → DNS resolver → one or more IP addresses → browser selects suitable address → next stage: establish connection.
It's at the next stage that the actual transport exchange with the remote system begins.
Where an attack could fit in here
If a user enters exchange.example, and is somehow directed somewhere other than expected, this is potentially dangerous.
That's why real systems have additional protective mechanisms.
In particular: HTTPS verifies the server's identity against the domain name; secure variants of DNS transport exist; DNSSEC exists to verify the authenticity of certain DNS data.
But for now, we're just noting these mechanisms.
We'll cover DNS protection in detail in Lesson 11, and HTTPS in Lesson 12.
Important: secure DNS and HTTPS are not the same thing
Secure DNS can help protect the DNS exchange itself.
HTTPS solves a different task:
it protects the browser's connection with the web service and verifies the server's certificate.
One mechanism does not replace the other.
This is a good example of a general KRYPTAION rule:
first determine exactly which problem a mechanism solves, and only then evaluate its protection.
The main thing to remember
- It's not enough for the browser to know the domain name — it needs a network address.
- The process of obtaining network information from a name is called name resolution.
- DNS helps match domain names to network information, including IP addresses.
- The browser or operating system can use a DNS cache and avoid making a new request every time.
- The DNS cache is stored for a limited time.
- A DNS resolver processes requests for DNS information.
- A site can have several IPv4 and IPv6 addresses.
- Different users can get different addresses for the same service.
- CDN and distributed infrastructure allow serving users from different network points.
- One IP address does not necessarily correspond to one physical server.
- One IP can serve several domain names.
- DNS helps find the network destination, but does not prove a site's trustworthiness.
- A DNS error and a network connection error occur at different stages.
- Obtaining an IP address does not yet mean that a connection to the server has been established.
- DNS and HTTPS solve different security tasks.
What's next
Now the browser has obtained a suitable address.
For example: academy.example.com → 203.0.113.20.
But between:
"I know the address"
and:
"I can exchange data with the server"
there is still another stage.
The browser needs to establish a transport interaction.
What exactly happens during a TCP connection?
Why does the browser sometimes use QUIC?
What is first-connection latency?
And why doesn't opening a site start right away with an HTTP request?
We continue — in the next part — "How a connection is established."
- It's not enough for a browser to know a domain name — it needs a network address.
- The process of getting network information from a name is called name resolution.
- DNS helps match domain names to network information, including IP addresses.
- The browser or operating system can use a DNS cache instead of making a new query every time.
- A DNS cache is kept only for a limited time.
- A DNS resolver handles requests for DNS information.
- A site can have several IPv4 and IPv6 addresses.
- Different users can get different addresses for the same service.
- A CDN and distributed infrastructure let users be served from different network locations.
- One IP address doesn't necessarily correspond to one physical server.
- One IP can serve several domain names.
- DNS helps find the network destination, but doesn't prove a site is trustworthy.
- A DNS error and a network-connection error happen at different stages.
- Getting an IP address still doesn't mean a connection to the server has been established.
- DNS and HTTPS solve different security problems.
Ο browser γνωρίζει το όνομα. Το δίκτυο χρειάζεται διεύθυνση
Η Emma Lee πληκτρολογεί https://academy.example.com.
Για τον άνθρωπο αυτό είναι βολικό.
Μπορεί κανείς να θυμάται το academy.example.com αντί για κάτι σαν το 203.0.113.20.
Όμως η δρομολόγηση του Internet λειτουργεί με διευθύνσεις δικτύου.
Γι' αυτό, μετά την ανάλυση του URL, ο browser πρέπει να λύσει ένα πρόβλημα:
Με ποια διεύθυνση IP συνδέεται το όνομα `academy.example.com`;
Και μόνο μετά από αυτό μπορεί να προχωρήσει στην εγκαθίδρυση της σύνδεσης δικτύου.
Το όνομα και η διεύθυνση IP είναι διαφορετικά πράγματα
Απλοποιημένα: το academy.example.com είναι όνομα, ενώ το 203.0.113.20 είναι διεύθυνση δικτύου.
Σημαντικό:
το όνομα δεν είναι η ίδια η διεύθυνση IP.
Μεταξύ τους υπάρχει ένας μηχανισμός αντιστοίχισης.
Γι' αυτό χρειάζεται το DNS
Έχουμε ήδη συναντήσει το DNS — Domain Name System.
Στο επίπεδο αυτού του μαθήματος μας αρκεί μία λειτουργία:
Το DNS βοηθά να μάθουμε ποιες διευθύνσεις δικτύου συνδέονται με ένα συγκεκριμένο domain name.
Απλοποιημένα: academy.example.com → DNS → 203.0.113.20.
Όμως αυτό δεν σημαίνει ακόμα ότι ο browser κάθε φορά ξεκινά υποχρεωτικά ένα νέο αίτημα DNS προς το Internet.
Αρχικά, ο browser μπορεί να γνωρίζει ήδη την απάντηση
Ας φανταστούμε ότι η Emma είχε ανοίξει αυτόν τον ιστότοπο πριν από λίγα λεπτά.
Το σύστημα μπορεί να θυμάται ήδη: academy.example.com → 203.0.113.20.
Δηλαδή, πριν απευθυνθεί προς τα έξω, ο browser ή το λειτουργικό σύστημα μπορούν να χρησιμοποιήσουν αποθηκευμένες πληροφορίες.
Αυτό είναι το DNS cache.
Ο σκοπός του:
να μην εκτελείται η ίδια εργασία ξανά χωρίς λόγο.
- 1Browser checks cached information — αρχικά ο browser ή το λειτουργικό σύστημα ελέγχουν αν υπάρχει ήδη αποθηκευμένη απάντηση.
- 2Cached result found — αν η απάντηση υπάρχει ήδη, δεν εκτελείται νέο αίτημα DNS.
- 3DNS resolver — αν δεν υπάρχει κατάλληλη προσωρινή μνήμη, αποστέλλεται αίτημα στον DNS resolver.
- 4IP address(es) — λαμβάνεται μία ή περισσότερες διευθύνσεις δικτύου που συνδέονται με το όνομα.
Γιατί να γίνεται caching του DNS
Χωρίς caching, το σενάριο θα μπορούσε να μοιάζει ως εξής: άνοιξε τη σελίδα → ρώτησε το DNS· ανανέωσε τη σελίδα → ρώτησε ξανά το DNS· άνοιξε άλλη μία καρτέλα → ρώτησε ξανά το DNS.
Αυτό θα δημιουργούσε: περιττά αιτήματα· περιττή καθυστέρηση· επιπλέον φόρτο.
Γι' αυτό το αποτέλεσμα που λαμβάνεται μπορεί να επαναχρησιμοποιηθεί για κάποιο διάστημα.
Όμως η προσωρινή μνήμη δεν πρέπει να ζει για πάντα
Σήμερα το όνομα μπορεί να οδηγεί στο 203.0.113.20, ενώ αύριο η υπηρεσία μπορεί να μετακινηθεί στο 203.0.113.45.
Αν η παλιά απάντηση αποθηκεύεται επ' αόριστον, ο browser θα συνεχίσει να αναζητά τον server εκεί όπου ενδέχεται να μην υπάρχει πια.
Γι' αυτό οι πληροφορίες DNS έχουν περιορισμένη διάρκεια ισχύος.
Αργότερα, στο Μάθημα 11, θα γνωρίσουμε την έννοια του DNS TTL.
Προς το παρόν αρκεί να θυμόμαστε:
Το DNS cache είναι προσωρινό.
Αν η απάντηση δεν υπάρχει στην προσωρινή μνήμη
Τότε το σύστημα πρέπει να ρωτήσει τον DNS resolver.
Απλοποιημένα: browser → operating system → DNS resolver → απάντηση → IP address.
Στην πραγματικότητα οι λεπτομέρειες εξαρτώνται από τη συσκευή, τον browser και τις ρυθμίσεις.
Ποιος παρέχει τον DNS resolver
Αυτό μπορεί να είναι, για παράδειγμα: ο πάροχος Internet· ένας οργανισμός· μια δημόσια υπηρεσία DNS· τοπική υποδομή· μια ασφαλής υπηρεσία DNS, ρυθμισμένη από τον browser ή το λειτουργικό σύστημα.
Γι' αυτό η φράση:
«Το DNS το παρέχει πάντα ο πάροχός μου»
δεν αποτελεί καθολικό κανόνα.
Ο browser μπορεί επίσης να συμμετέχει πιο ενεργά
Ένας σύγχρονος browser δεν λέει απαραίτητα απλώς στο λειτουργικό σύστημα:
«Κανόνισέ το εσύ».
Ανάλογα με τη διαμόρφωση, μπορεί: να διαθέτει δικό του DNS cache· να χρησιμοποιεί τον resolver του συστήματος· να χρησιμοποιεί έναν ασφαλή μηχανισμό DNS· να εφαρμόζει τη δική του λογική επιλογής διευθύνσεων.
Για έναν αρχάριο δεν έχει σημασία ποιο συστατικό έκανε το συγκεκριμένο αίτημα.
Σημασία έχει η κατανόηση της συνολικής αλυσίδας: όνομα → επίλυση ονόματος → διεύθυνση δικτύου.
Τι σημαίνει «επίλυση ονόματος»
Αυτή η διαδικασία ονομάζεται συχνά name resolution, επίλυση ονόματος.
Στην περίπτωσή μας: academy.example.com → name resolution → IP address.
Η απάντηση μπορεί να περιέχει IPv4
Για παράδειγμα: academy.example.com → 203.0.113.20.
Αυτή είναι διεύθυνση IPv4.
Ή IPv6
Για παράδειγμα, το σύστημα μπορεί να λάβει μια διεύθυνση όπως η 2001:db8::20.
Αυτή είναι πλέον IPv6.
Στο Μάθημα 11 θα εξετάσουμε τα IPv4 και IPv6 αναλυτικότερα.
Προς το παρόν αρκεί να κατανοήσουμε:
ένας σύγχρονος ιστότοπος μπορεί να έχει IPv4, IPv6, ή και τους δύο τύπους διευθύνσεων.
Ένα όνομα μπορεί να έχει πολλές διευθύνσεις
Για παράδειγμα: academy.example.com → 203.0.113.20, 203.0.113.21, 203.0.113.22.
Αυτό είναι απολύτως φυσιολογικό.
Γιατί μια υπηρεσία μπορεί να χρειάζεται πολλές διευθύνσεις;
Για παράδειγμα: πολλαπλοί servers· κατανομή φόρτου· εφεδρεία· διαφορετικά σημεία παρουσίας.
Γι' αυτό:
domain name ≠ υποχρεωτικά μία IP ≠ υποχρεωτικά ένας φυσικός server.
Ένας ιστότοπος μπορεί να βρίσκεται πιο κοντά απ' ό,τι φαίνεται
Μεγάλες υπηρεσίες χρησιμοποιούν συχνά CDN — Content Delivery Network.
Για παράδειγμα, η Emma βρίσκεται στην Ευρώπη.
Αντί να φορτώσει την εικόνα από έναν server σε άλλη ήπειρο, το σύστημα μπορεί να την κατευθύνει προς ένα πιο κοντινό σημείο CDN.
Εννοιολογικά: Emma → nearest suitable CDN location → content.
Αυτό μπορεί να μειώνει την καθυστέρηση
Ήδη γνωρίζουμε ότι η φυσική απόσταση και η διαδρομή δικτύου επηρεάζουν το latency.
Αν τα δεδομένα είναι διαθέσιμα πιο κοντά στον χρήστη, η διαδρομή (Emma → nearby server) μπορεί να αποδειχθεί συντομότερη από την Emma → another continent → server.
Γι' αυτό ακριβώς η ίδια παγκόσμια υπηρεσία μπορεί στην πράξη να εξυπηρετεί διαφορετικούς χρήστες από διαφορετικά data centers.
- 1IP A — Server location A, μία από τις πιθανές διευθύνσεις του ονόματος.
- 2IP B — Server location B, άλλη πιθανή διεύθυνση του ίδιου ονόματος.
- 3IP C — CDN location C, το πλησιέστερο στον χρήστη σημείο διανομής περιεχομένου. Η συγκεκριμένη απάντηση μπορεί να εξαρτάται από την υποδομή της υπηρεσίας και τη δικτυακή κατάσταση.
Δύο χρήστες μπορούν να λάβουν διαφορετικές απαντήσεις
Η Emma ρωτά: Where is example.com? — και λαμβάνει το 203.0.113.20.
Ο Alex, σε άλλο δίκτυο, μπορεί να λάβει το 203.0.113.80.
Αυτό δεν είναι απαραίτητα σφάλμα.
Η υπηρεσία μπορεί να λαμβάνει υπόψη: τη γεωγραφική τοποθεσία· την τοπολογία δικτύου· την εξισορρόπηση φόρτου· τη διαθεσιμότητα της υποδομής.
Σημαίνει η διεύθυνση IP ότι βρήκαμε έναν φυσικό server;
Όχι.
Πίσω από τη διεύθυνση μπορεί να βρίσκεται: IP → Load Balancer → Server A, Server B, Server C.
Ή: IP → CDN → distributed infrastructure.
Το έχουμε ήδη συναντήσει στο Μάθημα 9.
Η διεύθυνση δικτύου είναι ένα σημείο δικτυακής αλληλεπίδρασης.
Δεν είναι υποχρεωμένη να αποκαλύπτει την εσωτερική αρχιτεκτονική της υπηρεσίας.
Και αντίστροφα: μία IP μπορεί να εξυπηρετεί πολλούς ιστότοπους
Ας φανταστούμε το 203.0.113.20.
Στην ίδια υποδομή μπορούν να λειτουργούν: site-a.example, site-b.example, site-c.example.
Δηλαδή:
μία IP ≠ υποχρεωτικά ένας ιστότοπος.
Αργότερα θα δούμε πώς τα HTTPS και HTTP βοηθούν την υποδομή του server να κατανοήσει σε ποιο όνομα απευθύνεται ο client.
Ο browser δεν χρειάζεται «έναν ιστότοπο γενικά», αλλά ένα συγκεκριμένο όνομα
Αυτό είναι σημαντικό για την ασφάλεια.
Η Emma θέλει να ανοίξει το exchange.example.
Δεν αρκεί να λάβει:
κάποιον οποιονδήποτε server στο Internet.
Ο browser πρέπει να συνεργάζεται ακριβώς με την υποδομή που συνδέεται με το αιτούμενο όνομα.
Ενώ με το HTTPS θα χρειαστεί αργότερα επίσης να επαληθευτεί κρυπτογραφικά:
έχει πράγματι ο server το δικαίωμα να αντιπροσωπεύει αυτό το όνομα;
Να γιατί το DNS και το HTTPS λύνουν διαφορετικά προβλήματα.
Το DNS δεν απαντά στο ερώτημα «μπορούμε να εμπιστευτούμε αυτόν τον ιστότοπο;»
Το DNS βοηθά στη λήψη πληροφοριών δικτύου.
Όμως το ίδιο το γεγονός example.com → 203.0.113.20 δεν σημαίνει:
η example.com είναι μια έντιμη εταιρεία.
Ένα απατηλό domain μπορεί επίσης να επιλύεται εντελώς κανονικά μέσω DNS.
Γι' αυτό:
η τεχνική ορθότητα της διευθυνσιοδότησης ≠ η αξιοπιστία του πόρου.
Και τι γίνεται αν το όνομα δεν μπορεί να επιλυθεί
Ας φανταστούμε: Browser → example.com → name resolution → ERROR.
Τότε ο browser δεν έχει φτάσει ακόμα στο στάδιο της κανονικής σύνδεσης με τον web server.
Το πρόβλημα προέκυψε νωρίτερα.
Μπορεί να σχετίζεται, για παράδειγμα, με: σφάλμα στο όνομα· ελλείπουσες πληροφορίες DNS· πρόβλημα του resolver· δικτυακή απροσπελασιμότητα της υπηρεσίας DNS· τοπική διαμόρφωση.
Αυτό είναι ένα σημαντικό διαγνωστικό όριο
Ας συγκρίνουμε δύο περιπτώσεις.
Περίπτωση A: Name resolution failed — ο browser δεν έχει λάβει ακόμα κατάλληλη διεύθυνση δικτύου.
Περίπτωση B: IP found, στη συνέχεια connection failed — το όνομα έχει ήδη επιλυθεί, το πρόβλημα βρίσκεται στο επόμενο στάδιο.
Αυτές είναι διαφορετικές καταστάσεις.
Γι' αυτό είναι χρήσιμο να διαβάζουμε το μήνυμα σφάλματος
Για παράδειγμα, ο browser μπορεί να αναφέρει πρόβλημα σχετικό με: το DNS· τη σύνδεση· το TLS· το HTTP.
Για τον χρήστη όλα φαίνονται ίδια:
«ο ιστότοπος δεν άνοιξε».
Όμως τεχνικά πρόκειται για τέσσερα εντελώς διαφορετικά στάδια.
Και διορθώνονται επίσης με διαφορετικό τρόπο.
- 1Hostname — το όνομα που εισήγαγε ο χρήστης.
- 2Name resolution — DNS failure: η διεύθυνση δεν λήφθηκε.
- 3IP address — η διεύθυνση δικτύου βρέθηκε.
- 4Connection — Connection failure: η διεύθυνση λήφθηκε, αλλά η σύνδεση μεταφοράς δεν εγκαθιδρύθηκε.
- 5TLS — TLS failure: η μεταφορά υπάρχει, αλλά η ασφαλής σύνδεση δεν έγινε αποδεκτή.
- 6HTTP — HTTP error: η σύνδεση λειτουργεί, αλλά η εφαρμογή web επέστρεψε σφάλμα. «Ο ιστότοπος δεν λειτουργεί» — δεν αποτελεί επαρκώς ακριβή τεχνική διάγνωση.
Μπορεί κανείς να ανοίξει τον ιστότοπο απευθείας μέσω IP;
Μερικές φορές τεχνικά είναι δυνατόν να δοκιμάσει κανείς να απευθυνθεί στο https://203.0.113.20.
Όμως αυτό δεν αποτελεί καθολική αντικατάσταση του domain name.
Γιατί;
Επειδή: μία IP μπορεί να εξυπηρετεί πολλούς ιστότοπους· για τον server μπορεί να είναι σημαντικό να γνωρίζει το hostname· το πιστοποιητικό TLS συνήθως ελέγχεται σε σχέση με το όνομα· η υποδομή μπορεί να αναμένει αίτημα ακριβώς μέσω του domain.
Γι' αυτό η διεύθυνση IP και το URL με το domain name δεν είναι εναλλάξιμες οντότητες.
Το Name resolution δεν εγκαθιδρύει ακόμα σύνδεση
Αυτός είναι ακόμα ένας σημαντικός διαχωρισμός.
Μετά τη λήψη του example.com → 203.0.113.20, ο browser έμαθε προς το παρόν μόνο:
πού μπορεί να δοκιμάσει να συνδεθεί.
Στη συνέχεια χρειάζεται ακόμα: IP address → transport connection → TLS → HTTP.
Το DNS δεν ανοίγει τον ιστότοπο από μόνο του.
Βοηθά να βρεθεί η δικτυακή κατεύθυνση.
Ολόκληρο το Μέρος 2 σε ένα διάγραμμα
Η Emma πληκτρολογεί https://academy.example.com.
Στη συνέχεια: browser checks available cached information → need new resolution? → DNS resolver → one or more IP addresses → browser selects suitable address → next stage: establish connection.
Ακριβώς στο επόμενο στάδιο αρχίζει η πραγματική ανταλλαγή μεταφοράς με το απομακρυσμένο σύστημα.
Πού μπορεί να βρίσκεται εδώ μια επίθεση
Αν ο χρήστης πληκτρολογεί exchange.example και με κάποιον τρόπο κατευθύνεται όχι εκεί όπου αναμενόταν, αυτό είναι δυνητικά επικίνδυνο.
Γι' αυτό στα πραγματικά συστήματα υπάρχουν επιπλέον προστατευτικοί μηχανισμοί.
Συγκεκριμένα: το HTTPS επαληθεύει την ταυτότητα του server σε σχέση με το domain name· υπάρχουν ασφαλείς παραλλαγές μετάδοσης του DNS· υπάρχει το DNSSEC για την επαλήθευση της γνησιότητας συγκεκριμένων δεδομένων DNS.
Όμως προς το παρόν απλώς σημειώνουμε αυτούς τους μηχανισμούς.
Την προστασία του DNS θα την εξετάσουμε αναλυτικά στο Μάθημα 11, το HTTPS — στο Μάθημα 12.
Σημαντικό: το ασφαλές DNS και το HTTPS δεν είναι το ίδιο πράγμα
Το ασφαλές DNS μπορεί να βοηθήσει στην προστασία της ίδιας της ανταλλαγής DNS.
Το HTTPS λύνει διαφορετικό πρόβλημα:
προστατεύει τη σύνδεση του browser με την υπηρεσία web και επαληθεύει το πιστοποιητικό του server.
Ο ένας μηχανισμός δεν αντικαθιστά τον άλλο.
Αυτό είναι ένα καλό παράδειγμα του γενικού κανόνα του KRYPTAION:
πρώτα προσδιορίζουμε ποιο ακριβώς πρόβλημα λύνει ο μηχανισμός, και μόνο μετά αξιολογούμε την προστασία του.
Τα βασικά που πρέπει να θυμόμαστε
- Δεν αρκεί ο browser να γνωρίζει το domain name — χρειάζεται διεύθυνση δικτύου.
- Η διαδικασία λήψης πληροφοριών δικτύου βάσει ονόματος ονομάζεται επίλυση ονόματος.
- Το DNS βοηθά στην αντιστοίχιση domain names με πληροφορίες δικτύου, συμπεριλαμβανομένων των διευθύνσεων IP.
- Ο browser ή το λειτουργικό σύστημα μπορούν να χρησιμοποιούν το DNS cache και να μην εκτελούν νέο αίτημα κάθε φορά.
- Το DNS cache αποθηκεύεται για περιορισμένο χρονικό διάστημα.
- Ο DNS resolver επεξεργάζεται αιτήματα για τη λήψη πληροφοριών DNS.
- Ένας ιστότοπος μπορεί να έχει πολλές διευθύνσεις IPv4 και IPv6.
- Διαφορετικοί χρήστες μπορούν να λάβουν διαφορετικές διευθύνσεις της ίδιας υπηρεσίας.
- Το CDN και η κατανεμημένη υποδομή επιτρέπουν την εξυπηρέτηση χρηστών από διαφορετικά σημεία δικτύου.
- Μία διεύθυνση IP δεν αντιστοιχεί υποχρεωτικά σε έναν φυσικό server.
- Μία IP μπορεί να εξυπηρετεί πολλά domain names.
- Το DNS βοηθά να βρεθεί ο δικτυακός προορισμός, αλλά δεν αποδεικνύει την αξιοπιστία του ιστότοπου.
- Το σφάλμα DNS και το σφάλμα σύνδεσης δικτύου συμβαίνουν σε διαφορετικά στάδια.
- Η λήψη μιας διεύθυνσης IP δεν σημαίνει ακόμα ότι η σύνδεση με τον server έχει εγκαθιδρυθεί.
- Το DNS και το HTTPS λύνουν διαφορετικά προβλήματα ασφάλειας.
Τι ακολουθεί
Τώρα ο browser έλαβε κατάλληλη διεύθυνση.
Για παράδειγμα: academy.example.com → 203.0.113.20.
Όμως ανάμεσα:
«Γνωρίζω τη διεύθυνση»
και:
«Μπορώ να ανταλλάσσω δεδομένα με τον server»
υπάρχει ακόμα ένα στάδιο.
Ο browser πρέπει να εγκαθιδρύσει την αλληλεπίδραση μεταφοράς.
Τι ακριβώς συμβαίνει κατά τη διάρκεια της TCP connection;
Γιατί μερικές φορές ο browser χρησιμοποιεί QUIC;
Τι είναι το latency της πρώτης σύνδεσης;
Και γιατί το άνοιγμα του ιστότοπου δεν ξεκινά αμέσως με ένα αίτημα HTTP;
Συνεχίζουμε — στο επόμενο μέρος — «Πώς εγκαθιδρύεται η σύνδεση».
- Δεν αρκεί για το πρόγραμμα περιήγησης να γνωρίζει ένα όνομα τομέα — χρειάζεται μια δικτυακή διεύθυνση.
- Η διαδικασία λήψης δικτυακών πληροφοριών από ένα όνομα ονομάζεται επίλυση ονόματος.
- Το DNS βοηθά να αντιστοιχίζονται τα ονόματα τομέα με δικτυακές πληροφορίες, συμπεριλαμβανομένων των διευθύνσεων IP.
- Το πρόγραμμα περιήγησης ή το λειτουργικό σύστημα μπορούν να χρησιμοποιήσουν μια DNS cache αντί να κάνουν νέο ερώτημα κάθε φορά.
- Η DNS cache διατηρείται μόνο για περιορισμένο χρόνο.
- Ένα DNS resolver διαχειρίζεται τα αιτήματα για πληροφορίες DNS.
- Ένας ιστότοπος μπορεί να έχει πολλές διευθύνσεις IPv4 και IPv6.
- Διαφορετικοί χρήστες μπορούν να λάβουν διαφορετικές διευθύνσεις για την ίδια υπηρεσία.
- Ένα CDN και η κατανεμημένη υποδομή επιτρέπουν την εξυπηρέτηση χρηστών από διαφορετικές δικτυακές τοποθεσίες.
- Μία διεύθυνση IP δεν αντιστοιχεί απαραίτητα σε έναν φυσικό server.
- Μία διεύθυνση IP μπορεί να εξυπηρετεί πολλά ονόματα τομέα.
- Το DNS βοηθά να βρεθεί ο δικτυακός προορισμός, αλλά δεν αποδεικνύει ότι ένας ιστότοπος είναι αξιόπιστος.
- Ένα σφάλμα DNS και ένα σφάλμα δικτυακής σύνδεσης συμβαίνουν σε διαφορετικά στάδια.
- Η λήψη μιας διεύθυνσης IP δεν σημαίνει ακόμη ότι έχει καθιερωθεί σύνδεση με τον server.
- Το DNS και το HTTPS λύνουν διαφορετικά προβλήματα ασφάλειας.