DNS: Probleme mit Reverse Lookup

odoll · 10 Dez 2009

7270v2 54.04.76

Hallo,

ich habe zuhause hinter meiner 7270 einen offiziellen /24 PI IP Adressraum, der auch über VPN von extern zu erreichen ist. Ebenso habe ich eine offizielle Domain und auch die Reverse-Zone für den IP-Space ist im DNS meines Providers, der auch die DSL-PPPoE-IP liefert sauber eingetragen.

Einige Rechner haben aus dem IP-Adressraum fest zugeordnete Adressen, ein Teilbereich (.20 - .40) wird von der 7270 per DHCP zugeteilt.

Leider verhält sich die FRITZ!Box zumindest was die Reverse-Lookups angeht nicht richtig!?

Eigentlich sollte z.B. die Anfrage (fixed IP)

dig -x 194.b.c.254

die Antwort

254.c.b.194.in-addr.arpa. 10 IN PTR Share.<meine-domain>.de.

liefern. Tatsächlich kommt aber

root@Share:~# dig -x 194.b.c.254

; <<>> DiG 9.5.1-P2 <<>> -x 194.b.c.254
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18141
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;254.c.b.194.in-addr.arpa. IN PTR

;; ANSWER SECTION:
254.c.b.194.in-addr.arpa. 10 IN PTR Share.fritz.box.

;; Query time: 19 msec
;; SERVER: 194.b.c.1#53(194.b.c.1)
;; WHEN: Thu Dec 10 10:47:09 2009
;; MSG SIZE rcvd: 74

Ich habe jetzt keine Lust auf allen Rechnern manuell andere NS (Proxy/Resolver) als die FB einzutragen.

Was muss ich tun, damit die Fbox dies richtig macht.
Danke

RalfFriedl · 10 Dez 2009

Die Box davon überzeugen, daß sie nicht für den Adressbereich zuständig ist, in dem sie selbst per DHCP Adressen vergeben darf.
Ich vermute, daß Dein Anwendungsfall so selten ist, daß AVM hierfür nichts spezielles vorgesehen hat und Du daher nicht um eine grundlegende Modifikation herum kommst.
Freetz mit dnsmasq könnte eine Lösung sein.

pfeffer · 10 Dez 2009

gehe mal per telnet auf die Fritzbox und guck Dir die ar7.cfg an:

Code:

nvi /var/flash/ar7.cfg

Achtung - vorher googlen, wie der Editor "vi" zu bedienen ist.
In dieser Einstellungsdatei finden sich vermutlich einige Einträge, die Dir weiterhelfen könnten.
BTW: hast Du NAT an der FritzBox ausgestellt (wenn ja: wie geht das?)

Gruß,
Pfeffer.

odoll · 10 Dez 2009

Danke für die Antworten.

@RalfFriedl: Freetz würde ich eher gern vermeiden (habe nur zwei 701v auf "AVM" gefreezt). Dann würde ich lieber den DHCP (incl. (hidden) Primary) auf meine Sheeva-Plug (Ubuntu) umziehen ... und die FB ganz umgehen ... mal schauen.

@pfeffer: eigentlich versuche ich soweit wie möglich am "Standard" zu bleiben, aber die ar7 haben ich schon geändert um die Freischaltung für den OpenVPN-Access freizugeben (ein Ende terminiert auf der dyn-IP der FB).
Nein, NAT über die dyn-IP für normalen DSL-Traffic ist an - nur der Verkehr durch den VPN-Tunnel läuft ungenattet.

pfeffer · 11 Dez 2009

was ist denn Dein Ziel?

Soll die FritzBox anstelle der internen domain die public domain zurückgegeben? - Ich glaube, das wird Dir nicht gelingen. Obwohl - vielleicht kannst Du die Domain der FritzBox, die ja standardmäßi fritz.box ist, auf Deine public domain ändern? - Wäre das das, was Du willst?

Oder willst Du, dass die internen Rechner nicht den DNS-Server der Fritzbox verwenden, sondern den Deines ISP? - kennt der die Namen der Rechner an Deinem /24-Netz?

Gruß,
Pfeffer.

odoll · 11 Dez 2009

Ja, mein IP-Space ist bei meinem ISP bzgl. Forward und Reverse-Mapping sauber im DNS hinterlegt.

