Server reageert zelf op niet-bestaande domeinen

[dtech]

Hallo,

op dit moment vertoont een server die ik (mede) beheer een wat raar gedrag. Op het moment dat een niet-bestaand adres wordt benaderd reageert de server zelf. Dit zorgt er bijvoorbeeld voor dat als je "www.google.co" benaderd je de default webpagina van de server krijgt.
ook in de ping is het te zien:

code:

# ping www.google.co
PING www.google.co.domeinvanserver.nl (xx-xx-xx-xx) 56(84) bytes of data.
64 bytes from xx-xx-xx-xx.colo.transip.net (xx-xx-xx-xx): icmp_seq=1 ttl=64 time=0.021 ms
64 bytes from xx-xx-xx-xx.colo.transip.net (xx-xx-xx-xx): icmp_seq=2 ttl=64 time=0.022 ms

Hier lijkt het dus op dat automatisch het domein van de server wordt geappend waarop vervolgens de wildcard (*.domeinvanserver.nl) reageert.

Zodra we IPv6 zijn gaan gebruiken is het echter pas echt vervelend geworden: nu treed dit probleem namelijk op bij elk domein dat geen eigen IPv6 domein heeft:

code:

# ping6 ftp.nl.debian.org
PING ftp.nl.debian.org(2a01:xxxxx::1) 56 data bytes
64 bytes from 2a01:xxxx::1: icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from 2a01:xxxx1::1: icmp_seq=2 ttl=64 time=0.010 ms

Dit maakt effectief het internet onbereikbaar, omdat bij nagenoeg alle sites de server zelf reageert i.p.v. de echte site.

Weet iemand hoe ik dat gedrag kan uitschakelen?

[TimDJ]

edit:
oops, in windows is dit het domein wat je aan je dns instellingen meegeeft

[ Voor 159% gewijzigd door TimDJ op 13-12-2010 20:55 ]

[Keiichi]

probeer de 'catchall' A entry in je DNS eens weg te halen van je domein 'domeinvanserver.nl'

[dtech]

@FAD

Noch in /etc/resolv.conf nog in /etc/network/interfaces staat een domain entry

@Keiichi

Dat is niet echt een optie, aangezien we wel graag willen dat de server bereikbaar is onder *.domein.com. Bovendien haalt dat het diepere probleem niet weg. Ik zag wel dat er toch een AAAA (IPv6) catchall was, en die heb ik nu weggehaalt. Dat geeft wel verbetering:

code:

ping6 blaargh.acom
unknown host

Internet zou dus weer te gebruiken moeten zijn zodra DNS-cache leegt. Het onderliggende probleem is dan echter nog niet opgelost. (en ook op IPv6 willen we graag t.z.t. dat de server onder *.domein.com bereikbaar is)

[Keiichi]

Doe eens 'cat /etc/resolv.conf' en post dat hier.

Het enige wat kan is dat daar 'search domeinvanserver.nl' staat.

Heb zelf eea getest en met ping6 negeert ie de search waar ie bij gewoon ping wel het domein achter m'n ongedeligde naam plakt.

-edit-

Verder zou ik me er niet druk om maken, het standaard behaviour van de host! Die zoekt naar de DNS, de server heeft wat dat betreft er niets mee te maken (In geval je vanaf verschillende client/servers zit te werken)

[ Voor 31% gewijzigd door Keiichi op 13-12-2010 21:27 ]

[DiedX]

staat in /etc/resolv.conf niet iets in de vorm van

domain <eigendomein>

in plaats van alleen de resolvers? En zo ja, zet dan eens een # voor domain

[Verwijderd]

bekijk eens volgende

pico /etc/hosts
pico /etc/apache2/sites-available/default

let op verschil ip4 en ip6
wat mogelijks ook het probleem kan zijn

localhost
ip4 127.1.1.0
ip6 ::1


CONTROLE hostname
hostname -f

