🥷 Основы DNS: работа DNS-request'a

С SSH мы закончили, теперь переходим к новой и не менее интересной теме - DNS, процесс начинается с того, что ваш компьютер или устройство отправляет запрос на ближайший DNS-сервер, который обычно предоставляется вашим интернет-провайдером. Этот сервер называется рекурсивным резолвером.

— Если этот сервер знает нужный IP-адрес, он возвращает его вашему браузеру. Если нет, запрос передается на другие DNS-серверы, пока не будет найден правильный адрес.

🕹 Для наглядности представьте, что вы ищете дом example.com:

1. Локальный кеш: сначала браузер проверяет свой локальный кеш на наличие записи для example.com. Если она найдена, используется закешированный IP-адрес.
2. Рекурсивный резолвер: если записи нет в локальном кеше, запрос отправляется на рекурсивный DNS-сервер. Этот сервер выполняет роль посредника, который ищет нужную информацию, обращаясь к другим серверам.
3. Корневые серверы: если рекурсивный сервер не знает IP-адрес, он отправляет запрос на один из корневых серверов. Корневые серверы знают, какой сервер отвечает за каждый домен верхнего уровня (TLD), такой как .com, .net, .org и так далее.
4. Сервер TLD: корневой сервер отвечает, какой сервер управляет доменом .com, и рекурсивный резолвер отправляет запрос на этот сервер.
5. Авторитетный сервер: сервер TLD (например, для .com) отвечает, какой сервер управляет доменом example.com. Рекурсивный резолвер направляет запрос на авторитетный DNS-сервер для example.com, который содержит точные данные о домене.
6. Возвращение IP-адреса: авторитетный сервер возвращает IP-адрес, связанный с example.com, рекурсивному резолверу, который, в свою очередь, возвращает его вашему браузеру.
7. Подключение к веб-сайту: теперь, когда браузер знает IP-адрес, он может отправить запрос непосредственно на сервер, чтобы загрузить содержимое веб-сайта.

❗️ Итак, всё по старому — жду ваших реакций и делаю пост про иерархию DNS

#DNS #Request | 😊 @iscode

🥷 Основы DNS: иерархия

DNS построен по иерархическому принципу, который обеспечивает надежность и масштабируемость системы.

- Каждый из этих уровней играет важную роль в обеспечении надежной и эффективной работы DNS-системы. Корневые серверы, сервера TLD и авторитетные серверы работают вместе, чтобы обеспечить быстрое и точное разрешение доменных имен в IP-адреса.

🕹 Иерархия DNS включает несколько уровней:

1. Корневые серверы: на вершине иерархии находятся корневые серверы. Эти серверы являются начальной точкой для всех DNS-запросов. В мире существует всего 13 корневых серверов, но каждый из них дублирован на множество серверов по всему миру для обеспечения надежности и доступности. Корневые серверы содержат информацию о доменах верхнего уровня (TLD) и направляют запросы к соответствующим серверам.

2. Домен верхнего уровня (TLD): под корневыми серверами находятся сервера доменов верхнего уровня (TLD), таких как .com, .net, .org, .ru и другие. Эти сервера управляют определенными доменными зонами. Например, сервер для домена .com знает, какие авторитетные серверы управляют доменами второго уровня в зоне .com.

— Серверы TLD обеспечивают организацию и управление доменами верхнего уровня и направляют запросы к авторитетным серверам, которые содержат детальную информацию о доменах второго уровня.

3. Авторитетные серверы: на следующем уровне находятся авторитетные DNS-серверы. Эти серверы содержат информацию о конкретных доменах и отвечают на запросы о них. Например, авторитетный сервер для example.com содержит записи, которые указывают на IP-адреса, связанные с этим доменом.

— Авторитетные серверы предоставляют окончательную информацию, необходимую для завершения DNS-запроса.

4. Рекурсивные резолверы: резолвер - это важный компонент системы доменных имен (DNS), который служит посредником между конечным пользователем и сетью DNS-серверов, обеспечивая преобразование доменных имен в IP-адреса. Когда пользователь вводит адрес веб-сайта в браузере или запускает приложение, которое требует доступа к интернет-ресурсам, запрос на преобразование доменного имени в IP-адрес отправляется именно рекурсивному резолверу.

