---

Hey Gruppe.

Jeg har et lille spørgsmål som jeg håber nogle kan hjælpe med her engang.

På mit arbejde har jeg følgende domæne som er masterdomænet.
insatech.com hvor jeg har sat bind op som intern DNS. Alt dette fungerer
fint, da domænet har sin egen mailserver etc.
Nu har min chef's kone så også et domæne, som indeholder en hjemmeside
og mail. Dette domæne ligger på en intern server - som kører seperat fra
det andet domæne, på en seperat maskine.

Men idet jeg prøver at sende en mail fra min mailkonto i masterdomænet
til chefens kone's mailadresse (rita@ritajuul.com)- får jeg at vide den
looper tilbage til min mailserver.
Udaftil er DNS hostet via gratisDNS, hvor jeg ikke pt har adgangen til
opsætningen af ritajuul.com. men har til masterdomænet.
Min mailserver mail.insatech.com er på 87.49.142.40
mail.ritajuul.com skulle gerne være 87.49.142.42.
hvilket i princippet også vises ved en dig.

Men da jeg kun har en zonefil i min bindopsætning - hvad skal jeg så
helt konkret gøre for dette problem løses???
Skal jeg lave en zonefil mere konkret for ritajuul.com domænet?? For det
har jeg prøvet uden det store held.

Som sagt den besked jeg får omkring loopback:
Fra: Mail Delivery System [mailto:MAILER-DAEMON@insatech.com]
Sendt: 3. august 2008 21:49
Til: pbj@insatech.com
Emne: Undelivered Mail Returned to Sender

This is the mail system at host insatech.com.

I'm sorry to have to inform you that your message could not be delivered to
one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can delete your own
text from the attached returned message.

The mail system

<rita@ritajuul.com>: mail for ritajuul.com loops back to myself

Hvor jeg har prøvet at lave en zonefil til domænet hvor jeg får dette svar:
This is the mail system at host insatech.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<rita@ritajuul.com>: Host or domain name not found. Name service error for
name=mail.ritajuul.com.ritajuul.com type=A: Host not found

Er der et smart hoved der lige kan forklare mig hvordan jeg skal gøre
dette nummer ???

--
Med Venlig Hilsen

Per Jørgense/\/

---

---

Den Tue, 5 Aug 2008 10:48:36 +0200 skrev Michael Rasmussen:
> --Sig_/_ekgKfs14Am/jEgpHrzM5nE
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, 05 Aug 2008 10:12:42 +0200
> Per J=F8rgensen <linux@pbj-design.dk> wrote:
>
>> <rita@ritajuul.com>: Host or domain name not found. Name service error for
>> name=3Dmail.ritajuul.com.ritajuul.com type=3DA: Host not found
>>=20
>> Er der et smart hoved der lige kan forklare mig hvordan jeg skal g=F8re d=
> ette nummer ???
>>=20
> Har du ikke blot glemt denne instruktion i din named.conf:
>
> forwarders {
> 87.72.47.122;
> 82.195.156.187;
> };

"forwarders" er da kun nødvendige når dns-serveren ikke selv har
adgang til internettet, eller hvis der er tale om ikke-officielle
domæner.

Når de ligger hos gratisdns, vil jeg gå ud fra de er officielle.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis skrev den 05-08-2008 10:55:

> "forwarders" er da kun nødvendige når dns-serveren ikke selv har
> adgang til internettet, eller hvis der er tale om ikke-officielle
> domæner.

Eller hvis man ønsker at udnytte at ens udbyders DNS-server formentlig
er større og har mere i cachen end ens egen.

--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

On 2008-08-05, Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:
>
>> "forwarders" er da kun nødvendige når dns-serveren ikke selv har
>> adgang til internettet, eller hvis der er tale om ikke-officielle
>> domæner.
>
> Eller hvis man ønsker at udnytte at ens udbyders DNS-server formentlig
> er større og har mere i cachen end ens egen.

Eller hvis man har en nameserver, der er sårbar over for
Kaminsky-angrebet.

--
Andreas

---

Den Tue, 5 Aug 2008 10:35:04 +0000 (UTC) skrev Andreas Plesner Jacobsen:
> On 2008-08-05, Thorbjørn Ravn Andersen <thunderaxiom@gmail.com> wrote:
>>
>>> "forwarders" er da kun nødvendige når dns-serveren ikke selv har
>>> adgang til internettet, eller hvis der er tale om ikke-officielle
>>> domæner.
>>
>> Eller hvis man ønsker at udnytte at ens udbyders DNS-server formentlig
>> er større og har mere i cachen end ens egen.
>
> Eller hvis man har en nameserver, der er sårbar over for
> Kaminsky-angrebet.

Er det nogensinde kommet frem hvad det angreb går ud på? Det eneste
jeg har set var en test-side som det aldrig lykkedes at få til at
teste andet end cybercitys servere (ikke vores egne), CentOS så
ikke ud til at have nogen opdatering, og på bind siden var der
kun en ny release med (efter deres egen beskrivelse) så elendig
performance at de anbefalede development-udgaven.

