Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > ger.ct > #269412 > unrolled thread

Domain nicht bei allen Nameservern bekannt

Back to article view | Back to ger.ct

Contents

  Domain nicht bei allen Nameservern bekannt Rico Heil <news-spam@silmaril.de> - 2016-08-22 21:11 +0200
    Re: Domain nicht bei allen Nameservern bekannt Dr. Joachim Neudert <neudert@5sl.org> - 2016-08-22 19:26 +0000
      Re: Domain nicht bei allen Nameservern bekannt Goetz Schultz <ng-delete-mailer@goetz.co.uk> - 2016-08-22 20:58 +0100
    Re: Domain nicht bei allen Nameservern bekannt Ingo Paschke <ipaschke@lpclabs.de> - 2016-08-23 01:22 +0200
      Re: Domain nicht bei allen Nameservern bekannt "Juergen P. Meier" <nospam-1984@jors.net> - 2016-08-23 03:38 +0000
        Re: Domain nicht bei allen Nameservern bekannt Ingo Paschke <ipaschke@lpclabs.de> - 2016-08-23 11:35 +0200
          Re: Domain nicht bei allen Nameservern bekannt Rico Heil <news-spam@silmaril.de> - 2016-08-23 19:52 +0200
    Re: Domain nicht bei allen Nameservern bekannt "Juergen P. Meier" <nospam-1984@jors.net> - 2016-08-23 03:20 +0000

#269412 — Domain nicht bei allen Nameservern bekannt

Was macht man bei folgendem Problem?

Eine .net-Domain (nicht meine) ist bei manchen Nameservern im Internet
bekannt, bei anderen nicht.
Mit nslookup habe ich ein paar Stichproben gemacht: Die Server des
deutschen Providers, der sie hostet, kennen sie natürlich, OpenDNS auch.
Aber z.B. M-Net nicht und auch die weit verbreiteten Google-Server
(8.8.8.8 und 8.8.4.4) kennen sie nicht.

Der Support des Providers ist bislang wenig hilfreich, da kommen nur
Aussagen der Art "Ich kann die Domain anpingen, also geht's" (ist ja
klar, dass das von seinem PC im richtigen Firmennetz klappt).

Anscheinend ist da beim Propagieren der Einträge irgendwas schief
gelaufen - aber was könnte das genau sein?
Und was kann man machen, um so einen Fall wieder in den Griff zu bekommen?
Gibt es vielleicht irgendein Tool, mit dem man gezielt die Schwachstelle
aufspüren kann?

Das Hauptproblem ist, dass diese Domain bereits als E-Mail-Adresse auf
geschäftliche Visitenkarten gedruckt wurde und man nun nie weiß, ob der
Gegenüber einen auch erreichen kann, oder ob seine Mail mit einer
Fehlermeldung zurückgeht (die dann mehrere Tage braucht, weil die
Mailserver ja geduldig sind).

Vielen Dank für sachdienliche Hinweise!
Rico

[toc] | [next] | [standalone]

#269415

Rico Heil <news-spam@silmaril.de> wrote:
> Was macht man bei folgendem Problem?
> 
> Eine .net-Domain (nicht meine) ist bei manchen Nameservern im Internet
> bekannt, bei anderen nicht.
> Mit nslookup habe ich ein paar Stichproben gemacht: Die Server des
> deutschen Providers, der sie hostet, kennen sie natürlich, OpenDNS auch.
> Aber z.B. M-Net nicht und auch die weit verbreiteten Google-Server
> (8.8.8.8 und 8.8.4.4) kennen sie nicht.
> 
> Der Support des Providers ist bislang wenig hilfreich, da kommen nur
> Aussagen der Art "Ich kann die Domain anpingen, also geht's" (ist ja
> klar, dass das von seinem PC im richtigen Firmennetz klappt).
> 
> Anscheinend ist da beim Propagieren der Einträge irgendwas schief
> gelaufen - aber was könnte das genau sein?
> Und was kann man machen, um so einen Fall wieder in den Griff zu bekommen?
> Gibt es vielleicht irgendein Tool, mit dem man gezielt die Schwachstelle
> aufspüren kann?
> 
> Das Hauptproblem ist, dass diese Domain bereits als E-Mail-Adresse auf
> geschäftliche Visitenkarten gedruckt wurde und man nun nie weiß, ob der
> Gegenüber einen auch erreichen kann, oder ob seine Mail mit einer
> Fehlermeldung zurückgeht (die dann mehrere Tage braucht, weil die
> Mailserver ja geduldig sind).
> 
> Vielen Dank für sachdienliche Hinweise!
> Rico
> 

