Подскажите пожалуйста как создать локальный домен и DNS сервер, например,
чтобы хосту mail.ru соответствовал IP 192.168.0.1 ?
если у тебя линукс - создаешь dummy-интерфейс, назначаешь ему IP 192.168.0.1. Потом поднимаешь bind, пишешь для него прямую зону mail.ru и прописываешь в него соответствие mail.ru и 192.168.0.1. Потом пишешь реверсную зону 1.0.168.192.in-addr.arpa в которой, соответственно, сопоставлешь 192.168.0.1 и mail.ru. Обе зоны скармливаешь bind'у.
У меня FreeBSD 5....
не знаю механизма виртуальных интерфейсов в FreeBSD. Не исключено, что можно обойтись алиасом к локальному, либо к Ethernet-интерфейсу, если таковой имеется.
Вообще говоря, я неверно поставил вопрос...
Проблема в следующем:
Имеется зарегистрированный домен Domen.ru IP 161.8.0.1,
на этой машине стоит ipfw и пренеправляет порты 25 и 110 на машину с локальным адресом 192.168.0.1 на которой хотелось бы установить сервер qmail, который получал и отправлял бы письма с Domen.ru
хм... а в чем проблема? насколько я себе представил топологию, там никаких дополнительных телодвижений не должно быть. Ну разве что сделать в DNS на сервере 161.8.0.1 MX-запись, показывающую на 192.168.0.1
КАК?
можно поподробнее?
К сожалению, в DNS и почте я 0.0 :((
Читаешь теорию - понятно, начинаешь что-то делать - а не выходит каменный цветок.... :) Но ведь надо же как-то учиться...
Буду безмерно благодарен за любую информацию...
>дополнительных телодвижений не должно быть. Ну разве что сделать в DNS
>на сервере 161.8.0.1 MX-запись, показывающую на 192.168.0.1И весь остальной мир дружно начнет отправлять почту для вашего домена
на свои локальные 192.168.0.1 :-) Наблюдать такое весело...
Ну дык чего делать то, мужики?
>Ну дык чего делать то, мужики?Ну, поднять sendmail на реальном IP, а с него всю почту домена
завернуть через mailertable на ваш qmail
domain.ru smtp:[192.168.0.1]
действительно, ошибочка вышла %)
на внешнем IP не комп, а железка стоит типа SDSL модема или чего то вроде, тама сложно почту поднимать...
>на внешнем IP не комп, а железка стоит типа SDSL модема или
>чего то вроде, тама сложно почту поднимать...
Обычно на таких железках есть возможность маппинга внешнего адреса (по определенному порту) во внутренний или другими словами проброс входящего СМТР коннекшена на внутренний адрес.
Само-собой, я же говорю: 25 и 110 порт внешнего IP мапятся на внутреннюю машину.... но в DNS то прописан внешний IP и поэтому почта ругается....
И охота тебе ковыряться с BIND, периодически латать его дыры, настраивать. Тем более, сам говоришь, что нет опыта.Я уже давно BIND использую только там, где другого выхода нет (нужно зоны держать, синхронизировать с secondary)
В повседневной практике использую dnsmasq. Это кэширующий NDS форвардер. Т.е. он просто направляет запросы клиентов реальному name server. Но при этом, ему можно указать отдельные хосты в локальном /etc/hosts. По поводу адресов для таких хостов он будет сам отвечать, без форварда.
Для твоего случая
В dnsmasq.conf указываем
mx-host=mail.ru
mx-target=fake.mail.ruВ /etc/hosts
192.168.0.121 fake.mail.ruДля всех снаружи все останется как было, а вот клиенты внутри сети будут отправлять почту для mail.ru на сервер 192.168.0.121
Есть еще замечательная опция в dnsmasq.conf
local-mx
На все запросы MX записей для любых (!) доменов он будет локальным клиентам отвечать собственным IP адресом :-)
Если понимаешь КАК это можно использовать ...
Спасиба за совет, сегодня же попробую...
>
>Для всех снаружи все останется как было, а вот клиенты внутри сети
>будут отправлять почту для mail.ru на сервер 192.168.0.121
Для этого надо не DNS корежить, а клиентов настраивать правильно.
>
>На все запросы MX записей для любых (!) доменов он будет локальным
>клиентам отвечать собственным IP адресом :-)
"запросы MX записей для любых (!) доменов" означают неправильно настроенную почту. Лечить надо причину, а не последствия.
>Если понимаешь КАК это можно использовать ...
>>
>>Для всех снаружи все останется как было, а вот клиенты внутри сети
>>будут отправлять почту для mail.ru на сервер 192.168.0.121
>Для этого надо не DNS корежить, а клиентов настраивать правильно.
>>Ты чего то не понял. Это не основной режим работы, а возможность!
Возможность быстро подкрутить маленький конфиг на сервере, вместо того, что бы кучу "клиентов настраивать".>>На все запросы MX записей для любых (!) доменов он будет локальным
>>клиентам отвечать собственным IP адресом :-)
>"запросы MX записей для любых (!) доменов" означают неправильно настроенную почту.Полностью согласен. Ни кто не заставляет использовать эту возможность. Но в некоторых случаях бывает оченно полезно. (Кстати на BIND'e сделать такое невозможно совсем).
>>>
>>>Для всех снаружи все останется как было, а вот клиенты внутри сети
>>>будут отправлять почту для mail.ru на сервер 192.168.0.121
>>Для этого надо не DNS корежить, а клиентов настраивать правильно.
>>>
>
>Ты чего то не понял. Это не основной режим работы, а возможность!
>
>Возможность быстро подкрутить маленький конфиг на сервере, вместо того, что бы кучу
>"клиентов настраивать".
>
>>>На все запросы MX записей для любых (!) доменов он будет локальным
>>>клиентам отвечать собственным IP адресом :-)
>>"запросы MX записей для любых (!) доменов" означают неправильно настроенную почту.
>
>Полностью согласен. Ни кто не заставляет использовать эту возможность. Но в некоторых
>случаях бывает оченно полезно. (Кстати на BIND'e сделать такое невозможно совсем).
>в bind'е можно сделать ВСЕ что касается заморочек DNS службы, для этого
он и создан.
>в bind'е можно сделать ВСЕ что касается заморочек DNS службы, для этого
>
>он и создан.Често говоря, не представляю, как заставить BIND на запрос любой (для произвольного домена) MX записи отвечать единственным конкретным адресом.
Подскажи, плиз. Хотя бы идею, с реализацией сам разберусь.
>Често говоря, не представляю, как заставить BIND на запрос любой (для произвольного
>домена) MX записи отвечать единственным конкретным адресом.
>
>Подскажи, плиз. Хотя бы идею, с реализацией сам разберусь."А в ответ - тишина" (с) В.С.Высотский
>>в bind'е можно сделать ВСЕ что касается заморочек DNS службы, для этого
>>
>>он и создан.
>Может ты, просто, брякнул, не подумав?
>>Често говоря, не представляю, как заставить BIND на запрос любой (для произвольного
>>домена) MX записи отвечать единственным конкретным адресом.
>>
>>Подскажи, плиз. Хотя бы идею, с реализацией сам разберусь.
>
>"А в ответ - тишина" (с) В.С.Высотский
>
>>>в bind'е можно сделать ВСЕ что касается заморочек DNS службы, для этого
>>>
>>>он и создан.
>>
>
>Может ты, просто, брякнул, не подумав?думай, есть такая штука "*", остальное - как сможешь сделать
>>в bind'е можно сделать ВСЕ что касается заморочек DNS службы, для этого
>>
>>он и создан.
>
>Често говоря, не представляю, как заставить BIND на запрос любой (для произвольного
>домена) MX записи отвечать единственным конкретным адресом.
>
>Подскажи, плиз. Хотя бы идею, с реализацией сам разберусь.
>>
>>Для всех снаружи все останется как было, а вот клиенты внутри сети
>>будут отправлять почту для mail.ru на сервер 192.168.0.121
>Для этого надо не DNS корежить, а клиентов настраивать правильно.
>>
>>На все запросы MX записей для любых (!) доменов он будет локальным
>>клиентам отвечать собственным IP адресом :-)
>"запросы MX записей для любых (!) доменов" означают неправильно настроенную почту. Лечить
>надо причину, а не последствия.
>>Если понимаешь КАК это можно использовать ...Здесь есть примеры:
http://gennadi.dyn.ee/modules.php?name=Forums&file=viewforum...
Ребят, запутали совсем... Может кто то все же расскажет по порядку...
Если ты используешь Dind 8 или 9 то можно создать view для локального отображения и для внешнего
причем они будут отличатся
ns# cat named.conf
options {
directory "/usr/local/named";
/*
* If there is a firewall between you and nameservers you want
* to talk to, you might need to uncomment the query-source
* directive below. Previous versions of BIND always asked
* questions using port 53, but BIND 8.1 uses an unprivileged
* port by default.
*/
// query-source address * port 53;
};logging {
channel my_syslog {
syslog daemon;
severity info;
};
channel my_file {
file "log.msgs";
severity dynamic;
};
category default {my_file;};
};
include "/etc/rndc.key";
acl "lo_net" {172.16/16;localhost;};
acl "slave_serv"{xxx.xxx.xxx.xxx;};
acl "serv"{127.0.0.1;};
view "internal" {
match-clients {lo_net;};
zone "твой домен-для внешних запросов" IN {
type master;
file "dbzone/твой домен-для внешних запросов.zone";
allow-update {none;};
allow-transfer {none;};
};
zone "локал.in-addr.arpa" IN {
type master;
file "dbzone/172.16.zone";
allow-update { none; };
allow-transfer {none;};
};
zone "0.0.127.in-addr.arpa" IN {
type master;
file "dbzone/127.0.0.1.zone";
allow-update { none; };
allow-transfer {none;};
};
zone "." IN {
type hint;
file "dbzone/named.ca";
};
zone "localhost" IN {
type master;
file "dbzone/localhost.zone";
};
zone "твой домен для внутрених запросов" IN {
type master;
file "dbzone/твой домен для внутрених запросов.zone";
allow-transfer {none;};
};zone "mail.ru" IN {
type master;
file "dbzone/mail.ru.zone";
allow-update {none;};
allow-transfer {none;};
};
};
view "external" {
match-clients {any;};
zone "твой домен-для внешних запросов" IN {
type master;
file "dbzone/твой домен-для внешних запросов.zone";
allow-transfer {slave_serv;};
};
zone "внешняя сетка.in-addr.arpa" IN {
type master;
file "dbzone/внешняя сетка.zone";
allow-transfer {none;};
};
zone "." IN {
type hint;
file "dbzone/named.ca";
};
};
в этом случае если клиент из локалки делает запрос (определяется он по acl "lo_net" {172.16/16;localhost;};)
то ему передаются адреса из view "internal"
>Если ты используешь Dind 8 или 9 то можно создать view для
>локального отображения и для внешнего
>причем они будут отличатся
>ns# cat named.conf
>options {
> directory "/usr/local/named";
> /*
> * If there
>is a firewall between you and nameservers you want
> * to talk
>to, you might need to uncomment the query-source
> * directive below.
> Previous versions of BIND always asked
> * questions using
>port 53, but BIND 8.1 uses an unprivileged
> * port by
>default.
> */
> // query-source address *
>port 53;
>};
>
>logging {
> channel my_syslog {
>
> syslog daemon;
>
> severity info;
>
> };
> channel my_file {
>
> file "log.msgs";
>
> severity dynamic;
>
> };
> category default
> {my_file;};
>};
>include "/etc/rndc.key";
>acl "lo_net" {172.16/16;localhost;};
>acl "slave_serv"{xxx.xxx.xxx.xxx;};
>acl "serv"{127.0.0.1;};
>view "internal" {
> match-clients {lo_net;};
>zone "твой домен-для внешних запросов" IN {
> type master;
> file "dbzone/твой домен-для внешних
>запросов.zone";
> allow-update {none;};
> allow-transfer {none;};
> };
>zone "локал.in-addr.arpa" IN {
> type master;
> file "dbzone/172.16.zone";
> allow-update { none; };
>
> allow-transfer {none;};
> };
>zone "0.0.127.in-addr.arpa" IN {
> type master;
> file "dbzone/127.0.0.1.zone";
> allow-update { none; };
>
> allow-transfer {none;};
> };
>zone "." IN {
> type hint;
> file "dbzone/named.ca";
> };
>zone "localhost" IN {
> type master;
> file "dbzone/localhost.zone";
> };
>zone "твой домен для внутрених запросов" IN {
> type master;
> file "dbzone/твой домен для
>внутрених запросов.zone";
> allow-transfer {none;};
> };
>
>zone "mail.ru" IN {
> type master;
> file "dbzone/mail.ru.zone";
> allow-update {none;};
> allow-transfer {none;};
> };
>};
>view "external" {
> match-clients {any;};
>zone "твой домен-для внешних запросов" IN {
> type master;
> file "dbzone/твой домен-для внешних
>запросов.zone";
> allow-transfer {slave_serv;};
> };
>zone "внешняя сетка.in-addr.arpa" IN {
> type master;
> file "dbzone/внешняя сетка.zone";
> allow-transfer {none;};
> };
>zone "." IN {
> type hint;
> file "dbzone/named.ca";
> };
>};
>
>
>в этом случае если клиент из локалки делает запрос (определяется он по
>acl "lo_net" {172.16/16;localhost;};)
>то ему передаются адреса из view "internal"Настоящие герои не ищут легких путей :-))
Сравни с
В dnsmasq.conf указываем
mx-host=mail.ru
mx-target=fake.mail.ruВ /etc/hosts
192.168.0.121 fake.mail.ruЗ.Ы.
Ей Богу, не понимаю! Почему люди продолжают использовать sendmail, BIND?
И была охота писать подобные конфиги, обновляться каждый месяц из-за критических дыр?"Зачем делать сложно, то что проще простого?" (С) В.Бутусов
Ну, вообще-то, была просто показана часть возможностей с примером, а не только решение данной проблемы.
Вот рабочй конфиг, работает на ФРЕ 4.7 сам промучался 6 часов пока запустил: Сервер имеет ип 192.168.0.1 клиент 192.168.0.2.(Имя сервера, ns.furmanova.org atomicfurmanova.org, клиент, john.furmanova.org)
named.confoptions {
directory "/etc/namedb";forwarders {
80.78.96.1; 80.78.97.6; 81.91.36.4; 81.91.36.3; 212.220.66.33; 212.220.67.33;
};
};zone "furmanova.org" {
type master;
file "furmanova.org";
};zone "0.168.192.in-addr.arpa" {
type master;
file "furmanova.org-reverse";
};zone "." {
type hint;
file "named.root";
};zone "0.0.127.in-addr.arpa" {
type master;
file "localhost.rev";
};
####
localhost.rev; From: @(#)localhost.rev 5.1 (Berkeley) 6/30/90
; $FreeBSD: src/etc/namedb/PROTO.localhost.rev,v 1.6 2000/01/10 15:31:40 peter Exp $
;
; This file is automatically edited by the `make-localhost' script in
; the /etc/namedb directory.
;$TTL 3600
@ IN SOA ns.furmanova.org. root.ns.furmanova.org. (
2003300617 ; Serial
3600 ; Refresh
900 ; Retry
3600000 ; Expire
3600 ) ; Minimum
IN NS ns.furmanova.org.
1 IN PTR localhost.furmanova.org.####
furmanova.org$TTL 86400
furmanova.org. IN SOA ns.furmanova.org. root.furmanova.org. (
20033006
86400
7200
8640000
86400 )IN NS ns.furmanova.org.
localhost IN A 127.0.0.1
ns IN A 192.168.0.1
john IN A 192.168.0.2
atomic IN A 192.168.0.1
@ IN A 192.168.0.1www IN CNAME @
ftp IN CNAME @#######
furmanova.org-reverse$TTL 86400
0.168.192.in-addr.arpa. IN SOA ns.furmanova.org. root.ns.furmanova.org. (
20030603
86400
7200
8640000
96400)IN NS ns.furmanova.org.
2 IN PTR john.furmanova.org.
1 IN PTR atomic.furmanova.org.все работает, тольков resolv.conf пропиши nameserver 127.0.0.1
и зделай так чтобы ppp не скидывал туда свой nameserver иначе будет затираться 127.0.0.1,
перпиши конф под себя ивсе, и выставь свои forwarders