(Det er et stykke tid siden jeg checkede - ferie).

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis <nospam@nospam.invalid> wrote:

> Er det nogensinde kommet frem hvad det angreb går ud på? Det eneste
> jeg har set var en test-side som det aldrig lykkedes at få til at
> teste andet end cybercitys servere (ikke vores egne), CentOS så

$ dig +short porttest.dns-oarc.net TXT @dns102.telia.com
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"194.255.56.70 is GREAT: 26 queries in 4.6 seconds from 26 ports with std dev 18221"

$ dig +short porttest.dns-oarc.net TXT @195.184.44.34
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"195.184.44.34 is POOR: 26 queries in 4.6 seconds from 1 ports with std dev 0"

--
-René

---

Den 05 Aug 2008 13:46:04 GMT skrev Rene Joergensen:
> Kent Friis <nospam@nospam.invalid> wrote:
>
>> Er det nogensinde kommet frem hvad det angreb går ud på? Det eneste
>> jeg har set var en test-side som det aldrig lykkedes at få til at
>> teste andet end cybercitys servere (ikke vores egne), CentOS så
>
> $ dig +short porttest.dns-oarc.net TXT @dns102.telia.com
> porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
> "194.255.56.70 is GREAT: 26 queries in 4.6 seconds from 26 ports with std dev 18221"
>
> $ dig +short porttest.dns-oarc.net TXT @195.184.44.34
> porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
> "195.184.44.34 is POOR: 26 queries in 4.6 seconds from 1 ports with std dev 0"

Den kan ikke få fat i vores DNS-servere. Var der ikke noget med at
hullet var noget der kunne angribes fra en browser? (javascript?)
Eller blander ejg det sammen med et andet hul?

Og det forklarer stadig ikke hvad hullet var, hvergang der var
nogen der sagde "Nåh, det der bare genbrug af portnumre. Det har
DJB råbt op om i årevis", var svaret at det er meget værre, det
med portnumrene er bare en workaround.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis <nospam@nospam.invalid> wrote:

> Den kan ikke få fat i vores DNS-servere. Var der ikke noget med at
> hullet var noget der kunne angribes fra en browser? (javascript?)
> Eller blander ejg det sammen med et andet hul?

Nej, det er cache poisoning der problemet.

> Og det forklarer stadig ikke hvad hullet var, hvergang der var
> nogen der sagde "Nåh, det der bare genbrug af portnumre. Det har
> DJB råbt op om i årevis", var svaret at det er meget værre, det
> med portnumrene er bare en workaround.

Det er designfejl i selve DNS, og det nuværende "fix" er blot et som gør
det sværere at udnytte fejlen.

http://blog.wired.com/27bstroke6/2008/07/details-of-dns.html

--
-René

---

Den 05 Aug 2008 20:06:26 GMT skrev Rene Joergensen:
> Kent Friis <nospam@nospam.invalid> wrote:
>
>> Den kan ikke få fat i vores DNS-servere. Var der ikke noget med at
>> hullet var noget der kunne angribes fra en browser? (javascript?)
>> Eller blander ejg det sammen med et andet hul?
>
> Nej, det er cache poisoning der problemet.

Og kræver at man kan få en der har adgang til at spørge den DNS-server
der skal angribes til at spørge om en række domæner. Fx <img> tags
i en browser.

Så jo, angrebet kan godt startes fra en browser. At dns-serveren er
bag firewall'en hjælper ikke.

>> Og det forklarer stadig ikke hvad hullet var, hvergang der var
>> nogen der sagde "Nåh, det der bare genbrug af portnumre. Det har
>> DJB råbt op om i årevis", var svaret at det er meget værre, det
>> med portnumrene er bare en workaround.
>
> Det er designfejl i selve DNS, og det nuværende "fix" er blot et som gør
> det sværere at udnytte fejlen.
>
> http://blog.wired.com/27bstroke6/2008/07/details-of-dns.html

Ok, http://beezari.livejournal.com/141796.html forklarer hvad det
egentlig går ud på.

Men som en skriver på ovenstående link: Jamen hov, checker DNS-serveren
ikke afsender-IP'en? Og har ISP'erne ikke efterhånden fået sat filtre
på afsender-IP på border-routerne, så spoofing er begrænset til hosts
på samme net?

Hvad er iøvrigt den korrekte løsning? At ændre protokollen til at
håndtere 128-bit query-id'er?

Og til slut: Nå, bare cache poisoning... Og det efter at manden har
fået det til at lyde som om hele internettet ville blive Pwned, hvis
ikke alle opgraderede. Ikke nok med at man skal lokke nogen (fx en
browser) til at spørge om victim-domænet, man skal også vide hvornår
den gør det, og hvilken dns-server man skal sende det falske svar
til. Risikoen ser ikke så stor ud, IMHO. Den kan komme med i næste
yum update, hvis der er en stabil version af bind klar til den tid.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis <nospam@nospam.invalid> wrote:

> Og kræver at man kan få en der har adgang til at spørge den DNS-server
> der skal angribes til at spørge om en række domæner. Fx <img> tags
> i en browser.

Ja, men mange rekursive navneservere har ikke lukket for omverdenen og
tillader navneopslag fra andet end deres egne net. Derudover skal det
nok være muligt at få ram på en navneserver via botnets. Mon ikke der er
mindst en bot på hver af de danske udbyderes net.

> Så jo, angrebet kan godt startes fra en browser. At dns-serveren er
> bag firewall'en hjælper ikke.

Nej, det har jeg vist heller aldrig påstået at det gjorde :)

> Og til slut: Nå, bare cache poisoning... Og det efter at manden har
> fået det til at lyde som om hele internettet ville blive Pwned, hvis
> ikke alle opgraderede. Ikke nok med at man skal lokke nogen (fx en
> browser) til at spørge om victim-domænet, man skal også vide hvornår
> den gør det, og hvilken dns-server man skal sende det falske svar
> til. Risikoen ser ikke så stor ud, IMHO. Den kan komme med i næste
> yum update, hvis der er en stabil version af bind klar til den tid.

Botnets.....

Jeg synes nu truslen er reel nok.

--
-René

---

Den 06 Aug 2008 06:24:27 GMT skrev Rene Joergensen:
> Kent Friis <nospam@nospam.invalid> wrote:
>
>> Og kræver at man kan få en der har adgang til at spørge den DNS-server
>> der skal angribes til at spørge om en række domæner. Fx <img> tags
>> i en browser.
>
> Ja, men mange rekursive navneservere har ikke lukket for omverdenen og
> tillader navneopslag fra andet end deres egne net. Derudover skal det
> nok være muligt at få ram på en navneserver via botnets. Mon ikke der er
> mindst en bot på hver af de danske udbyderes net.

Nu bekymrer jeg mig så ikke om udbydernes navneservere, dem må de
selv sørge for at opdatere.

Jeg bekymrer mig kun om vores egne, og jeg kan se ingen af dem er
tilgængelige udefra, og de fleste endda kun fra 127.0.0.1.

>> Og til slut: Nå, bare cache poisoning... Og det efter at manden har
>> fået det til at lyde som om hele internettet ville blive Pwned, hvis
>> ikke alle opgraderede. Ikke nok med at man skal lokke nogen (fx en
>> browser) til at spørge om victim-domænet, man skal også vide hvornår
>> den gør det, og hvilken dns-server man skal sende det falske svar
>> til. Risikoen ser ikke så stor ud, IMHO. Den kan komme med i næste
>> yum update, hvis der er en stabil version af bind klar til den tid.
>
> Botnets.....

Er på den forkerte side af firewall'en.

> Jeg synes nu truslen er reel nok.

Vi ser den fra forskellige synspunkter.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis skrev:
> Den 06 Aug 2008 06:24:27 GMT skrev Rene Joergensen:
>> Kent Friis <nospam@nospam.invalid> wrote:
>>
>>> Og kræver at man kan få en der har adgang til at spørge den DNS-server
>>> der skal angribes til at spørge om en række domæner. Fx <img> tags
>>> i en browser.
>> Ja, men mange rekursive navneservere har ikke lukket for omverdenen og
>> tillader navneopslag fra andet end deres egne net. Derudover skal det
>> nok være muligt at få ram på en navneserver via botnets. Mon ikke der er
>> mindst en bot på hver af de danske udbyderes net.
>
> Nu bekymrer jeg mig så ikke om udbydernes navneservere, dem må de
> selv sørge for at opdatere.
>
> Jeg bekymrer mig kun om vores egne, og jeg kan se ingen af dem er
> tilgængelige udefra, og de fleste endda kun fra 127.0.0.1.
>
>>> Og til slut: Nå, bare cache poisoning... Og det efter at manden har
>>> fået det til at lyde som om hele internettet ville blive Pwned, hvis
>>> ikke alle opgraderede. Ikke nok med at man skal lokke nogen (fx en
>>> browser) til at spørge om victim-domænet, man skal også vide hvornår
>>> den gør det, og hvilken dns-server man skal sende det falske svar
>>> til. Risikoen ser ikke så stor ud, IMHO. Den kan komme med i næste
>>> yum update, hvis der er en stabil version af bind klar til den tid.
>> Botnets.....
>
> Er på den forkerte side af firewall'en.
>
>> Jeg synes nu truslen er reel nok.
>
> Vi ser den fra forskellige synspunkter.
>
> Mvh
> Kent
Hmmmm men det forklarer ikke generelt hvordan jeg skal løse mit problem
omkring den looper tilbage til sig selv - selvom gratisDNS står rigtigt!

--
Med Venlig Hilsen

Per Jørgense/\/

---

Kent Friis <nospam@nospam.invalid> wrote:

> Nu bekymrer jeg mig så ikke om udbydernes navneservere, dem må de
> selv sørge for at opdatere.

