Caching DNS-server probleempje

[Richard Rasker]

Ik heb al sinds jaar en dag een caching DNS-server draaien op mijn firewall,
alleen merk ik sinds enige tijd iets vreemds: sommige URL's zijn prima
herleidbaar vanaf deze machine zelf, maar niet vanaf achterliggende
machines -- zie onderstaand voorbeeld.

Vanaf de firewallmachine:

# host www.laptopjacks.co.uk
www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.

Vanaf een achterliggende machine:

$ host www.laptopjacks.co.uk
;; connection timed out; no servers could be reached

De resolving van andere adressen werkt probleemloos, en dit probleem treedt
maar bij een doodenkele URL op; ik zou bijna vermoeden dat bepaalde
DNS-gegevens in mijn nameserver verouderd zijn. Een reload (of zelfs
restart) van bind9 helpt overigens ook niet. Heeft iemand een idee wat er
aan de hand kan zijn?

Richard Rasker

[Wietse Muizelaar]

Post by Richard Rasker
Ik heb al sinds jaar en dag een caching DNS-server draaien op mijn firewall,
alleen merk ik sinds enige tijd iets vreemds: sommige URL's zijn prima
herleidbaar vanaf deze machine zelf, maar niet vanaf achterliggende
machines -- zie onderstaand voorbeeld.
# host www.laptopjacks.co.uk
www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.
$ host www.laptopjacks.co.uk
;; connection timed out; no servers could be reached
De resolving van andere adressen werkt probleemloos, en dit probleem treedt
maar bij een doodenkele URL op; ik zou bijna vermoeden dat bepaalde
DNS-gegevens in mijn nameserver verouderd zijn. Een reload (of zelfs
restart) van bind9 helpt overigens ook niet. Heeft iemand een idee wat er
aan de hand kan zijn?

Misschien iets met UDP versus TCP poort 53? Ik heb daar wel 'ns rare
dingen mee gezien. Met 'dig' kun je opties als +tcp en +notcp meegeven
om een bepaald protocol te forceren; en dan kijken of je dit hiermee
kunt reproduceren.

[Richard Rasker]

Post by Wietse Muizelaar

Post by Richard Rasker
Ik heb al sinds jaar en dag een caching DNS-server draaien op mijn
firewall, alleen merk ik sinds enige tijd iets vreemds: sommige URL's
zijn prima herleidbaar vanaf deze machine zelf, maar niet vanaf
achterliggende machines -- zie onderstaand voorbeeld.
# host www.laptopjacks.co.uk
www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.
$ host www.laptopjacks.co.uk
;; connection timed out; no servers could be reached
De resolving van andere adressen werkt probleemloos, en dit probleem
treedt maar bij een doodenkele URL op; ik zou bijna vermoeden dat
bepaalde DNS-gegevens in mijn nameserver verouderd zijn. Een reload (of
zelfs restart) van bind9 helpt overigens ook niet. Heeft iemand een idee
wat er aan de hand kan zijn?

Misschien iets met UDP versus TCP poort 53? Ik heb daar wel 'ns rare
dingen mee gezien. Met 'dig' kun je opties als +tcp en +notcp meegeven
om een bepaald protocol te forceren; en dan kijken of je dit hiermee
kunt reproduceren.

Mnee, dig ziet niets vanaf het LAN, en alles vanaf de firewallmachine,
ongeacht welk protocol ik forceer. Hoe kan een protocolkeuze trouwens
invloed hebben op bepaalde URL's en niet op andere?

Richard Rasker

[Wietse Muizelaar]

Post by Richard Rasker

Post by Wietse Muizelaar

Post by Richard Rasker
Ik heb al sinds jaar en dag een caching DNS-server draaien op mijn
firewall, alleen merk ik sinds enige tijd iets vreemds: sommige URL's
zijn prima herleidbaar vanaf deze machine zelf, maar niet vanaf
achterliggende machines -- zie onderstaand voorbeeld.
# host www.laptopjacks.co.uk
www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.
$ host www.laptopjacks.co.uk
;; connection timed out; no servers could be reached
De resolving van andere adressen werkt probleemloos, en dit probleem
treedt maar bij een doodenkele URL op; ik zou bijna vermoeden dat
bepaalde DNS-gegevens in mijn nameserver verouderd zijn. Een reload (of
zelfs restart) van bind9 helpt overigens ook niet. Heeft iemand een idee
wat er aan de hand kan zijn?

Misschien iets met UDP versus TCP poort 53? Ik heb daar wel 'ns rare
dingen mee gezien. Met 'dig' kun je opties als +tcp en +notcp meegeven
om een bepaald protocol te forceren; en dan kijken of je dit hiermee
kunt reproduceren.

Mnee, dig ziet niets vanaf het LAN, en alles vanaf de firewallmachine,
ongeacht welk protocol ik forceer. Hoe kan een protocolkeuze trouwens
invloed hebben op bepaalde URL's en niet op andere?

Als er 'veel' informatie terugkomt (in dit geval lijkt dat overigens
niet het geval te zijn, zie ik nu), dan past het niet ine en UDP-pakket,
en gaat er een retry over TCP gedaan worden. Ik heb op die manier wel
eens gezien dat dus heel veel lookups goed gingen (want allemaal over
UDP), maar dat het over TCP stuk ging (dat stond ten onrechte dicht), en
dan krijg je dus rare situaties.

Maar goed; dat lijkt duidelijk jouw probleem niet te zijn, dus dat is
het niet :)

Als je een dig +trace www.laptopjacks.co.uk doet, krijg je vanaf de
host-achter-de-firewall wel een respons? Of ook niet?

[Richard Rasker]

Post by Wietse Muizelaar

Post by Richard Rasker

Post by Wietse Muizelaar

Post by Richard Rasker
Ik heb al sinds jaar en dag een caching DNS-server draaien op mijn
firewall, alleen merk ik sinds enige tijd iets vreemds: sommige URL's
zijn prima herleidbaar vanaf deze machine zelf, maar niet vanaf
achterliggende machines -- zie onderstaand voorbeeld.
# host www.laptopjacks.co.uk
www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.
$ host www.laptopjacks.co.uk
;; connection timed out; no servers could be reached
De resolving van andere adressen werkt probleemloos, en dit probleem
treedt maar bij een doodenkele URL op; ik zou bijna vermoeden dat
bepaalde DNS-gegevens in mijn nameserver verouderd zijn. Een reload (of
zelfs restart) van bind9 helpt overigens ook niet. Heeft iemand een
idee wat er aan de hand kan zijn?

Misschien iets met UDP versus TCP poort 53? Ik heb daar wel 'ns rare
dingen mee gezien. Met 'dig' kun je opties als +tcp en +notcp meegeven
om een bepaald protocol te forceren; en dan kijken of je dit hiermee
kunt reproduceren.

Mnee, dig ziet niets vanaf het LAN, en alles vanaf de firewallmachine,
ongeacht welk protocol ik forceer. Hoe kan een protocolkeuze trouwens
invloed hebben op bepaalde URL's en niet op andere?

Als er 'veel' informatie terugkomt (in dit geval lijkt dat overigens
niet het geval te zijn, zie ik nu), dan past het niet ine en UDP-pakket,
en gaat er een retry over TCP gedaan worden. Ik heb op die manier wel
eens gezien dat dus heel veel lookups goed gingen (want allemaal over
UDP), maar dat het over TCP stuk ging (dat stond ten onrechte dicht), en
dan krijg je dus rare situaties.
Maar goed; dat lijkt duidelijk jouw probleem niet te zijn, dus dat is
het niet :)
Als je een dig +trace www.laptopjacks.co.uk doet, krijg je vanaf de
host-achter-de-firewall wel een respons? Of ook niet?

Vanaf de client:

$ dig +trace www.laptopjacks.co.uk

; <<>> DiG 9.5.0-P1 <<>> +trace www.laptopjacks.co.uk
;; global options: printcmd
. 513495 IN NS D.ROOT-SERVERS.NET.
. 513495 IN NS E.ROOT-SERVERS.NET.
. 513495 IN NS F.ROOT-SERVERS.NET.
. 513495 IN NS G.ROOT-SERVERS.NET.
. 513495 IN NS H.ROOT-SERVERS.NET.
. 513495 IN NS I.ROOT-SERVERS.NET.
. 513495 IN NS J.ROOT-SERVERS.NET.
. 513495 IN NS K.ROOT-SERVERS.NET.
. 513495 IN NS L.ROOT-SERVERS.NET.
. 513495 IN NS M.ROOT-SERVERS.NET.
. 513495 IN NS A.ROOT-SERVERS.NET.
. 513495 IN NS B.ROOT-SERVERS.NET.
. 513495 IN NS C.ROOT-SERVERS.NET.
;; Received 500 bytes from 192.168.1.1#53(192.168.1.1) in 16 ms