— Резолверы получают запросы от пользователей и выполняют весь процесс поиска нужной информации, обращаясь к другим DNS-серверам. Начинают они с корневых серверов, затем обращаются к серверам TLD и авторитетным серверам, пока не найдут нужный IP-адрес. Рекурсивные резолверы часто предоставляются интернет-провайдерами (ISP) или публичными сервисами, такими как Google Public DNS или Cloudflare DNS. Они кешируют ответы на определённое время, чтобы ускорить последующие запросы к тому же доменному имени.

❗️ Итак, всё по старому — жду ваших реакций и делаю пост про записи DNS и их типы.

#DNS

🥷 Джонни вещает: записи DNS и их типы

Начнём вообще с того, что они представляют из себя основные элементы, которые хранятся на DNS-серверах и обеспечивают маршрутизацию трафика, управление электронной почтой, верификацию данных и др. функции, необходимые для работы интернета 🖥

— Различные типы записей DNS выполняют специфические задачи, обеспечивая эффективное управление и работу доменов. Вот подробное описание наиболее распространенных типов записей DNS:

1. A-записи:
· Функция: преобразование доменного имени в IPv4-адрес.
· Пример использования: при вводе в браузере адреса example.com, A-запись может указать на IP-адрес 192.0.2.1.
· Особенности: A-записи являются основными записями для большинства доменов, связывая доменные имена с их соответствующими IP-адресами.

2. AAAA-записи:
· Функция: преобразование доменного имени в IPv6-адрес.
· Пример использования: для домена example.com, AAAA-запись может указать на IP-адрес 2001:0db8:85a3:0000:0000:8a2e:0370:7334.
· Особенности: используются для обеспечения поддержки IPv6, нового стандарта IP-адресов, который обеспечивает более широкий диапазон адресов по сравнению с IPv4.

3. MX-записи:
· Функция: определение почтовых серверов, ответственных за прием электронной почты для домена.
· Пример использования: MX-запись для example.com может указывать на сервер mail.example.com с приоритетом 10.
· Особенности: включают приоритет, позволяя указать резервные почтовые серверы. Серверы с более низким приоритетом (большим числом) используются, если серверы с более высоким приоритетом недоступны.

4. CNAME-записи:
· Функция: создание алиасов для доменов, перенаправление одного доменного имени на другое.
· Пример использования: CNAME-запись для www.example.com может указывать на example.com.
· Особенности: полезны для упрощения управления доменами и их перенаправления. CNAME-записи не могут существовать одновременно с другими записями для одного и того же домена.

5. TXT-записи:
· Функция: хранение текстовой информации, используемой для различных целей.
· Пример использования: TXT-записи часто используются для верификации домена, для SPF-записей для предотвращения спама, или для DKIM и DMARC для проверки подлинности электронной почты.
· Особенности: гибкость использования, возможность включения различных текстовых данных для множества различных применений.

6. SRV-записи:
· Функция: указание на серверы, предоставляющие определенные услуги, такие как VoIP или IM.
· Пример использования: SRV-запись для протокола SIP может указывать на сервер sip.example.com с определенными параметрами приоритета и веса.
· Особенности: используются для указания конкретных сервисов, поддерживают параметры веса и приоритета для балансировки нагрузки и отказоустойчивости.

7. NS-записи:
· Функция: определение авторитетных серверов имен для домена.
· Пример использования: NS-запись для example.com может указывать на ns1.example.com и ns2.example.com.
· Особенности: определяют, какие DNS-серверы содержат авторитетные записи для домена, обеспечивая делегирование зон.

🕹 Каждый из этих типов записей выполняет свою уникальную роль, обеспечивая надежное и эффективное функционирование доменных имен и связанных с ними интернет-сервисов.

🥷 Джонни вещает: 12 заблуждений сетевого администратора