Umziehen zu einem Provider, der tatsächlich in der Lage ist eine Domain
authoritativ zu definieren und die Delegation zu bekommen. 

Das Bürgernetz 5-Seenland kann das seit 1998.



-- 
please forgive my iPhone typos -sent via Newstap

[toc] | [prev] | [next] | [standalone]

#269418

On 22/08/16 20:26, Dr. Joachim Neudert wrote:
> Rico Heil <news-spam@silmaril.de> wrote:
>> Was macht man bei folgendem Problem?
>>
>> Eine .net-Domain (nicht meine) ist bei manchen Nameservern im Internet
>> bekannt, bei anderen nicht.
>> Mit nslookup habe ich ein paar Stichproben gemacht: Die Server des
>> deutschen Providers, der sie hostet, kennen sie natürlich, OpenDNS auch.
>> Aber z.B. M-Net nicht und auch die weit verbreiteten Google-Server
>> (8.8.8.8 und 8.8.4.4) kennen sie nicht.
>>
>> Der Support des Providers ist bislang wenig hilfreich, da kommen nur
>> Aussagen der Art "Ich kann die Domain anpingen, also geht's" (ist ja
>> klar, dass das von seinem PC im richtigen Firmennetz klappt).
>>
>> Anscheinend ist da beim Propagieren der Einträge irgendwas schief
>> gelaufen - aber was könnte das genau sein?
>> Und was kann man machen, um so einen Fall wieder in den Griff zu bekommen?
>> Gibt es vielleicht irgendein Tool, mit dem man gezielt die Schwachstelle
>> aufspüren kann?
>>
>> Das Hauptproblem ist, dass diese Domain bereits als E-Mail-Adresse auf
>> geschäftliche Visitenkarten gedruckt wurde und man nun nie weiß, ob der
>> Gegenüber einen auch erreichen kann, oder ob seine Mail mit einer
>> Fehlermeldung zurückgeht (die dann mehrere Tage braucht, weil die
>> Mailserver ja geduldig sind).
>>
>> Vielen Dank für sachdienliche Hinweise!
>> Rico
>>
>
> Umziehen zu einem Provider, der tatsächlich in der Lage ist eine Domain
> authoritativ zu definieren und die Delegation zu bekommen.
>
> Das Bürgernetz 5-Seenland kann das seit 1998.
>
>
>
Wuerde ixh auch so sehen.

Mach mal eine WHOIS abfrage und schau nach wer die Auth-DNS inne hat. 
Wenn das leer ist oder falsch, den Provider treten oder xfer request 
stellen. Dann wachen viele auf.

Cheers
   G.

[toc] | [prev] | [next] | [standalone]

#269432

