[Megoldva] MX query nem működik Windows Server DNS-en keresztül

Sajnos a Windows Server témakör még eléggé új számomra. Egy kis segítséget szeretnék kérni.

A következő hibába futottam bele:

root@oldserver:~# nslookup -query=MX mail.t-online.hu 192.168.0.1
Server: 192.168.0.1
Address: 192.168.0.1#53

Non-authoritative answer:
*** Can't find mail.t-online.hu: No answer

Authoritative answers can be found from:
mail.t-online.hu nameserver = ans2.telekom.hu.
mail.t-online.hu nameserver = ans1.t-online.hu.
mail.t-online.hu nameserver = ans0.t-online.hu.
ans2.telekom.hu internet address = 193.225.4.82
ans1.t-online.hu internet address = 195.56.77.76
ans0.t-online.hu internet address = 195.228.240.85

root@oldserver:~# nslookup -query=MX mail.t-online.hu 192.168.0.100
Server: 192.168.0.100
Address: 192.168.0.100#53

** server can't find mail.t-online.hu: NXDOMAIN

root@oldserver:~# nslookup -query=A mail.t-online.hu 192.168.0.1
Server: 192.168.0.1
Address: 192.168.0.1#53

Non-authoritative answer:
Name: mail.t-online.hu
Address: 84.2.46.3
Name: mail.t-online.hu
Address: 84.2.44.3

root@oldserver:~# nslookup -query=A mail.t-online.hu 192.168.0.100
Server: 192.168.0.100
Address: 192.168.0.100#53

Non-authoritative answer:
Name: mail.t-online.hu
Address: 84.2.44.3
Name: mail.t-online.hu
Address: 84.2.46.3

A 192.168.0.100-as a Windows Server (2012 R2 Essentials), amin DNS és DHCP szerver fut... A helyi hálózatot ez látja el. A 192.168.0.1-es cím pedig az internet felé a router (ami egy MikroTik router, bár ennek most itt azt hiszem nincs semmi jelentősége)

A probléma, ami fent is nyilvánvalóan látszik. A Windows Serveren keresztül valami miatt nem megy az MX rekord lekérdezése. Sima névfeloldás működik. Ugyanez a lekérés direktbe a routerre hivatkozva simán működik. Ja és ez nem egyedi cím probléma, hanem bármilyen domain-nél ugyanezt csinálja!!

Mi lehet a probléma? Milyen beállítás hiányozhat a Windows DNS Serverénél?

A segítséget előre is köszönöm!

Hozzászólások

Sajnos a probléma még mindig fennáll.
Senkinek sincs ötlete erre?

mail.t-online.hu. domainnek nincs MX rekordja, tehát NXDOMAIN a válasz.

Teljesen jól, és az elvártak szerinti választ adta.

Próbáld meg simán pl. a t-online.hu domain név MX-ét lekérni.

MikroVPS

OK, az világos amit írsz... De azt mivel magyarázod, hogy az egyik DNS szerver ad választ az MX kérésre, a másik pedig NXDOMAIN választ! Hozzáteszem az előbbi a jó, mert egész idáig tökéletesen működött a levél küldés... És mindenhol máshol lekérdezve ugyanaz a válasz az nslookup -query=MX -nél, mint a "jó" DNS szervernél!

Egyébként az alap probléma ebből indult ki:

Ha a fenti 192.168.0.100-as DNS van megadva, akkor ez a válasz:

Feb 24 14:32:09 oldserver postfix/smtp[15912]: 0563B1E26E5: to=, relay=none, delay=21486, delays=21486/0.02/0.1/0, dsn=4.4.3, status=deferred (Host or domain name not found. Name service error for name=mail.t-online.hu type=MX: Host not found, try again)

Ha pedig a 192.168.0.1-es DNS van megadva, akkor természetesen simán elmegy a levél:

Feb 25 18:28:40 oldserver postfix/smtp[21231]: CCCB81E09F9: to=, relay=mail.t-online.hu[84.2.46.3]:25, delay=0.58, delays=0.11/0/0.25/0.22, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 3kskcY3Y2SzJqP)

(E-mail címeket direkt takartam ki!)

Magyarán most is működik a levél küldés, de csak a 192.168.0.1-es router DNS-en keresztül. A Windows-os DNS szerver viszont a korábban említett választ produkálja. Pedig a Windows szervernél forwardersként ugyanúgy a 192.168.0.1 DNS van beállítva!

Szóval ezek alapján még mindig nem értem, hogy miért nem ugyanúgy viselkedik a két DNS szolgáltatás?! És még mindig úgy gondolom, hogy valami beállítás gond lehet a Windows-os DNS szolgáltatásnál?!

Ez teljesen világos, nem vitattam a korábbi hozzászólást sem.
Értem, hogy nincsen MX rekord egyik esetben sem (én is néztem már azóta).

De akkor mivel magyarázod a Postfix viselkedését a fenti nslookup eredmények és a postfix logok tekintetében? Nincs MX rekord egyik esetben sem (egyik DNS-nél sem!), de mégis a MikroTik DNS-ével simán megy. (Eddig is mindig működött a mail.t-online.hu-n keresztül a küldés!!!) Csak most a Windows Server DNS-sel jött elő ez a probléma.

A kérdésedre a válasz, hogy teljesen mindegy milyen címre küldök, mert bármilyen címnél ezt csinálja! (Host or domain name not found. Name service error for name=mail.t-online.hu type=MX: Host not found, try again)

Amúgy az is fura, hogy miért MX rekordot keres az levélküldő szerver címénél (mail.t-online.hu), azonban a normálisan feloldott címen megy végül a levél ki?! Ezek valamelyikén:

Non-authoritative answer:
Name: mail.t-online.hu
Address: 84.2.46.3
Name: mail.t-online.hu
Address: 84.2.44.3