uk. 172800 IN NS NS5.NIC.uk.
uk. 172800 IN NS NS6.NIC.uk.
uk. 172800 IN NS NS3.NIC.uk.
uk. 172800 IN NS NSD.NIC.uk.
uk. 172800 IN NS NS2.NIC.uk.
uk. 172800 IN NS NSC.NIC.uk.
uk. 172800 IN NS NSB.NIC.uk.
uk. 172800 IN NS NS7.NIC.uk.
uk. 172800 IN NS NS4.NIC.uk.
uk. 172800 IN NS NS1.NIC.uk.
uk. 172800 IN NS NSA.NIC.uk.
;; Received 501 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 177 ms

laptopjacks.co.uk. 172800 IN NS ns196.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS ns195.websitewelcome.com.
;; Received 97 bytes from 213.219.13.131#53(NS3.NIC.uk) in 23 ms

;; connection timed out; no servers could be reached


En vanaf de firewall:

# dig +trace www.laptopjacks.co.uk

; <<>> DiG 9.3.4-P1.1 <<>> +trace www.laptopjacks.co.uk
;; global options: printcmd
. 496767 IN NS C.ROOT-SERVERS.NET.
. 496767 IN NS A.ROOT-SERVERS.NET.
. 496767 IN NS L.ROOT-SERVERS.NET.
. 496767 IN NS G.ROOT-SERVERS.NET.
. 496767 IN NS F.ROOT-SERVERS.NET.
. 496767 IN NS E.ROOT-SERVERS.NET.
. 496767 IN NS I.ROOT-SERVERS.NET.
. 496767 IN NS M.ROOT-SERVERS.NET.
. 496767 IN NS D.ROOT-SERVERS.NET.
. 496767 IN NS H.ROOT-SERVERS.NET.
. 496767 IN NS J.ROOT-SERVERS.NET.
. 496767 IN NS B.ROOT-SERVERS.NET.
. 496767 IN NS K.ROOT-SERVERS.NET.
;; Received 500 bytes from 217.149.192.6#53(217.149.192.6) in 26 ms

uk. 172800 IN NS NSC.NIC.uk.
uk. 172800 IN NS NS1.NIC.uk.
uk. 172800 IN NS NS7.NIC.uk.
uk. 172800 IN NS NSA.NIC.uk.
uk. 172800 IN NS NS2.NIC.uk.
uk. 172800 IN NS NS6.NIC.uk.
uk. 172800 IN NS NSB.NIC.uk.
uk. 172800 IN NS NS4.NIC.uk.
uk. 172800 IN NS NS3.NIC.uk.
uk. 172800 IN NS NS5.NIC.uk.
uk. 172800 IN NS NSD.NIC.uk.
;; Received 501 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 31 ms

laptopjacks.co.uk. 172800 IN NS ns196.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS ns195.websitewelcome.com.
;; Received 97 bytes from 199.7.66.44#53(NSC.NIC.uk) in 115 ms

;; connection timed out; no servers could be reached


Dit snap ik even niet. Zowel vanaf de client als de firewall komt er
uiteindelijk een 'no servers could be reached', maar de firewall kan de
site wel degelijk resolven. Wat gebeurt hier precies? Heb ik wellicht toch
iets helemaal verkeerd staan in mijn DNS-servertje?


Richard Rasker

[Wietse Muizelaar]

Post by Richard Rasker

Post by Wietse Muizelaar

Post by Richard Rasker

Post by Wietse Muizelaar

Post by Richard Rasker
Ik heb al sinds jaar en dag een caching DNS-server draaien op mijn
firewall, alleen merk ik sinds enige tijd iets vreemds: sommige URL's
zijn prima herleidbaar vanaf deze machine zelf, maar niet vanaf
achterliggende machines -- zie onderstaand voorbeeld.
# host www.laptopjacks.co.uk
www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.
$ host www.laptopjacks.co.uk
;; connection timed out; no servers could be reached
De resolving van andere adressen werkt probleemloos, en dit probleem
treedt maar bij een doodenkele URL op; ik zou bijna vermoeden dat
bepaalde DNS-gegevens in mijn nameserver verouderd zijn. Een reload (of
zelfs restart) van bind9 helpt overigens ook niet. Heeft iemand een
idee wat er aan de hand kan zijn?

Misschien iets met UDP versus TCP poort 53? Ik heb daar wel 'ns rare
dingen mee gezien. Met 'dig' kun je opties als +tcp en +notcp meegeven
om een bepaald protocol te forceren; en dan kijken of je dit hiermee
kunt reproduceren.

Mnee, dig ziet niets vanaf het LAN, en alles vanaf de firewallmachine,
ongeacht welk protocol ik forceer. Hoe kan een protocolkeuze trouwens
invloed hebben op bepaalde URL's en niet op andere?

Als er 'veel' informatie terugkomt (in dit geval lijkt dat overigens
niet het geval te zijn, zie ik nu), dan past het niet ine en UDP-pakket,
en gaat er een retry over TCP gedaan worden. Ik heb op die manier wel
eens gezien dat dus heel veel lookups goed gingen (want allemaal over
UDP), maar dat het over TCP stuk ging (dat stond ten onrechte dicht), en
dan krijg je dus rare situaties.
Maar goed; dat lijkt duidelijk jouw probleem niet te zijn, dus dat is
het niet :)
Als je een dig +trace www.laptopjacks.co.uk doet, krijg je vanaf de
host-achter-de-firewall wel een respons? Of ook niet?

$ dig +trace www.laptopjacks.co.uk
; <<>> DiG 9.5.0-P1 <<>> +trace www.laptopjacks.co.uk
;; global options: printcmd
. 513495 IN NS D.ROOT-SERVERS.NET.
. 513495 IN NS E.ROOT-SERVERS.NET.
. 513495 IN NS F.ROOT-SERVERS.NET.
. 513495 IN NS G.ROOT-SERVERS.NET.
. 513495 IN NS H.ROOT-SERVERS.NET.
. 513495 IN NS I.ROOT-SERVERS.NET.
. 513495 IN NS J.ROOT-SERVERS.NET.
. 513495 IN NS K.ROOT-SERVERS.NET.
. 513495 IN NS L.ROOT-SERVERS.NET.
. 513495 IN NS M.ROOT-SERVERS.NET.
. 513495 IN NS A.ROOT-SERVERS.NET.
. 513495 IN NS B.ROOT-SERVERS.NET.
. 513495 IN NS C.ROOT-SERVERS.NET.
;; Received 500 bytes from 192.168.1.1#53(192.168.1.1) in 16 ms
uk. 172800 IN NS NS5.NIC.uk.
uk. 172800 IN NS NS6.NIC.uk.
uk. 172800 IN NS NS3.NIC.uk.
uk. 172800 IN NS NSD.NIC.uk.
uk. 172800 IN NS NS2.NIC.uk.
uk. 172800 IN NS NSC.NIC.uk.
uk. 172800 IN NS NSB.NIC.uk.
uk. 172800 IN NS NS7.NIC.uk.
uk. 172800 IN NS NS4.NIC.uk.
uk. 172800 IN NS NS1.NIC.uk.
uk. 172800 IN NS NSA.NIC.uk.
;; Received 501 bytes from 192.5.5.241#53(F.ROOT-SERVERS.NET) in 177 ms
laptopjacks.co.uk. 172800 IN NS ns196.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS ns195.websitewelcome.com.
;; Received 97 bytes from 213.219.13.131#53(NS3.NIC.uk) in 23 ms
;; connection timed out; no servers could be reached
# dig +trace www.laptopjacks.co.uk
; <<>> DiG 9.3.4-P1.1 <<>> +trace www.laptopjacks.co.uk
;; global options: printcmd
. 496767 IN NS C.ROOT-SERVERS.NET.
. 496767 IN NS A.ROOT-SERVERS.NET.
. 496767 IN NS L.ROOT-SERVERS.NET.
. 496767 IN NS G.ROOT-SERVERS.NET.
. 496767 IN NS F.ROOT-SERVERS.NET.
. 496767 IN NS E.ROOT-SERVERS.NET.
. 496767 IN NS I.ROOT-SERVERS.NET.
. 496767 IN NS M.ROOT-SERVERS.NET.
. 496767 IN NS D.ROOT-SERVERS.NET.
. 496767 IN NS H.ROOT-SERVERS.NET.
. 496767 IN NS J.ROOT-SERVERS.NET.
. 496767 IN NS B.ROOT-SERVERS.NET.
. 496767 IN NS K.ROOT-SERVERS.NET.
;; Received 500 bytes from 217.149.192.6#53(217.149.192.6) in 26 ms
uk. 172800 IN NS NSC.NIC.uk.
uk. 172800 IN NS NS1.NIC.uk.
uk. 172800 IN NS NS7.NIC.uk.
uk. 172800 IN NS NSA.NIC.uk.
uk. 172800 IN NS NS2.NIC.uk.
uk. 172800 IN NS NS6.NIC.uk.
uk. 172800 IN NS NSB.NIC.uk.
uk. 172800 IN NS NS4.NIC.uk.
uk. 172800 IN NS NS3.NIC.uk.
uk. 172800 IN NS NS5.NIC.uk.
uk. 172800 IN NS NSD.NIC.uk.
;; Received 501 bytes from 192.33.4.12#53(C.ROOT-SERVERS.NET) in 31 ms
laptopjacks.co.uk. 172800 IN NS ns196.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS ns195.websitewelcome.com.
;; Received 97 bytes from 199.7.66.44#53(NSC.NIC.uk) in 115 ms
;; connection timed out; no servers could be reached

