Newsgroup: it.comp.os.linux.sys
Titolo: Problema DNS e SMTP

Ciao a tutti.
Non sono molto pratico di DNS, ma ho dovuto configurarne uno interno
alla mia lan.
La lan è collegata ad internet tramite una ADSL, ed ho messo su
indirizzo pubblico un SMTP al quale accedo sempre tramite l'IP pubblico.
Quando a volte l'ADSL è "down" i servizi della mia lan rallentano molto,
immagino fino al timeout del dns, e poi la ricerca all'interno della lan
va a buon fine.
Vorrei evitare i rallentamenti.
E' possibile fare in modo che il mio smtp venga cercato prima su un
indirizzo privato, ed eventualmente poi su quello pubblico?
I client di posta ricercano il server smtp.mailserver.xxx al quale
normalmente corrisponde l'IP pubblico.
E' possibile assegnargli prima un IP privato ed eventualmente quello
pubblico?
Grazie.
Giulio

 Giulio
Potresti risolvere mettendo un DNS Cache nella rete privata. Impostando tutti i 
client ad utilizzare questo invece che i DNS pubblici, hai un primo vantaggio 
che le richieste avvengono su lan ed eventualmente il chaching dns interroga 
quelli pubblici (se non conosce il nome).
Sull'indirizzo pubblico, se il router ADSL non lo risolve come nome interno, io 
ho trovato questa soluzione:
avendo un ip statico, ho creato una scheda tap con l'ip statico pubblico e 
maschera 255.255.255.255 sul mio server e ho configurato il server come gateway 
(č poi il server a comunicare con il router, se lo ritiene necessario).
In questo modo, tutte le richieste transitano per il server. Se si tratta del 
mio ip pubblico, il router non viene neanche interrogato.
L'altro caso (accesso da internet) il router continua a funzionare come niente 
fosse e redirige le richieste al server giusto.
LP

 pubblico?
Se hai un tuo ns interno basta creare delle view con bind. In pratica il
nameserver ti risponde x o y a seconda di chi lo interroga.
Ciao.

 LP
Credevo di aver fatto una cosa del genere... ma evidentemente non
funziona bene.
Ho creato un DNS che risolve internamente la classe di indirizzi
192.168.xx.1-255
purtroppo mail.mailserver ha un indirizzo pubblico, quindi viene risolto
all'esterno (se raggiungibile) oppure non viene trovato.
Che succederebbe se avendo anche lui una scheda con indirizzo
192.168.xxx io lo inserissi nel mio ns? POtrei by-passare il ns
corretto? E' troppo sporca?
Giulio

 corretto? E' troppo sporca?
Non direi! Anzi, a livello di sicurezza e' consigliabile!
Tutto cio' che circola su una rete privata e' per definizione al di fuori
delle grinfie degli Hacker "la fuori".
A quel punto, magari, a meno di esigenze diverse, io configurerei
addirittura l'MTA per accettare le autenticazioni SOLO sull'indirizzo IP
della rete privata.
In tal modo, anche se qualcuno scopre una password, da fuori la ditta non
se ne fa niente.
RIPETO: sempre che tu non abbia anche l'esigenza di autenticarti da
Internet!
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

Giuseppe Iuculano ha scritto:

Tento.. di spiegarlo meglio...
//
// Sample named.conf BIND DNS server 'named' configuration file
// for the Red Hat BIND distribution.
//
// See the BIND Administrator's Reference Manual (ARM) for details, in:
//   file:///usr/share/doc/bind-*/arm/Bv9ARM.html
// Also see the BIND Configuration GUI : /usr/bin/system-config-bind and
// its manual.
//
options
{
         /* make named use port 53 for the source of all queries, to allow
          * firewalls to block all ports except 53:
          */
         query-source    port 53;
         query-source-v6 port 53;
         // Put files that named is allowed to write in the data/ directory:
         directory "/var/named"; // the default
         dump-file               "data/cache_dump.db";
         statistics-file         "data/named_stats.txt";
         memstatistics-file      "data/named_mem_stats.txt";
};
logging
{
/*      If you want to enable debugging, eg. using the 'rndc trace' command,
  *      named will try to write the 'named.run' file in the $directory 
(/var/named).
  *      By default, SELinux policy does not allow named to modify the 
/var/named directory,
  *      so put the default debug log file in data/ :
  */
         channel default_debug {
                 file "data/named.run";
                 severity dynamic;
         };
};
//
// All BIND 9 zones are in a "view", which allow different zones to be 
served
// to different types of client addresses, and for options to be set for 
groups
// of zones.
//
// By default, if named.conf contains no "view" clauses, all zones are 
in the
// "default" view, which matches all clients.
//
// If named.conf contains any "view" clause, then all zones MUST be in a 
view;
// so it is recommended to start off using views to avoid having to 
restructure
// your configuration files in the future.
//
view "localhost_resolver"
{
/* This view sets up named to be a localhost resolver ( caching only 
nameserver ).
  * If all you want is a caching-only nameserver, then you need only 
define this view:
  */
         match-clients           { localhost; };
         match-destinations      { localhost; };
         recursion yes;
         # all views must contain the root hints zone:
         include "/etc/named.root.hints";
         /* these are zones that contain definitions for all the localhost
          * names and addresses, as recommended in RFC1912 - these names 
should
          * ONLY be served to localhost clients:
          */
         include "/etc/named.rfc1912.zones";
};
view "internal"
{
/* This view will contain zones you want to serve only to "internal" clients
    that connect via your directly attached LAN interfaces - "localnets" .
  */
         match-clients           { localnets; };
         match-destinations      { localnets; };
         recursion yes;
         // all views must contain the root hints zone:
         include "/etc/named.root.hints";
         // include "named.rfc1912.zones";
         // you should not serve your rfc1912 names to non-localhost 
clients.
         // These are your "authoritative" internal zones, and would 
probably
         // also be included in the "localhost_resolver" view above :
         zone "my.internal.zone" {
                 type master;
                 file "my.internal.zone.db";
         };
         zone "my.slave.internal.zone" {
                 type slave;
                 file "slaves/my.slave.internal.zone.db";
                 masters { /* put master nameserver IPs here */ 
127.0.0.1; } ;
                 // put slave zones in the slaves/ directory so named 
can update them
         };
         zone "my.ddns.internal.zone" {
                 type master;
                 allow-update { key ddns_key; };
                 file "slaves/my.ddns.internal.zone.db";
                 // put dynamically updateable zones in the slaves/ 
directory so named can update them
         };
};
key ddns_key
{
         algorithm hmac-md5;
         secret "use /usr/sbin/dns-keygen to generate TSIG keys";
};
view    "external"
{
/* This view will contain zones you want to serve only to "external" clients
  * that have addresses that are not on your directly attached LAN 
interface subnets:
  */
         match-clients           { !localnets; !localhost; };
         match-destinations      { !localnets; !localhost; };
         recursion no;
         // you'd probably want to deny recursion to external clients, 
so you don't
         // end up providing free DNS service to all takers
         // all views must contain the root hints zone:
         include "/etc/named.root.hints";
         // These are your "authoritative" external zones, and would 
probably
         // contain entries for just your web and mail servers:
         zone "my.external.zone" {
                 type master;
                 file "my.external.zone.db";
         };
};