Der var tale om internettet som helhed, og ikke kun jeres lokalnet.

--
-René

---

Den 06 Aug 2008 11:09:44 GMT skrev Rene Joergensen:
> Kent Friis <nospam@nospam.invalid> wrote:
>
>> Nu bekymrer jeg mig så ikke om udbydernes navneservere, dem må de
>> selv sørge for at opdatere.
>
> Der var tale om internettet som helhed, og ikke kun jeres lokalnet.

Jeg *kan* kun opdatere vores egne navneservere. Resten har jeg sg*
ikke passwords til.

Det blev meldt ud som om det var et meget alvorligt problem, og alle
skulle opdatere. Da jeg læste det, måtte jeg nødvendigvis overveje
om jeg skulle tage chancen med en ustabil version af bind, og risikere
at lægge hele firmaet ned - eller jeg skulle tage chancen og satse
på at det ikke var alvorligt, med deraf følgende risiko for at nogen
lægger hele firmaet ned.

Jeg valgte det sidste. Og nu detaljerne er kommet frem, ser det ud
til at det var det korrekte valg, selvom der blev råbt højt om at
det var meget vigtigt at opdatere. Det hul der er tale om er ikke
værd at risikere at køre på en ustabil af bind for.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

On 2008-08-05, Kent Friis <nospam@nospam.invalid> wrote:
>>
>> Nej, det er cache poisoning der problemet.
>
> Og kræver at man kan få en der har adgang til at spørge den DNS-server
> der skal angribes til at spørge om en række domæner. Fx <img> tags
> i en browser.
>
> Så jo, angrebet kan godt startes fra en browser. At dns-serveren er
> bag firewall'en hjælper ikke.

Det er noget søgt at begynde at blande browsere ind i det. Mennesker er
trods alt ikke særligt deterministiske. Jeg tror jeg ville udnytte at
mange mailservere laver reverse->forward DNS-check, hvis jeg var
blackhat.

> Men som en skriver på ovenstående link: Jamen hov, checker DNS-serveren
> ikke afsender-IP'en? Og har ISP'erne ikke efterhånden fået sat filtre
> på afsender-IP på border-routerne, så spoofing er begrænset til hosts
> på samme net?

Hahaha, nej. BCP38 er håbløst smalt udbredt. Danmark er nok langt
fremme i forhold til resten af verden, men angriberen behøver jo ikke at
være i landet.

> Hvad er iøvrigt den korrekte løsning? At ændre protokollen til at
> håndtere 128-bit query-id'er?

Det udskyder blot problemet lidt endnu. Løsningen er DNSSEC.

> Og til slut: Nå, bare cache poisoning... Og det efter at manden har
> fået det til at lyde som om hele internettet ville blive Pwned, hvis
> ikke alle opgraderede. Ikke nok med at man skal lokke nogen (fx en
> browser) til at spørge om victim-domænet, man skal også vide hvornår
> den gør det, og hvilken dns-server man skal sende det falske svar
> til.

Du undervurderer angriberes kreativitet, hvilket IMO er en stor fejl.
Jeg brugte et par minutter på at finde på at udnytte reverse DNS og
mailservere, og det var endda før jeg fik kaffe.

--
Andreas

---

Andreas Plesner Jacobsen skrev:
> On 2008-08-05, Kent Friis <nospam@nospam.invalid> wrote:
>>> Nej, det er cache poisoning der problemet.
>> Og kræver at man kan få en der har adgang til at spørge den DNS-server
>> der skal angribes til at spørge om en række domæner. Fx <img> tags
>> i en browser.
>>
>> Så jo, angrebet kan godt startes fra en browser. At dns-serveren er
>> bag firewall'en hjælper ikke.
>
> Det er noget søgt at begynde at blande browsere ind i det. Mennesker er
> trods alt ikke særligt deterministiske. Jeg tror jeg ville udnytte at
> mange mailservere laver reverse->forward DNS-check, hvis jeg var
> blackhat.
>
>> Men som en skriver på ovenstående link: Jamen hov, checker DNS-serveren
>> ikke afsender-IP'en? Og har ISP'erne ikke efterhånden fået sat filtre
>> på afsender-IP på border-routerne, så spoofing er begrænset til hosts
>> på samme net?
>
> Hahaha, nej. BCP38 er håbløst smalt udbredt. Danmark er nok langt
> fremme i forhold til resten af verden, men angriberen behøver jo ikke at
> være i landet.
>
>> Hvad er iøvrigt den korrekte løsning? At ændre protokollen til at
>> håndtere 128-bit query-id'er?
>
> Det udskyder blot problemet lidt endnu. Løsningen er DNSSEC.
>
>> Og til slut: Nå, bare cache poisoning... Og det efter at manden har
>> fået det til at lyde som om hele internettet ville blive Pwned, hvis
>> ikke alle opgraderede. Ikke nok med at man skal lokke nogen (fx en
>> browser) til at spørge om victim-domænet, man skal også vide hvornår
>> den gør det, og hvilken dns-server man skal sende det falske svar
>> til.
>
> Du undervurderer angriberes kreativitet, hvilket IMO er en stor fejl.
> Jeg brugte et par minutter på at finde på at udnytte reverse DNS og
> mailservere, og det var endda før jeg fik kaffe.
>
Hehehe - kaffe er en overvurderet ting.