Boeiend. Ter vergelijk, dit is wat ik krijg:

; <<>> DiG 9.5.0-P2 <<>> +trace www.laptopjacks.co.uk
;; global options: printcmd
. 427323 IN NS d.root-servers.net.
. 427323 IN NS e.root-servers.net.
. 427323 IN NS l.root-servers.net.
. 427323 IN NS j.root-servers.net.
. 427323 IN NS k.root-servers.net.
. 427323 IN NS g.root-servers.net.
. 427323 IN NS b.root-servers.net.
. 427323 IN NS m.root-servers.net.
. 427323 IN NS i.root-servers.net.
. 427323 IN NS a.root-servers.net.
. 427323 IN NS h.root-servers.net.
. 427323 IN NS f.root-servers.net.
. 427323 IN NS c.root-servers.net.
;; Received 449 bytes from 192.168.1.254#53(192.168.1.254) in 14 ms

uk. 172800 IN NS NSC.NIC.uk.
uk. 172800 IN NS NSD.NIC.uk.
uk. 172800 IN NS NS1.NIC.uk.
uk. 172800 IN NS NS2.NIC.uk.
uk. 172800 IN NS NS3.NIC.uk.
uk. 172800 IN NS NS4.NIC.uk.
uk. 172800 IN NS NS5.NIC.uk.
uk. 172800 IN NS NS6.NIC.uk.
uk. 172800 IN NS NS7.NIC.uk.
uk. 172800 IN NS NSA.NIC.uk.
uk. 172800 IN NS NSB.NIC.uk.
;; Received 501 bytes from 2001:503:ba3e::2:30#53(a.root-servers.net) in
104 ms

laptopjacks.co.uk. 172800 IN NS
ns195.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS
ns196.websitewelcome.com.
;; Received 97 bytes from 212.121.40.130#53(NS7.NIC.uk) in 34 ms

www.laptopjacks.co.uk. 14400 IN CNAME laptopjacks.co.uk.
laptopjacks.co.uk. 14400 IN A 70.87.90.130
laptopjacks.co.uk. 86400 IN NS
ns195.websitewelcome.com.
laptopjacks.co.uk. 86400 IN NS
ns196.websitewelcome.com.
;; Received 159 bytes from 70.87.90.131#53(ns196.websitewelcome.com) in
133 ms

Post by Richard Rasker
Dit snap ik even niet. Zowel vanaf de client als de firewall komt er
uiteindelijk een 'no servers could be reached', maar de firewall kan de
site wel degelijk resolven. Wat gebeurt hier precies? Heb ik wellicht toch
iets helemaal verkeerd staan in mijn DNS-servertje?

