Wat stellen jullie in als rDNS voor je primary nameserver?
Als onze nameserver nu een request krijgt dat niet in de cache staat en niet een domein van ons zelf is, reageert hij vrij traag. Ik zou dat graag oplossen.
Likes: 0

Wat stellen jullie in als rDNS voor je primary nameserver?
Als onze nameserver nu een request krijgt dat niet in de cache staat en niet een domein van ons zelf is, reageert hij vrij traag. Ik zou dat graag oplossen.
rDNS ? (=reversed dns) Je bedoeld waarschijnlijk een dns server die overige domains kan resolven waar je zelf dus niet authoritive voor bent? ik zelf gebruik daar de rootservers voor. En dat gaat opzich prima hoor.

Klopt idd. Ik bedoel resolving nameserver.
Gegevens over rootservers bijwerken?
Firewall controleren? Meeste problemen bij het resolven die ik heb gezien worden door de firewall veroorzaakt. Simpele test: uitschakelen en proberen iets te laten resolven.
/etc/resolv.conf bevat niet de juiste gegevens?
heb je ook al eens met "dig" getest om de ingestelde nameserver direct te query'en? (Er vanuit gaande dat je linux gebruikt). En duurt het dan ook nog steeds zo lang?
Firewall is inderdaad ook nog een optie. Alhoewel je alleen maar udp port 53 hoeft toe te laten.
Heeft je server zijn hostname ook een A record?
DNS kijkt namelijk ook naar <query>.hostnamevanjeserver, als hostname niet bestaat kan die idd traag worden (happend to me)

De server heeft een A-record voor de hostname, de nameservers resolven prima, directe queries van domeinen binnen ons netwerk zijn razend snel, pas als we gaan resolven naar iets wat wij niet in onze cache hebben zitten, wordt het dramatisch traag:
Op de Mac Pro
# dig tokioonline.jp
; <<>> DiG 9.3.4 <<>> tokioonline.jp
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 36401
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;tokioonline.jp. IN A
;; AUTHORITY SECTION:
jp. 900 IN SOA z.dns.jp. root.dns.jp. 1193104800 3600 900 604800 900
;; Query time: 564 msec
;; SERVER: 192.168.0.1#53(192.168.0.1)
;; WHEN: Tue Oct 23 04:11:12 2007
;; MSG SIZE rcvd: 79
Op onze nameserver
# dig tokioonline.jp @ns1.xentronix.nl
; <<>> DiG 9.3.4 <<>> tokioonline.jp @ns1.xentronix.nl
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 48119
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;tokioonline.jp. IN A
;; AUTHORITY SECTION:
jp. 900 IN SOA z.dns.jp. root.dns.jp. 1193104800 3600 900 604800 900
;; Query time: 3483 msec
;; SERVER: 85.12.15.250#53(85.12.15.250)
;; WHEN: Tue Oct 23 04:11:29 2007
;; MSG SIZE rcvd: 79
Firewall aan of uit maakt niet uit. Poort 53 hebben we zowel TCP als UDP open.
UPDATE: Zelfs als ik de IP's van de vanuit ons snelste rootservers in resolve.conf zet, blijft de resolve tijd 3400mS+ voor niet bekende domeinen.
Laatst gewijzigd door FransVanNispen; 23/10/07 om 04:26.
Als je met dig "@ns1.xentronix.nl" meegeeft, maakt het natuurlijk niet meer uit wat er in je resolv.conf staat. ns1.xentronix.nl resolv't hier trouwens prima recursive (ik weet niet of je dat wilt toestaan overigens).
Verder heb ik ook weinig ideeën wat het nog kan zijn. Je kan kijken of je hostname ook in je hosts file staat (weet niet of het hier veel voor uitmaakt) en je kan eens met een sniffer het verkeer monitoren om te zien waar het precies lang duurt oid.
Misschien heeft iemand anders nog wel een goed idee![]()
Behalve het controleren van de configuratie zou ik het niet zo snel weten.
Ik heb hier gekeken hoe lang het duurt om diverse namen te resolven en ik zie diverse waardes die een stuk lager zitten dan welke TS noemt.

Het probleem is gevonden, het was de versie van Bind. Na een update werkt hij razend snel.
Misschien begrijp ik je verhaal niet helemaal goed hoor. Maar hoe kan het aan je eigen bind installatie liggen, als je een externe resolver geprobeerd hebt? Dan wordt er geen lokale dns server gebruikt natuurlijk.
Waarschijnlijk wordt er bedoeld dat als er een domein aan de lokale bind wordt gevraagd die NIET wordt geserved door de lokale bind dat het request wordt geforward naar een externe resolver.