Men det er vel ikke således at du kan komme med et bud på en løsning på
mit problem, så det kan fixes

--
Med Venlig Hilsen

Per Jørgense/\/

---

On 2008-08-11, Per Jørgensen <linux@pbj-design.dk> wrote:
>>
>> Du undervurderer angriberes kreativitet, hvilket IMO er en stor fejl.
>> Jeg brugte et par minutter på at finde på at udnytte reverse DNS og
>> mailservere, og det var endda før jeg fik kaffe.
>>
> Hehehe - kaffe er en overvurderet ting.
>
> Men det er vel ikke således at du kan komme med et bud på en løsning på
> mit problem, så det kan fixes

Ikke så længe vi kun får halve historier. Der må facts og output fra
dig, host og venner på bordet.
Det er ikke nok at du skriver at de "giver det rigtige svar".

http://www.catb.org/~esr/faqs/smart-questions.html

--
Andreas

---

Andreas Plesner Jacobsen skrev:
> On 2008-08-11, Per Jørgensen <linux@pbj-design.dk> wrote:
>>> Du undervurderer angriberes kreativitet, hvilket IMO er en stor fejl.
>>> Jeg brugte et par minutter på at finde på at udnytte reverse DNS og
>>> mailservere, og det var endda før jeg fik kaffe.
>>>
>> Hehehe - kaffe er en overvurderet ting.
>>
>> Men det er vel ikke således at du kan komme med et bud på en løsning på
>> mit problem, så det kan fixes
>
> Ikke så længe vi kun får halve historier. Der må facts og output fra
> dig, host og venner på bordet.
> Det er ikke nok at du skriver at de "giver det rigtige svar".
>
> http://www.catb.org/~esr/faqs/smart-questions.html
>
Her er det hele taget fra det interne netværk:
dig mail.ritajuul.com

; <<>> DiG 9.4.2-P1 <<>> mail.ritajuul.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11252
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 10

;; QUESTION SECTION:
;mail.ritajuul.com.      IN   A

;; ANSWER SECTION:
mail.ritajuul.com.   43200   IN   A   87.49.142.42

;; AUTHORITY SECTION:
ritajuul.com.      43200   IN   NS   ns1.gratisdns.dk.
ritajuul.com.      43200   IN   NS   ns2.gratisdns.dk.
ritajuul.com.      43200   IN   NS   ns3.gratisdns.dk.
ritajuul.com.      43200   IN   NS   ns4.gratisdns.dk.
ritajuul.com.      43200   IN   NS   ns5.gratisdns.dk.

;; ADDITIONAL SECTION:
ns1.gratisdns.dk.   16503   IN   A   213.173.243.8
ns1.gratisdns.dk.   17427   IN   AAAA   2001:16d8:ffba::1
ns2.gratisdns.dk.   17413   IN   A   87.72.47.122
ns2.gratisdns.dk.   17268   IN   AAAA   2001:16d8:ff64::1
ns3.gratisdns.dk.   17413   IN   A   82.195.156.187
ns3.gratisdns.dk.   18321   IN   AAAA   2001:770:189::1
ns4.gratisdns.dk.   17413   IN   A   207.44.200.58
ns4.gratisdns.dk.   17418   IN   AAAA   2001:4830:1684::1
ns5.gratisdns.dk.   17412   IN   A   195.24.78.25
ns5.gratisdns.dk.   30437   IN   AAAA   2001:6f8:3ad::1

;; Query time: 108 msec
;; SERVER: 172.16.50.5#53(172.16.50.5)
;; WHEN: Tue Aug 12 07:40:06 2008
;; MSG SIZE rcvd: 373


Host:
$ host ritajuul.com
ritajuul.com has address 87.49.142.42
ritajuul.com mail is handled by 10 ritajuul.com.

Når jeg fra insatech.com sender en mail til ritajuul.com - kommer denne
mail tilbage:
This is the mail system at host insatech.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<rita@ritajuul.com>: mail for ritajuul.com loops back to myself

Reporting-MTA: dns; insatech.com
X-Postfix-Queue-ID: 0B2B51503C0
X-Postfix-Sender: rfc822; pbj@insatech.com
Arrival-Date: Tue, 12 Aug 2008 07:41:39 +0200 (CEST)

Final-Recipient: rfc822; rita@ritajuul.com
Original-Recipient: rfc822;rita@ritajuul.com
Action: failed
Status: 5.4.6
Diagnostic-Code: X-Postfix; mail for ritajuul.com loops back to myself