bekijk ook de software router monowall voor leuke toepassingen bekijk ook de output zodat je met xml alle domeinen snel kan instellen.

[ Voor 22% gewijzigd door Verwijderd op 13-12-2010 23:40 ]

[dtech]

Verwijderd schreef op maandag 13 december 2010 @ 23:20:
bekijk eens volgende

pico /etc/hosts

Enkele een paar statische hosts en 2 entries voor 127.0.0.1, en wat (standaard? denk ik) mumbo-jumbo over IPv6:

code:

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
... nog meer entries ...

pico /etc/apache2/sites-available/default

let op verschil ip4 en ip6
wat mogelijks ook het probleem kan zijn

localhost
ip4 127.1.1.0
ip6 ::1

In defaults staat niets specifieks, enkel <VirtualHost *:80>, maar niks specifieks over domeinen of IPv6

CONTROLE hostname
hostname -f

Ik snap niet precies wat je hier mee bedoelt, die geeft gewoon de (correcte) hostname van de server terug.

[dtech]

DiedX schreef op maandag 13 december 2010 @ 21:39:
staat in /etc/resolv.conf niet iets in de vorm van

domain <eigendomein>

in plaats van alleen de resolvers? En zo ja, zet dan eens een # voor domain

Nope

code:

# cat /etc/resolv.conf
nameserver 80.69.67.66
nameserver 80.69.66.67

Niets raars dus

Keiichi schreef op maandag 13 december 2010 @ 21:26:
Doe eens 'cat /etc/resolv.conf' en post dat hier.

Het enige wat kan is dat daar 'search domeinvanserver.nl' staat.

Zie boven, staat er dus niet in

Verder zou ik me er niet druk om maken, het standaard behaviour van de host! Die zoekt naar de DNS, de server heeft wat dat betreft er niets mee te maken (In geval je vanaf verschillende client/servers zit te werken)

Welke host bedoel je precies? Maar dan alsnog: je moet toch ergens kunnen instellen welk domein hij er achter plakt? En het is dus wel degelijk een beetje een probleem in dit geval, aangezien het een catch-all voor IPv6 onmogelijk maakt en zorgt voor fouten als de host niet bestaat (bijv. bij een typefout oid)

[ Voor 51% gewijzigd door dtech op 14-12-2010 00:39 ]

[Kees]

En toch is het verhaal wat jij beschrijft normaal gesproken de 'schuld' van een 'search' in je resolv.conf. Mischien haalt hij het uit een andere file, staat er mischien iets in een andere file waardoor je een search domein krijgt?

bekijk bijvoorbeeld eens de output van

(strace -f host niet-bestaande.host) 2>&1|grep open

om te zien of hij iets uit een andere file haalt. Of, mischien ligt het aan je dns server, wat gebeurt er als je een andere dns server gebruikt (host blaat $andere.dns.server.com).

En wat als je /etc/hostname alleen de naam van de server bevat, en niet de domeinnaam?

[Keiichi]

ping je vanaf de server zelf of heb je daar een andere host voor gebruikt?

Je hoeft alleen maar te kijken aan de kant van waar je de pings uitstuurt, de server in kwestie heeft er niets mee te maken, die doet gewoon wat ie moet doen en dat is het reageren op ping pakjes naar zijn IP adres toe (dns is voor deserver al niet van belang)

[Verwijderd]

Wat Kees zegt klopt helemaal. Echter is er iets dat veel mensen niet weten of niet beseffen. Het is mogelijk dat de gethostname() call een fqdn teruggeeft, en in dat geval wordt een deel van die hostname gebruikt. Ook de kernel.domainname parameter kan nog "roet in het eten gooien", dus controleer ook de waarde van /proc/sys/kernel/domainname
Om die "automatische" search domain uit te schakelen (om te zien of het daar deels aan ligt) kun je het best tijdelijk een search domain expliciet in /etc/resolv.conf zetten waarvan je zeker weet dat het niet gaat werken.