Ich kann ja verstehen, dass in den meisten Fällen Otto-Normalverbraucher den von der FB vorgegeben IP-Range aus dem RFC1918 Block verwenden wird.

Allerdings würde ich erwarten, dass die FB zumindest für offizielle IPs die Anfragen transparent an die zuständigen DNS-Server proxiet und die korrekten Einträge ausliefert.

Ich möchte eigentlich nicht an zwei Stellen meine DNS-Konfig pflegen müssen (autoritative DNS und in der FB).

Z.Z. scheint es ja so, dass sich die FB sowohl für IPs aus dem DHCP-Bereich, als auch 'darum herum (/24)' zuständig fühlt.

Leider kann man ja bis dato nicht über die MACs die IP-Zuordnung auf der FB erledigen (sondern nur festlegen, dass die einmalig getroffene Zuordnung weiterhin verwendet wird?).

Nun wird mir langsam klar, warum es immer wieder Probleme der Windows-Klienten beim Zugriff auf meinen Windows-Domain (samba) gibt!?

Die Fragen nach _ldap._tcp.dc._msdcs(.fritz.box), bekommen nichts zurück, weil nur die korrekte Frage nach _ldap._tcp.dc._msdcs.<meine-domain>.de die richtige Antwort "SRV 0 3 9 share" liefert?!

Es sei denn ich setze auf allen Rechner den richtigen Domain-Suffix per Hand ...!?

Ich denke, ich werde wohl der FB das "DHCP"-Recht entziehen und einen separten DHCP/DNS-Server auf meinem Sheeva-Plug aufsetzen müssen. Und der sollte zumindest direkt die Resolver meines ISPs fragen und nicht die FB (in der Hoffung, dass das was mir mein ISP als DNS-Server während der PPPoP-Handlung sagt einigermaßen stabil ist).

mag · 11 Dez 2009

nur so am Rande: warum muss das unbedingt auf einer SoHo-IAD realisiert werden, für sowas gibts richtige Router(*), da kann man die Fritzbox ja immer noch hinter hängen.

(*) Cisco, Juniper, Lancom, MikroTik - je nach Budget und Glaubensrichtung ;-)

odoll · 11 Dez 2009

sicher - alles eine Frage des Portemonnaies ;-)

ist jetzt leicht OT, aber bis vor wenigen Jahren hatte ich da tatsächlich sogar eine Cisco, allerdings noch eine 801. Kniff war: nur ein Eth (und ein BRI). Da mußte man das virtuelle Dialer-Interface ans gleiche Eth-Interface binden (Config [s.u.] irgendwann so in 2004 gebaut).

Nur, da hatte ich noch 4+ Einzelgeräte rumstehen und mit wachsender Bandbreite ging der 801 bei IPsec die Puste aus:

DSL-Modem
Cisco
Euracom-TK-Anlage
Siemens-Basisstation

Jetzt alles in eine 7270 "kollabiert" und noch ein paar Features mehr. Will ich nicht meckern. Oder doch ;-)

Auf der anderen Seite könnte man die Sachen, die man macht auch richtig/konform machen ;-)

Code:

eine der letzten Sicherungen:
!
! Last configuration change at 10:15:41 CEST Sun Mar 26 2006 by odoll
! NVRAM config last updated at 10:19:17 CEST Sun Mar 26 2006 by odoll
!
version 12.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname odoll-dsl
!
boot system flash
logging queue-limit 100
enable secret <secret>
!
username odoll password <pwd>
clock timezone CET 1
clock summer-time CEST recurring last Sun Mar 2:00 last Sun Oct 3:00
ip subnet-zero
no ip source-route
ip domain name <meine-domain>.de
ip name-server 193.b.c.20
ip name-server 193.b.c.10
ip name-server 192.b.c.66
ip dhcp excluded-address 194.b.c.1 194.b.c.19
ip dhcp excluded-address 194.b.c.31 194.b.c.254
!
ip dhcp pool LocalDHCPpool
   network 194.b.c.0 255.255.255.0
   dns-server 193.b.c.10 193.b.c.20
   default-router 194.b.c.1
   domain-name <meine-domain>.de
   lease 21
!
vpdn enable
vpdn ip udp ignore checksum
!
vpdn-group 1
 request-dialin
  protocol pppoe
