Wat is er toch aan de hand met de nameservers van Chello?

[Erik Hensema]

Hoi,

Wat hebben de mensen van Chello toch uitgespookt met hun nameservers? Ze
waren al berucht omdat ze zo achterlopen bij een verhuizing van een domein,
en ik merk dat dus nu ook.

Concreet gaat het om onder andere hostingxs.nl:
erik@gargamel:~> whois hostingxs.nl
[...]

Domain nameservers:
ns1.hostingxs.nl 81.17.51.100
ns2.hostingxs.nl 81.17.51.2
[...]
Record last updated: 19-02-2003

De reload bij SIDN was dus op 20-03-2003, met een TTL van 4 dagen (wat sidn
gebruikt), moet de verhuizing dus op 23-03-2003 rond zijn.

Nu, 6 dagen nadien:

erik@gargamel:~> dig ns hostingxs.nl @ns1.upc.nl
;; ANSWER SECTION:
hostingxs.nl. 69812 IN NS ns1.psdesign.nl.
hostingxs.nl. 69812 IN NS ns2.psdesign.nl.

Die TTL klopt gewoon: in de NS van psdesign.nl staat die op 1 dag.

Heeft iemand enig idee wat Chello voor iets vreselijk ranzigs heeft
uitgespookt met hun nameserver? Ikzelf heb het sterke gevoel dat ze de TTL
van NS records intern flink verhogen, zonder dat extern aan te kondigen.
Het ontgaat me volkomen wat voor nut dat heeft.

--
Erik Hensema (erik@hensema.net) ICQ# 8280101
"I'm willing to sacrifice anything for this cause, even other people's
lives"

[Julius]

With more on that story, here's correspondent *Erik Hensema*:

> Wat hebben de mensen van Chello toch uitgespookt met hun nameservers? Ze
> waren al berucht omdat ze zo achterlopen bij een verhuizing van een domein,
> en ik merk dat dus nu ook.

Krijg jij geen toegang meer voor queries op 62.108.1.65 en 62.108.1.66 ?
Die 2 lopen namelijk wel redelijk netjes mee met de rest...

[Martijn Loots]

Erik Hensema <usenet@smac.hensema.net> once wrote:

> Wat hebben de mensen van Chello toch uitgespookt met hun nameservers? Ze
> waren al berucht omdat ze zo achterlopen bij een verhuizing van een domein,
> en ik merk dat dus nu ook.

> De reload bij SIDN was dus op 20-03-2003, met een TTL van 4 dagen (wat sidn
> gebruikt), moet de verhuizing dus op 23-03-2003 rond zijn.

> Nu, 6 dagen nadien:

Wel, als je dit serieus meent, dan zou het een soort van
voorzienigheid zijn als Chello inmiddels "up-to-date" is...

Tip: het is nog maar _net_ maart 2003 eigenlijk ... ;-)))