[dtech]

Kees schreef op dinsdag 14 december 2010 @ 01:35:
En toch is het verhaal wat jij beschrijft normaal gesproken de 'schuld' van een 'search' in je resolv.conf. Mischien haalt hij het uit een andere file, staat er mischien iets in een andere file waardoor je een search domein krijgt?

bekijk bijvoorbeeld eens de output van

(strace -f host niet-bestaande.host) 2>&1|grep open

om te zien of hij iets uit een andere file haalt. Of, mischien ligt het aan je dns server, wat gebeurt er als je een andere dns server gebruikt (host blaat $andere.dns.server.com).

En wat als je /etc/hostname alleen de naam van de server bevat, en niet de domeinnaam?

Komt niet uit een file:

code:

# (strace -f ping blaat.acom) 2>&1|grep open
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/libresolv.so.2", O_RDONLY)   = 3
open("/lib/libc.so.6", O_RDONLY)        = 3
open("/etc/resolv.conf", O_RDONLY)      = 4
open("/etc/resolv.conf", O_RDONLY)      = 4
open("/etc/nsswitch.conf", O_RDONLY)    = 4
open("/etc/ld.so.cache", O_RDONLY)      = 4
open("/lib/libnss_files.so.2", O_RDONLY) = 4
open("/etc/host.conf", O_RDONLY)        = 4
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
open("/etc/ld.so.cache", O_RDONLY)      = 4
open("/lib/libnss_dns.so.2", O_RDONLY)  = 4
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4
open("/etc/hosts", O_RDONLY|O_CLOEXEC)  = 4

Heb ze allemaal gecontroleerd en nergens staat dat specifieke domein.

Verwijderd schreef op dinsdag 14 december 2010 @ 07:49:
Wat Kees zegt klopt helemaal. Echter is er iets dat veel mensen niet weten of niet beseffen. Het is mogelijk dat de gethostname() call een fqdn teruggeeft, en in dat geval wordt een deel van die hostname gebruikt. Ook de kernel.domainname parameter kan nog "roet in het eten gooien", dus controleer ook de waarde van /proc/sys/kernel/domainname
Om die "automatische" search domain uit te schakelen (om te zien of het daar deels aan ligt) kun je het best tijdelijk een search domain expliciet in /etc/resolv.conf zetten waarvan je zeker weet dat het niet gaat werken.

/proc/sys/kernel/domainname bevat wel een domein, maar geen fqdn (het .nl deel mist). Ik zal die expliciete search vanmiddag even proberen. Is er nog iets dat ik moet restarten voordat het in gaat?


Btw ik heb nog wel last van cron scripts die eens in de zoveel tijd websites benaderen en daardoor waarschijnlijk de DNS cache levendig houden, want ze blijven 404'en op het IPv6 adres van de server. (ook als ik ze ping krijg ik het IPv6 adres van de server terug i.p.v. het goede IPv4 adres). Hoe kan ik die cache legen? Op internet vind ik overal dat je nscd moet restarten maar /etc/init.d/nscd bestaat niet.

[ Voor 39% gewijzigd door dtech op 14-12-2010 10:53 ]

[dtech]

/etc/hostname aanpassen naar een niet-fqdn werkt niet

greppen op /etc vind alleen /etc/hostname en /etc/mailname.

In man resolv.conf staat nog dat LOCALDOMAIN variabele search kan overschrijven, maar die is niet geset dus dat kan het niet zijn.

handmatig een search zetten in /etc/resolv.conf werkt min of meer, maar er zitten nog een aantal belangrijke adressen als verkeerde IPv6 adressen in de cache, plus dat ik gewoon graag die catchall wil.

[Verwijderd]

1: Het is geen catchall maar een wildcard.
2: Een zone met een wildcard record moet je nooit als search domain willen instellen.

[dtech]

2: eens, maar hoe kan ik het search gedrag uitzetten?...