!
isdn switch-type basic-net3
!
!
!
crypto isakmp policy 1
 hash md5
 authentication pre-share
 group 2
crypto isakmp key <key> address 139.b.c.89
!
!
crypto ipsec transform-set <name> esp-des esp-md5-hmac
!
crypto map to<name> 10 ipsec-isakmp
 set peer 139.b.c.89
 set transform-set <name>
 match address 101
!
!
!
!
interface Ethernet0
 ip address 194.b.c.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 ip nat inside
 ip tcp adjust-mss 1408
 pppoe enable
 pppoe-client dial-pool-number 1
 crypto map to<name>
!
interface BRI0
 no ip address
 shutdown
 isdn switch-type basic-net3
 isdn point-to-point-setup
!
interface Dialer1
 description T-DSL Flat odoll
 ip address negotiated
 no ip proxy-arp
 ip mtu 1448
 ip nat outside
 encapsulation ppp
 no ip split-horizon
 ip tcp adjust-mss 1408
 dialer pool 1
 dialer idle-timeout 0
 dialer persistent
 dialer vpdn
 dialer-group 1
 no cdp enable
 ppp authentication chap pap callin
 ppp chap hostname <user>
 ppp chap password <pwd>
 ppp pap sent-username <user> password <pwd>
 ppp ipcp dns request accept
!
ip nat inside source list 102 interface Dialer1 overload
ip nat inside source static tcp 194.b.c.4 2105 interface Dialer1 2105
ip nat inside source static tcp 194.b.c.6 3389 interface Dialer1 3389
ip nat inside source static tcp 194.b.c.6 5900 interface Dialer1 5900
ip nat inside source static tcp 194.b.c.6 4662 interface Dialer1 4662
ip nat inside source static udp 194.b.c.6 5238 interface Dialer1 5238
ip nat inside source static tcp 194.b.c.6 22 interface Dialer1 109
ip classless
ip route 0.0.0.0 0.0.0.0 Dailer1
no ip http server
ip http secure-server
!
!
access-list 100 remark *** Clear-DF Bit [for VPN-Packets]
access-list 100 permit tcp any 194.b.c.0 0.0.0.255
access-list 100 permit tcp 194.b.c.0 0.0.0.255 any
access-list 101 remark *** Define the special IP range for IPSEC
access-list 101 permit ip 194.b.c.0 0.0.0.255 62.b.c.0 0.0.0.255
access-list 101 permit ip 194.b.c.0 0.0.0.255 host 194.b.c.246
access-list 101 permit ip 194.b.c.0 0.0.0.255 host 194.b.c.250
access-list 102 remark *** Exclude special IP range from being NATed
access-list 102 deny   ip 194.b.c.0 0.0.0.255 62.b.c.0 0.0.0.255
access-list 102 deny   ip 194.b.c.0 0.0.0.255 host 194.b.c.246
access-list 102 deny   ip 194.b.c.0 0.0.0.255 host 194.b.c.250
access-list 102 remark *** Allow the non special IP ranges to go
access-list 102 remark *** NATed via the normal DSL connection
access-list 102 permit ip 194.b.c.0 0.0.0.255 any
!
route-map clear-df permit 10
 match ip address 100
 set ip df 0
!
!
line con 0
 exec-timeout 0 0
 stopbits 1
line vty 0 4
 exec-timeout 480 0
 login local
!
no rcapi server
!
!
end

RalfFriedl · 13 Dez 2009

odoll schrieb:
Ich kann ja verstehen, dass in den meisten Fällen Otto-Normalverbraucher den von der FB vorgegeben IP-Range aus dem RFC1918 Block verwenden wird.

Das ist die Zielgruppe der Box.

Allerdings würde ich erwarten, dass die FB zumindest für offizielle IPs die Anfragen transparent an die zuständigen DNS-Server proxiet und die korrekten Einträge ausliefert.

Das ist nicht die Zielgruppe der Box.

Z.Z. scheint es ja so, dass sich die FB sowohl für IPs aus dem DHCP-Bereich, als auch 'darum herum (/24)' zuständig fühlt.

Du weißt, wie ein Reverse Mapping funktioniert? Und das von Dir angesprochene Weiterleiten von anderen Adressen ist wirklich nicht für die Zielgruppe der Box relevant.