Og i min logfil på min mailserver kommer denne fejl:
Aug 12 07:41:39 sif amavis[18795]: (18795-08) Passed CLEAN, LOCAL
[172.16.50.200] [172.16.50.200] <pbj@insatech.com> ->
<rita@ritajuul.com>, Message-ID: <48A122D1.9010402@insatech.com>,
mail_id: Hhjp0DuyBsRV, Hits: -1.646, size: 6640, queued_as: 0B2B51503C0,
2075 ms
Aug 12 07:41:39 sif postfix/smtp[21186]: ED10015037B:
to=<rita@ritajuul.com>, relay=127.0.0.1[127.0.0.1]:10024, delay=2.1,
delays=0.02/0/0/2.1, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as
0B2B51503C0)
Aug 12 07:41:39 sif postfix/qmgr[10011]: ED10015037B: removed
Aug 12 07:41:39 sif postfix/smtp[21203]: warning: host
ritajuul.com[87.49.142.42]:25 greeted me with my own hostname insatech.com
Aug 12 07:41:39 sif postfix/smtp[21203]: warning: host
ritajuul.com[87.49.142.42]:25 replied to HELO/EHLO with my own hostname
insatech.com
Aug 12 07:41:39 sif postfix/smtp[21203]: 0B2B51503C0:
to=<rita@ritajuul.com>, relay=ritajuul.com[87.49.142.42]:25, delay=0.08,
delays=0.01/0/0.06/0, dsn=5.4.6, status=bounced (mail for ritajuul.com
loops back to myself)

Der hvor jeg så bliver i tvivl - er denne maskine som står på XX:42
adressen, er normalt vores webserver, men min forgænger har så sat en
ekstra mailserver op - på wwwserveren som en seperat mailserver kun til
håndtering af mails til ritajuul.com.

Efter hvad jeg kan se i det - svarer denne mailserver med ehlo
insatech.com, men da denne kører sendmail, har jeg kigget overalt for at
finde hvor den evt sætter EHLO - og det eneste sted jeg kan fidne dette
er i /etc/hosts - som ser således ud:
127.0.0.1   insatech.com   insatech   localhost.localdomain   localhost
127.0.0.2   ritajuul.com   www
127.0.0.3   ritajuul.dk   www

Men det burde vel være det eneste sted, hvor maskinens navn er nævnt!


--
Med Venlig Hilsen

Per Jørgense/\/

---

Den Mon, 11 Aug 2008 08:59:09 +0000 (UTC) skrev Andreas Plesner Jacobsen:
> On 2008-08-05, Kent Friis <nospam@nospam.invalid> wrote:
>
>> Men som en skriver på ovenstående link: Jamen hov, checker DNS-serveren
>> ikke afsender-IP'en? Og har ISP'erne ikke efterhånden fået sat filtre
>> på afsender-IP på border-routerne, så spoofing er begrænset til hosts
>> på samme net?
>
> Hahaha, nej. BCP38 er håbløst smalt udbredt. Danmark er nok langt
> fremme i forhold til resten af verden, men angriberen behøver jo ikke at
> være i landet.

Men hvis de danske ISP'er har styr på det, kan man jo ikke spoofe
udefra. At kineserne kan spoofe brasilianske IP'er behøver jeg
jo ikke bekymre mig om.

>> Hvad er iøvrigt den korrekte løsning? At ændre protokollen til at
>> håndtere 128-bit query-id'er?
>
> Det udskyder blot problemet lidt endnu. Løsningen er DNSSEC.

Så kan du sg* lige så godt sige IPv6 eller kolonisering af Mars.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

On 2008-08-11, Kent Friis <nospam@nospam.invalid> wrote:
>>
>>> Men som en skriver på ovenstående link: Jamen hov, checker DNS-serveren
>>> ikke afsender-IP'en? Og har ISP'erne ikke efterhånden fået sat filtre
>>> på afsender-IP på border-routerne, så spoofing er begrænset til hosts
>>> på samme net?
>>
>> Hahaha, nej. BCP38 er håbløst smalt udbredt. Danmark er nok langt
>> fremme i forhold til resten af verden, men angriberen behøver jo ikke at
>> være i landet.
>
> Men hvis de danske ISP'er har styr på det, kan man jo ikke spoofe
> udefra. At kineserne kan spoofe brasilianske IP'er behøver jeg
> jo ikke bekymre mig om.

Prøv lige at spole tilbage. Så længe du benytter en "Kaminsky-sårbar"
DNS-server har du problemer. De danske ISP'er har kun filtre på, således
at deres egne kunder ikke kan spoofe, og at de ikke slipper pakker ind,
der har deres egne kunder som source.
Så det er i høj grad noget du skal bekymre dig om, hvis du har en
rekursiv server.
Der skal netop ikke mere til end at du stoler på en brasiliansk
tjeneste, og der er en kineser, der er klar over dette i dit ovenstående
eksempel.
Faktisk kan det være endnu tættere på hjem end det, hvis du har din
forbindelse hos en dansk udbyder og din tjeneste hos en anden, og
derudover sidder bag en mere sårbar resolver, så er det forholdsvist
trivielt for selvsamme kineser at angribe dig. Hvis du vel at mærke er
interessant.