1. Комментировать изменения в конфигах — не нужно. На память вы не жалуетесь, amiright?
2. QoS — не нужен. Всегда проще купить канал, заведомо превышающий потребности компании.
3. Бессмысленно проверять возможность удаленного управления оборудованием перед отправкой в удаленный офис.
Вы — профессионал и не могли ошибиться в настройке такой элементарной функции.
4. Устная договоренность с сетевиками ISP является полноценной разновидностью SLA.
5. Сертификация — незначима. Экзамены всегда можно сдать с помощью дампов.
6. Прямой доступ через serial к оборудованию — анахронизм. IP-интерфейс — удобнее.
7. С системой мониторинга должен работать соответствующий отдел. Сотрудники там опытные, разберутся, что к чему.
8. Во внутренних маршрутах никогда не будет более 15 хопов.
9. Остановка работы компании из-за разрыва линка со стороны ISP — не ваша вина.
10. Одного гигабитного линка будет достаточно для всех.
11. Никто никогда не соединит 2 сетевые розетки патчкордом. Зачем это делать?
12. Какой смысл ставить 2 маршрутизатора в ядре, если загрузка одного менее 50%?

🌃 Как создавать Kubernetes секреты из Vault, используя external-secrets-operator

Бывают случаи, когда инженеры хранят секретные данные, ключи, токены в открытом виде или в переменных Gitlab. В Kubernetes для хранения данных, которые нежелательно показывать широкому кругу лиц, предусмотрены секреты.

— В этой статье предлагаю рассмотреть безопасный способ передавать, синхронизировать, интегрировать секреты напрямую из Vault в Kubernetes – с помощью метода аутентификации AppRole, используя external-secrets-operator.

↘ habr.com

#Kubernetes #Vault #DevOps | 😊 @iscode

🥷 Джонни вещает: настройка Git сервера с нуля

В данной статье я подробно опишу процесс настройки системы управления репозиториями, используя лишь возможности самого Git.

Этот подход может показаться необычным, но он позволяет лучше понять внутренние механизмы работы Git и получить новые навыки, которые могут оказаться полезными в вашей карьере DevOps.

— В этом руководстве мы рассмотрим, как настроить собственный Git сервер на базе Debian 12. Весь процесс настройки Git сервера поделен на следующие задачи:
1. настройка SSH;
2. создание пользователей;
3. инициализация проекта;
4. конфигурация Git‑демона;
5. настройка веб‑интерфейса для просмотра репозиториев;
6. настройка дополнительных аспектов безопасности.

↘ habr.com

#DevOps #Git #SSH | 😊 @iscode

🥷 Джонни вещает: десятка лучших консольных команд

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

Десятое место: Комбинация 'ALT+.' или '<ESC> .' — ввод последнего аргумента недавних команд. Удерживая ALT или ESC, с каждым нажатием на точку в строку ввода будут подставляться параметры предыдущих команд, начиная от недавно введенных к старым.

Девятое место: reset — переинициализация терминала без завершения текущей сессии. Например, в случае когда в терминал были выведены двоичные данные и он перестал корректно работать.

Восьмое место: > file.txt — создает пустой файл. Уничтожает содержимое файла без его удаления.

Седьмое место: <пробел>команда — запуск команды с пробелом перед ней не сохраняет ее в истории. Может пригодиться при передаче паролей программам в открытом виде.

Шестое место: Комбинация 'CTRL+X E' — запуск редактора для ввода сложной команды или скрипта, выбор редактора определяется переменной $EDITOR

Пятое место: mtr google.com — утилита My Traceroute эффективнее, чем комбинация traceroute и ping. Утилита mtr сочетает в себе функциональность traceroute и ping, позволяет проводить диагностику сети в более наглядном виде.

Четвертое место: ^foo^bar — запуск предыдущей команды с заменой в ней подстроки, например, с foo на bar. Полезна при опечатках. Если ввести просто ^foo, то в предыдущей команде первое вхождение foo будет удалено.

Третье место: 'cd -' — возврат в предыдущую рабочую директорию. Может пригодиться и для переключения туда-сюда между двумя директориями.

Второе место: python -m SimpleHTTPServer — запуск HTTP-сервера в текущей директории на 8000 порту. Если в директории нет файла index.html, то будет показан её листинг.

Первое место: sudo !! — запуск последней команды под root.
Полезна когда забыли использовать sudo для команды. "!!" — подставляет ласт введенную команду.

#Linux #Bash #shell | 😊 @iscode