Nun wird mir langsam klar, warum es immer wieder Probleme der Windows-Klienten beim Zugriff auf meinen Windows-Domain (samba) gibt!?

Die Fragen nach _ldap._tcp.dc._msdcs(.fritz.box), bekommen nichts zurück, weil nur die korrekte Frage nach _ldap._tcp.dc._msdcs.<meine-domain>.de die richtige Antwort "SRV 0 3 9 share" liefert?!

Es funktioniert auch ohne diese Einträge, wenn man WINS nutzt.

Aber Du hast sowieso schon einen Linux-Server und fragst hier nach der Konfiguration auf der Box, statt gleich den Linux-Server für DHCP und DNS zu nutzen?

odoll · 16 Dez 2009

pfeffer schrieb:
was ist denn Dein Ziel?

zu erreichen, dass "sauber" implementiert wird!? ;-)

pfeffer schrieb:
Soll die FritzBox anstelle der internen domain die public domain zurückgegeben?

Ja!

pfeffer schrieb:
vielleicht kannst Du die Domain der FritzBox, die ja standardmäßi fritz.box ist, auf Deine public domain ändern?

Zumindest wäre dies schon mal ein Schritt in die richtige Richtung. Ich finde z.Z. nur nicht in welcher config das steht (in der ar7.cfg definitiv nicht!?)
Und gut wäre, wenn das auch "Reboot-resistent" wäre.
(Denn Änderungen am Workgroup-Name werden beim Reboot ja immer wieder überschrieben.)
Obwohl, das FB-Webinterface für die Benamsung der Clients ist ja bisweilen bzgl. der eigentlich erlaubten Zeichen auch etwas zu restriktiv.

pfeffer schrieb:
Oder willst Du, dass die internen Rechner nicht den DNS-Server der Fritzbox verwenden, sondern den Deines ISP?

Neben der Wahl-Option einstellen zu können, dass die Anfragen mit Antworten aus einer autoritativen Quelle (von außen) beantwortet werden, wäre dies aus meiner Sicht auch eine Möglichkeit.
Option: IP des Eth-Int der FB oder IPs der bei der PPPoE-Aushandlung mitgeteilten DNS per DHCP an die lokalen Clients verteilen?!

RalfFriedl · 16 Dez 2009

odoll schrieb:
Freetz würde ich eher gern vermeiden

odoll schrieb:
zu erreichen, dass "sauber" implementiert wird!? ;-)
...
Option: IP des Eth-Int der FB oder IPs der bei der PPPoE-Aushandlung mitgeteilten DNS per DHCP an die lokalen Clients verteilen?!

Ich denke, wir haben verstanden, was Du möchtest. Wir sind uns auch einig, daß es mit der aktuellen Firmware nicht geht. Du hast zwei Möglichkeiten:

Bei AVM nachfragen und darauf warten, ob sie es umsetzen.
Modifikation (Freetz oder andere).
Anderer Router.

AVM wird mit höchster Wahrscheinlichkeit nichts tun, weil Du einen viel zu seltenen Anwendungsfall hast.
Wenn Du eine Modifikation generell (und nicht nur Freetz speziell) vermeiden willst, bleibt nur ein anderer Router, der das von sich aus unterstützt. Ich vermute, daß die meisten anderen günstigen Geräte diese Funktion auch nicht bieten, einfach weil sie so selten gebraucht wird.

odoll · 16 Dez 2009

RalfFriedl schrieb:
Wir sind uns auch einig, daß es mit der aktuellen Firmware nicht geht.

Wer ist wir? ;-) Ich bin mir da noch nicht einig. Nur dass ich was im GUI nicht einstellen/eintragen kann, heißt ja noch lange nicht, dass es auch nicht auf der CLI umzubiegen wäre.

BTW: hat jetzt nicht direkt was damit zu tun - bin nur beim Scannen der ar7.cfg drüber gestolpert. Kann es sein, dass im Bereich dhcpserver {statics {}} die festen MAC <-> IP-Leases gespeichert werden. Dann könnte ich ja doch noch ein wenig mit meinen Wunsch-IPs für spezielle MACs nachhelfen ;-)