On 2016-08-22, Rico Heil <news-spam@silmaril.de> wrote:
> Was macht man bei folgendem Problem?
>
> Eine .net-Domain (nicht meine) ist bei manchen Nameservern im Internet
> bekannt, bei anderen nicht.
> Mit nslookup habe ich ein paar Stichproben gemacht: Die Server des
> deutschen Providers, der sie hostet, kennen sie natürlich, OpenDNS auch.
> Aber z.B. M-Net nicht und auch die weit verbreiteten Google-Server
> (8.8.8.8 und 8.8.4.4) kennen sie nicht.
>
> Der Support des Providers ist bislang wenig hilfreich, da kommen nur
> Aussagen der Art "Ich kann die Domain anpingen, also geht's" (ist ja
> klar, dass das von seinem PC im richtigen Firmennetz klappt).
>
> Anscheinend ist da beim Propagieren der Einträge irgendwas schief
> gelaufen - aber was könnte das genau sein?
> Und was kann man machen, um so einen Fall wieder in den Griff zu bekommen?
> Gibt es vielleicht irgendein Tool, mit dem man gezielt die Schwachstelle
> aufspüren kann?

1. Schauen, ob die Domain bei der TLD richtig registriert ist:

$ whois domain.net 

-> gucken, was da bei Name Server drinsteht
-> Domain unbekannt? -> beim Provider beschweren, sonst: 

2. diesen Nameserver fragen, was er für die aktuelle Seriennummer der
   Domain hält

$ dig -t soa @[nameserver-von-schritt-1] domain.net

3. einem Nameserver, der nicht die richtigen Werte liefert, dieselbe Frage
   stellen

$ dig -t soa @8.8.8.8 domain.net

-> schauen, stimmt das mit Schritt 2 überein?
-> nein? Dann ist die falsche wahrscheinlich höher und man muss ein
   Serial Wraparound machen. Nervig, bringt einen aber nicht um:
   http://www.microhowto.info/howto/reset_the_serial_number_of_a_dns_zone.html

4. ansonsten kann's natürlich immer sein, dass der alte DNS-Eintrag eine
   so lange TTL hatte, dass er noch gecachet werden darf. Kann man nachschauen,
   indem man "falsche" DNS-Server nach den Eintrag fragt und auf die TTL
   schaut:

--------------------
$ dig -t mx @8.8.8.8 lpclabs.de

;; ANSWER SECTION:
lpclabs.de.		3599	IN	MX	20 mx01.udag.de.
lpclabs.de.		3599	IN	MX	10 mx00.udag.de.
--------------------

-> der darf noch eine Stunde lang diese Werte ausliefern, bevor er wieder
den zuständigen Nameserver nach dem aktuellen Wert fragen muss...

Wenn dem so ist, hilft nur Aussitzen...

Viele Grüße,
Ingo. 

[toc] | [prev] | [next] | [standalone]

#269438

Ingo Paschke <ipaschke@lpclabs.de>:
> 1. Schauen, ob die Domain bei der TLD richtig registriert ist:
>
> $ whois domain.net 

Korrekte Whois-Eintraege sind zwar nie verkehrt, haben aber mit der
eigentlichen Namensaufloesung exakt genau garnichts zu tun.

> -> gucken, was da bei Name Server drinsteht
> -> Domain unbekannt? -> beim Provider beschweren, sonst: 
>
> 2. diesen Nameserver fragen, was er für die aktuelle Seriennummer der
>    Domain hält

Die Seriennummer im SOA hat nur fuer die Autoritativen DNS-Server eine
Bedeutung und ist ausserhalb dieser vollkommen Semantikfrei.

Das bedeutet, dass je nach dem welche DNS-Server verwendet werden,
die von BIND her bekannte Bedeutung (auf die du gerade ansprichst)
falsch sein kann.

Nur wenn du genau weist welche Software der Betreiber der Autoritativen
Server verwendet, kannst du solche Rueckschluesse aufgrund des Werts
des Serial-Feldes in SOA-Records ziehen.

In allen anderen Faellen schiesst du dir damit nur ins Knie.

> 3. einem Nameserver, der nicht die richtigen Werte liefert, dieselbe Frage
>    stellen
>
> $ dig -t soa @8.8.8.8 domain.net

Ausgerechnet die Schnueffelserver, die auch dann Antworten faelschen
wenn das DoC, das DoD, das DoJ, das DoHS oder eine andere Behoerde der
Vereinigten Staaten das gerade fuer Opportun halten?