--
-Martijn @..@ ( Martijn Loots - Hengelo [NL] )
(`--') ( martijn@cosix.com - www.cosix.com )
( >__< ) --------------------------------------
^^^ ^^^ ( Highspeed Internet: Linux@7M8 ADSL )

[Hans Wolters]

On Sat, 1 Mar 2003 19:30:32 +0000 (UTC), Erik Hensema <usenet@smac.hensema.net> wrote:
> Hoi,
>
> Wat hebben de mensen van Chello toch uitgespookt met hun nameservers? Ze
> waren al berucht omdat ze zo achterlopen bij een verhuizing van een domein,
> en ik merk dat dus nu ook.

De nameservers van chello zijn idd raar:

dig ns hostingxs.nl

....

;; ANSWER SECTION:
hostingxs.nl. 157939 IN NS ns1.hostingxs.nl.
hostingxs.nl. 157939 IN NS ns2.hostingxs.nl.

dig ns hostingxs.nl @ns1.upc.nl

;; ANSWER SECTION:
hostingxs.nl. 81237 IN NS ns2.psdesign.nl.
hostingxs.nl. 81237 IN NS ns1.psdesign.nl.

En ik zit toch echt bij chello:

host 212.83.68.130
130.68.83.212.in-addr.arpa domain name pointer ns01.chello.nl.

de andere nameservers van chello zijn hier nu niet te vinden....

Hans


--
Ik wil http://www.linux.nl wel overnemen voor het symbolische bedrag
van 1 EURO.

[Jurjen Oskam]

In article <slrnb622in.6n6.usenet@dexter.hensema.net>, Erik Hensema wrote:

> erik@gargamel:~> dig ns hostingxs.nl @ns1.upc.nl
> ;; ANSWER SECTION:
> hostingxs.nl. 69812 IN NS ns1.psdesign.nl.
> hostingxs.nl. 69812 IN NS ns2.psdesign.nl.
>
> Die TTL klopt gewoon: in de NS van psdesign.nl staat die op 1 dag.

Hm, diezelfde query nu net uitgevoerd geeft:

joskam@calvin:~> dnsq ns hostingxs.nl ns1.upc.nl
2 hostingxs.nl:
107 bytes, 1+2+0+2 records, response, weird ra, noerror
query: 2 hostingxs.nl
answer: hostingxs.nl 83137 NS ns1.psdesign.nl
answer: hostingxs.nl 83137 NS ns2.psdesign.nl
additional: ns1.psdesign.nl 33160 A 80.247.199.3
additional: ns2.psdesign.nl 2930 A 80.247.198.3

.... dus een TTL *hoger* dan wat jij zag.

En weer dezelfde query een half uur later:

joskam@calvin:~> dnsq ns hostingxs.nl 80.247.199.3
skam@calvin:~> dnsq ns hostingxs.nl ns1.upc.nl
2 hostingxs.nl:
107 bytes, 1+2+0+2 records, response, weird ra, noerror
query: 2 hostingxs.nl
answer: hostingxs.nl 85298 NS ns2.psdesign.nl
answer: hostingxs.nl 85298 NS ns1.psdesign.nl
additional: ns1.psdesign.nl 30163 A 80.247.199.3
additional: ns2.psdesign.nl 86336 A 81.17.51.2

.... *weer* met een hogere TTL.


Het lijkt erop dat ns1.upc.nl geen veilig algoritme volgt, of zelf
een cache gebruikt die geen veilig algoritme gebruikt. ns1.upc.nl
lijkt geen BIND te zijn (geen kunstmatige verlaging van de TTL gezien),
wellicht is het een Microsoft DNS server die het vinkje "Secure DNS
resolving" (of hoe dat dan ook precies heet) niet aan heeft staan.
(wat onbegrijpelijk genoeg de standaardinstelling is!)

--
Jurjen Oskam

PGP Key available at http://www.stupendous.org/

[Ruben van der Leij]

begin quotations from: Jurjen Oskam <joskam@quadpro.stupendous.org>:

>wellicht is het een Microsoft DNS server die het vinkje "Secure DNS
>resolving" (of hoe dat dan ook precies heet) niet aan heeft staan.

Dat doet alleen iets met de source-port van de query. >1024 of port 53. Dat
zou nul invloed op ander gedrag van de nameserver moeten hebben.

--
Ruben van der Leij

today, n.:
A nice place to visit, but you can't stay here for long.

[Jurjen Oskam]

In article <slrnb652f3.gm5.ruben-news@its.blacklisted.nl>, Ruben van der Leij wrote:

>>wellicht is het een Microsoft DNS server die het vinkje "Secure DNS
>>resolving" (of hoe dat dan ook precies heet) niet aan heeft staan.
>
> Dat doet alleen iets met de source-port van de query. >1024 of port 53. Dat
> zou nul invloed op ander gedrag van de nameserver moeten hebben.

Da's niet waar. Ik heb het even nagekeken, en het vinkje heet "Secure cache
against pollution". Als dit vinkje niet aanstaat (en dat staat het standaard
niet!) dan accepteert de cache poison.

--
Jurjen Oskam

PGP Key available at http://www.stupendous.org/

[Ruben van der Leij]

begin quotations from: Jurjen Oskam <joskam@quadpro.stupendous.org>:

>>>wellicht is het een Microsoft DNS server die het vinkje "Secure DNS
>>>resolving" (of hoe dat dan ook precies heet) niet aan heeft staan.

>> Dat doet alleen iets met de source-port van de query. >1024 of port 53. Dat
>> zou nul invloed op ander gedrag van de nameserver moeten hebben.

>Da's niet waar. Ik heb het even nagekeken, en het vinkje heet "Secure cache
>against pollution". Als dit vinkje niet aanstaat (en dat staat het standaard
>niet!) dan accepteert de cache poison.

Jouw eerste omschrijving wees een andere kant op. Gelukkig weet ik niets van
Microsoft DNS, dat is wel bewezen.

--
Ruben van der Leij

today, n.:
A nice place to visit, but you can't stay here for long.

[Erik Hensema]

Jurjen Oskam (joskam@quadpro.stupendous.org) wrote:
> In article <slrnb652f3.gm5.ruben-news@its.blacklisted.nl>, Ruben van der Leij wrote:
>
>>>wellicht is het een Microsoft DNS server die het vinkje "Secure DNS
>>>resolving" (of hoe dat dan ook precies heet) niet aan heeft staan.
>>
>> Dat doet alleen iets met de source-port van de query. >1024 of port 53. Dat
>> zou nul invloed op ander gedrag van de nameserver moeten hebben.
>
> Da's niet waar. Ik heb het even nagekeken, en het vinkje heet "Secure cache
> against pollution". Als dit vinkje niet aanstaat (en dat staat het standaard
> niet!) dan accepteert de cache poison.

Wat brak :-( Ik dacht dat elke huidige nameservers wel standaard beveiligd
was tegen poison. Gelukkig heb ik nu de upc-nameserver via dezelfde weg
vergiftigd met de juiste nameservers ;-)

--
Erik Hensema (erik@hensema.net) ICQ# 8280101
Please note that my From: field is spamtrapped.

[Jurjen Oskam]

In article <slrnb66qf3.1f8.usenet@bender.home.hensema.net>, Erik Hensema wrote:

> Wat brak :-( Ik dacht dat elke huidige nameservers wel standaard beveiligd
> was tegen poison.

Het leuke is ook dat als je de helptekst van die optie leest, dan zeggen ze dat
het sneller is als het uitstaat, en omdat Windows 2000 DNS servers nooit poison
sturen het eigenlijk niet zo'n probleem is.

Die optie zit uiteraard vervolgens diep begraven, en staat standaard uit...

Ik snap werkelijk niet waarom Microsoft dat zo gedaan heeft. Dat je het dan
perse een keuze wil maken, nou, okee dan, misschien, MAAR DAT JE HEM DAN
STANDAARD ZO LEK ALS EEN MANDJE MAAKT??!?!

--
Jurjen Oskam

PGP Key available at http://www.stupendous.org/

[Julius]

With more on that story, here's correspondent *Jurjen Oskam*:

> Ik snap werkelijk niet waarom Microsoft dat zo gedaan heeft. Dat je het dan
> perse een keuze wil maken, nou, okee dan, misschien, MAAR DAT JE HEM DAN
> STANDAARD ZO LEK ALS EEN MANDJE MAAKT??!?!

Dat is omdat dit type DNS meestal gebruikt zal worden (target audience)
op kleine schaal en *binnen* de muren van een kantoor of bedrijf.
Dan vind ik het namelijk ook wel handig om wat poison te kunnen hanteren.
Als je MS DNS in een pro omgeving wilt inzetten, dan zul je, net als
wanneer je een unix DNS configged, de readme eerst moeten raadplegen
voor een optimale configuratie. Jouw foute veronderstelling in dezen
is die van veel admins die Microsoft op hoog niveau willen inzetten,
namelijk dat je, als het van Microsoft komt, dan niet evenveel tijd
kwijt zult zijn als wanneer je andere operating systems gebruikt.

Dat 'zo lek als een mandje' valt trouwens alleszins mee met MS DNS,
ik gebruik het al jaren op een werkplek, erg handig met veel namen zonder
TLD erin die verwijzen naar lange urls enzo, draaiend naast de lokale PDC.
--
Julius
http://jult.net http://jthz.com http://mixfreaks.net http://bn.nl