Und die Einträge in landevices {landevices {}} sollten natürlich in sync sein, weil hier die Benamsung 'verewigt' wird? Die multid.leases kann man ignorieren?
Posting 2:
Re: BTW
Antwort gefunden http://www.ip-phone-forum.de/showpost.php?p=1431336&postcount=7

MaxMuster · 19 Dez 2009

Ob ein DNS nun "zuständig" ist oder nicht ergibt sich ja erstmal nicht daraus, ob der gleiche Server diese IPs per DHCP verteilt. Letztlich vergibt die FB ja IPs mit einer /24-er Maske, wenn ich das recht verstehe. Und wenn die FB daraus schließt, dass es sich um eine in-addr.arpa-Subdomain handelt, ist das doch zumindest nicht zu beanstanden.
Soll denn die FB nun DNS sein oder nicht?
Denn wenn ja, die FB also für die DHCP-Adressen "legal" zuständig wäre: Ganz platt gefragt, selbst mit RFC-konformer "Classless IN-ADDR.ARPA delegation", wie willst du damit den DHCP-Bereich Bereich ".20 - .40" abdecken?
Ich glaube nicht dass es zulässig wäre, z.B. für eine Netzwerk-Adresse 194.b.c.20/30 neben dem zugehörigen DNS für die Zone auch noch einen "Netzhostnamen" einzutragen.

Jörg

odoll · 27 Dez 2009

Sorry für die späte Antwort, aber zum Einen "kämpfe" ich neben Xmas gerade an einer anderen Baustelle, und zum Anderen wusste ich ich, dass eine (hoffentlich) einigermaßen kompetente Antwort (Eigenlob stinkt- hüstel) nicht in 5 Minuten geschrieben sein wird.

Ob ein DNS nun "zuständig" ist oder nicht ergibt sich ja erstmal nicht daraus, ob der gleiche Server diese IPs per DHCP verteilt.

Stimmt, denn DHCP und DNS haben erst mal nichts miteinander zu tun, sondern sind zwei verschiedene Dienste.

Der Eine vergibt IP-Adressen, der Andere ordnet Namen z.B. IP-Adressen (A) zu, bzw. umgekehrt IP-Adressen "Namen" (PTR).

Ob ein NS für eine Zone autoritative Antworten geben kann/darf, ergibt sich dadurch, ob die Zone von den Root-NS aus an ihn delegiert worden ist.

Letztlich vergibt die FB ja IPs mit einer /24-er Maske, wenn ich das recht verstehe. Und wenn die FB daraus schließt, dass es sich um eine in-addr.arpa-Subdomain handelt, ist das doch zumindest nicht zu beanstanden..

Der Schluss ist falsch (s.o.). Auch wenn es wahrscheinlich eher ungewöhnlich ist, niemand hindert mich daran Bereiche aus einem /24er an mehrere verschiedene NS, und damit verschiedene Subdomains zu delegieren. Wie gesagt, DNS hat nichts mit der Netztopologie zu tun (L3 OSI).
Aber genau hier liegt das Problem. AVM macht es sich IMO mit Blick auf ihre Zielgruppe zu einfach und zieht damit einige Schlüsse, die zwar Vielen reichen werden, aber in einigen Situationen nicht dem Standard gerecht werden.

Soll denn die FB nun DNS sein oder nicht?

Die Frage ist unscharf und die Antwort kann nur jein lauten: ja, wenn sie's denn halbwegs richtig machen würde. Allerdings nein, wenn nicht.

Etwas länger: Wenn die FB ihren Job als Nameserver richtig machen würde (wohl eher nicht, weder mit Boardmitteln, noch ohne Freetz zu bemühen) gern. Allerdings glaube ich kaum, dass das AVM für ihre Klientel umsetzen möchte.

Es würde mir halt auch reichen, wenn sie ein reiner Resolver wäre. Da wäre ich ja noch guter Hoffung, dass es evt. AVM nachbesert, bzw., dass man das mit einem moderaten Eingriff in die Konfiguration hinbekommen kann?!

Denn wenn ja, die FB also für die DHCP-Adressen "legal" zuständig wäre: Ganz platt gefragt, selbst mit RFC-konformer "Classless IN-ADDR.ARPA delegation", wie willst du damit den DHCP-Bereich Bereich ".20 - .40" abdecken?.

Die Frage/das Problem habe ich nicht verstanden.