🥷 Джонни вещает: 10 типичных ошибок при использовании k8s

За годы использования Kubernetes мне довелось поработать с большим числом кластеров (как управляемых, так и неуправляемых — на GCP, AWS и Azure). Со временем я стал замечать, что некоторые ошибки постоянно повторяются. Однако в этом нет ничего постыдного: я и сам совершил большинство из них!

— В статье собраны наиболее распространенные ошибки, а также упомянуто о том, как их исправлять.

↘ telegra.ph

#k8s #DevOps #mistakes | 😊 @iscode

🥷 Джонни вещает: Мониторинг и Kubernetes

Интересный доклад, который прозвучал в далёком 2018 году на RootConf2018, в нём рассказывается об опыте настройки мониторинга с Prometheus, который был получен в результате эксплуатации десятков проектов на k8s.

— Доклад прикрепляю здесь же, YT нынче не особо актуален, но вот ссыль на всякий 😣

#k8s | 😊 @iscode

🥷 Джонни вещает: внутреннее устройство Kubernetes-кластера простым языком

В этой статье вы узнаете, как выглядит кластер Kubernetes, как работают узлы, и в целом, обо всех основных компонентах системы Kubernetes.

↘ telegra.ph

#k8s #DevOps | 😊 @iscode

🥷 Джонни вещает: Автомасштабирование и управление ресурсами в Kubernetes

В докладе речь пойдёт о том, как с помощью K8s обеспечить высокую доступность приложений и гарантировать их максимальную производительность.

— Доклад прикрепляю здесь же, YT нынче не особо актуален, но вот ссыль на всякий 😣

#k8s #DevOps #Infrastructure | 😊 @iscode

🥷 Джонни вещает: DNS-хостинг для начинающих, многообразие ресурсных записей

Чтобы хоть как-то связать IP-адрес с доменом, хватит всего нескольких базовых ресурсных записей. Однако их существуют десятки, одни могут дружить или конфликтовать друг с другом, другие повышают безопасность, но при их неправильной настройке все перестает работать.

🌜 В данной серии постов разберемся, какие типы ресурсных записей бывают, зачем их так много и посмотрим на примеры их добавления, а начнём в этом посте с обязательных типов записей:

1. SOA — одна из тех записей, которые необходимы всем DNS-зонам, чтобы соответствовать стандартам IETF. Помимо очевидных параметров (имени и типа записи) может содержать другие значения.

mname — имя основного сервера, откуда приходят обновления для вторичных серверов, на которых хранятся дубликаты DNS-записей.
rname — адрес электронной почты администратора. Нужно обратить внимание, что здесь вместо символа @ используется точка.
serial — номер копии зоны. При создании зоны по умолчанию указывается значение 1. При каждой синхронизации данных между серверами значение увеличивается. Таким образом, чем больше значение serial, тем новее данные на сервере.
refresh — частота, с которой вторичные серверы запрашивают у первичных обновление SOA-записи. Указывается в секундах.
retry — частота, с которой вторичные серверы могут запрашивать обновления у основного, если тот не отвечает.
expire — время, по прошествии которого вторичный сервер перестает отвечать на запросы зоны, если не получает ответ от основного.

2. NS — запись указывает, какой сервер содержит фактические записи DNS. Без правильно настроенных NS-записей не получится открыть сайт или приложение, поскольку не получится получить IP-адрес домена.

🕹 Обычно домен использует сразу несколько NS-записей, просто потому что так надежнее: если один сервер упадет, можно будет обратиться к другому. На самих серверах хранятся копии всех остальных DNS-записей.

#DNS #hosting | 😊 @iscode

🥷 Джонни вещает: DNS-хостинг для начинающих, многообразие ресурсных записей

Как нетрудно догадаться, классические записи это записи, которые встречаются повсеместно. Скорее всего, при запуске сайта или приложения на облачном или выделенном сервере, вы будете пользоваться одной из этих записей. Вкратце, все они указывают на адрес назначения, которым в конечном счете будет IPv4 или IPv6. (предыдущий пост про обязательные типы записей)

1. А — Тип записи, который используется для связывания IPv4-адреса сервера с ресурсной записью домена. Значение A-записи состоит только из поля value, поэтому и работает все предельно просто.