Plusz egy érdekesség, hogy ugyanilyen postfix SMTP-n keresztül kimegy a levél a "mail.kabelnet.hu" szerver esetében (egy másik rendszeren), ahol szintén nincsen MX rekord?!

Szóval most akkor nem értem, hogy mi is a gond?!

Értem. Ennek ennyire nem néztem utána, de ez úgy tűnik, hogy a másik szerveren működik is.
Mondjuk egyértelmű különbség a két szerver között, hogy más-más postfix verziók vannak.
A DNS problémás helyen 2.9.6-os verzió van, ahol pedig megy mindegyik beállítással ott 2.11.0 verzió! Szóval ezek alapján lehet, hogy ebből adódott az egész probléma!?

Kérdésedre a válasz: Persze a sima névfeloldás működött a Windows Server esetében is.
(A nyitó-posztban látod a két DNS között a különbséget az nslookup alapján - MX rekord valóban nincs egyik esetben sem!)

Mikrotik-es DNS-nél a Postfix egyébként nem warning-olt, hogy nem talál MX-et?
Idéztél egy sort, de nem volt véletlenül ez felette?

Nekem ez alapján úgy tűnik, hogy a Postfix megpróbálja rátolni az A rekordra, ha nem talál MX-et. (csak műkedvelő vagyok, nem Postfix rendszergazda :))

Nem, nálam egy "postfix/smtp"-s sor van a log-ban. Ahol jó ott az, hogy elment a levél, ahol pedig rossz ott a fenti hibaüzenet. De ez lehet amiatt is, hogy mondjuk a loggolás alacsonyabb szintre van téve és emiatt nincs warning, csak error!? (Ez csak egy tipp!)

Véleményem szerint ez valami bug lehetett a korábbi postfix verzióban?! (De ez is csak egy tipp! - Másra nem tudok gondolni a fentiek alapján?! - És ez egybe vág azzal is, hogy nem is a DNS feloldással volt a gond!!)

Bár a DNS-es dolog még mindig nem világos, mert máshol megy (előző hozzászólásnál, mail.kabelnet.hu szintén nincs MX bejegyzés!) enélkül a beállítás nélkül is!

Szóval a lényeg, hogy a következő:


7 /etc/postfix/transport:
8 # Internal delivery.
9 example.com :
10 .example.com :
11 # External delivery.
12 * smtp:[gateway.example.com]

Translation:

Lines 2, 7-12: Request that intranet mail is delivered directly, and that external mail is given to a gateway. Obviously, this example assumes that the organization uses DNS MX records internally. The [] forces Postfix to do no MX lookup.

Következőképp módosítva az /etc/postfix/transport file-t...

* smtp:[mail.t-online.hu]

...tökéletesen működik a levélküldés az eredeti 192.168.0.100-as (Windows-os DNS-sel is!) Igen, persze így nincs MX rekord ellenőrzés.

Ha smarthostot használsz (mint a fenti konfig), akkor minek kéne MX? Minden levél, amit nem kezelsz helyben, megy a smarthostra.
Ha direkt kézbesítesz, akkor viszont akkor lenne csak gondod, ha valaki @ mail.t-online.hu címre küldesz.
Nekem sokkal inkább kérdéses, hogy miért akart a postfix MX-et feloldani a mail.t-online.hu-ra, mint hogy miért sikerült a Mikrotikon... (bár ez utóbbi is érdekes kérdés :)

Azt igazából én sem tudom, hogy minek az MX rekord?!
A fentieket a postfix dokumentációjából idéztem. Szóval az MX rekord ellenőrzés alapból van, ha pedig [] jelek közé teszed a host nevét, akkor nincs MX ellenőrzés egyáltalán.

Szerintem az egész hiba inkább valamilyen postfix bug. Mint írtam, ugyanilyen config egy másik szerveren másik postfix verzióval működött. (MX rekord egyik relay hoszt nevénél sem volt, ezért gyanakszom inkább postfix hibára, mintsem DNS hibára!)

Most jöttem rá, mit csinálsz, és honnan volt ismerős a transport fájl. Én is használom cloudban egy a külvilággal való kapcsolattartást szolgáló mailszerveren, hogy a belső szerverek közötti forgalom ne menjen ki a világba és ne számlázzon érte a szolgáltató.
Ha viszont egy irodai rendszerről van szó, akkor a transportot felejtsd el, a main.cf-ben a relayhost értékének add meg a smarthostot. (Doksi szerint ott is van MX ellenőrzés, ha nem teszed szögletes zárójelek közé, de ez tapasztalati alapon nem igaz, végképp nem is tudom mire gondoltak.)

Irodai környezetben is hasznos tud lenni, hogy nem megy ki az egymás közötti levelezés megkerülve a fél világot. Itt most elsősorban a hosszabb levelekre gondolok. Plusz a bejövő levelek POP3 szerverről töltődnek az egyéni helyi IMAP szerveres mappákba, ezért is jó hogy a hosszabb levelek nem mennek ki és újra nem kerülnek bele az POP3-as INBOX-ba foglalva az ott használható tárhelyet feleslegesen. Persze tudom az is egy jogos kérdés lenne, hogy egymás közt minek küldözgetnek nagyobb terjedelmű leveleket... De ez már azt hiszem nem rendszergazdai kérdés, hanem inkább felhasználói dilemma... :)

OK, ebben igazad van.

Viszont van egy domain, ami szinten "belső", amit viszont ki kell küldetni, hogy VPN nélkül a POP3-as szerverről (szolgáltató webmail) lehessen nézegetni. Szerintem anno, ezért állítottam be a transport fájlt. Amúgy a végeredmény, mindkét esetben ugyanaz... :)