Goeie vraag. Waar het zo te zien op misgaat is bij het opvragen van
'zeg, dat laptopjacks.co.uk, waar is dat' bij ns195.websitewelcome.com
en/of ns196.websitewelcome.com. Kun je ze wel rechtstreeks opvragen bij
die servers? (als in:

***@oscar(12:31):~$ host www.laptopjacks.co.uk ns195.websitewelcome.com
Using domain server:
Name: ns195.websitewelcome.com
Address: 70.87.90.130#53
Aliases:

www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.
***@oscar(12:31):~$ host www.laptopjacks.co.uk ns196.websitewelcome.com
Using domain server:
Name: ns196.websitewelcome.com
Address: 70.87.90.131#53
Aliases:

www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.

Zie je ook nog dingen in je firewall-logs richting deze hosts?
(ns195.websitewelcome.com en ns196.websitewelcome.com)

[Richard Rasker]

Post by Wietse Muizelaar

Post by Richard Rasker
$ dig +trace www.laptopjacks.co.uk

...

Post by Wietse Muizelaar

Post by Richard Rasker
laptopjacks.co.uk. 172800 IN NS
ns196.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS
ns195.websitewelcome.com. ;; Received 97 bytes from
213.219.13.131#53(NS3.NIC.uk) in 23 ms
;; connection timed out; no servers could be reached
# dig +trace www.laptopjacks.co.uk

...

Post by Wietse Muizelaar

Post by Richard Rasker
laptopjacks.co.uk. 172800 IN NS
ns196.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS
ns195.websitewelcome.com. ;; Received 97 bytes from
199.7.66.44#53(NSC.NIC.uk) in 115 ms
;; connection timed out; no servers could be reached

; <<>> DiG 9.5.0-P2 <<>> +trace www.laptopjacks.co.uk

...

Post by Wietse Muizelaar
laptopjacks.co.uk. 172800 IN NS
ns195.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS
ns196.websitewelcome.com.
;; Received 97 bytes from 212.121.40.130#53(NS7.NIC.uk) in 34 ms
www.laptopjacks.co.uk. 14400 IN CNAME laptopjacks.co.uk.
laptopjacks.co.uk. 14400 IN A 70.87.90.130
laptopjacks.co.uk. 86400 IN NS
ns195.websitewelcome.com.
laptopjacks.co.uk. 86400 IN NS
ns196.websitewelcome.com.
;; Received 159 bytes from 70.87.90.131#53(ns196.websitewelcome.com) in
133 ms

Post by Richard Rasker
Dit snap ik even niet. Zowel vanaf de client als de firewall komt er
uiteindelijk een 'no servers could be reached', maar de firewall kan de
site wel degelijk resolven. Wat gebeurt hier precies? Heb ik wellicht
toch iets helemaal verkeerd staan in mijn DNS-servertje?

Goeie vraag. Waar het zo te zien op misgaat is bij het opvragen van
'zeg, dat laptopjacks.co.uk, waar is dat' bij ns195.websitewelcome.com
en/of ns196.websitewelcome.com. Kun je ze wel rechtstreeks opvragen bij
Name: ns195.websitewelcome.com
Address: 70.87.90.130#53
www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.
Name: ns196.websitewelcome.com
Address: 70.87.90.131#53
www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.

Zowel vanaf de firewall als de client gebeurt er dit:

host www.laptopjacks.co.uk ns195.websitewelcome.com
;; connection timed out; no servers could be reached

Het maakt ook niets uit als ik ns195.websitewelcome.com vervang door het
IP-adres van de nameserver, of als ik ns195... vervang door ns196...
Gek genoeg geeft een expliciet aan deze nameservers gerichte dig-opdracht
wel de correcte respons, in ieder geval vanaf de firewall (maar niet vanaf
de client):

dig ***@ns196.websitewelcome.com

; <<>> DiG 9.3.4-P1.1 <<>> ***@ns196.websitewelcome.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41147
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;www.laptopjacks.co.uk\@ns196.websitewelcome.com. IN A

;; AUTHORITY SECTION:
websitewelcome.com. 3600 IN SOA ns1.websitewelcome.com.
root.ferrari.websitewelcome.com. 2008082001 14400 120 1200000 3600

;; Query time: 152 msec
;; SERVER: 217.149.192.6#53(217.149.192.6)
;; WHEN: Mon Sep 22 14:20:36 2008
;; MSG SIZE rcvd: 117

Post by Wietse Muizelaar
Zie je ook nog dingen in je firewall-logs richting deze hosts?
(ns195.websitewelcome.com en ns196.websitewelcome.com)

Nee, maar ik log eerlijk gezegd ook maar heel weinig van wat er in de
firewall gebeurt, zeker wat betreft uitgaand verkeer; wat zou ik kunnen
bekijken?

Richard Rasker

[Wietse Muizelaar]

Post by Wietse Muizelaar

Post by Wietse Muizelaar

Post by Richard Rasker
$ dig +trace www.laptopjacks.co.uk

...

Post by Wietse Muizelaar

Post by Richard Rasker
laptopjacks.co.uk. 172800 IN NS
ns196.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS
ns195.websitewelcome.com. ;; Received 97 bytes from
213.219.13.131#53(NS3.NIC.uk) in 23 ms
;; connection timed out; no servers could be reached
# dig +trace www.laptopjacks.co.uk

...

Post by Wietse Muizelaar

Post by Richard Rasker
laptopjacks.co.uk. 172800 IN NS
ns196.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS
ns195.websitewelcome.com. ;; Received 97 bytes from
199.7.66.44#53(NSC.NIC.uk) in 115 ms
;; connection timed out; no servers could be reached

; <<>> DiG 9.5.0-P2 <<>> +trace www.laptopjacks.co.uk

...

Post by Wietse Muizelaar
laptopjacks.co.uk. 172800 IN NS
ns195.websitewelcome.com.
laptopjacks.co.uk. 172800 IN NS
ns196.websitewelcome.com.
;; Received 97 bytes from 212.121.40.130#53(NS7.NIC.uk) in 34 ms
www.laptopjacks.co.uk. 14400 IN CNAME laptopjacks.co.uk.
laptopjacks.co.uk. 14400 IN A 70.87.90.130
laptopjacks.co.uk. 86400 IN NS
ns195.websitewelcome.com.
laptopjacks.co.uk. 86400 IN NS
ns196.websitewelcome.com.
;; Received 159 bytes from 70.87.90.131#53(ns196.websitewelcome.com) in
133 ms

Post by Richard Rasker
Dit snap ik even niet. Zowel vanaf de client als de firewall komt er
uiteindelijk een 'no servers could be reached', maar de firewall kan de
site wel degelijk resolven. Wat gebeurt hier precies? Heb ik wellicht
toch iets helemaal verkeerd staan in mijn DNS-servertje?

Goeie vraag. Waar het zo te zien op misgaat is bij het opvragen van
'zeg, dat laptopjacks.co.uk, waar is dat' bij ns195.websitewelcome.com
en/of ns196.websitewelcome.com. Kun je ze wel rechtstreeks opvragen bij
Name: ns195.websitewelcome.com
Address: 70.87.90.130#53
www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.
Name: ns196.websitewelcome.com
Address: 70.87.90.131#53
www.laptopjacks.co.uk is an alias for laptopjacks.co.uk.
laptopjacks.co.uk has address 70.87.90.130
laptopjacks.co.uk mail is handled by 0 laptopjacks.co.uk.

host www.laptopjacks.co.uk ns195.websitewelcome.com
;; connection timed out; no servers could be reached

Ok. Dat is dan in ieder geval consequent.

Post by Wietse Muizelaar
Het maakt ook niets uit als ik ns195.websitewelcome.com vervang door het
IP-adres van de nameserver, of als ik ns195... vervang door ns196...
Gek genoeg geeft een expliciet aan deze nameservers gerichte dig-opdracht
wel de correcte respons, in ieder geval vanaf de firewall (maar niet vanaf
;; global options: printcmd
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41147
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
websitewelcome.com. 3600 IN SOA ns1.websitewelcome.com.
root.ferrari.websitewelcome.com. 2008082001 14400 120 1200000 3600
;; Query time: 152 msec
;; SERVER: 217.149.192.6#53(217.149.192.6)
;; WHEN: Mon Sep 22 14:20:36 2008
;; MSG SIZE rcvd: 117

Dat is niet helemaal goed gegaan: je vraagt hier aan een
internlnet-server (althans, dat is waar de SERVER naar wijst)waar

Post by Wietse Muizelaar

Post by Wietse Muizelaar
Zie je ook nog dingen in je firewall-logs richting deze hosts?
(ns195.websitewelcome.com en ns196.websitewelcome.com)

Nee, maar ik log eerlijk gezegd ook maar heel weinig van wat er in de
firewall gebeurt, zeker wat betreft uitgaand verkeer; wat zou ik kunnen
bekijken?

Kijken of er wellicht verkeer van/naar poort 53 tcp/udp gedropt wordt.
En heel, heel misschien is het ook nog iets Path-MTU-discovery-achtigs.
Dat ligt eraan in hoeverre je ICMP blockt in je firewall of niet.

[Richard Rasker]

Post by Wietse Muizelaar

Post by Richard Rasker
Het maakt ook niets uit als ik ns195.websitewelcome.com vervang door het
IP-adres van de nameserver, of als ik ns195... vervang door ns196...
Gek genoeg geeft een expliciet aan deze nameservers gerichte dig-opdracht
wel de correcte respons, in ieder geval vanaf de firewall (maar niet

Dat is niet helemaal goed gegaan: je vraagt hier aan een
internlnet-server (althans, dat is waar de SERVER naar wijst)waar

Klopt -- en met de spatie netjes op zijn plaats is het inderdaad weer 'no
servers could be reached'.

Post by Wietse Muizelaar

Post by Richard Rasker

Post by Wietse Muizelaar
Zie je ook nog dingen in je firewall-logs richting deze hosts?
(ns195.websitewelcome.com en ns196.websitewelcome.com)

Nee, maar ik log eerlijk gezegd ook maar heel weinig van wat er in de
firewall gebeurt, zeker wat betreft uitgaand verkeer; wat zou ik kunnen
bekijken?

Kijken of er wellicht verkeer van/naar poort 53 tcp/udp gedropt wordt.
En heel, heel misschien is het ook nog iets Path-MTU-discovery-achtigs.
Dat ligt eraan in hoeverre je ICMP blockt in je firewall of niet.

Mnee, dit zijn de enige iptables-regels waarin wat met icmp gebeurt:

# iptables -L
...
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere
...

Voor de rest wordt in de block-chain alleen related/established
geaccepteerd:

Chain block (2 references)
target prot opt source destination
ACCEPT 0 -- anywhere anywhere state
RELATED,ESTABLISHED
DROP 0 -- anywhere anywhere

En deze chain komt aan het einde van de chains INPUT en FORWARD --
behoorlijk standaard allemaal, dunkt me.

Richard Rasker

[Wietse Muizelaar]

Post by Richard Rasker

Post by Wietse Muizelaar

Post by Richard Rasker
Het maakt ook niets uit als ik ns195.websitewelcome.com vervang door het
IP-adres van de nameserver, of als ik ns195... vervang door ns196...
Gek genoeg geeft een expliciet aan deze nameservers gerichte dig-opdracht
wel de correcte respons, in ieder geval vanaf de firewall (maar niet

Dat is niet helemaal goed gegaan: je vraagt hier aan een
internlnet-server (althans, dat is waar de SERVER naar wijst)waar

Klopt -- en met de spatie netjes op zijn plaats is het inderdaad weer 'no
servers could be reached'.

Helder.

Post by Richard Rasker

Post by Wietse Muizelaar

Post by Richard Rasker

Post by Wietse Muizelaar
Zie je ook nog dingen in je firewall-logs richting deze hosts?
(ns195.websitewelcome.com en ns196.websitewelcome.com)

Nee, maar ik log eerlijk gezegd ook maar heel weinig van wat er in de
firewall gebeurt, zeker wat betreft uitgaand verkeer; wat zou ik kunnen
bekijken?

Kijken of er wellicht verkeer van/naar poort 53 tcp/udp gedropt wordt.
En heel, heel misschien is het ook nog iets Path-MTU-discovery-achtigs.
Dat ligt eraan in hoeverre je ICMP blockt in je firewall of niet.

# iptables -L
...
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere
...
Voor de rest wordt in de block-chain alleen related/established
Chain block (2 references)
target prot opt source destination
ACCEPT 0 -- anywhere anywhere state
RELATED,ESTABLISHED
DROP 0 -- anywhere anywhere
En deze chain komt aan het einde van de chains INPUT en FORWARD --
behoorlijk standaard allemaal, dunkt me.

Jup, dat ziet er ok uit, in mijn ogen :)

Enige wat ik nog zou kunnen verzinnen is met wireshark/tcpdump
meespieken wat er op de lijn gebeurt aan DNS-verkeer...

[Richard Rasker]

Post by Wietse Muizelaar
Enige wat ik nog zou kunnen verzinnen is met wireshark/tcpdump
meespieken wat er op de lijn gebeurt aan DNS-verkeer...

Hm, ik ben hier niet bijster in thuis ... dus maar de hele dump van de dig-
opdracht vanaf de client:

$ dig www.laptopjacks.co.uk @ns195.websitewelcome.com

; <<>> DiG 9.5.0-P1 <<>> www.laptopjacks.co.uk @ns195.websitewelcome.com
;; global options: printcmd
;; connection timed out; no servers could be reached

En dit geeft het volgende te zien op de firewall (eth1 is de WAN-interface):

# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
15:20:38.495388 IP hedgehog.linetec.nl.ipp > 255-55.bbned.dsl.internl.net.ipp: UDP, length 169
15:20:38.497628 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 486+ PTR? 255.55.254.92.in-addr.arpa. (44)
15:20:38.512542 IP vlan83.newxr2.nik-asd.internl.net > hedgehog.linetec.nl: ICMP host 255-55.bbned.dsl.internl.net unreachable, length 36
15:20:38.519665 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 486 1/2/2 (164)
15:20:38.520776 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 40809+ PTR? 6.192.149.217.in-addr.arpa. (44)
15:20:38.542889 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 40809 1/2/2 (157)
15:20:38.543702 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 9574+ PTR? 133.196.149.217.in-addr.arpa. (46)
15:20:38.567746 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 9574 1/2/2 (171)
15:20:43.494592 arp who-has 1-48.bbned.dsl.internl.net tell hedgehog.linetec.nl
15:20:43.496439 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 24291+ PTR? 1.48.254.92.in-addr.arpa. (42)
15:20:43.510644 arp reply 1-48.bbned.dsl.internl.net is-at 00:13:19:bd:a6:a8 (oui Unknown)
15:20:43.518996 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 24291 1/2/2 PTR[|domain]
15:20:54.882818 IP hedgehog.linetec.nl.10359 > ferrari.websitewelcome.com.domain: 30543 [1au] AAAA? ns195.websitewelcome.com. (53)
15:20:54.883684 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 45672+ PTR? 176.54.18.67.in-addr.arpa. (43)
15:20:55.031431 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 45672 1/2/8 (257)
15:21:05.944865 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 18679+ PTR? 59.37.247.121.in-addr.arpa. (44)
15:21:05.967079 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 18679 1/2/2 (180)
15:21:06.371624 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 15012+ PTR? 59.37.247.121.in-addr.arpa. (44)
15:21:06.394047 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 15012 1/2/2 (180)
15:21:06.394886 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 21285+[|domain]
15:21:06.686952 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 21285 NXDomain[|domain]
15:21:06.687553 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 22176+[|domain]
15:21:06.709403 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 22176 NXDomain[|domain]
15:21:06.888533 IP hedgehog.linetec.nl.27076 > b1.36.1243.static.theplanet.com.domain: 4615 [1au] AAAA? ns195.websitewelcome.com. (53)
15:21:06.889315 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 3766+ PTR? 177.54.18.67.in-addr.arpa. (43)
15:21:07.036629 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 3766 1/2/8 (252)
15:21:09.496398 IP hedgehog.linetec.nl.ipp > 255-55.bbned.dsl.internl.net.ipp: UDP, length 169
15:21:09.513428 IP vlan83.newxr2.nik-asd.internl.net > hedgehog.linetec.nl: ICMP host 255-55.bbned.dsl.internl.net unreachable, length 36
15:21:14.882303 IP hedgehog.linetec.nl.43734 > bugatti.websitewelcome.com.domain: 19492+ A? www.laptopjacks.co.uk. (39)
15:21:14.882955 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 32789+ PTR? 130.90.87.70.in-addr.arpa. (43)
15:21:15.030474 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 32789 1/2/8 (257)
15:21:18.894147 IP hedgehog.linetec.nl.38557 > ferrari.websitewelcome.com.domain: 49181 [1au] AAAA? ns195.websitewelcome.com. (53)
15:21:18.896960 IP hedgehog.linetec.nl.13224 > h.root-servers.net.domain: 63488% [1au] AAAA? ns1.websitewelcome.com. (51)
15:21:18.898550 IP hedgehog.linetec.nl.50779 > h.root-servers.net.domain: 60614% [1au] AAAA? ns2.websitewelcome.com. (51)
15:21:18.899484 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 336+ PTR? 53.2.63.128.in-addr.arpa. (42)
15:21:18.997484 IP h.root-servers.net.domain > hedgehog.linetec.nl.13224: 63488- 0/13/16 (539)
15:21:18.998932 IP h.root-servers.net.domain > hedgehog.linetec.nl.50779: 60614- 0/13/16 (539)
15:21:19.002068 IP hedgehog.linetec.nl.50523 > h.gtld-servers.net.domain: 52824% [1au] AAAA? ns1.websitewelcome.com. (51)
15:21:19.005697 IP hedgehog.linetec.nl.63693 > h.gtld-servers.net.domain: 9995% [1au] AAAA? ns2.websitewelcome.com. (51)
15:21:19.022758 IP h.gtld-servers.net.domain > hedgehog.linetec.nl.50523: 52824- 0/2/3 (115)
15:21:19.024869 IP hedgehog.linetec.nl.52380 > ferrari.websitewelcome.com.domain: 14684% [1au] AAAA? ns1.websitewelcome.com. (51)
15:21:19.026704 IP h.gtld-servers.net.domain > hedgehog.linetec.nl.63693: 9995- 0/2/3 (115)
15:21:19.028611 IP hedgehog.linetec.nl.64548 > ferrari.websitewelcome.com.domain: 61816% [1au] AAAA? ns2.websitewelcome.com. (51)
15:21:19.191832 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 336 1/3/0 PTR[|domain]
15:21:19.192892 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 36513+ PTR? 30.112.54.192.in-addr.arpa. (44)
15:21:19.394637 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 36513 1/7/7 (316)
15:21:19.883077 IP hedgehog.linetec.nl.43734 > bugatti.websitewelcome.com.domain: 19492+ A? www.laptopjacks.co.uk. (39)
15:21:24.884075 IP hedgehog.linetec.nl.43734 > bugatti.websitewelcome.com.domain: 19492+ A? www.laptopjacks.co.uk. (39)
15:21:32.029869 IP hedgehog.linetec.nl.46867 > b1.36.1243.static.theplanet.com.domain: 51239% [1au] AAAA? ns1.websitewelcome.com. (51)
15:21:32.031444 IP hedgehog.linetec.nl.23578 > b1.36.1243.static.theplanet.com.domain: 12427% [1au] AAAA? ns2.websitewelcome.com. (51)
15:21:37.029207 arp who-has 1-48.bbned.dsl.internl.net tell hedgehog.linetec.nl
15:21:37.085012 arp reply 1-48.bbned.dsl.internl.net is-at 00:13:19:bd:a6:a8 (oui Unknown)
15:21:40.498460 IP hedgehog.linetec.nl.ipp > 255-55.bbned.dsl.internl.net.ipp: UDP, length 169
15:21:40.515839 IP vlan83.newxr2.nik-asd.internl.net > hedgehog.linetec.nl: ICMP host 255-55.bbned.dsl.internl.net unreachable, length 36
15:21:45.035058 IP hedgehog.linetec.nl.34390 > ferrari.websitewelcome.com.domain: 9876% [1au] AAAA? ns1.websitewelcome.com. (51)
15:21:45.036387 IP hedgehog.linetec.nl.63736 > ferrari.websitewelcome.com.domain: 2839% [1au] AAAA? ns2.websitewelcome.com. (51)
15:21:49.174724 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 7534+ PTR? 215.88.95.82.in-addr.arpa. (43)
15:21:49.197564 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 7534 1/2/2 (138)
15:22:11.499440 IP hedgehog.linetec.nl.ipp > 255-55.bbned.dsl.internl.net.ipp: UDP, length 169
15:22:11.516265 IP vlan83.newxr2.nik-asd.internl.net > hedgehog.linetec.nl: ICMP host 255-55.bbned.dsl.internl.net unreachable, length 36

Enig idee wat dit zegt over wat er fout gaat?

Richard Rasker

[Wietse Muizelaar]

Post by Richard Rasker

Post by Wietse Muizelaar
Enige wat ik nog zou kunnen verzinnen is met wireshark/tcpdump
meespieken wat er op de lijn gebeurt aan DNS-verkeer...

Hm, ik ben hier niet bijster in thuis ... dus maar de hele dump van de dig-
;; global options: printcmd
;; connection timed out; no servers could be reached
# tcpdump -i eth1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
15:20:38.495388 IP hedgehog.linetec.nl.ipp > 255-55.bbned.dsl.internl.net.ipp: UDP, length 169
15:20:38.497628 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 486+ PTR? 255.55.254.92.in-addr.arpa. (44)
15:20:38.512542 IP vlan83.newxr2.nik-asd.internl.net > hedgehog.linetec.nl: ICMP host 255-55.bbned.dsl.internl.net unreachable, length 36
15:20:38.519665 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 486 1/2/2 (164)
15:20:38.520776 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 40809+ PTR? 6.192.149.217.in-addr.arpa. (44)
15:20:38.542889 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 40809 1/2/2 (157)
15:20:38.543702 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 9574+ PTR? 133.196.149.217.in-addr.arpa. (46)
15:20:38.567746 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 9574 1/2/2 (171)
15:20:43.494592 arp who-has 1-48.bbned.dsl.internl.net tell hedgehog.linetec.nl
15:20:43.496439 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 24291+ PTR? 1.48.254.92.in-addr.arpa. (42)
15:20:43.510644 arp reply 1-48.bbned.dsl.internl.net is-at 00:13:19:bd:a6:a8 (oui Unknown)
15:20:43.518996 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 24291 1/2/2 PTR[|domain]
15:20:54.882818 IP hedgehog.linetec.nl.10359 > ferrari.websitewelcome.com.domain: 30543 [1au] AAAA? ns195.websitewelcome.com. (53)
15:20:54.883684 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 45672+ PTR? 176.54.18.67.in-addr.arpa. (43)
15:20:55.031431 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 45672 1/2/8 (257)
15:21:05.944865 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 18679+ PTR? 59.37.247.121.in-addr.arpa. (44)
15:21:05.967079 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 18679 1/2/2 (180)
15:21:06.371624 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 15012+ PTR? 59.37.247.121.in-addr.arpa. (44)
15:21:06.394047 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 15012 1/2/2 (180)
15:21:06.394886 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 21285+[|domain]
15:21:06.686952 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 21285 NXDomain[|domain]
15:21:06.687553 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 22176+[|domain]
15:21:06.709403 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 22176 NXDomain[|domain]
15:21:06.888533 IP hedgehog.linetec.nl.27076 > b1.36.1243.static.theplanet.com.domain: 4615 [1au] AAAA? ns195.websitewelcome.com. (53)
15:21:06.889315 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 3766+ PTR? 177.54.18.67.in-addr.arpa. (43)
15:21:07.036629 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 3766 1/2/8 (252)
15:21:09.496398 IP hedgehog.linetec.nl.ipp > 255-55.bbned.dsl.internl.net.ipp: UDP, length 169
15:21:09.513428 IP vlan83.newxr2.nik-asd.internl.net > hedgehog.linetec.nl: ICMP host 255-55.bbned.dsl.internl.net unreachable, length 36
15:21:14.882303 IP hedgehog.linetec.nl.43734 > bugatti.websitewelcome.com.domain: 19492+ A? www.laptopjacks.co.uk. (39)
15:21:14.882955 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 32789+ PTR? 130.90.87.70.in-addr.arpa. (43)
15:21:15.030474 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 32789 1/2/8 (257)
15:21:18.894147 IP hedgehog.linetec.nl.38557 > ferrari.websitewelcome.com.domain: 49181 [1au] AAAA? ns195.websitewelcome.com. (53)
15:21:18.896960 IP hedgehog.linetec.nl.13224 > h.root-servers.net.domain: 63488% [1au] AAAA? ns1.websitewelcome.com. (51)
15:21:18.898550 IP hedgehog.linetec.nl.50779 > h.root-servers.net.domain: 60614% [1au] AAAA? ns2.websitewelcome.com. (51)
15:21:18.899484 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 336+ PTR? 53.2.63.128.in-addr.arpa. (42)
15:21:18.997484 IP h.root-servers.net.domain > hedgehog.linetec.nl.13224: 63488- 0/13/16 (539)
15:21:18.998932 IP h.root-servers.net.domain > hedgehog.linetec.nl.50779: 60614- 0/13/16 (539)
15:21:19.002068 IP hedgehog.linetec.nl.50523 > h.gtld-servers.net.domain: 52824% [1au] AAAA? ns1.websitewelcome.com. (51)
15:21:19.005697 IP hedgehog.linetec.nl.63693 > h.gtld-servers.net.domain: 9995% [1au] AAAA? ns2.websitewelcome.com. (51)
15:21:19.022758 IP h.gtld-servers.net.domain > hedgehog.linetec.nl.50523: 52824- 0/2/3 (115)
15:21:19.024869 IP hedgehog.linetec.nl.52380 > ferrari.websitewelcome.com.domain: 14684% [1au] AAAA? ns1.websitewelcome.com. (51)
15:21:19.026704 IP h.gtld-servers.net.domain > hedgehog.linetec.nl.63693: 9995- 0/2/3 (115)
15:21:19.028611 IP hedgehog.linetec.nl.64548 > ferrari.websitewelcome.com.domain: 61816% [1au] AAAA? ns2.websitewelcome.com. (51)
15:21:19.191832 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 336 1/3/0 PTR[|domain]
15:21:19.192892 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 36513+ PTR? 30.112.54.192.in-addr.arpa. (44)
15:21:19.394637 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 36513 1/7/7 (316)
15:21:19.883077 IP hedgehog.linetec.nl.43734 > bugatti.websitewelcome.com.domain: 19492+ A? www.laptopjacks.co.uk. (39)
15:21:24.884075 IP hedgehog.linetec.nl.43734 > bugatti.websitewelcome.com.domain: 19492+ A? www.laptopjacks.co.uk. (39)
15:21:32.029869 IP hedgehog.linetec.nl.46867 > b1.36.1243.static.theplanet.com.domain: 51239% [1au] AAAA? ns1.websitewelcome.com. (51)
15:21:32.031444 IP hedgehog.linetec.nl.23578 > b1.36.1243.static.theplanet.com.domain: 12427% [1au] AAAA? ns2.websitewelcome.com. (51)
15:21:37.029207 arp who-has 1-48.bbned.dsl.internl.net tell hedgehog.linetec.nl
15:21:37.085012 arp reply 1-48.bbned.dsl.internl.net is-at 00:13:19:bd:a6:a8 (oui Unknown)
15:21:40.498460 IP hedgehog.linetec.nl.ipp > 255-55.bbned.dsl.internl.net.ipp: UDP, length 169
15:21:40.515839 IP vlan83.newxr2.nik-asd.internl.net > hedgehog.linetec.nl: ICMP host 255-55.bbned.dsl.internl.net unreachable, length 36
15:21:45.035058 IP hedgehog.linetec.nl.34390 > ferrari.websitewelcome.com.domain: 9876% [1au] AAAA? ns1.websitewelcome.com. (51)
15:21:45.036387 IP hedgehog.linetec.nl.63736 > ferrari.websitewelcome.com.domain: 2839% [1au] AAAA? ns2.websitewelcome.com. (51)
15:21:49.174724 IP hedgehog.linetec.nl.4734 > resolve20.dns.internl.net.domain: 7534+ PTR? 215.88.95.82.in-addr.arpa. (43)
15:21:49.197564 IP resolve20.dns.internl.net.domain > hedgehog.linetec.nl.4734: 7534 1/2/2 (138)
15:22:11.499440 IP hedgehog.linetec.nl.ipp > 255-55.bbned.dsl.internl.net.ipp: UDP, length 169
15:22:11.516265 IP vlan83.newxr2.nik-asd.internl.net > hedgehog.linetec.nl: ICMP host 255-55.bbned.dsl.internl.net unreachable, length 36
Enig idee wat dit zegt over wat er fout gaat?

Euhm.... nee, sorry :) Ik zie wel dingen, maar zie ook allemaal dingen
die waarschijnlijk eruitgefilterd moeten worden, maar kan dat niet
volledig gokken. Ik wil wel even in een dump-file voor je gaan spitten
of ik wat kan vinden, maar dan moet je 'm even opnieuw doen, en dan met
wireshark/tshark (tshark -i eth1 -w dump.foo), en dan even laten weten
waar die file staat. Dan kan ik er hopelijk wat meer voor je over zeggen
:)

[Richard Rasker]

[knip uitvoer van tcpdump]

Post by Wietse Muizelaar

Post by Richard Rasker
Enig idee wat dit zegt over wat er fout gaat?

Euhm.... nee, sorry :) Ik zie wel dingen, maar zie ook allemaal dingen
die waarschijnlijk eruitgefilterd moeten worden, maar kan dat niet
volledig gokken. Ik wil wel even in een dump-file voor je gaan spitten
of ik wat kan vinden, maar dan moet je 'm even opnieuw doen, en dan met
wireshark/tshark (tshark -i eth1 -w dump.foo), en dan even laten weten
waar die file staat. Dan kan ik er hopelijk wat meer voor je over zeggen
:)