Naja, ausserhalb dieses Dunstkreises liefern die immerhin korrekte
Antworten, im Gegensatz zu den anderen Servern die der OP ausprobiert
hatte.

> -> schauen, stimmt das mit Schritt 2 überein?

Das hat nur dann eine Bedeutung, wenn die Autoritativen Nameserver mit
einer Software laufen, welche die BIND Master/Slave-Semantik umsetzt.

In anderen Faellen ist der Wert des SOA Serial Feldes ganz einfach nicht
interpretierbar.

> 4. ansonsten kann's natürlich immer sein, dass der alte DNS-Eintrag eine
>    so lange TTL hatte, dass er noch gecachet werden darf. Kann man nachschauen,
>    indem man "falsche" DNS-Server nach den Eintrag fragt und auf die TTL
>    schaut:
>
> --------------------
> $ dig -t mx @8.8.8.8 lpclabs.de
>
> ;; ANSWER SECTION:
> lpclabs.de.		3599	IN	MX	20 mx01.udag.de.
> lpclabs.de.		3599	IN	MX	10 mx00.udag.de.
> --------------------
>
> -> der darf noch eine Stunde lang diese Werte ausliefern, bevor er wieder
> den zuständigen Nameserver nach dem aktuellen Wert fragen muss...

Ganz besonders wenn negative Antworten (Fehler) gecached werden.

Wie lange ein NXDOMAIN gecached werden darf, steuert nicht die TTL
eines RR sondern die negative cache TTL im SOA.

> Wenn dem so ist, hilft nur Aussitzen...

Allerdings.

Juergen
-- 
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems.  (Bruce Schneier)

[toc] | [prev] | [next] | [standalone]

#269459

Hallo!

Stimmt, totalen Blödsinn erzählt. Man sollte nicht posten, wenn man
nachts übermüdet vorm Rechner sitzt :-).

Ich hätte sagen wollen:

1. whois schadet nicht, um den Verwaltungsvorgang zu überprüfen
2. Delegation mit dig -t ns +norecurse überprüfen
3. vielleicht mal alle Nameserver aus 2. fragen, ob die im selben
   Film sind.
4. Die Serial kann einen ärgern, wenn man Bind mit Slaves benutzt
   (BTDT)
5. vermutlich liegt's doch wieder nur an der TTL (am Eintrag oder
   im SOA-Record)

Und ja, mit den diversen DNS-Check-Webseiten geht einfacher und
gründlicher.

Viele Grüße,
Ingo.

[toc] | [prev] | [next] | [standalone]

#269531

Schonmal vielen Dank an alle, die geantwortet haben!
Ich sehe schon, DNS ist *noch* komplizierter als ich dachte 8-)

Es geht um die Domain textgut.net.

Die genannten Web-Dienste haben natürlich sofort Fehler gefunden:

http://dnscheck.ripe.net/
Total parent/child glue mismatch.
The parent lists name servers that the child doesn't know about. This
configuration could actually work but breaks very easily if one of these
zones changes slightly.

Inconsistent security for textgut.net - DS found at parent, but no
DNSKEY found at child.
The parent has a secure delegation to the child (indicated by DS RRset
at the parent), but the child has no DNSKEY records. This is probably
due to a previously signed zone that became unsigned without requesting
the parent to remove the secure delegation.


http://mxtoolbox.com/dnscheck.aspx
Primary Name Server Not Listed At Parent


Die Infos soll die Domain-Inhaberin mal dem Support des zuständigen
Providers um die Ohren hauen - hoffentlich kapiert der Mitarbeiter dann,
dass ihm das zu hoch ist und schaltet jemanden mit Ahnung ein.

Schau mer mal was rauskommt...

Ciao
Rico