Ich glaube nicht dass es zulässig wäre, z.B. für eine Netzwerk-Adresse 194.b.c.20/30 neben dem zugehörigen DNS für die Zone auch noch einen "Netzhostnamen" einzutragen.

doch (siehe oben DHCP/Tologie =! DNS)

MaxMuster · 28 Dez 2009

Moin,

die fünf Minuten überschreiten meine Antwort auch, damit ist sie hoffentlich "kompetent" ;-)

odoll schrieb:
Der Schluss ist falsch (s.o.).

Das sehe ich (noch?) nicht so. Die "reverse" Auflösung ist zunächstmal "Classfull", also an die Layer-3 Struktur angepasst. Die "kleinste" Einheit dafür ist die eines Class-C Blocks. Auch für "dein" Netz gilt, dass "nach außen" nur genau ein Server das Netz 194.b.c.0/24 für die reverse Auflösung "vertreten" darf und eine Unterteilung von diesem einen DNS deligiert werden muss. Auf Grund der Beschränkung auf nur eine zulässige Delegation pro Zone und dem Fortschreitenden der "klassenlosen" Netze ergab sich die Notwendigkeit von neuen Ansätzen, wie der im RFC 2317 eingeführten Möglichkeit einer "Classless IN-ADDR.ARPA delegation".

Der "Haken" an der Sache in der Box ist, dass diese zunächstmal ja nicht von dir als DNS eingerichtet wurde, sondern das "von sich aus" macht und sich "zuständig" fühlt. Der dahinter stehende Automatismus, dass sich der DNS-Bereich über das komplette Netz erstreckt, ist aus meiner Sicht daher schon o.k., dein Fall ist doch sehr speziell.

odoll schrieb:
[...]niemand hindert mich daran Bereiche aus einem /24er an mehrere verschiedene NS, und damit verschiedene Subdomains zu delegieren.

In gewissen Grenzen, ja, die Einschränkungen stehen ja schon oben.

odoll schrieb:
Wie gesagt, DNS hat nichts mit der Netztopologie zu tun

Im Reverse-Fall aus meiner Sicht nur "halb richtig" (s.o.)

odoll schrieb:
Die Frage/das Problem habe ich nicht verstanden.[...]
doch (siehe oben DHCP/Tologie =! DNS)

Naja, in RFC 2317 wird nur an "Netzgrenzen" deligiert und die von dir gewählten DHCP-Bereiche der FB lassen sich nur schwer (eigentlich garnicht) in solche Netze einordnen (und z.B. die .20 wird dann eine Netz-IP sein).

Ich gebe allerdings zu, da im Prinzip jede Delegation, also auch sowas wie

Code:

   20-40          NS      FB.your.domain.
   20-40          NS      maybe.some.other.name.server.
   ;
   20             CNAME   20.20-40.c.b.194.in-addr.arpa.
   21             CNAME   21.20-40.c.b.194.in-addr.arpa.
   22             CNAME   22.20-40.c.b.194.in-addr.arpa.
  [...]

"zulässig" sein sollte, damit ließe sich "dein Problem" natürlich lösen.

Jörg

RalfFriedl · 28 Dez 2009

odoll schrieb:
Ob ein NS für eine Zone autoritative Antworten geben kann/darf, ergibt sich dadurch, ob die Zone von den Root-NS aus an ihn delegiert worden ist.

Ob ein NS für eine Zone autoritative Antworten gibt, hängt davon ab, ob er dazu konfiguriert wurde oder nicht. Und das hat nichts mit Einträgen im Root-NS zu tun.

Aber genau hier liegt das Problem. AVM macht es sich IMO mit Blick auf ihre Zielgruppe zu einfach.
...
Allerdings glaube ich kaum, dass das AVM für ihre Klientel umsetzen möchte.

AVM macht hier genau das, was auf die Zielgruppe zugeschnitten ist. Und das scheint auch Dir klar zu sein, auch wenn Du es nicht gerne zugibst.

Es würde mir halt auch reichen, wenn sie ein reiner Resolver wäre.

Es ist ein DNS-Server, der für die eigene Zone autoritativ ist und für den Rest Forwarding zum Provider-DNS macht.

Verwende einen anderen PC als DNS-Server und hör auf, darüber zu jammern, daß AVM Deinen Sonderfall nicht mit abgedeckt hat.

