Re: lug-bg: mail.bg, abv.bg etc..
- Subject: Re: lug-bg: mail.bg, abv.bg etc..
- From: vlk@email.domain.hidden (Vesselin Kolev)
- Date: Wed, 16 Apr 2003 15:52:21 +0300
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Wednesday 16 Apr 2003 12:58, Alexander Atanasov wrote:
<em class="quotelev1">>
<em class="quotelev1">> Reslovera prashta kum server query za type A RR, dns server-a spored
<em class="quotelev1">> RFC-to triabva mu otgovori s A RRs, v paketa koito se poluchava obratno ot
<em class="quotelev1">> server-a ima 3 sekcii: Answer, Authority i Aditional.
<em class="quotelev1">>
<em class="quotelev1">> dig cname.domai.com A
<em class="quotelev1">> v answer sekciata idvat:
<em class="quotelev1">> cname.domain.com. 300 IN CNAME host.domain.com.
<em class="quotelev1">> host.domain.com. 300 IN A 1.2.3.4
<em class="quotelev1">>
<em class="quotelev1">> ako se pita za cname, niama da doide A RR, server-a po jelanie moje da go
<em class="quotelev1">> sloji v aditional. T.e. resolver-a kato client s edno query si poluchava
<em class="quotelev1">> zapisa, nishto che e cname. V server-a syotvetno pak ima edin lookup v
<em class="quotelev1">> zonata dobria sluchai, moje i dva no edva li.
<em class="quotelev1">>
Za po-novite versii na BIND mozhe i da se syglasia s gornoto! No za
po-starite NE!!!
<p>Shto se kasae do sluchaia, kogato CNAME zapisa kanonizira host ot drug
domain, to togava niama kak da ne napravish dve zaiavki. Inache otgovariashtia
ti server traibva da e v recursiven rezhim publichno dostypen za vseki!
Haide obache prebroi zaiavkite, koito shte se podadat v hoda na izpylnenie
na zaiavkata... Broim: Pyrvo se pita "." za NS RR za TLD, kym koito
prinadlezhi canonichnia zapis. Posle se pita edin ot tezi serveri za imena
za NS RR za TLD i sled tova chak se pita za domaina v systava mu, kato
pak se tyrsiat na praktika dva pyti NS RR. Sled tova syshtoto se povtaria
za subdomain.. i t.n.. dokato se stigne do hosta. Koito ne viarva, da vzeme
da si pusne DNS servera bez formard da dupmva i da proveri dali e taka ili
ne!
Pokazvam s detailen primer kak se prenasochva (primeryt e obshtodostypen
i mozhe vseki da vyzprozivede tova, koeto sym napisal):
Imam zona ltph.chem.uni-sofia.bg. V neia pravia slednia zapis:
$ORIGIN ltph.chem.uni-sofia.bg.
mail CNAME mail.dir.bg.
Tazi zona e opisana vyrhu servera za imena lcpe.pip.digsys.bg. Ako sega ot
vynshen host otpravia zapitvane za izvlichane na A RR s DIG shte se poluchi
slednoto:
$ dig @lcpe.pip.digsys.bg -t a mail.ltph.chem.uni-sofia.bg
; <<>> DiG 9.2.0rc3 <<>> @lcpe.pip.digsys.bg -t a mail.ltph.chem.uni-sofia.bg
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64413
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 1
;; QUESTION SECTION:
;mail.ltph.chem.uni-sofia.bg. IN A
;; ANSWER SECTION:
mail.ltph.chem.uni-sofia.bg. 86400 IN CNAME mail.dir.bg.
;; AUTHORITY SECTION:
dir.bg. 345600 IN NS ns.dir.bg.
dir.bg. 345600 IN NS ns.spnet.net.
dir.bg. 345600 IN NS purgatory.spnet.net.
;; ADDITIONAL SECTION:
ns.dir.bg. 345600 IN A 194.145.63.2
;; Query time: 165 msec
;; SERVER: 193.68.0.202#53(lcpe.pip.digsys.bg)
;; WHEN: Wed Apr 16 14:14:51 2003
;; MSG SIZE rcvd: 151
<p>Tova, koeto idva e imeto na hosta, no ne i IP adresa na hosta! Zabelezhi i
che ANSWER: 1. Za da niama symnenia, vseki mozhe da povtori gornoto!
Zabelezehete, che tyrseneto traibva da prodyzlhi vyrhu edin ot serverite
za imena posocheni v AUTHORITY SECTION. Facticheski tova sa
otgovorite vyrnati ot registera (tynkiat moment tuk e, che te ne sa polucheni
v ramkite na rekursivno zapitvane). Za da niama pak symnenia mozhete da
si napravite proverka:
$ dig +norecursive @ns.digsys.bg -t ns dir.bg
; <<>> DiG 9.2.0rc3 <<>> +norecursive @ns.digsys.bg -t ns dir.bg
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17727
;; flags: qr; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;dir.bg. IN NS
;; ANSWER SECTION:
dir.bg. 345600 IN NS ns.dir.bg.
dir.bg. 345600 IN NS ns.spnet.net.
dir.bg. 345600 IN NS purgatory.spnet.net.
;; ADDITIONAL SECTION:
ns.dir.bg. 345600 IN A 194.145.63.2
ns.spnet.net. 8640 IN A 212.50.0.10
purgatory.spnet.net. 5395 IN A 212.50.0.15
;; Query time: 194 msec
;; SERVER: 192.92.129.1#53(ns.digsys.bg)
;; WHEN: Wed Apr 16 14:21:40 2003
;; MSG SIZE rcvd: 139
Ako obache recursivnata zaiavka se prodylzhi, to shte se poluchi
slednoto (az simuliram s poredica ot nerecursivni - dvete nerekursivni
davat procesa v edna rekursivna zaiavka v sykraten vid, ne sym
postavil vytre NS zapitvaniata kym TLD i t.n...):
$ dig +norecursive @ns.dir.bg -t ns dir.bg
; <<>> DiG 9.2.0rc3 <<>> +norecursive @ns.dir.bg -t ns dir.bg
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16402
;; flags: qr aa ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4
;; QUESTION SECTION:
;dir.bg. IN NS
;; ANSWER SECTION:
dir.bg. 86400 IN NS ns.spnet.net.
dir.bg. 86400 IN NS purgatory.spnet.net.
dir.bg. 86400 IN NS sql.dir.bg.
dir.bg. 86400 IN NS ns.dir.bg.
;; ADDITIONAL SECTION:
ns.spnet.net. 103150 IN A 212.50.0.10
purgatory.spnet.net. 74993 IN A 212.50.0.15
sql.dir.bg. 86400 IN A 194.145.63.21
ns.dir.bg. 86400 IN A 194.145.63.2
;; Query time: 128 msec
;; SERVER: 194.145.63.2#53(ns.dir.bg)
;; WHEN: Wed Apr 16 14:23:00 2003
;; MSG SIZE rcvd: 173
<p><em class="quotelev1">> Tuk variantite sa 2:
<em class="quotelev1">> 1. ako edin server obslujva i dvete zoni, v reply mogat da doidat
<em class="quotelev1">> i CNAME i A RRs, ne pomnia kogato beshe druga zonata kum koiato sochi
<em class="quotelev1">> cname dali se prashtashe v Answer ili v Aditional, no resultata pak
<em class="quotelev1">> se poluchava samo s 1 query.
V Answer section e:
|name |type |class |TTL |length |cname
<em class="quotelev1">> 2. Ako zonata ne se obslujva ot sushtia server v zavisimost ot
<em class="quotelev1">> settings v server, za recursive i cache toi pak moje da vyrne
<em class="quotelev1">> i CNAME i A RRs, no ima podrobnosti okolo tova dali e authoritative
<em class="quotelev1">> answera.
Ako ne e authoritativen, dosta MTA reshenia prosto niama da se syobraziat
s tozi zapis! Poznavam dosta hora, koito poddyrzhat DNS na MTA
mashinite. Tezi DNS-i ne polzvat forwarderi (nito only, nito first). Taka
directno mozhe da se opredeli authoritativnostta na otgovorite. I ako ne
se poluchi AA flag v otgovora.. prosto mail-a se othvyrlia ot MTA.
<em class="quotelev1">> Ne, CNAME m/u zoni ne mislia. Celta na cnames spored men
<em class="quotelev1">> e da kajat koito tochno host kakvo e
<em class="quotelev1">> smtp cname funnyname.domain.com
<em class="quotelev1">> i taka, a tova izobshto ne e problem.
Ehhh... A niakoi me syvetvat da chetat RFC-ta. Za tova, koi host
otgovaria za opredelena usluga se izpolzva WKS (Well Known Services):
"For each MX, a WKS query should be issued to see if the domain name list
actually supports the mail service desired. ... This step is optional, but
strongly encouraged."
(RFC 974/Interpreting the List of MX RRs)
Primer:
ayshell.umd.edu. A 128.8.1.14
MX 10 sayshell.umd.edu.
HINFO NeXT UNIX
WKS 128.8.1.14 tcp ftp telnet smtp
RP louie.trantor.umd.edu. LAM1.people.umd.edu.
<p>Taka, che e napravo smehotvorno obiasnenieto
za tova, che s CNAME se ukazvalo koi e SMTP za domaina...
<p>Osven tova!
Opitai se da ocenish broia na delegiranite po RFC 2317 zoni in-addr.arpa
i CNAME v zonite na domaini za pravata zadacha v DNS. I shte vidish,
che v tozi moment, kogato ima deficit na IP adresi i bezklasovoto delegirane
se praktikuva shiroko, imenno prehvyrlianeto mezhdu domaini e po-chesto
izpolzvanata rolia na CNAME.
<p><p>Ima i oshte neshto! MX zapis ne se preporyhva da byde CNAME! Tova
go kazva RFC 974. Ta kato stignahme do RFC-ta, kakto ti me posyvetva,
haide da ti kazha pyk az kakvo sym prochel za CNAME i MX,
koito pyk sigurno ti ne si prochel predi da pishesh. Otivash i chetesh
sekcia 3.6.2 na RFC 1034. Mozhe da se obyrne vnimanie na RFC 2181.
V lesno smilaem za dushata variant, tova mozhe da se prochete na kratko tuk:
http://www.intac.com/~cdp/cptd-faq/section6.html#MXCNAMEA
<em class="quotelev1">> [cut]
<em class="quotelev1">> za delegiraneto po kusno, ako ostane vreme.
Eto, az pone namerih vreme za da pokazha kak se pravi takova lema
delegirane i kakyv e efektyt ot nego!
Neka pak se vyrnem na zonata ltph.chem.uni-sofia.bg, delegirana
narochno lame vyrhu edin ot moite serveri za imena 193.68.0.202.
Za zonata ima napraven edin edinstven zapis (simuliram CNAME
lame delegirane).
NS host-2
posle po-dolu e kazano
host-2 CNAME host-l
host-l A 192.168.100.9
Sega hvashtame dig i pravim proverka. Opitvame se da izvlechen NS
RR ot ochevidno authoritativen server za imena za ltph.chem.uni-sofia.bg:
$ dig @lcpe.pip.digsys.bg -t ns ltph.chem.uni-sofia.bg
; <<>> DiG 9.2.0rc3 <<>> @lcpe.pip.digsys.bg -t ns ltph.chem.uni-sofia.bg
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13992
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;ltph.chem.uni-sofia.bg. IN NS
;; ANSWER SECTION:
ltph.chem.uni-sofia.bg. 86400 IN NS host-2.ltph.chem.uni-sofia.bg.
;; Query time: 46 msec
;; SERVER: 193.68.0.202#53(lcpe.pip.digsys.bg)
;; WHEN: Wed Apr 16 15:08:09 2003
;; MSG SIZE rcvd: 61
Izliaza taka, vse edno niama NS RR... A vsashnost ima.
Otmetka: Oshte kogato sa se pisali pyrvite DNS software-i se e obyrnalo
vnimanie na vyzmozhnite problemi, koito bi syzdala edna nepravilna
rekursia porodena ot CNAME RR (da ne govorim, che CNAME po
princip otnema poveche resurs za izpylnenieto si)e napraveno
taka. Po princip ima patchove za DNS software-a, koito mogat da nakarat
NS -> CNAME da raboti, no ne se preporychvat. Tova ne sa edinstvenite
problemi, koito sa nakarali horata da vodiat NS->CNAME kym klasa na
lame delegaciite, no e bil edin ot reshavashtite. Ako mi ostane vreme shte
potyrsia linkove kym obsyzdaniata (ako vse oshte stoiat v Internet).
Mozhe da se zabelezhi obache, che ako tozi server za imena byde
popitan za drug resursen zapis, shte se poluchi otgovor (obache taka se
zaobikalia ierarhichnata shema na DNS, v narushenie s koato e izpolzvaneto
na NS -> CNAME i takyv otgovor se naricha neierarhichen):
$ dig @lcpe.pip.digsys.bg -t a host-2.ltph.chem.uni-sofia.bg
; <<>> DiG 9.2.0rc3 <<>> @lcpe.pip.digsys.bg -t a
host-2.ltph.chem.uni-sofia.bg
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21990
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;host-2.ltph.chem.uni-sofia.bg. IN A
;; ANSWER SECTION:
host-2.ltph.chem.uni-sofia.bg. 86400 IN CNAME host-l.ltph.chem.uni-sofia.bg.
host-l.ltph.chem.uni-sofia.bg. 86400 IN A 192.168.100.90
;; AUTHORITY SECTION:
ltph.chem.uni-sofia.bg. 86400 IN NS host-2.ltph.chem.uni-sofia.bg.
;; Query time: 70 msec
;; SERVER: 193.68.0.202#53(lcpe.pip.digsys.bg)
;; WHEN: Wed Apr 16 15:10:21 2003
;; MSG SIZE rcvd: 98
<p>Nakraia pak za UDP i zakysneniata... Dobre, da kazhem, che ako edin CNAME
sochi kym host ot syshtata zona, mozhe i da se izbegne komprometiraneto na
byrzinata. No, ako sochi kym druga zona zakysnenieto ne mozhe da se izbegne
dori i ako otgovoriashtia server pravi rekursiata... zashtoto i na nego shte
mu e nuzhno vreme da ia napravi! Keshiraneto ne pomaga, ako se pitat razlichni
hostove v ramkite na razlichni domaini. Pusni si edin DNS server bez forward,
poigrai si malko da merish zakysnenia kato se pravish na client i shte se
ubedish v tova, koeto kazvam.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
iD8DBQE+nVIM+48lZPXaa+MRAnhIAKCl6111q+ZFaqr5UNOBE0P00fOYvACg8no8
xuCCNkHV6DLO3xfx2vQyCRI=
=8SJu
-----END PGP SIGNATURE-----
============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================
|