Rander skrev:
> Okay, jeg har fattet så meget at rbldns arbejder bedst sammen
> med dnscache/tinydns, og efter ca. 12 timer og ca. det dobbelte
> antal kopper kaffe er jeg nået frem til at det fra LAN-siden
> svarer korrekt på adresser inden for LANet, men det svarer
> overhovedet ikke på eksterne adresser!
"Det"? Er "det" dnscache eller tinydns?
I filerne {dnscache,tinydns}/env/IP står der hvilken adresse der lyttes
på. Normalt sætter man vel tinydns (som er en nameserver) til at lytte
på en "extern" IP adresse og dnscache (som er en caching resolver) til
at lytte på en "intern" IP-adresse, og sætter så /etc/resolv.conf på
LANets maskiner til adressen for dnscache.
Jeg har fx sat tinydns/env/IP til min maskines offentlige IP-adresse
og dnscache/env/IP til 127.0.0.1, samt har "nameserver 127.0.0.1" i
/etc/resolv.conf. Den opsætning får tinydns til at klare forespørgsler
på de domæner min maskine er autoritativ NS for, og får alle programmer
på LAN-siden til at bede dnscache om at slå adresser op (hos de NS'er
der nu er autoritative for forespørgslen). Tinydns kan således nås
både indefra (via dnscache, som selv finder ud af hvor den skal spørge)
og udefra, mens dnscache kun kan nås fra LAN-siden.
(Teoretisk set burde man kunne sætte IP til 0.0.0.0 og dermed få både
tinydns og dnscache til at lytte til alle IP-adresser på maskinens
interfaces, men jeg har ikke prøvet det i praksis (og har heller ikke
lyst til at folk udefra kan tilgå min dnscache.))
Jeg har aldrig brugt dnscachex til noget, så jeg ved ikke hvor dén
hører ind i billedet.
> Jeg har kigget lidt på logfiler og er nået frem til, at når jeg
> laver en nslookup fra Windows-maskinen, så svarer tinydns godt nok
> på den - men når det drejer sig om eksterne adresser burde den jo
> så konsultere dnscachex - det gør den IKKE!
Det er heller ikke dens opgave. Tinydns er en nameserver, intet andet,
og den svarer på forespørgsler som den er autoritativ for - dvs., den
kan servere de oplysninger som ligger i tinydns/root/data.cdb. Det er
ikke tinydns' opgave at spørge andre nameservere, den slags klarer
dnscache (som ikke er en nameserver, men en caching resolver) og cacher
de oplysninger den har i TTL sekunder.
> Rbldns fatter jeg INTET af overhovedet!
Det kan osse være lidt langhåret at sætte DJB-ting op, men rbldns er
ikke sværere end de andre dele. Nu har jeg ikke fulgt ordentlig med i
denne tråd fra starten af, så jeg går ud fra at du ved at rbldns kun
er en privat RBL-server (hvor "privat" betyder "jeg bestemmer hvem
der skal i den sorte gryde").
Konfigurering:
# rbldns-conf rbldns dnslog /service/rbldns 127.53.0.2 rbl.example.com
får rbldns til at køre som bruger "rbldns" med logbruger "dnslog" i
kataloget /service/rbldns, lyttende på [port 53 på] IP-adressen
127.53.0.2, svarende på [RBLDNS] forespørgsler på rbl.example.com.
I filen rbldns/root/data kan man så hælde alle de IP-adresser man ikke
ønsker at modtage post fra - én IP-adresse (eller CIDR-blok) pr linje
(og husk at DJB vil have fire quads i en CIDR-blok: 61.28/15 dur IKKE,
det skal være 61.28.0.0/15 (ja, jeg har hældt stort set hele APNIC i
min rbldns)).
Der er dog én speciel linje i rbldns/root/data, og det er den linje
som fortæller rbldns hvad den skal returnere for et positivt svar.
En linje som
:127.0.0.2:Spam source -- see
http://www.example.com/spampolicy.html
vil få rbldns til at returnere 127.0.0.2 for et positivt svar, samt
sætte TXT-recorden for opslaget til alt efter andet kolon. Mailere
der ramler ind i rbldns vil herefter få meddelelsen
554 Service unavailable; [212.59.152.181] blocked using \
rbl.example.com, reason: Spam source -- see \
http://www.example.com/spampolicy.html
Hvis linien ender med et $, vil dette $ blive erstattet med den
pågældende IP-adresse. Således vil
:127.0.0.2:See
http://www.example.com/rbl/lookup?ip=$
returnere
554 Service unavailable; [212.59.152.181] blocked using \
rbl.example.com, reason: See \
http://www.example.com/rbl/lookup?ip=212.59.152.181
Det irriterer mig at man kun kan have én kolon-linje pr rbldns, i
stedet for én pr IP-adresse i rbldns, men sådan syntes DJB åbenbart
ikke at det skulle være.
Nårh ja, og for at min dnscache skal vide at den skal konsultere
127.53.0.2 for at slå *.rbl.example.com op, har jeg gjort følgende:
# cd {mumle}/dnscache/root/servers
# echo 127.53.0.2 > 0.rbl.example.com
# for i in $(seq 1 255)
> do
> ln -s 0.rbl.example.com ${i}.example.com
> done
# cd ../..
# svc -t $(pwd)
(kan det gøres smartere?).
Når rbldns kører på 127.53.0.2, betyder det osse at rbl.example.com
kun kan tilgås fra LAN-siden. Hvis den skal være offentlig til-
gængelig, må man naturligvis sætte det anderledes op.
Er det ikke det hele? Det er efterhånden lang tid siden jeg har sat
djbdns op, så måske har jeg glemt noget, men spørg endelig løs - jeg
er villig til at blive ved til du har fået det op at køre.
(Disclaimer: jeg ved INTET om qmail og rblsmtpd, så her må andre
træde til.)
Og når du så har fået det til at svinge, burde du overveje at sætte
din egen root-server op, så slipper dnscache for at gå ud i verden
hver gang den skal se hvor et TLD skal slås op - det giver en bedre
responstid, synes jeg.
Smagsprøve kan ses på
http://support.open-rsc.org/How_To/unix/djbdns/
men de får det til at lyde en anelse mere besværligt end det er i
virkeligheden.
// Klaus
--
><>° vandag, môre, altyd saam