Am 23.08.2016 um 11:35 schrieb Ingo Paschke:
> Hallo!
> 
> Stimmt, totalen Blödsinn erzählt. Man sollte nicht posten, wenn man
> nachts übermüdet vorm Rechner sitzt :-).
> 
> Ich hätte sagen wollen:
> 
> 1. whois schadet nicht, um den Verwaltungsvorgang zu überprüfen
> 2. Delegation mit dig -t ns +norecurse überprüfen
> 3. vielleicht mal alle Nameserver aus 2. fragen, ob die im selben
>    Film sind.
> 4. Die Serial kann einen ärgern, wenn man Bind mit Slaves benutzt
>    (BTDT)
> 5. vermutlich liegt's doch wieder nur an der TTL (am Eintrag oder
>    im SOA-Record)
> 
> Und ja, mit den diversen DNS-Check-Webseiten geht einfacher und
> gründlicher.
> 
> Viele Grüße,
> Ingo.
> 

[toc] | [prev] | [next] | [standalone]

#269437

Rico Heil <news-spam@silmaril.de>:
> Was macht man bei folgendem Problem?

man dig

> Eine .net-Domain (nicht meine) ist bei manchen Nameservern im Internet
> bekannt, bei anderen nicht.
> Mit nslookup habe ich ein paar Stichproben gemacht: Die Server des
> deutschen Providers, der sie hostet, kennen sie natürlich, OpenDNS auch.
> Aber z.B. M-Net nicht und auch die weit verbreiteten Google-Server
> (8.8.8.8 und 8.8.4.4) kennen sie nicht.
>
> Der Support des Providers ist bislang wenig hilfreich, da kommen nur
> Aussagen der Art "Ich kann die Domain anpingen, also geht's" (ist ja
> klar, dass das von seinem PC im richtigen Firmennetz klappt).
>
> Anscheinend ist da beim Propagieren der Einträge irgendwas schief
> gelaufen - aber was könnte das genau sein?

Viel. Heutzutage kann neben fehlendem Klebstoff (Glue Records) auch
jede Menge DNSSEC mit daran Schuld sein, das eine Domain nicht
aufloest.

> Und was kann man machen, um so einen Fall wieder in den Griff zu bekommen?

Erst mal die Domain sagen, dann kann man nachschauen.

> Gibt es vielleicht irgendein Tool, mit dem man gezielt die Schwachstelle
> aufspüren kann?

Ja: dig
Es gibt aber auch Onlinewebdienste die DNS Eintraege verifizieren.
http://dnscheck.ripe.net/
http://mxtoolbox.com/dnscheck.aspx
(um mal zwei nicht unserioese aufzulisten)
Letzteres ist auch ein gutes Werkzeug um die Erreichbarkeit des eigenen
Mailservers zu verifizieren.

> Das Hauptproblem ist, dass diese Domain bereits als E-Mail-Adresse auf
> geschäftliche Visitenkarten gedruckt wurde und man nun nie weiß, ob der
> Gegenüber einen auch erreichen kann, oder ob seine Mail mit einer
> Fehlermeldung zurückgeht (die dann mehrere Tage braucht, weil die
> Mailserver ja geduldig sind).
>
> Vielen Dank für sachdienliche Hinweise!

Falls es sich um silmaril.de handelt, so kann alleine die RR Groesse
von weit ueber drei Kilobyte wegen der DNSSEC-Records dazu fuehren, dass
kaputte DNS-Implmentierungen diese Domain nicht aufloesen koennen.

Ansonsten ist silmaril.de voellig korrekt eingerichtet. Alle
Signaturen sind soweit ok, sowohl bei der domain selbst als auch der
fuer die Mailserver (MX).
Und auch sowohl ueber Google's Schnueffel-Server aufloesbar als auch
(erstaunlicherweise) ueber die faelschenden Server von OpenDNS.
Und auch regulaere nicht-manipulative Server (z.B. 141.1.1.1) loesen
korrekt auf.

Juergen
-- 
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems.  (Bruce Schneier)

[toc] | [prev] | [standalone]

Back to top | Article view | ger.ct

csiph-web