odoll · 28 Dez 2009

RalfFriedl schrieb:
Ob ein NS für eine Zone autoritative Antworten gibt, hängt davon ab, ob er dazu konfiguriert wurde oder nicht. Und das hat nichts mit Einträgen im Root-NS zu tun.

Stimmt, das Ganze ist doch recht diffizil und man muss seine Wortwahl gut überlegen. Anstatt von "authoritativ" hatte ich besser von Authentizität gesprochen. Und damit meinte ich eigentlich, dass die Authentizität aus der Sicht eines Internetbenutzers (private Netzwerke außen vor gelassen, da mag eine Antwort wohl formal autoritativ und authentisch sein) zumindest gewährleistet ist, wenn die Information aus einem NS stammt, der von den offiziellen Root-NSn ausgehend durch Delegation auch für die Zone zuständig ist.

RalfFriedl schrieb:
AVM macht hier genau das, was auf die Zielgruppe zugeschnitten ist. Und das scheint auch Dir klar zu sein, auch wenn Du es nicht gerne zugibst.

Das stimmt nicht, denn das habe ich bereits "zugegeben". Können wir bitte sachlich bleiben und keine Vermutungen über andere natürliche Personen äußern.

RalfFriedl schrieb:
Es ist ein DNS-Server, der für die eigene Zone autoritativ ist und für den Rest Forwarding zum Provider-DNS macht.

Das wird bei der Einführung von DNSSEC IMHO aber Probleme geben, wenn man denn das DNSSEC Feature als User nutzen möchte?! Oder wie siehst Du das?

RalfFriedl schrieb:
Verwende einen anderen PC als DNS-Server und hör auf, darüber zu jammern, daß AVM Deinen Sonderfall nicht mit abgedeckt hat.

Noch so eine Unterstellung. Ich jammere hier überhaupt nicht rum, sondern hoffe in diesem Forum von Leuten wir Dir z.B. Hinweise zu bekommen, wie ich die FB evt. doch noch nach meinem Geschmack umbiegen kann.
Aber ehrlich gesagt fühle ich mich durch Aussagen von Dir wie

Du weißt, wie ein Reverse Mapping funktioniert?

disqualifiert, und das gefällt mir nicht.

MaxMuster · 28 Dez 2009

... nun ja, "authoritative" als Fachbegriff im DNS Umfeld sollte man schon nutzen dürfen ;-)

Jörg

odoll · 28 Dez 2009

MaxMuster schrieb:
die fünf Minuten überschreiten meine Antwort auch, damit ist sie hoffentlich "kompetent" ;-)

zumindest liest es sich so

auch wenn der Schluss bzgl. der Kompetenz in diese Richtung nicht ganz überzeugend ist, ist es doch gut gekontert ;-)

MaxMuster schrieb:
[...] gewählten DHCP-Bereiche der FB lassen sich nur schwer (eigentlich garnicht) in solche Netze einordnen (und z.B. die .20 wird dann eine Netz-IP sein).

Klar, die .20 ist natürlich dem FB-Default geschuldet. Müsste ich tatsächlich die Reverse-Zone für das /24er an mehrere NS delegieren lassen, hätte ich sicherlich eine andere Grenze gewählt.

odoll · 28 Dez 2009

MaxMuster schrieb:
... nun ja, "authoritative" als Fachbegriff im DNS Umfeld sollte man schon nutzen dürfen

schon, aber hier hat RalfFriedl - mein Hostmaster-Wissen von vor 10+ Jahren hervorkramend - wohl bzgl. des Begriff schon recht.

Aber ich lasse mir nicht einreden, dass ein nicht konformes Verhalten dadurch richtig wird, weil ich nicht zu einer Zielgruppe gehöre und meine Konfiguration eben zu speziell ist.

Kunde: Mein Auto klappert hinten.
Werkstatt: Dann gehen sie doch zu Fuß, dann klappert es nicht.

DNS: Probleme mit Reverse Lookup

Mitglied

IPPF-Urgestein

Mitglied

Mitglied

Mitglied

Mitglied

mag

Guest

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Urgestein

Mitglied

IPPF-Promi

Mitglied

IPPF-Promi

IPPF-Urgestein

Mitglied

IPPF-Promi

Mitglied

Mitglied

Statistik des Forums