Problema con server DNS su Windows Server 2008 SP2.

Pagina 1 di 2 1 2 ultimo
Visualizzazione dei risultati da 1 a 10 su 12
  1. #1
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito Problema con server DNS su Windows Server 2008 SP2.

    Stò riscontrando un'anomalia, che forse non è un vero problema, ma che stà risultando piuttosto fastidiosa.

    Ho due server DNS pubblici, che sono i NameServer autoritativi per alcuni domini.
    Alcuni giorni fà ho dovuto inviare una mail ad un nostro collaboratore presso un'università italiana e mi sono accorto che le mail provenienti dai nostri domini vengono respinte dal server di posta del destinatario con un messaggio piuttosto criptico:
    codice:
    Last Error: 451 4.1.8 Possibly forged hostname for -Ip del mio server di posta-
    Ho già contattato il responsabile tecnico per il dominio in questione con cui stiamo tentando di risolvere il problema ma onestamente io stò rimanendo a corto di idee.

    Premetto che ho la risoluzione diretta ed inversa configurata per quell'indirizzo IP, che praticamente tutti i tool di analisi e check dei DNS che ho trovato online mi danno dei report puliti e senza errori o problemi e che anche dall'altra parte sembra funzionare tutto correttamente,

    I due DNS sono così configurati:
    - dns1.miodominio.it: Server Windows 2008 SP2 64 bit aggiornato, è il NS di riferimento ed ospita la zona di ricerca diretta primaria per il dominio.
    - dns2.miodominio.it: Server CentOS 5.6 64bit, bind aggiornato e le zone di ricerca diretta sono configurate come secondarie delle zone ospitate dal server Windows (quindi se le scarica così come sono dal server Windows).
    Su entrambi i server ho configurato le zone di ricerca inversa come secondarie dei dns di Fastweb, che rimangono i server autorevoli per queste zone.

    La cosa più strana è che alla medesima interrogazione i due DNS rispondono in maniera diversa e, a quanto sembra, la risposta più corretta la dà proprio il server Linux, nonostante ospiti solo una replica delle zone esistenti sul server Windows:

    Originariamente inviato da dns1.miodominio.it
    [matteo@arch-UEFI ~]$ dig @ -q posta.miodominio.it

    ; <<>> DiG 9.9.0 <<>> @ -q posta.miodominio.it
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37394
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ;; WARNING: recursion requested but not available

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1280
    ;; QUESTION SECTION:
    ;posta.miodominio.it. IN A

    ;; ANSWER SECTION:
    posta.miodominio.it. 3600 IN A

    ;; Query time: 54 msec
    ;; SERVER: dns1.miodominio.it#53(dns1.miodominio.it)
    ;; WHEN: Thu May 3 00:38:58 2012
    ;; MSG SIZE rcvd: 64
    Originariamente inviato da dns2.miodominio.it
    [matteo@arch-UEFI ~]$ dig @ -q posta.miodominio.it

    ; <<>> DiG 9.9.0 <<>> @ -q posta.miodominio.it
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55503
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
    ;; WARNING: recursion requested but not available

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;posta.miodominio.it. IN A

    ;; ANSWER SECTION:
    posta.miodominio.it. 3600 IN A

    ;; AUTHORITY SECTION:
    miodominio.it. 3600 IN NS dns2.miodominio.it.
    miodominio.it. 3600 IN NS dns1.miodominio.it.

    ;; ADDITIONAL SECTION:
    dns1.miodominio.it. 3600 IN A
    dns2.miodominio.it. 3600 IN A


    ;; Query time: 77 msec
    ;; SERVER: #53()
    ;; WHEN: Thu May 3 00:41:22 2012
    ;; MSG SIZE rcvd: 134
    Come si vede, la risposta del server primario manca completamente delle sezioni "AUTHORITY SECTION" e "ADDITIONAL SECTION" che invece il server Linux (che ricordo ospita solo zone secondarie) restituisce. Effettivamente è strano ma non è mai stato un problema. Il problema si presenta anche con le richieste di risoluzione inversa.
    Originariamente inviato da dns2.miodominio.it
    [matteo@arch-UEFI ~]$ dig @ -x

    ; <<>> DiG 9.9.0 <<>> @ -x
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22627
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
    ;; WARNING: recursion requested but not available

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 1280
    ;; QUESTION SECTION:
    ;d.c.b.a.in-addr.arpa. IN PTR

    ;; ANSWER SECTION:
    d.c.b.a.in-addr.arpa. 86400 IN PTR .

    ;; Query time: 30 msec
    ;; SERVER: #53()
    ;; WHEN: Thu May 3 00:56:17 2012
    ;; MSG SIZE rcvd: 84
    [matteo@arch-UEFI ~]$ dig @ -x 2.228.5.7

    ; <<>> DiG 9.9.0 <<>> @ -x
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17459
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
    ;; WARNING: recursion requested but not available

    ;; OPT PSEUDOSECTION:
    ; EDNS: version: 0, flags:; udp: 4096
    ;; QUESTION SECTION:
    ;d.c.b.a.in-addr.arpa. IN PTR

    ;; ANSWER SECTION:
    d.c.b.a.in-addr.arpa. 86400 IN PTR posta.miodominio.it

    ;; AUTHORITY SECTION:
    c.b.a.in-addr.arpa. 86400 IN NS dns1.fastweb.it.
    c.b.a.in-addr.arpa. 86400 IN NS dns2.fastweb.it.

    ;; Query time: 63 msec
    ;; SERVER: #53()
    ;; WHEN: Thu May 3 01:01:59 2012
    ;; MSG SIZE rcvd: 130
    Il server di posta del destinatario implementa uno script che verifica la corrispondenza del record A e PTR configurati nel DNS del mittente, per individuare lo spam. Il problema più grosso è che, a quanto pare, il suo resolver quando tenta di fare una query verso il mio dominio ottiene un bel NXDOMAIN...

    Il destinatario è un dominio di terzo livello di un'infrastruttura universitaria, il problema si presenta identico anche interrogando il resolver a cui fà riferimento il server di posta che si trova al livello superiore (i server di posta e DNS utilizzati per il dominio di secondo e terzo livello sono diversi) ma non sembra esserci al di fuori della rete universitaria perchè il dns del GARR mi risolve correttamente.

    Vista la risposta anomala dei miei DNS è lecito presumere che il problema sia dal mio lato... Qualcuno riesce a farsi venire un'idea geniale??
    Ultima modifica di frakka : 04-05-2012 a 01:13

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  2. #2
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    è abbastanza tardi e quindi butto lì una possibile spiegazione che implica due cause contestuali:


    1) il virtual server SMTP ha un FQDN che non è in qualche modo corrispondente al server-name

    2) il FQDN del virtual server SMTP non presenta una corretta registrazione Service Principal Name

  3. #3
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito

    Anche tu mattiniero, vedo...

    Oggi mi ha chiamato il responsabile tecnico del mail server universitario: Dopo una lunghissima sessione di debug di cui faccio fatica perfino ad immaginare i passaggi, il problema di comunicazione dei due mail server si è rivelata una ACL non aggiornata.
    I miei IP da un pò di tempo sono stati cambiati, passando dalla precedente rete 93.63.etc... ad una sottorete della classe A 2.0.0.0/8: Fino a poco tempo fà, questa rete era riservata dalla IANA ed era considerata "BOGUS".
    Il mail server dell'università aveva queste reti nell'elenco delle provenienze non ammissibili e la risoluzione infatti si fermava ai DNS parent ai miei. Quando il mail server veniva a conoscenza del fatto che il mio IP apparteneva ad alla rete 2.0.0.0/8 interrompeva la ricerca e rimpallava i messaggi.
    A causa dello shortage di indirizzi IP, la IANA ha recentemente sbloccato questa rete assegnandola al RIPE ed è quindi necessario aggiornare le ACL.


    Rimane da capire perché il mio server DNS Windows risponde in modo incompleto…

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  4. #4
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    Originariamente inviato da frakka
    Anche tu mattiniero, vedo...

    Oggi mi ha chiamato il responsabile tecnico del mail server universitario: Dopo una lunghissima sessione di debug di cui faccio fatica perfino ad immaginare i passaggi, il problema di comunicazione dei due mail server si è rivelata una ACL non aggiornata.
    I miei IP da un pò di tempo sono stati cambiati, passando dalla precedente rete 93.63.etc... ad una sottorete della classe A 2.0.0.0/8: Fino a poco tempo fà, questa rete era riservata dalla IANA ed era considerata "BOGUS".
    Il mail server dell'università aveva queste reti nell'elenco delle provenienze non ammissibili e la risoluzione infatti si fermava ai DNS parent ai miei. Quando il mail server veniva a conoscenza del fatto che il mio IP apparteneva ad alla rete 2.0.0.0/8 interrompeva la ricerca e rimpallava i messaggi.
    A causa dello shortage di indirizzi IP, la IANA ha recentemente sbloccato questa rete assegnandola al RIPE ed è quindi necessario aggiornare le ACL.
    [...]

    Si, l'ACL a cui si riferivano è senz'altro questa, o comunque molto simile:

    codice:
    /* These are known fake source addresses. */
    acl "bogon" {
    0.0.0.0/8;     # Null address    
    1.0.0.0/8;     # IANA reserved, popular fakes    
    2.0.0.0/8;     # IANA reserved, popular fakes        
    192.0.2.0/24;  # Test address    
    224.0.0.0/3;   # Multicast addresses    
    /* RFC 1918 addresses may be fake too. Don't list these if you       
    use them internally. */    
    10.0.0.0/8;    
    172.16.0.0/12;    
    192.168.0.0/16;
    };

    E' davvero molto semplice da implementare (e modificare): è quella caldamente consigliata e più largamente adottata in giro per il mondo.

    Ultimamente era risaputo che essendo arrivati agli sgoccioli con IPV4, IANA aveva ceduto alle strutture di diversi continenti tutta una serie di classi precedentemente riservate.

    Certo che se addirittura la divisione informatica di una struttura universitaria non si tiene aggiornata su un aspetto così importante e sensibile, e non provvede dinamicamente alle modifiche ......

    A questo punto chissà quanti altri server di posta questa ACL aveva all'insaputa già fatto fuori; e soprattutto se non incontravano te sulla loro strada, chissà quanti altri avrebbero fatto la medesima fine in futuro



    Originariamente inviato da frakka

    Rimane da capire perché il mio server DNS Windows risponde in modo incompleto…
    quindi hai già verificato che la registrazione SPN è OK?

  5. #5
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito

    Originariamente inviato da Totocellux
    Certo che se addirittura la divisione informatica di una struttura universitaria non si tiene aggiornata su un aspetto così importante e sensibile, e non provvede dinamicamente alle modifiche ......

    A questo punto chissà quanti altri server di posta questa ACL aveva all'insaputa già fatto fuori; e soprattutto se non incontravano te sulla loro strada, chissà quanti altri avrebbero fatto la medesima fine in futuro
    A onor del vero, devo dire che io non sarei stato capace di fare tutte le procedure di debug che hanno attuato loro per cercare di capire l'origine del problema: Il contatto con cui ho lavorato si è dimostrato molto competente e disponibile... Molti altri mi avrebbero semplicemente risposto:"Boh... Noi la posta la ricevano normalmente. Sarà un problema tuo" anche in considerazione dell'accertata anomalia con il DNS.
    Inoltre, se nessuno prima di me ha sollevato il problema o la mia classe di IP è ancora molto poco diffusa o non sono più molti a far caso al contenuto di un NDR e soprattutto a curarsene...

    Originariamente inviato da Totocellux
    quindi hai già verificato che la registrazione SPN è OK?
    Onestamente non ho capito il suggerimento: Cosa c'entra l'SPN (Service Principal Name)? Il server è membro di dominio ma il DNS non ospita zone di AD, solo zone pubbliche.
    Inoltre il server Linux (che ospita zone secondarie quindi tutto il contenuto lo pesca dalle zone del server Windows) trasmette i dati completi e corretti.
    Sembra quasi che il server Windows non sia configurato per includere quelle sezioni nelle risposte (e mi sembra assurdo!) ma non ho trovato alcuna guida o articolo della technet che spieghi come modificare o verificare queste impostazioni.

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  6. #6
    mebibyte L'avatar di pgfiore
    Registrato
    Jun 2011
    Località
    Genova
    Età
    61
    Messaggi
    567

    Predefinito

    10.0.0.0/8;
    172.16.0.0/12;
    192.168.0.0/16;

    E io che li ho sempre pensati con maschera a 8/16/24...

  7. #7
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito

    Vuoi ridere??? Pure io...


    C'è da dire che (fortunatamente a questo punto) non ho mai dovuto usare reti più grandi una /24...

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  8. #8
    ●⁞◌ Ȏrȉzzȏntέ Ðέglȋ ȨvέntȊ ◌⁞●
    Registrato
    Aug 2008
    Località
    Palermo
    Messaggi
    2,952

    Predefinito

    Originariamente inviato da frakka
    [...]
    Onestamente non ho capito il suggerimento: Cosa c'entra l'SPN (Service Principal Name)? Il server è membro di dominio ma il DNS non ospita zone di AD, solo zone pubbliche.
    [...]

    Partendo dal presupposto che in azienda utilizziate Exchange associato a Server 2008, sono propenso a credere che il problema non derivi affatto da una non corretta gestione delle zone su Active Directory (quelle vanno bene, tant'è che il secondario funzia a dovere), ma direttamente dal server SMTP di Exchange.

    La mia idea parte dal presupposto (ancora da verificare) che qualora il FQDN del server SMTP ed il FQDN del server che lo contiene non corrispondano, sarebbe impossibile la corretta registrazione SPN.


    Spero ora di essere abbastanza chiaro e soprattutto di non scordarmi qualcosa:

    Start -> Tutti i programmi -> Microsoft Exchange -> System Manager

    a questo punto:

    espandi -> Gruppi amministrativi (deve essere spuntato "Visualizza gruppi amministrativi")

    quindi

    espandi -> Primo gruppo amministrativo -> click dx sulla tua Organizzazione -> Proprietà -> spunta su Visualizza gruppi amministrativi

    quindi

    click due volte su OK e fai riavviare il System Manager di Exchange.

    A questo punto:

    Servers -> il tuo Server Exchange -> Protocolli -> SMTP

    ora nel pannello di destra:

    click dx -> Inoltro -> Avanzate

    proprio qui si dovrebbe verificare che quanto descritto nel FQDN del server SMTP corrisponda con il FQDN del server.



  9. #9
    Super Moderatore L'avatar di frakka
    Registrato
    May 2001
    Località
    Casalecchio di Reno (Bo)
    Età
    43
    Messaggi
    23,379
    configurazione

    Predefinito

    Ho un Exchange 2007, la consolle cambia molto ma ho capito quello che intendi: il FQDN della macchina è sicuramente diverso dal FQDN del server smtp ma questo non dovrebbe in alcun modo costituire un problema.

    Non mi risulta che la registrazione SPN e kerberos intervengano in alcun modo nelle transazioni SMTP provenienti da un dominio esterno e non trusted. Inoltre anche se fosse, il servizio SMTP/Exchange con il servizio DNS installato su un altro server non hanno alcuna correlazione.
    Tant'è che il problema si presenta identico anche interrogando il DNS per zone il cui servizio mail non è gestito dal nostro server Exchange.

    Ho stò facendo un controllo che mi ha suggerito un MVP del forum MS... Vediamo cosa salta fuori.

    Questa è la storia di 4 persone chiamate Ognuno, Qualcuno, Ciascuno e Nessuno. C'era un lavoro importante da fare e Ognuno era sicuro che Qualcuno lo avrebbe fatto. Ciascuno poteva farlo, ma Nessuno lo fece, Qualcuno si arrabbiò perché era il lavoro di Ognuno. Ognuno pensò che Ciascuno potesse farlo, ma Ognuno capì che Nessuno l'avrebbe fatto. Finì che Ognuno incolpò Qualcuno perché Nessuno fece ciò che Ciascuno avrebbe potuto fare.

  10. #10
    mebibyte L'avatar di pgfiore
    Registrato
    Jun 2011
    Località
    Genova
    Età
    61
    Messaggi
    567

    Predefinito

    Originariamente inviato da frakka
    Ho un Exchange 2007...
    Direi che 2010 è un miglioramento è un eufemismo imho!

Pagina 1 di 2 1 2 ultimo

Informazioni Thread

Users Browsing this Thread

Ci sono attualmente 1 utenti che stanno visualizzando questa discussione. (0 utenti e 1 ospiti)

Tags

Regole d'invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
nexthardware.com - © 2002-2022