Dat zou aardig zijn; ik wil nou toch wel eens weten wat hier gebeurt -- en
wellicht ook wat meer opsteken over de analyse van netwerkverkeer ;-)

http://www.linetec.nl/linux/tshark.dump

Er lijkt nog wel enige vervuiling in deze info te staan -- zo zie ik wat
verkeer van de printserver, maar dat is bijna onvermijdelijk, omdat de
machine wordt gebruikt als server-voor-alles.
Het overgrote deel zou echter betrekking moeten hebben op deze opdracht,
uitgevoerd vanaf de client:
dig www.laptopjacks.co.uk @ns195.websitewelcome.com

Alvast mijn dank voor de moeite!

Richard Rasker

[Wietse Muizelaar]

Post by Richard Rasker
[knip uitvoer van tcpdump]

Post by Wietse Muizelaar

Post by Richard Rasker
Enig idee wat dit zegt over wat er fout gaat?

Euhm.... nee, sorry :) Ik zie wel dingen, maar zie ook allemaal dingen
die waarschijnlijk eruitgefilterd moeten worden, maar kan dat niet
volledig gokken. Ik wil wel even in een dump-file voor je gaan spitten
of ik wat kan vinden, maar dan moet je 'm even opnieuw doen, en dan met
wireshark/tshark (tshark -i eth1 -w dump.foo), en dan even laten weten
waar die file staat. Dan kan ik er hopelijk wat meer voor je over zeggen
:)