>>> Hvad er iøvrigt den korrekte løsning? At ændre protokollen til at
>>> håndtere 128-bit query-id'er?
>>
>> Det udskyder blot problemet lidt endnu. Løsningen er DNSSEC.
>
> Så kan du sg* lige så godt sige IPv6 eller kolonisering af Mars.

Koloniseringen af Mars er nok den af de tre jeg ikke forventer at se i
min levetid. IPv6 kører jeg allerede, og DNSSEC kommer mine egne domæner
til at understøtte i en nær fremtid. Indtil da sætter jeg min lid til
certifikatudbyderne og mine SSH-nøgler.
Og så forventer jeg også at den seneste debat omkring driften af .dk gør
at jeg får mulighed for DNSSEC der. På den ene eller anden måde.
Derudover ville 128 bit id'er forudsætte en komplet udskiftning af alle
dns-servere, mens DNSSEC allerede findes i mange af de eksisterende.

--
Andreas

---

Den Mon, 11 Aug 2008 20:19:09 +0000 (UTC) skrev Andreas Plesner Jacobsen:
> On 2008-08-11, Kent Friis <nospam@nospam.invalid> wrote:
>>>
>>>> Men som en skriver på ovenstående link: Jamen hov, checker DNS-serveren
>>>> ikke afsender-IP'en? Og har ISP'erne ikke efterhånden fået sat filtre
>>>> på afsender-IP på border-routerne, så spoofing er begrænset til hosts
>>>> på samme net?
>>>
>>> Hahaha, nej. BCP38 er håbløst smalt udbredt. Danmark er nok langt
>>> fremme i forhold til resten af verden, men angriberen behøver jo ikke at
>>> være i landet.
>>
>> Men hvis de danske ISP'er har styr på det, kan man jo ikke spoofe
>> udefra. At kineserne kan spoofe brasilianske IP'er behøver jeg
>> jo ikke bekymre mig om.
>
> Prøv lige at spole tilbage. Så længe du benytter en "Kaminsky-sårbar"
> DNS-server

Og det var alle der ikke kører DNSSEC...

> har du problemer. De danske ISP'er har kun filtre på, således
> at deres egne kunder ikke kan spoofe, og at de ikke slipper pakker ind,
> der har deres egne kunder som source.
> Så det er i høj grad noget du skal bekymre dig om, hvis du har en
> rekursiv server.
> Der skal netop ikke mere til end at du stoler på en brasiliansk
> tjeneste, og der er en kineser, der er klar over dette i dit ovenstående
> eksempel.

Det har du vel egentlig ret i.

>>>> Hvad er iøvrigt den korrekte løsning? At ændre protokollen til at
>>>> håndtere 128-bit query-id'er?
>>>
>>> Det udskyder blot problemet lidt endnu. Løsningen er DNSSEC.
>>
>> Så kan du sg* lige så godt sige IPv6 eller kolonisering af Mars.
>
> Koloniseringen af Mars er nok den af de tre jeg ikke forventer at se i
> min levetid. IPv6 kører jeg allerede, og DNSSEC kommer mine egne domæner
> til at understøtte i en nær fremtid. Indtil da sætter jeg min lid til
> certifikatudbyderne og mine SSH-nøgler.

Er der en DNSSEC howto?

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

On 2008-08-12, Kent Friis <nospam@nospam.invalid> wrote:
>>>>
>> Prøv lige at spole tilbage. Så længe du benytter en "Kaminsky-sårbar"
>> DNS-server
>
> Og det var alle der ikke kører DNSSEC...

nej. det var derfor jeg tilføjede kaminsky.
selvom port randomization ikke er løsningen, er det godt nok indtil
videre.

>> Koloniseringen af Mars er nok den af de tre jeg ikke forventer at se i
>> min levetid. IPv6 kører jeg allerede, og DNSSEC kommer mine egne domæner
>> til at understøtte i en nær fremtid. Indtil da sætter jeg min lid til
>> certifikatudbyderne og mine SSH-nøgler.
>
> Er der en DNSSEC howto?

http://dnssec.net/

--
Andreas

---

Den Tue, 05 Aug 2008 12:36:42 +0200 skrev Thorbjørn Ravn Andersen:
> Kent Friis skrev den 05-08-2008 10:55:
>
>> "forwarders" er da kun nødvendige når dns-serveren ikke selv har
>> adgang til internettet, eller hvis der er tale om ikke-officielle
>> domæner.
>
> Eller hvis man ønsker at udnytte at ens udbyders DNS-server formentlig
> er større og har mere i cachen end ens egen.

Nu skrev jeg jo "nødvendig", ikke "ønsket".

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Den Tue, 05 Aug 2008 10:12:42 +0200 skrev Per Jørgensen:
>
> <rita@ritajuul.com>: Host or domain name not found. Name service error for
> name=mail.ritajuul.com.ritajuul.com type=A: Host not found

