Выбрать язык


Выбрать язык | Show only


Русский | English


пятница, 22 апреля 2016 г.

Does DNS use TCP or UDP? RFC says...

Usually we mean DNS uses UDP port 53 but TCP port 53 is reserved for DNS too.
After some time the one question may become interesting for any specialist working with information technologies or information security:

When does DNS use UDP or TCP?

Answer is provided by  RFC5966, section 4. Transport Protocol Selection, where you may find such statements:
Most DNS [RFC1034] transactions take place over UDP [RFC0768].  TCP
[RFC0793] is always used for zone transfers and is often used for
messages whose sizes exceed the DNS protocol's original 512-byte
limit.
So, every request except zone transfer (query type AXFR) and the large message (more than 512 bytes) containing one is processed by UDP.
One can ask: "Why AXFR and large messages must use TCP?". The reason is ability to use UDP-based services with large responses for DDoS-attacks.
All general-purpose DNS implementations MUST support both UDP and TCP
transport.
It means that each DNS-server implementation must support both transport protocols.

DNS использует UDP или TCP? Что говорит RFC

Как правило, считается, что DNS использует UDP port 53, но TCP port 53 также зарезервирован под использование для DNS.  
Со временем ответ на довольно примитивный вопрос начинает интересовать каждого специалиста, так или иначе имеющего отношение к информационным технологиям и безопасности: 

В каком случае DNS работает по UDP, а в каком - по TCP?

На этот вопрос отвечает действующий документ RFC5966, раздел 4. Transport Protocol Selection, в котором фигурируют следующие утверждения:
Most DNS [RFC1034] transactions take place over UDP [RFC0768].  TCP
[RFC0793] is always used for zone transfers and is often used for
messages whose sizes exceed the DNS protocol's original 512-byte
limit.
То есть, большинство DNS-запросов будет обрабатываться с использованием протокола UDP, исключение составляют трансфер зоны (Query type AXFR) и ответы сервера, превышающие 512 байт на одно сообщение. На вопрос "зачем" ответ простой: чтобы не использовались для DDoS.

All general-purpose DNS implementations MUST support both UDP and TCP
transport.
Это означает, что все реализации DNS-серверов в общем случае должны поддерживать использование обоих протоколов транспортного уровня: TCP и UDP.

воскресенье, 3 апреля 2016 г.

Routing and ACL direction

Sometimes I can see questions related to the ACL directions needed for the traffic filtering on the network equipment.

Let's suppose a case when PC is located in the network 10.0.10.0/24 and DNS server - in the 10.0.20.0/24 one. See the picture.

Маршрутизация и направление ACL

Неоднократно встречался по работе с таким вопросом, но недавно опять обнаружил в Интернете вопрос, связанный с тем, как работают ACL на сетевом оборудовании и в каком направлении их применять.

Рассмотрим на примере, когда ПК находится в подсети 10.0.10.0/24, DNS-сервер - в 10.0.20.0/24. См. картинку.

суббота, 2 апреля 2016 г.

Linux "show mac-address-table" analogue

Few days ago I could see a user question about Linux analogue for Cisco "show mac-address-table" command. He wo'nt use the "arp"or "arp -a" command for some hidden reasons. And I think it may be interesting for other users.

Аналог команды Cisco IOS "show mac-address-table" в Linux

Пару дней назад я увидел в Интернете вопрос о том, какой в Linux существует аналог команды Cisco IOS "show mac-address-table". При этом пользователь категорически не хотел пользоваться командой "arp" либо "arp -a". То ли с целью парсинга и вывода на третьи системы, то ли еще из каких побуждений. Естестенно, мне стало интересно, и свой вариант я опишу в этой, так сказать, "статье".

SPAN-aggregation and packet brokers. Protocol Stripping

Why you may need protocol stripping function?
As you know there are 7 OSI model levels. Each one adds some particular volume header to the packet. 

пятница, 1 апреля 2016 г.

SPAN-агрегация и пакетные брокеры. Удаление лишних заголовков, или Protocol Stripping

Зачем нужен этот функционал?
Как известно, у модели OSI 7 уровней, и каждый из них привносит в пакет свой дополнительный объем. В самом простом случае, на который рассчитаны все анализаторы сетевого трафика, пакет содержит MAC-адреса отправителя и получателя, затем идут IP-адреса. В то же время, по зеркалируемым линкам влета в ЦОД и уровня распределения может идти 802.1q-тегированный трафик либо MPLS с метками. Оба этих вида заголовка помещаются между заголовками канального и сетевого уровней. На моей практике случалось, что анализирующие устройства либо просто не понимали их и игнорировали (лучший случай), либо начинали неверно интерпретировать информацию более высокого уровня (худший случай, когда зашитые алгоритмы для увеличения пропускной способности устройства при вычислениях используют побитовое смещение относительно начала пакета). 
То есть, если у нас явным образом не стоит задача определения номера VLAN/VXLAN, метки MPLS, GTP и т.п., можно удалить их с помощью пакетного брокера.