— Например, у нас есть две записи: example.com и shop.example.com. Для первой в поле value указано значение 1.1.1.1, для второй — 2.2.2.2. При открытии сайта example.com браузер будет обращаться к серверу 1.1.1.1, а и при открытии shop.example.com — соответственно, к записи 2.2.2.2.

2. AAAA — Запись, в целом аналогичная А, но с той разницей, что ресурсная запись домена связывается с IPv6-адресом сервера. Пример значения АААА-записи: 2001:db8:abc1::54.

3. CNAME — тип записи, которая привязывает псевдоним к действительному (каноническому) доменному имени. Записи CNAME обычно используют для привязки к доменам, в которых размещен контент, и субдоменам вроде www или mail. Иначе говоря, CNAME в отличие от A и AAAA ссылается на доменное имя, а не на IP-адрес.

🌜 Практический пример: У вас есть домен example.com, и вы подключаете CDN для поддомена cdn.example.com: cdn.example.com CNAME uuid.selcdn.ru. Здесь uuid.selcdn.ru — доменное имя CDN-ресурса. Вы не можете напрямую указать IP-адреса CDN, так как не управляете ими, и они могут динамически меняться. Доменное имя CDN-ресурса при этом постоянно.

4. ALIAS — это, по сути, CNAME на максималках. Они также копируют данные целевого домена, но имеют несколько отличий. Прежде всего, запись ALIAS можно добавить для основного домена, а ее имя может быть любого уровня, включая второй.

🖥 Пример с облачным хранилищем: Есть контейнер, в который мы загрузили сайт, его основной домен вида uuid.selstorage.ru. Нам нужно, чтобы сайт открывался по example.com.

Сделаем запись example.com ALIAS uuid.selstorage.ru. При попытке открыть example.com произойдет магия.
· Браузер сделает запрос A и AAA-записей для example.com.
· Наш DNS-сервер, зная об ALIAS-записи, запустит ресолвинг адресов целевого домена uuid.selstorage.ru и получит в ответ IPv4 или IPv6.
· DNS-сервер вернет для example.com полученный на предудущем шаге набор IP-адресов.
· Браузер установит соединение с серверами облачного хранилища и откроет находящийся там example.com.

При использовании записей типа ALIAS нужно помнить, что для домена/поддомена не может быть записи A или AAAA. Кроме того, ALIAS нарушит DNSSEC на основном домене (@), поскольку в ответах @ A и @ AAAA будут отсутствовать записи RRSIG. Это, в свою очередь, нарушит разрешение на всех резолверах.

Какого-либо черновика и стандарта в RFC для ALIAS нет, поэтому от сервиса к сервису могут наблюдаться разные поведения у этого типа записи. Если пост понравился, жду от вас реакций и выпускаю на ту же тему, но уже о сервисных записях 💃

#DNS #hosting #IPv4 #IPv6 | 😊 @iscode

🥷 Джонни вещает: 8 популярных сетевых протоколов с наглядным объяснением

Сетевые протоколы работают на разных уровнях модели OSI, это важно знать.

🌜 Эта многоуровневая архитектура обеспечивает стандартизированное взаимодействие между различными программными и аппаратными компонентами в сети.

1. 𝗧𝗖𝗣/𝗜𝗣 — базовый метод передачи информации между устройствами в Интернете. В то время как IP отвечает за адресацию и маршрутизацию пакетов данных, TCP заботится о сборке данных в пакеты, а также о надежной доставке.

2. 𝗛𝗧𝗧𝗣 — играет решающую роль при доступе к веб-сайтам. Он отвечает за получение и доставку веб-контента с серверов конечным пользователям.

3. 𝗛𝗧𝗧𝗣𝗦 — усовершенствованная версия HTTP, HTTPS объединяет протоколы безопасности (а именно TLS) для шифрования данных, обеспечивая безопасный и конфиденциальный обмен между браузерами и веб-сайтами.

4. 𝗙𝗧𝗣 — Как следует из названия, FTP используется для передачи файлов (загрузки и скачивания) между компьютерами в сети.

