[RN3DCX]

Изучая MAN к unbound'у наткнутся на msg-buffer-size, где говориться что размер DNS пакета должен быть 64 Kb.

 

msg-buffer-size: <number>
             Number of bytes size of the message buffers.  Default  is  65552
             bytes,  enough  for 64 Kb packets, the maximum DNS message size.
             No message larger than this can be  sent  or  received.  Can  be
             reduced to use less memory, but some requests for DNS data, such
             as for huge resource records, will result in a SERVFAIL reply to
             the client.

 

 

И вот этот момент вогнал меня в ступор. Почему его размер не 512 Kb ???

Ведь в 512 Kb можно больше инфы загнать одним запросом ???

[dmvy]

Can be reduced to use less memory...

Я бы даже сократил этот размер еще, чтобы уменьшить DDoS DNS amplification коэффициент.

[Ivan_83]

И вот этот момент вогнал меня в ступор. Почему его размер не 512 Kb ??? Ведь в 512 Kb можно больше инфы загнать одним запросом ???

Потому что максимальный размер юдп пакета.

recvfrom() при работе с UDP сокетом больше просто не сможет вернуть, принципиально. Там по пакету за раз вычитывается из буфера сокета. Я бы вообще даже выносить это в настройки не стал, а просто захардкодил 64кб.

Но если совсем интересно то нужно грепать исходники.

[dmvy]

Фрагментация IPv4-пакетов возможна только до 65536 байт в связи с размерностью заголовка fragment offset.

[^rage^]

Там по пакету за раз вычитывается из буфера сокета.

я бы это запатчил на тему recvmmsg :)

[Ivan_83]

recvmmsg

А оно точно отдельным сисколом, а то может внутри либс просто цикл recvmsg()?

Да и проще сразу в ядро модулем лезть.

[^rage^]

recvmmsg

А оно точно отдельным сисколом, а то может внутри либс просто цикл recvmsg()?

точно.

 

Да и проще сразу в ядро модулем лезть.

ну так можно скатиться к netmap/dpdk на ровном месте.

[Timax]

Добрый день! Подскажите такой момент. Есть DNS сервер на Unbound для клиентов. Есть задача для клиентов из подсети (например 10.0.0.0/24) отдавать локальный домен (например example.com) для доступа на сервер, но чтобы для остальных клиентов этот домен не резолвился. Можно ли такое реализовать? 

[RN3DCX]

В зависимости от схемы доступа, либо на маршрутизаторе, либо на тазике создаете правила

[Timax]

39 минут назад, RN3DCX сказал:

В зависимости от схемы доступа, либо на маршрутизаторе, либо на тазике создаете правила

Нужно именно отдавать домен, именно через DNS. Или только поднимать отдельный приватный DNS сервер для локальных узлов? Суть в том чтобы сотрудники могли заходить на сервера по доменному имени, в не по IP, но клиентам эти домены не нужно светить. Понятно что если по IP у клиентов доступа к серверам не будет, то можно и всем домены отдавать, но хотелось бы отдавать только определенным IP.

[alibek]

Используйте BIND, там есть представления.

Либо форвардинг на отдельный DNS (на лупбэке) с своими правами доступа.

[RN3DCX]

3 часа назад, alibek сказал:

Используйте BIND, там есть представления.

Дядь, у тебя сколько хомяков обращяется к нему?

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

 

[rm_]

5 hours ago, Timax said:

но клиентам эти домены не нужно светить

В чём выражается "свечение" если crm.corp.companyname.com будет резолвиться в какой-нибудь 10.0.23.100? У вас либо крайне нубские странные представления о безопасности, либо вы просто не потратили даже одной минуты чтобы сесть и подумать над этим.

[RN3DCX]

6 часов назад, Timax сказал:

Есть задача для клиентов из подсети (например 10.0.0.0/24) отдавать локальный домен (например example.com) для доступа на сервер, но чтобы для остальных клиентов этот домен не резолвился

Мож разогнать хомяков по разным подсетям? И не утруждаться с маршрутизацией и цепочкой правил?

 

Timax, если вам действительно нужно решение, запосите отдельную тему.

З.Ы. Правильно поставленный (развернутый) вопрос, это уже половина выполненого решения.

[Timax]

5 часов назад, RN3DCX сказал:

Мож разогнать хомяков по разным подсетям? И не утруждаться с маршрутизацией и цепочкой правил?

 

Timax, если вам действительно нужно решение, запосите отдельную тему.

З.Ы. Правильно поставленный (развернутый) вопрос, это уже половина выполненого решения.

Не совсем понятно причем тут маршрутизация. Меня интересует именно решение на самом unbound. Отдавать домен example.com только клиентам из 10.0.0.0/24. 

[guеst]

я такого не делал в unbound , но судя по мануалу действовать надо как-то так:

server:
     ...
     access-control-view: 10.0.0.0/24 private-domain

view:
     name: "private-domain"
     local-zone: "example.com." static
     local-data: "example.com. IN A 1.2.3.4"

но вообще, соглашусь с предыдущими ораторами :) правильней для работы внутренних сотрудников с какими-то ресурсами создать где-то на авторитативном ДНС-сервере отдельно нормальную зону и уже туда форвардить запросы с unbound...

Изменено 11 июля, 2018 пользователем guеst

[Timax]

Спасибо всем за советы.