Den fejl der (domænet skrevet to gange) betyder at du har glemt
et punktum efter domænet i zone-filen.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.

---

Kent Friis skrev:
> Den Tue, 05 Aug 2008 10:12:42 +0200 skrev Per Jørgensen:
>> <rita@ritajuul.com>: Host or domain name not found. Name service error for
>> name=mail.ritajuul.com.ritajuul.com type=A: Host not found
>
> Den fejl der (domænet skrevet to gange) betyder at du har glemt
> et punktum efter domænet i zone-filen.
>
> Mvh
> Kent
Hey Kent.

Det var rigtigt - Den fejl er nu rettet.
Men det er så ikke løsningen konkret for selvom jeg nu har en seperat
zonefil der skriver hvor mailserveren for ritajuul.com er - så får jeg
stadigvæk svaret omkring den looper tilbage til mig selv!
This is the mail system at host insatech.com.

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.

For further assistance, please send mail to postmaster.

If you do so, please include this problem report. You can
delete your own text from the attached returned message.

The mail system

<rita@ritajuul.com>: mail for ritajuul.com loops back to myself

Nu får jeg denne besked med en seperat zonefil!

Og så lavede jeg lige denne :
# grep -R ritajuul.com /etc/bind/*
/etc/bind/db.ritajuul.com:@   IN   SOA   odin.ritajuul.com.
hostmaster.ritajuul.com. (
/etc/bind/db.ritajuul.com:   IN   MX   10   mail.ritajuul.com.
/etc/bind/named.conf.local:zone "ritajuul.com" {
/etc/bind/named.conf.local:   file "/etc/bind/db.ritajuul.com";
--
Med Venlig Hilsen

Per Jørgense/\/

---

Per Jørgensen skrev den 05-08-2008 11:33:

> Og så lavede jeg lige denne :
> # grep -R ritajuul.com /etc/bind/*
> /etc/bind/db.ritajuul.com:@ IN SOA odin.ritajuul.com.
> hostmaster.ritajuul.com. (
> /etc/bind/db.ritajuul.com: IN MX 10 mail.ritajuul.com.
> /etc/bind/named.conf.local:zone "ritajuul.com" {
> /etc/bind/named.conf.local: file "/etc/bind/db.ritajuul.com";

Lyder som om du skal til at kigge på "host" og/eller "dig" til at
fortælle dig hvad DNS-serveren tror om ritajuul.com domænet.

Er det maskinen der også lyder navnet "mail.ritajuul.com" du laver de
her øvelser på? I så fald, skal du nok fortælle SMT-serveren at du også
gerne vil have den skal modtage post for ritajuul.com domænet.
--
Thorbjørn Ravn Andersen "... plus... Tubular Bells!"

---

Thorbjørn Ravn Andersen skrev:
> Per Jørgensen skrev den 05-08-2008 11:33:
>
>> Og så lavede jeg lige denne :
>> # grep -R ritajuul.com /etc/bind/*
>> /etc/bind/db.ritajuul.com:@ IN SOA odin.ritajuul.com.
>> hostmaster.ritajuul.com. (
>> /etc/bind/db.ritajuul.com: IN MX 10 mail.ritajuul.com.
>> /etc/bind/named.conf.local:zone "ritajuul.com" {
>> /etc/bind/named.conf.local: file "/etc/bind/db.ritajuul.com";
>
> Lyder som om du skal til at kigge på "host" og/eller "dig" til at
> fortælle dig hvad DNS-serveren tror om ritajuul.com domænet.
>
> Er det maskinen der også lyder navnet "mail.ritajuul.com" du laver de
> her øvelser på? I så fald, skal du nok fortælle SMT-serveren at du også
> gerne vil have den skal modtage post for ritajuul.com domænet.
Generelt virker det hele godt nok - uden problemer.

Det eneste tidspunkt hvor det ikke virker - er når jeg sender fra en
insatech.com adresse.
Dig og host viser de rigtige IP'er og alle mails kommer frem til
mailboksen - HVIS IKKE de er sendt fra en insatech.com adresse

--
Med Venlig Hilsen

Per Jørgense/\/

---

---

Den Tue, 5 Aug 2008 11:36:11 +0200 skrev Michael Rasmussen:
> --Sig_/zPDhKrMBY/QBuX5xuEYJDko
> Content-Type: text/plain; charset=ISO-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> On 05 Aug 2008 08:55:21 GMT
> Kent Friis <nospam@nospam.invalid> wrote:
>
>>=20
>> "forwarders" er da kun n=F8dvendige n=E5r dns-serveren ikke selv har
>> adgang til internettet, eller hvis der er tale om ikke-officielle
>> dom=E6ner.
>>=20
> Den m=E5 du vist lige uddybe??

Uden forwarders, vil den spørge en root-server, som vil sende den
videre til en gtld-server, der henviser til gratisdns.

Mvh
Kent
--
Hvis en sort kat går over vejen foran en bil, betyder det ulykke

.... for katten.