10.02.08
Resolvers
Ситуация. Имеем FreeBSD Jail. В нем работает rbldnsd. Как оказывается, при использовании одного ip (это условие) возникает проблема в работе dns. Куда вешать named?
Решения, естественно есть, но вот какие-то все кривоватые. Так как тупо нет адреса 127.0.0.1. (В openvz, например, есть).
1) Поднять named где-то еще. Минус один, но ощутимый. Конфигурация получается не самодостаточная. Зависит от внешнего источника. Если использовать внешний dns сервер, то это решение, имхо, хорошо, когда все дело происходит в локалке. Там - да, один dns на всех. А если это должен быть один из самодостаточных серверов где-нибудь в датацентре? А на самой ноде named может быть явно не в тему. Хотя бы из соображений безопасности.
2) Добавить алиасом еще один, какой-нибудь фейковый ip типа 192.168.x.x или 10.x.x.x на интерфейс и отдать его джайлу. Уже нарушаем условие. Плюс, в некоторых версиях FreeBSD были какие-то проблемы при использовании алиасов в jail. Хотя это решение мне ближе всех, но с 127 все было бы проще, да и конфигурация была бы переносимее.
К чему это все я? Да к тому, что как это ни странно, но в этом моменте, чисто системном, MacOS оказалось более функциональной, нежели BSD или Linux. Там можно повесить named на другой порт и настроить резолвер соответствующим образом.
Читаем из мана по resolver. Опции resolv.conf:
===
nameserver
Internet address (in dot notation for IPv4 or in colon notation for IPv6) of a name server that the resolver should query. The address may optionally have a trailing dot followed by a port number. For example, 10.0.0.17.55 specifies that the nameserver at 10.0.0.17 uses port 55.
port
IP port number to be used for this resolver. The default port is 53. The port number for an individual nameserver may be specified as part of the nameserver address (see nameserver above) to override the default or the port number specified as a value for this keyword.
===
А вот в моих горячо любимых BSD и Linux такой довольно полезной фичи - нет.
viliar said,
October 5, 2008 at 7:48 pm
Да, если кому-то придет в голову вешать named на 53 порт в таком случае и просто форвардить запросы на rbldnsd на другом порту. В этом случае возникает, насколько я помню, нюанс с рекурсивными запросами. Форвадить он будет только от тех клиентов, которые allow-recursion. И если хочется, чтобы конфигурация работала для внешних запросов, то все, кому можно делать запросы к rbldnsd получают возможность делать рекурсивные запросы. Хотя, наверно можно что-то еще поковырять с acl. Но так как named в этой связке получается лишним неэффективным звеном, то даже и не смотрел.
viliar said,
October 8, 2008 at 1:14 am
Разобрался с вопросом связки bind+rbldnsd. С acl все просто:
view local {
match-clients { local; };
allow-query { local; };
allow-transfer { local; };
recursion yes;
include “/etc/namedb/other.zone”;
include “/etc/namedb/rbldnsd.zone”;
};
view world {
match-clients { world; };
allow-query { world; };
recursion yes;
forward only;
forwarders {
xxx.xxx.xxx.xxx port 1053;
};
// include “/etc/namedb/rbldnsd.zone”;
};
Но работать в такой конфигурации это не будет. Поясню. Все сетевые хауту предлагают вариант связки bind+rbldnsd, по умолчанию предпологая, что форвардить запросы будет локальный бинд, который используется хостом как dns по умолчанию. То есть для всех запросов, с включенным флагом RD (recursion desired). В этом случае все окей. А теперь, что мы имеем в нашем случае. Клиент посылает запрос типа dig a 2.0.0.127.main.bl.xx.xx.
По цепочке dns серверов выясняется, что авторитарным сервером является наш. И тут уже посылается последний запрос, с брошенным флагом RD. А bind для такого запроса максимум что может сделать - достать запись из кеша. А форвардить он не будет. Хоть убей. И опции специальной, а ля force-recursive я для этого не нашел.