5. 𝗨𝗗𝗣 — более оптимизированный аналог TCP, UDP передает данные без накладных расходов на установление соединения, что приводит к более быстрой передаче, но без гарантии, что данные будут доставлены или будут в порядке.

6. 𝗦𝗠𝗧𝗣 — движущая сила обмена электронной почтой, которая управляет форматированием, маршрутизацией и доставкой писем между почтовыми серверами.

7. 𝗦𝗦𝗛 — криптографический сетевой протокол, который обеспечивает безопасную передачу данных по незащищенной сети.

- Он обеспечивает безопасный канал, гарантируя, что хакеры не смогут интерпретировать информацию путем подслушивания 📠

#Protocol #cheatsheet | 😊 @iscode

🏃‍♀️ Когда что-то сломалось и вызывают сисадмина Олега

🥷 Джонни вещает: DNS-хостинг для начинающих, многообразие ресурсных записей

В этом посте разберём сервисные записи, они указывают на тип сервиса и его дополнительные параметры. Например, определяют местоположение хоста или почтового сервера, предпочтительный протокол соединения и т. д. (пост про обязательные типы записей; про классические типы записей)

— Другими словами, в теории сервис может работать и без этих записей, но с ними пользоваться им будет удобнее, быстрее и безопаснее 🏃‍♀️

1. MX — тип записи, который указывает на почтовый сервер доменного имени. Это позволяет внешним почтовым серверам определять, куда отправлять электронную почту. Другими словами, запись отвечает на вопрос, где ваш почтовик.

Формат этой записи содержит два значения: priority и value. Первое поле определяет приоритет сервера, на который будет отправляться почта. Он может иметь числовое значение (integer): чем оно ниже, тем выше приоритет.

— Поле value определяет доменное имя или IP-адрес сервера входящей электронной почты.

Рассмотрим на примере: допустим, у нас есть MX-запись example.com, в которой для значения 203.0.113.102 установлен приоритет 10, а для значения 198.51.100.5 — 20. В этом случае при отправке письма на электронный адрес info@example.com, оно будет направлено на сервер 203.0.113.102, а при его недоступности — на сервер 198.51.100.5.

2. SRV — это тип записи, который определяет местоположение, то есть имя хоста и номер порта серверов для определенных служб. По сути, такая запись отвечает на вопрос, где сервис такого типа, каков его IP и порт. SRV придумали, чтобы не плодить новые типы записей, как получилось с MX.

❗️ Формат такой записи выглядит следующим образом:

service.proto.name TTL class SRV priority weight port target.

Пример записи: xxx.tcp.example.com 86400 IN SRV 10 5 5060 xxxserver.example.com (про последовательность и назначение)

3. SVCB — это дальнейшее развитие SRV-записи с добавлением других метаданных, необходимых для сетевого соединения. Среди них — предпочтительный протокол и его версия, IP-адреса и порты.

Основное преимущество этого типа записей в том, что они повышают производительность DNS-сервера и ускоряют загрузку сайта или приложения.

SVCB-записи имеют два режима: AliasMode(делегирует оперативное управление ресурсом); ServiceMode (объединяет информацию о конфигурации для эндпоинта)

— Записи SVCB и HTTPS также предоставляют IP-адреса напрямую, без необходимости просмотра клиентом записей A и AAAA. Для этого к записям можно добавить параметры ipv4hint и ipv6hint.

Пример записи: example.com 3600 IN SVCB 1. alpn=«h3,h2» ipv4hint=«192.0.2.1» ipv6hint=«2001:db8::1»

4. HTTPS — разновидность SVCB с акцентом на подключение по HTTPS. Они также помогают ускорить загрузку сайтов и приложений.

В отличие от устаревшего протокола HTTP, который запрашивал у пользователя только IP-адрес, HTTPS умеет, например, создавать альтернативное подключение к эндпоинтам (HTTP/3), включать Encrypted ClientHello и поддерживает нестандартные порты TCP и UDP.

— HTTPS шифрует запросы и ответы с помощью TLS(SSL) в отличии от устаревшего HTTP.

#DNS #hosting #IPv4 #IPv6 | 😊 @iscode

Владимирский админ,ветер в серверной.
Пингуют из Твери, пинг немеренный.

#memes | 😊 @iscode