Dat zou aardig zijn; ik wil nou toch wel eens weten wat hier gebeurt -- en
wellicht ook wat meer opsteken over de analyse van netwerkverkeer ;-)
http://www.linetec.nl/linux/tshark.dump
Er lijkt nog wel enige vervuiling in deze info te staan -- zo zie ik wat
verkeer van de printserver, maar dat is bijna onvermijdelijk, omdat de
machine wordt gebruikt als server-voor-alles.
Het overgrote deel zou echter betrekking moeten hebben op deze opdracht,
Alvast mijn dank voor de moeite!

Geen dank. Ik zie inderdaad dat er wel verkeer naar hun nameserver
toegestuurd wordt; maar dat er simpelweg niets terugkomt. Helemaal
niets.

Ik zie een aantal queries voorbijkomen; met hun antwoorden. Je hebt een
mooie wireshark-gui (op fedora het wireshark-gnome-pakket), en als je
daarmee deze file opent kun je meekijken met wat er gebeurt, en op een
best overzichtelijke manier. Zo zie je bij nr. 6 dat er een query gedaan
wordt voor het AAAA-record van ns1.websitewelcome.com; bij 198.41.0.4,
een root-server. In nr 8 komt het antwoord daarop binnen, en die zeggen:
zoek het op bij <iets>gtld-servers.net. Vervolgens zie je ook dat daarna
de boel opgevraagd wordt bij a.gtld-servers.net, een logische stap.
(nr's 10 - 12; en voor ns2 is dat 11-14). In dat antwoord staat ook weer
dat je door moet vragen bij ns1.websitewelcome.com; met het ip
67.18.54.176. En dan zie je dat er alleen maar vragen gesteld worden;
maar geen antwoorden meer terugkomen. Oftewel: het verdwijnt daar
ergens.

Wat me wel opvalt is dat er veel AAAA-records opgevraagd worden; en geen
A-records. Als ik een query van mijzelf opvraag, dan zie ik dat-ie eerst
AAAA probeert, daar een 'nah' op terugkrijgt, en vervolgens een A
probeert op te vragen. Maar nou is de situatie wellicht verschillend: ik
zit het vanaf mijn laptopje te proberen (die een ipv6-tunnel heeft), en
dat laptopje hangt achter NAT (speedtouch-modem).

[Richard Rasker]

Post by Wietse Muizelaar

Post by Richard Rasker
http://www.linetec.nl/linux/tshark.dump

Geen dank. Ik zie inderdaad dat er wel verkeer naar hun nameserver
toegestuurd wordt; maar dat er simpelweg niets terugkomt. Helemaal
niets.
Ik zie een aantal queries voorbijkomen; met hun antwoorden. Je hebt een
mooie wireshark-gui (op fedora het wireshark-gnome-pakket),

Ik heb onder Mandriva iets gevonden en geïnstalleerd dat wireshark-tools
heet -- maar nog niks GUI-achtigs gevonden om e.e.a. te bekijken. Naja, nog
maar even goed zoeken.

Post by Wietse Muizelaar
en als je
daarmee deze file opent kun je meekijken met wat er gebeurt, en op een
best overzichtelijke manier. Zo zie je bij nr. 6 dat er een query gedaan
wordt voor het AAAA-record van ns1.websitewelcome.com; bij 198.41.0.4,
zoek het op bij <iets>gtld-servers.net. Vervolgens zie je ook dat daarna
de boel opgevraagd wordt bij a.gtld-servers.net, een logische stap.
(nr's 10 - 12; en voor ns2 is dat 11-14). In dat antwoord staat ook weer
dat je door moet vragen bij ns1.websitewelcome.com; met het ip
67.18.54.176. En dan zie je dat er alleen maar vragen gesteld worden;
maar geen antwoorden meer terugkomen. Oftewel: het verdwijnt daar
ergens.

Raar. Zou er wellicht sprake van zijn dat ik in een netwerksegment zit dat
ergens geblokkeerd is?

Post by Wietse Muizelaar
Wat me wel opvalt is dat er veel AAAA-records opgevraagd worden; en geen
A-records. Als ik een query van mijzelf opvraag, dan zie ik dat-ie eerst
AAAA probeert, daar een 'nah' op terugkrijgt, en vervolgens een A
probeert op te vragen. Maar nou is de situatie wellicht verschillend: ik
zit het vanaf mijn laptopje te proberen (die een ipv6-tunnel heeft), en
dat laptopje hangt achter NAT (speedtouch-modem).

Tja, daar heb ik nog geen kaas van gegeten. In ieder geval dank tot zover;
kennelijk gebeurt er dus iets raars aan de kant van de DNS-servers waar ik
niet zo veel aan kan doen.

Richard Rasker

[Wietse Muizelaar]

Post by Richard Rasker

Post by Wietse Muizelaar

Post by Richard Rasker
http://www.linetec.nl/linux/tshark.dump

Geen dank. Ik zie inderdaad dat er wel verkeer naar hun nameserver
toegestuurd wordt; maar dat er simpelweg niets terugkomt. Helemaal
niets.
Ik zie een aantal queries voorbijkomen; met hun antwoorden. Je hebt een
mooie wireshark-gui (op fedora het wireshark-gnome-pakket),

Ik heb onder Mandriva iets gevonden en geïnstalleerd dat wireshark-tools
heet -- maar nog niks GUI-achtigs gevonden om e.e.a. te bekijken. Naja, nog
maar even goed zoeken.

Ok.

Post by Richard Rasker

Post by Wietse Muizelaar
en als je
daarmee deze file opent kun je meekijken met wat er gebeurt, en op een
best overzichtelijke manier. Zo zie je bij nr. 6 dat er een query gedaan
wordt voor het AAAA-record van ns1.websitewelcome.com; bij 198.41.0.4,
zoek het op bij <iets>gtld-servers.net. Vervolgens zie je ook dat daarna
de boel opgevraagd wordt bij a.gtld-servers.net, een logische stap.
(nr's 10 - 12; en voor ns2 is dat 11-14). In dat antwoord staat ook weer
dat je door moet vragen bij ns1.websitewelcome.com; met het ip
67.18.54.176. En dan zie je dat er alleen maar vragen gesteld worden;
maar geen antwoorden meer terugkomen. Oftewel: het verdwijnt daar
ergens.

Raar. Zou er wellicht sprake van zijn dat ik in een netwerksegment zit dat
ergens geblokkeerd is?

Dat lijkt haast wel het geval ja. Dat kun je nog weer elimineren door
die client via een andere aansluiting te laten query-en; maar dat
behelst wellicht fysiek verplaatsen, niet altijd even handig.

Post by Richard Rasker

Post by Wietse Muizelaar
Wat me wel opvalt is dat er veel AAAA-records opgevraagd worden; en geen
A-records. Als ik een query van mijzelf opvraag, dan zie ik dat-ie eerst
AAAA probeert, daar een 'nah' op terugkrijgt, en vervolgens een A
probeert op te vragen. Maar nou is de situatie wellicht verschillend: ik
zit het vanaf mijn laptopje te proberen (die een ipv6-tunnel heeft), en
dat laptopje hangt achter NAT (speedtouch-modem).

Tja, daar heb ik nog geen kaas van gegeten. In ieder geval dank tot zover;
kennelijk gebeurt er dus iets raars aan de kant van de DNS-servers waar ik
niet zo veel aan kan doen.

Daar lijkt het wel op; meer dan dat kan ik er ook niet van maken. Geen
dank, verder.

[Richard Rasker]

Post by Wietse Muizelaar

Post by Richard Rasker
Raar. Zou er wellicht sprake van zijn dat ik in een netwerksegment zit
dat ergens geblokkeerd is?

Dat lijkt haast wel het geval ja. Dat kun je nog weer elimineren door
die client via een andere aansluiting te laten query-en; maar dat
behelst wellicht fysiek verplaatsen, niet altijd even handig.

Ik heb ssh-toegang tot meerdere firewalls en servers op allerlei plaatsen,
en geen van die machines vertoont zo te zien deze kuren. Het enige wat ik
niet kan testen, is een query vanaf een ander adres op hetzelfde
netwerksegment. Ik zal morgen wel even bij de netwerkprovider vragen of ze
e.e.a. kunnen nalopen.
Of is er een vlotte manier om na te trekken of het segment 92.254.48.0 -
92.254.55.255 ergens in een openbare bloklijst staat/stond?

Richard Rasker

[Ruben van der Leij]

Post by Richard Rasker
Of is er een vlotte manier om na te trekken of het segment 92.254.48.0 -
92.254.55.255 ergens in een openbare bloklijst staat/stond?

Het zou kunnen dat je nog ergens op een antiek exemplaar van een bogon-lijst
staat. http://www.cymru.com/Documents/bogon-list.html

Je zou dat met een traceroute naar de nameserver in kwestie moeten kunnen
achterhalen. Degene die stopt met antwoorden op je packets loopt achter.

[Richard Rasker]

Post by Ruben van der Leij

Post by Richard Rasker
Of is er een vlotte manier om na te trekken of het segment 92.254.48.0 -
92.254.55.255 ergens in een openbare bloklijst staat/stond?

Het zou kunnen dat je nog ergens op een antiek exemplaar van een
bogon-lijst staat. http://www.cymru.com/Documents/bogon-list.html

Hm, hier kan ik niet veel mee aanvangen. Ik zie nergens verwijzingen naar
bloklijsten.

Post by Ruben van der Leij
Je zou dat met een traceroute naar de nameserver in kwestie moeten kunnen
achterhalen. Degene die stopt met antwoorden op je packets loopt achter.

De traceroute naar ns1.websitewelcome.com doet het uiteraard niet, want
de resolving van deze host werkt niet vanaf hier. De traceroute naar het
IP-adres 67.18.54.176 strandt na de zestiende hop:

# traceroute 67.18.54.176
traceroute to 67.18.54.176 (67.18.54.176), 30 hops max, 38 byte packets
1 fw (192.168.1.1) 0.419 ms 0.241 ms 0.191 ms
2 1-48.bbned.dsl.internl.net (92.254.48.1) 15.311 ms 15.552 ms 14.771 ms
3 vlan83.newxr2.nik-asd.internl.net (217.149.196.133) 15.987 ms 15.274 ms 15.906 ms
4 K440.internlnet.ams1.nl.above.net (82.98.254.221) 15.574 ms 16.006 ms 15.649 ms
5 ge-3-0-0.mpr1.ams1.nl.above.net (64.125.26.82) 16.137 ms 16.940 ms 16.372 ms
6 so-0-0-0.mpr2.ams5.nl.above.net (64.125.26.46) 16.033 ms 16.711 ms 17.159 ms
7 so-2-0-0.mpr1.lhr2.uk.above.net (64.125.27.177) 29.819 ms 30.119 ms 29.819 ms
8 so-0-1-0.mpr1.dca2.us.above.net (64.125.27.57) 101.513 ms 102.154 ms 103.353 ms
9 so-1-0-0.mpr3.iah1.us.above.net (64.125.29.37) 129.370 ms 129.063 ms 128.608 ms
10 xe-1-1-0.er1.iah1.above.net (64.125.26.222) 128.488 ms 128.538 ms 128.362 ms
11 209.66.99.94.available.above.net (209.66.99.94) 141.135 ms 138.651 ms 138.145 ms
12 et5-4.ibr04.dllstx3.theplanet.com (70.87.253.53) 133.522 ms 133.774 ms 133.195 ms
13 te9-2.dsr01.dllstx3.theplanet.com (70.87.253.14) 133.532 ms 133.064 ms te7-2.dsr01.dllstx3.theplanet.com (70.87.253.10) 133.236 ms
14 te1-4.dsr01.dllstx2.theplanet.com (70.87.253.114) 133.995 ms 134.158 ms te3-3.dsr02.dllstx2.theplanet.com (70.87.253.126) 133.833 ms
15 vl2.asr01.dllstx2.theplanet.com (12.96.160.58) 133.695 ms 134.174 ms 133.488 ms
16 gi0-2.car16.dllstx2.theplanet.com (69.41.250.78) 133.652 ms 134.175 ms 134.122 ms
17 * * *
18 * * *
19 * * *

Het wordt echter nog wat interessanter. Dit is wat er gebeurt als ik vanaf een
andere host (die host ns1.websitewelcome.com wel gewoon kan terugvinden) een
traceroute naar deze nameserver uitvoer:

# traceroute ns1.websitewelcome.com
traceroute to ns1.websitewelcome.com (67.18.54.176), 30 hops max, 38 byte packets
1 212.238.235.1 (212.238.235.1) 9.626 ms 9.940 ms 9.541 ms
2 0.ge-3-1-0.xr3.3d12.xs4all.net (194.109.7.125) 10.448 ms 9.919 ms 9.238 ms
3 0.so-7-0-0.xr1.sara.xs4all.net (194.109.5.6) 11.013 ms 9.973 ms 9.814 ms
4 k701.pni-xs4all.ams1.nl.above.net (62.93.194.145) 10.606 ms 11.841 ms 9.818 ms
5 ge-3-0-0.mpr1.ams1.nl.above.net (64.125.26.82) 11.419 ms 10.567 ms 10.269 ms
6 so-0-0-0.mpr2.ams5.nl.above.net (64.125.26.46) 11.803 ms 11.007 ms 10.929 ms
7 so-2-0-0.mpr1.lhr2.uk.above.net (64.125.27.177) 25.324 ms 24.357 ms 23.833 ms
8 so-0-1-0.mpr1.dca2.us.above.net (64.125.27.57) 94.116 ms 94.579 ms 94.909 ms
9 so-1-0-0.mpr3.iah1.us.above.net (64.125.29.37) 121.497 ms 127.316 ms 124.062 ms
10 xe-1-1-0.er1.iah1.above.net (64.125.26.222) 121.307 ms 127.851 ms 128.646 ms
11 209.66.99.94.available.above.net (209.66.99.94) 132.311 ms 132.127 ms 131.002 ms
12 et5-4.ibr04.dllstx3.theplanet.com (70.87.253.53) 131.855 ms 132.647 ms 131.052 ms
13 te9-2.dsr02.dllstx3.theplanet.com (70.87.253.30) 132.112 ms 132.231 ms te7-2.dsr02.dllstx3.theplanet.com (70.87.253.26) 130.936 ms
14 te1-3.dsr02.dllstx2.theplanet.com (70.87.253.122) 133.124 ms 132.409 ms 76.fd.5746.static.theplanet.com (70.87.253.118) 131.220 ms
15 vl1.asr01.dllstx2.theplanet.com (12.96.160.26) 132.887 ms 131.776 ms 131.531 ms
16 gi0-2.car16.dllstx2.theplanet.com (69.41.250.78) 132.427 ms 132.393 ms 131.310 ms
17 * * *
18 * * *
19 * * *
20 * * *

Met andere woorden: de server reageert op ping, is echter niet vindbaar via
traceroute ongeacht het netwerk, en reageert niet op DNS-query's vanaf
bepaalde netwerken. Ik begrijp er hoe langer hoe minder van.

Naja, ik denk dat ik het hierbij laat. Kennelijk heeft ns1.websitewelcome.com
zijn zaakjes niet op orde.

Richard Rasker

[Ruben van der Leij]

Post by Richard Rasker

Post by Ruben van der Leij
Het zou kunnen dat je nog ergens op een antiek exemplaar van een
bogon-lijst staat. http://www.cymru.com/Documents/bogon-list.html

Hm, hier kan ik niet veel mee aanvangen. Ik zie nergens verwijzingen naar
bloklijsten.

Een bogon-lijst is een lijst van routes die je normaal gesproken niet zou
mogen zien in de BGP van je peers. Dus: routes voor 10/8, 172.16/16 en
192.168/16, maar ook niet-toegewezen en gereserveerde blokken adresruimte.

Omdat 92.254/16 redelijk recent in gebruik lijkt genomen te zijn kan het
zijn dat iemand tussen jou en de nameserver dat verkeer dropt op grond van
een oude bogon-lijst.

[Martijn Lievaart]

Post by Ruben van der Leij
Een bogon-lijst is een lijst van routes die je normaal gesproken niet
zou mogen zien in de BGP van je peers. Dus: routes voor 10/8, 172.16/16
en 192.168/16, maar ook niet-toegewezen en gereserveerde blokken
adresruimte.

ITYM 172.16/12.

M4

[Richard Rasker]

[knip resolving van bepaalde adressen werkt niet]

Post by Richard Rasker

Post by Wietse Muizelaar
Misschien iets met UDP versus TCP poort 53? Ik heb daar wel 'ns rare
dingen mee gezien. Met 'dig' kun je opties als +tcp en +notcp meegeven
om een bepaald protocol te forceren; en dan kijken of je dit hiermee
kunt reproduceren.

Mnee, dig ziet niets vanaf het LAN, en alles vanaf de firewallmachine,
ongeacht welk protocol ik forceer. Hoe kan een protocolkeuze trouwens
invloed hebben op bepaalde URL's en niet op andere?

Nog even een andere machine opgestart, en het wordt nog raadselachtiger: het
is vooralsnog slechts één client die dit merkwaardige gedrag vertoont; het
lijkt dus toch niet zozeer in de caching DNS-server zelf te zitten.

Overigens is er ook iets merkwaardigs met de website zelf aan de hand;
www.laptopjacks.co.uk zou IP-adres 70.87.90.130 moeten hebben, maar een
wget op dit adres (of invullen in Firefox) geeft hier een 404-foutmelding.
Zou dit laatste er iets mee te maken kunnen hebben? Nog even voor de
volledigheid: er draait geen firewall op de gewraakte machine, dus dat kan
het niet zijn.

Richard Rasker

[Wietse Muizelaar]

Post by Richard Rasker
[knip resolving van bepaalde adressen werkt niet]

Post by Richard Rasker

Post by Wietse Muizelaar
Misschien iets met UDP versus TCP poort 53? Ik heb daar wel 'ns rare
dingen mee gezien. Met 'dig' kun je opties als +tcp en +notcp meegeven
om een bepaald protocol te forceren; en dan kijken of je dit hiermee
kunt reproduceren.

Mnee, dig ziet niets vanaf het LAN, en alles vanaf de firewallmachine,
ongeacht welk protocol ik forceer. Hoe kan een protocolkeuze trouwens
invloed hebben op bepaalde URL's en niet op andere?

Nog even een andere machine opgestart, en het wordt nog raadselachtiger: het
is vooralsnog slechts één client die dit merkwaardige gedrag vertoont; het
lijkt dus toch niet zozeer in de caching DNS-server zelf te zitten.

Ok. Draait er ngo een of ander dns-caching-mechanisme op die host? Rare
entries in /etc/hosts ofzo?

Post by Richard Rasker
Overigens is er ook iets merkwaardigs met de website zelf aan de hand;
www.laptopjacks.co.uk zou IP-adres 70.87.90.130 moeten hebben, maar een
wget op dit adres (of invullen in Firefox) geeft hier een 404-foutmelding.
Zou dit laatste er iets mee te maken kunnen hebben? Nog even voor de
volledigheid: er draait geen firewall op de gewraakte machine, dus dat kan
het niet zijn.

Dat dat ip-adres niet hetzelfde resultaat geeft als
www.laptopjacks.co.uk, is vrij simpel te verklaren: dan werken ze met
name based virtual hosting. Oftewel: meerdere urls op 1 ip-adres.