PDA

Bekijk Volledige Versie : PI update jullie DNS eens !



Ideefixx
06/11/03, 16:15
Planet Internet is altijd zeer laat om hun dns up te daten als het gaat over
domeinnamen die van hun weg gaan he.
Dus PI update jullie DNS !! Ik ga eens zien als waar zal zijn .....

frank@openminds.be
06/11/03, 17:30
Ideefixx <ideefixx@hotmail.com.invalid> wrote:
> Planet Internet is altijd zeer laat om hun dns up te daten als het gaat over
> domeinnamen die van hun weg gaan he.
> Dus PI update jullie DNS !! Ik ga eens zien als waar zal zijn .....

wat dus erger is, is dat hun caching nameservers voor hun klanten dus
dezelfde zijn als hun authorative nameservers (of dat ze hun auth zones
repliceren op hun caching nameservers). Very evil. Very bad. Very Not
Done(tm).


Vriendelijke groeten,
Frank Louwers

--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

dfg
06/11/03, 17:30
"Ideefixx" <ideefixx@hotmail.com.invalid> schreef in bericht
news:3faa6537$0$30700$ba620e4c@reader1.news.skynet .be...
<KNIP>
> Dus PI update jullie DNS !! Ik ga eens zien als waar zal zijn .....

En nu nog eens in het Nederlands aub.

xeno
06/11/03, 17:30
On 6 Nov 2003 16:18:29 GMT, frank@openminds.be wrote:

>Ideefixx <ideefixx@hotmail.com.invalid> wrote:
>> Planet Internet is altijd zeer laat om hun dns up te daten als het gaat over
>> domeinnamen die van hun weg gaan he.
>> Dus PI update jullie DNS !! Ik ga eens zien als waar zal zijn .....
>
>wat dus erger is, is dat hun caching nameservers voor hun klanten dus
>dezelfde zijn als hun authorative nameservers (of dat ze hun auth zones
>repliceren op hun caching nameservers). Very evil. Very bad. Very Not
>Done(tm).

Tja... dat komt er van als ze zeer adequate admins als BLmet en Spy
buitengooien...

Tom Myny
06/11/03, 17:30
"xeno" <xenoREMOVE@pandora.be> wrote in message
news:d3tkqvgk5hjonlj0m7cvvgbumjp0aftg5q@4ax.com...
> On 6 Nov 2003 16:18:29 GMT, frank@openminds.be wrote:
>
> >Ideefixx <ideefixx@hotmail.com.invalid> wrote:
> >> Planet Internet is altijd zeer laat om hun dns up te daten als het gaat
over
> >> domeinnamen die van hun weg gaan he.
> >> Dus PI update jullie DNS !! Ik ga eens zien als waar zal zijn .....
> >
> >wat dus erger is, is dat hun caching nameservers voor hun klanten dus
> >dezelfde zijn als hun authorative nameservers (of dat ze hun auth zones
> >repliceren op hun caching nameservers). Very evil. Very bad. Very Not
> >Done(tm).
>
> Tja... dat komt er van als ze zeer adequate admins als BLmet en Spy
> buitengooien...

Wat doen die nu trouwens ?

tom
06/11/03, 17:45
<frank@openminds.be> schreef in bericht
news:bods8l$1dslht$1@ID-103399.news.uni-berlin.de...
> Ideefixx <ideefixx@hotmail.com.invalid> wrote:
> wat dus erger is, is dat hun caching nameservers voor hun klanten dus
> dezelfde zijn als hun authorative nameservers (of dat ze hun auth zones
> repliceren op hun caching nameservers). Very evil. Very bad. Very Not
> Done(tm).

indeed

heb het zelf ook vaak voor, maar connecties binnen scarlet roelen ;-)

Serge van Ginderachter
06/11/03, 18:45
frank@openminds.be wrote:

> wat dus erger is, is dat hun caching nameservers voor hun klanten dus
> dezelfde zijn als hun authorative nameservers (of dat ze hun auth zones
> repliceren op hun caching nameservers). Very evil. Very bad. Very Not
> Done(tm).

Ik ben dus een leek op DNS gebied (en nog vele andere ;-) ). Ik snap dit
dus niet.
Kan je dit es kort uitleggen, of mogelijks een pertinente link aanwijzen?


thx


--

Serge van Ginderachter

frank@openminds.be
07/11/03, 01:15
Serge van Ginderachter <pliesdoenotabjoes.serge@vanginderachter.be.thisadd ressis.invalid> wrote:
> frank@openminds.be wrote:

>> wat dus erger is, is dat hun caching nameservers voor hun klanten dus
>> dezelfde zijn als hun authorative nameservers (of dat ze hun auth zones
>> repliceren op hun caching nameservers). Very evil. Very bad. Very Not
>> Done(tm).

> Ik ben dus een leek op DNS gebied (en nog vele andere ;-) ). Ik snap dit
> dus niet.
> Kan je dit es kort uitleggen, of mogelijks een pertinente link aanwijzen?

Sure, sorry dat ik niet duidelijk was...

Hoe werkt dns? (beetje gesimplifieerd)

Stel, jij wil naar google surfen. Je opent je webbrowser, en tikt daar
www.google.be in. Je pc weet natuurlijk niet wat/wie google.be is. Die
weet enkel wat ipadressen zijn. Die moet dus die naam www.google.be
kunnen omzetten in een ip-adres. Daarvoor wordt DNS gebruikt. Je PC zal
aan de (caching) dns servers van je provider vragen "hebben jullie het
ip adres van www.google.be"? 9 kansen op 10 zal de nameserver van je
provider dit wel weten, omdat zeer veel mensen dit aan die servers
vragen, en die servers die resultaten cachen (een beetje zoals een proxy
doet met webpagina's).

Stel nu dat die nameservers dat niet weten. Wat dan? Wel, die
nameservers zoeken dan "wie zou iets kunnen weten over het google.be
domain?". Stel dat ze ook dat niet weten, dan kijken ze "wie zou iets
weten over het .be domain". Stel dat ze ook dat niet weten, dan kijken
ze naar wat ze zeker weten, en dat is welke nameservers iets weten over
"alles". Dit zijn de 13 root-nameservers. Ze vragen dan aan die
rootservers "weten jullie iets over www.google.be". Die rootservers
zullen zeggen "nee, maar we weten wel dat je voor .be domainen bij die
en die nameservers moet zijn". Die laatste zijn de nameservers van
dns.be. De nameservers van je provider vragen dan aan de nameservers van
dns.be of zij iets weten over www.google.be. Die zeggen "nee, maar de
servers die iets weten over google.be, zijn die en die (bv:
ns1.google.com, ns2.google.com, ...). De dns-servers van je providers
contacteren deze laatste nameservers (authorative nameservers), en die
zeggen "ah, www.google.be? dat is dat ip-adres".

Als laatste stapje deelt de caching nameserver van je provider dit mee
aan je pc: "www.google.be? ah, dat is dat ip-adres".

Bon, ik heb het hierboven aangehaald: je hebt 2 soorten nameservers:
caching nameservers (diegene die iets gaan opzoeken bij andere
nameservers, en die daarna het resultaat gaan bewaren (voor de
snelheid)) en authorative nameservers (diegenen die over een bepaald
"domain" (bv .be of google.be of zelfs . (die root nameservers)) iets
weten. Soms weten ze het antwoord zelf niet, maar zeggen ze "ik ben
zeker dat die nameserver je kan helpen".)

Elk werkend domain moet dus minstens 1 authorative dns-server hebben.
Elke ISP daarentegen moet natuurlijk een caching dns-server hebben,
anders kunnen zijn klanten niet deftig surfen.

Bon, stel nu volgende situatie:

Jij hebt een eigen domain, bv uwdomain.be. Je hebt dat geregistreerd via
provider X, je site staat bij X enz. Dat wil meestal zeggen dat de
nameservers van X de "authorative" nameservers zijn. Dit is logisch,
want je domain wordt beheerd door X, je site gehost door hen, enz.

Stel nu voor dat je niet tevreden bent van X, en naar ons wil verhuizen.
Wat gebeurt er dan? Wij zetten account voor uw site op, configureren
alles enz. Ook moeten wij natuurlijk in onze dns-servers instellen wat
de gegevens van uw domain zijn, kortom: onze dns-servers moeten denken
dat ze authorative zijn voor uwdomain.be. Aangezien niemand rechtstreeks
iets aan onze dns-servers zal vragen, gaat niemand echter op uw nieuwe
site uitkomen. Waarom niet? Omdat in de nameservers van dns.be (die
authorative zijn voor de hele .be zone) staat dat de authorative
nameservers voor uwdomain.be, die zijn van provider X.

Hoe zorgen we nu dat die info in de dns servers van dns.be aangepast
geraken? Door een "transfer" procedure van uw domain (of toch minstens
door een aanpassing, als u provider X als agent wilt behouden).
Als dit gelukt is, krijgen wij en provider X een bericht dat dat
aangepast is. Dan moet natuurlijk provider X nog zijn nameservers
aanpassen, en zeggen dat deze niet meer "authorative" zijn voor uw
domain.

Stel nu dat provider X die laatste stap niet doet, en die (onjuiste)
info laat staan in zijn dns-servers... Op zich is dat niet erg, als
niemand die dns-servers ooit iets vraagt over uwdomain.be. Het is niet
netjes, maar bon, het kan niet veel kwaad. Tenzij.... juist, tenzij
diezelfde dns-servers die denken nog steeds authorative te zijn voor
uwdomain.be, door de klanten van provider X gebruikt worden als caching
nameserver! Want stel dan dat een klant van X "www.uwdomain.be" intikt
in zijn browser, dan zal die nameserver zeggen "ha, ik weet daar alles
van!", en zal u doorsturen naar de webservers waar uw oude site op
stond. De klanten van provider X krijgen dus ofwel uw oude site te zien,
ofwel helemaal niks (als die oude site daar al weg is). Idem met mail:
dit gebruikt hetzelfde principe, de mail zal nooit toekomen.

Daarom is het dus sterk aan te bevelen om als provider uw caching
dns-servers te scheiden van uw authorative dns-servers!


Vriendelijke groeten,
Frank Louwers

--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

Jaak
07/11/03, 04:15
<frank@openminds.be> schreef in bericht
news:boenjq$1dq6q6$1@ID-103399.news.uni-berlin.de...
>Soms weten ze het antwoord zelf niet, maar zeggen ze "ik ben
>zeker dat die nameserver je kan helpen".)
>...
Wat kan die Frank dat toch mooi uitleggen hè
Meneerken duim wist het antwoord zelf niet, maar mevrouw pink zei tegen
meneerken duim dat vader wijsvinger je kan helpen

Ooit nog poppenkast gespeeld in een vorig leven ofzo?

david
07/11/03, 09:45
frank@openminds.be wrote:
><slurp>

snap weer iets meer van internet waarvoor dank


david

Gilbert
07/11/03, 12:15
hahaha, gewoonweg prachtig :-)))

Jan Reilink
07/11/03, 12:30
Serge van Ginderachter wrote:

> frank@openminds.be wrote:
>
>> wat dus erger is, is dat hun caching nameservers voor hun klanten dus
>> dezelfde zijn als hun authorative nameservers (of dat ze hun auth zones
>> repliceren op hun caching nameservers). Very evil. Very bad. Very Not
>> Done(tm).
>
>
> Ik ben dus een leek op DNS gebied (en nog vele andere ;-) ). Ik snap dit
> dus niet.
> Kan je dit es kort uitleggen, of mogelijks een pertinente link aanwijzen?
>

Wellicht interessant:

"Configuratie van de Bind 9 DNS-server <http://www.hensema.net/bind9/>
Dit is een korte introductie voor DNS en Bind. Er wordt niet te
diep ingegaan op de materie, maar toch diep genoeg op een systeem
van redelijk formaat op te zetten."

Nog meer informatie: <http://www.howstuffworks.com/dns.htm>
<http://www.bind9.net/>

--
Met vriendelijke groet / Best regards,
Jan Reilink, VEVIDA Nederland BV

Postbus 329, 9700 AH GRONINGEN, +31 (0)50 - 5492234

Luc Vos
07/11/03, 13:30
"xeno" <xenoREMOVE@pandora.be> wrote in message
news:d3tkqvgk5hjonlj0m7cvvgbumjp0aftg5q@4ax.com...
> On 6 Nov 2003 16:18:29 GMT, frank@openminds.be wrote:
>
> >Ideefixx <ideefixx@hotmail.com.invalid> wrote:
> >> Planet Internet is altijd zeer laat om hun dns up te daten als het gaat
over
> >> domeinnamen die van hun weg gaan he.
> >> Dus PI update jullie DNS !! Ik ga eens zien als waar zal zijn .....
> >
> >wat dus erger is, is dat hun caching nameservers voor hun klanten dus
> >dezelfde zijn als hun authorative nameservers (of dat ze hun auth zones
> >repliceren op hun caching nameservers). Very evil. Very bad. Very Not
> >Done(tm).
>
> Tja... dat komt er van als ze zeer adequate admins als BLmet en Spy
> buitengooien...

Correctie : die zijn zelf gegaan, en de admins die er nu zijn, zijn minstens
even goed. We zijn bezig om alles te optimaliseren en juist te zetten, maar
dat duurt even. We doen het liever goed, dan het rap rap te doen en het de
mist in te laten gaan. We spreken hier over de integratie van 3 bedrijven,
daar is even tijd voor nodig.


--
Groetjes,

LucV
Scarlet
http://www.scarlet.be

fred
07/11/03, 14:00
"Luc Vos" <nospam_lucv@staf.pi.be> wrote in message
news:bog3c4$6kq$1@reader08.wxs.nl...
> "xeno" <xenoREMOVE@pandora.be> wrote in message
> news:d3tkqvgk5hjonlj0m7cvvgbumjp0aftg5q@4ax.com...
> > On 6 Nov 2003 16:18:29 GMT, frank@openminds.be wrote:
> >
> Correctie : die zijn zelf gegaan, en de admins die er nu zijn, zijn
minstens
> even goed. We zijn bezig om alles te optimaliseren en juist te zetten,
maar
> dat duurt even. We doen het liever goed, dan het rap rap te doen en het de
> mist in te laten gaan. We spreken hier over de integratie van 3 bedrijven,
> daar is even tijd voor nodig.
>
>


TEUTEBOLLEN !
dit probleem bestaat al 2 jaar bij jullie ! Nog nooit iets aan gedaan en zal
waarschijnlijk nooit gebeuren ook !
'optimaliseren en liever goed doen' -> mijn kl*ten !

xeno
07/11/03, 15:30
On Fri, 7 Nov 2003 13:26:44 +0100, "Luc Vos" <nospam_lucv@staf.pi.be>
wrote:

>> Tja... dat komt er van als ze zeer adequate admins als BLmet en Spy
>> buitengooien...
>
>Correctie : die zijn zelf gegaan, en de admins die er nu zijn, zijn minstens
>even goed. We zijn bezig om alles te optimaliseren en juist te zetten, maar
>dat duurt even. We doen het liever goed, dan het rap rap te doen en het de
>mist in te laten gaan. We spreken hier over de integratie van 3 bedrijven,
>daar is even tijd voor nodig.

Ahja ?

Blmet is gevlogen, en niemand begreep waarom. Sindsdien zijn er
ettelijke andere uit eigen beweging vertrokken wegens dat voorval met
BLmet, waaronder Spy.

Als je het dan toch wil weerleggen, weerleg het met juiste informatie.

Jaak
07/11/03, 15:45
"Luc Vos" <nospam_lucv@staf.pi.be> schreef in bericht
news:bog3c4$6kq$1@reader08.wxs.nl...
> Correctie : die zijn zelf gegaan, en de admins die er nu zijn, zijn
minstens
> even goed. We zijn bezig om alles te optimaliseren en juist te zetten,
maar
> dat duurt even. We doen het liever goed, dan het rap rap te doen en het de
> mist in te laten gaan. We spreken hier over de integratie van 3 bedrijven,
> daar is even tijd voor nodig.
Je zal het niet mogen toegeven, maar je weet dat het zwaar mank loopt bij
jullie.

het onvoorziene vertrek van een aantal zeer capabele personen aan het hoofd
van enkele diensten
de abrubte transfer van gegevens in nieuwe applicaties
de verhuispogingen
de tal van overnames die er dan wel gekomen zijn of niet
de support is quasi onbereikbaar
de techs worden zot
sales heeft niets anders te doen dan klachten opvangen
backoffice staat op springen

Wie nog overblijft zit er mentaal echt onder door!

Serge van Ginderachter
08/11/03, 12:15
frank@openminds.be wrote:
> Serge van Ginderachter <pliesdoenotabjoes.serge@vanginderachter.be.thisadd ressis.invalid> wrote:
>
>>Ik ben dus een leek op DNS gebied (en nog vele andere ;-) ). Ik snap dit
>>dus niet.

Mijn excuses! Zo'n leek was ik nu ook weer niet, maar ik heb geen
pertinente ISP ervaring, was wat ik eigenlijk bedoelde.
Mara in ieder geval bedankt voor de uitvoerige uitleg, velen zullen hier
samen met mij veel aan hebben!

> Stel nu dat provider X die laatste stap niet doet, en die (onjuiste)
> info laat staan in zijn dns-servers... Op zich is dat niet erg, als
> niemand die dns-servers ooit iets vraagt over uwdomain.be. Het is niet
> netjes, maar bon, het kan niet veel kwaad. Tenzij.... juist, tenzij
> diezelfde dns-servers die denken nog steeds authorative te zijn voor
> uwdomain.be, door de klanten van provider X gebruikt worden als caching
> nameserver! Want stel dan dat een klant van X "www.uwdomain.be" intikt
> in zijn browser, dan zal die nameserver zeggen "ha, ik weet daar alles
> van!", en zal u doorsturen naar de webservers waar uw oude site op
> stond. De klanten van provider X krijgen dus ofwel uw oude site te zien,
> ofwel helemaal niks (als die oude site daar al weg is). Idem met mail:
> dit gebruikt hetzelfde principe, de mail zal nooit toekomen.

Het is dus die laatste stap waar ik niet dadelijk het gevaar van in zag...

> Daarom is het dus sterk aan te bevelen om als provider uw caching
> dns-servers te scheiden van uw authorative dns-servers!

Strikt genomen zou het geen kwaad mogen indien de provider consequent
was: het verwijderen van de primaire zone... Maar dit principe om
caching en authorative servers te scheiden is dus uiteraard een heel
goede best practice.
In mijn omgeving (Een prutserige dns.be agent, zonder ISP activiteiten)
hebben we dit probleem de facto niet, vandaar dat ik dat verband niet
wist te leggen.

> Vriendelijke groeten,
> Frank Louwers

Ook zoveel,

--

Serge van Ginderachter

frank@openminds.be
08/11/03, 13:15
Serge van Ginderachter <pliesdoenotabjoes.serge@vanginderachter.be.thisadd ressis.invalid> wrote:
>> Daarom is het dus sterk aan te bevelen om als provider uw caching
>> dns-servers te scheiden van uw authorative dns-servers!

> Strikt genomen zou het geen kwaad mogen indien de provider consequent
> was: het verwijderen van de primaire zone... Maar dit principe om
> caching en authorative servers te scheiden is dus uiteraard een heel
> goede best practice.
> In mijn omgeving (Een prutserige dns.be agent, zonder ISP activiteiten)
> hebben we dit probleem de facto niet, vandaar dat ik dat verband niet
> wist te leggen.

Bwa, dat hangt ervan af. Stel dat je hosting doet, en dat
klanten/resellers via een automatisch script accounts kunnen maken, of
domains kunnen toevoegen.

Stel verder dat je bv Debian draait, en je de updates van
security.debian.org regelmatig installeert. Stel nu dat je auth en je
eigen caching/resolving nameservers dezelfde zijn, en dat je een klant
met slechte bedoelingen hebt. Die maakt een account aan, zogezegd voor
debian.org, gekoppeld aan zijn webaccount. Hij zet daar dan een debian
pakketje op, met een install script dat je doos omzeep haalt. De
volgende keer dat jij een security update gaat doen, ga je zonder het te
weten het pakket van zijn site halen ipv van de echte site...


Vriendelijke groeten,
Frank Louwers

--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

Serge van Ginderachter
08/11/03, 16:45
frank@openminds.be wrote:
> Bwa, dat hangt ervan af. Stel dat je hosting doet, en dat
> klanten/resellers via een automatisch script accounts kunnen maken, of
> domains kunnen toevoegen.
Dan zou ik denken dat het geen goed idee is om die scripts toe te laten
domains aan te maken op de auth dns die niet officieel zijn?

Maar da's theorie, ik blijf akkoord met je oorspronkelijke stelling .

--

Serge van Ginderachter

frank@openminds.be
08/11/03, 21:45
Serge van Ginderachter <pliesdoenotabjoes.serge@vanginderachter.be.thisadd ressis.invalid> wrote:
> frank@openminds.be wrote:
>> Bwa, dat hangt ervan af. Stel dat je hosting doet, en dat
>> klanten/resellers via een automatisch script accounts kunnen maken, of
>> domains kunnen toevoegen.
> Dan zou ik denken dat het geen goed idee is om die scripts toe te laten
> domains aan te maken op de auth dns die niet officieel zijn?


Stel dat een klant nu bij provider X zit, maar wil verhuizen naar jouw.
Je gaat hem toch wachten met zijn account en zo aan te maken totdat de
transfer volledig in orde is, en de root/.be/.com/... nameservers
aangepast zijn? Dus je *moet* in zekere zin wel vertrouwen wat die daar
inklopt ...


Vriendelijke groeten,
Frank Louwers

--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

Serge van Ginderachter
09/11/03, 11:45
frank@openminds.be wrote:
> Stel dat een klant nu bij provider X zit, maar wil verhuizen naar jouw.
> Je gaat hem toch wachten met zijn account en zo aan te maken totdat de
> transfer volledig in orde is, en de root/.be/.com/... nameservers
> aangepast zijn? Dus je *moet* in zekere zin wel vertrouwen wat die daar
> inklopt ...

Point taken.

Je zou dan natuurlijk je procedure zo kunnen maken dat dit enkel kan in
samenwerking met een DNS overdracht, maar dan nog zeker...
Op de duur kom je dan op van die overdreven security toestanden zoals ik
enkele jaren geleden meemaakte:

- Switch van ISP van UUNET naar EASYNET.
- Easynet voert de DNS overdracht al uit, 2 maand voor afloop van
kontrakt met UUNET, dus 2 maand voor afloop van feitelijke switch van de
Leased Line
- Plots komt er geen mail mee binnen....
- UUNet detecteerde blijkbaar dat ons domain niet meer bij hen gehost
werd, waardoor er iets beblokkeerd werd - ik weet niet juist meer wat,
de SMTP feed of hun relay/backupMX servers of zoiets.


UUNet, betekenen die nog iets in België trouwens? Ik hoor er niet zo
veel meer van. Die zijn precies nogal van hun sokkel getuimeld. Als ik
me hun nieuwjaarsrecepties herinner :-) amaai, dat was ook duidelijk dat
die te veel aanrekenden :-| En dan nog argumenteren hoeveel beter ze
zouden zijn om hun hogere prijzen te proberen verantwoorden.


--
Groetjes,

Serge van Ginderachter

houghi
10/11/03, 00:00
frank@openminds.be wrote:
>
> Stel dat een klant nu bij provider X zit, maar wil verhuizen naar jouw.
> Je gaat hem toch wachten met zijn account en zo aan te maken totdat de
> transfer volledig in orde is, en de root/.be/.com/... nameservers
> aangepast zijn? Dus je *moet* in zekere zin wel vertrouwen wat die daar
> inklopt ...

Als ik me goed herinner werkt het als volgt:
Je verteld je nieuwe provider dat je je DNS voor je domein bij hen wil
hosten. Die verwittigd de uitgever van je domein (dns.be voor be) Die
verteld de ander de domein te deleten. Op dat moment heeft de niewe DNS
hoster dat domein al aangemaakt.

Caching nameservers zorgen dat de overgang in orde word gemaakt
afhankelijk van de TTL (Time To Live) van het domein.

Wat kan er fout gaan? De oude hoster vergeet het domein te deleten. Dit
heeft als gevolg dat de DNS daar blijft staan. Mensen die gebruik maken
van die servers krijgen de verkeerde info.

De rest van de wereld maakt gebruik van caching nameservers die (normaal
gezien) gaan kijken wie er verantwoordelijk is. Ze kijken zie
verantwoordelijk is voor '.' dan voor 'com.' dan voor 'example.com.'

Uiteraard moeten dan al zijn accounts, mailboxen en dergelijke in orde
zijn. Een beetje hostmaster kijkt dat natuurlijk na.

--
houghi http://www.houghi.org/jargon
It's people. Source code is made out of people! They're making our source out
of people. Next thing they'll be breeding us like cattle for code. You've
gotta tell them. You've gotta tell them!

frank@openminds.be
10/11/03, 13:30
houghi <houghi@houghi.org> wrote:
> frank@openminds.be wrote:
>>
>> Stel dat een klant nu bij provider X zit, maar wil verhuizen naar jouw.
>> Je gaat hem toch wachten met zijn account en zo aan te maken totdat de
>> transfer volledig in orde is, en de root/.be/.com/... nameservers
>> aangepast zijn? Dus je *moet* in zekere zin wel vertrouwen wat die daar
>> inklopt ...

> Als ik me goed herinner werkt het als volgt:
> Je verteld je nieuwe provider dat je je DNS voor je domein bij hen wil
> hosten. Die verwittigd de uitgever van je domein (dns.be voor be) Die
> verteld de ander de domein te deleten. Op dat moment heeft de niewe DNS
> hoster dat domein al aangemaakt.

Euh, niet helemaal. De huidige agent ("losing agent") krijgt bij .be's
pas bericht dat hij het domain kwijt is, op het moment dat de transfer
is uitgevoerd (merk op dat op dat moment de dns.be nameservers nog NIET
zijn aangepast, en nog naar de oude provider zullen wijzen!).

> Caching nameservers zorgen dat de overgang in orde word gemaakt
> afhankelijk van de TTL (Time To Live) van het domein.

> Wat kan er fout gaan? De oude hoster vergeet het domein te deleten. Dit
> heeft als gevolg dat de DNS daar blijft staan. Mensen die gebruik maken
> van die servers krijgen de verkeerde info.

Het punt ging er hem om twee zaken:

- oorspronkelijk: dat bij PI de caching nameservers ook authorative zijn
voor de lokale domainen die bij PI staan (of die niet meer bij PI
staan, maar die ze dus vergeten te deleten). Gevolg: alle PI
adsl/inbel klanten zien nog weken de oude site. Mails van PI klanten
komen niet meer toe.

- ik zei dan: zelfs als je ze op tijd delete, is er ook een potentieel
probleem bij het aanmaken van nieuwe accounts, als je als hoster bv.
zelf in je caching nameservers naar je eigen authorative nameservers
eerst gaat luisteren, zonder de "normale" weg te volgen...


Vriendelijke groeten,
Frank Louwers

--
Openminds bvba www.openminds.be
Tweebruggenstraat 16 - 9000 Gent - Belgium

Luc Vos
11/11/03, 00:00
"Jaak" <teesisnibelangrijk@hotmail.com> wrote in message
news:8bOqb.8737$W32.287879@phobos.telenet-ops.be...
>
> "Luc Vos" <nospam_lucv@staf.pi.be> schreef in bericht
> news:bog3c4$6kq$1@reader08.wxs.nl...
> > Correctie : die zijn zelf gegaan, en de admins die er nu zijn, zijn
> minstens
> > even goed. We zijn bezig om alles te optimaliseren en juist te zetten,
> maar
> > dat duurt even. We doen het liever goed, dan het rap rap te doen en het
de
> > mist in te laten gaan. We spreken hier over de integratie van 3
bedrijven,
> > daar is even tijd voor nodig.
> Je zal het niet mogen toegeven, maar je weet dat het zwaar mank loopt bij
> jullie.

Het is geen kwestie van mogen, maar ik denk niet dat het de bedoeling is de
'vuile was' van eender welk bedrijf in deze nieuwsgroepen hier buiten te
hangen. En als jij van Scarlet bent, zou ik je aanraden dit ook niet te
doen. Dit is geen dreigement hoor, daar hou ik me niet mee bezig, maar er is
zoiets als fair blijven tov je werkgever. Wat er ook mag gebeuren.

> het onvoorziene vertrek van een aantal zeer capabele personen aan het
hoofd van enkele diensten
We zitten in een overgansperiode, 3 bedrijven die 1 worden, dat is niet
evident, dat mag je aan eenieder vragen.

> de abrubte transfer van gegevens in nieuwe applicaties
?
> de verhuispogingen
> de tal van overnames die er dan wel gekomen zijn of niet
> de support is quasi onbereikbaar
> de techs worden zot
> sales heeft niets anders te doen dan klachten opvangen
> backoffice staat op springen
>
> Wie nog overblijft zit er mentaal echt onder door!
>
Ik ga niet beweren dat er geen problemen zijn, die zijn er overal, maar ik
denk dat je dit best op een andere manier oplost dan door hier Scarlet zwart
te maken. Daar ga je de problemen echt niet mee oplossen hoor.


--
Groetjes,

LucV
Scarlet
http://www.scarlet.be

>

Luc Vos
11/11/03, 00:00
"xeno" <xenoREMOVE@pandora.be> wrote in message
news:unanqvstr68lp3e9n90hn971d3uiorqosg@4ax.com...
> On Fri, 7 Nov 2003 13:26:44 +0100, "Luc Vos" <nospam_lucv@staf.pi.be>
> wrote:
>
> >> Tja... dat komt er van als ze zeer adequate admins als BLmet en Spy
> >> buitengooien...
> >
> >Correctie : die zijn zelf gegaan, en de admins die er nu zijn, zijn
minstens
> >even goed. We zijn bezig om alles te optimaliseren en juist te zetten,
maar
> >dat duurt even. We doen het liever goed, dan het rap rap te doen en het
de
> >mist in te laten gaan. We spreken hier over de integratie van 3
bedrijven,
> >daar is even tijd voor nodig.
>
> Ahja ?
>
> Blmet is gevlogen, en niemand begreep waarom. Sindsdien zijn er
> ettelijke andere uit eigen beweging vertrokken wegens dat voorval met
> BLmet, waaronder Spy.
>
> Als je het dan toch wil weerleggen, weerleg het met juiste informatie.

Ik ken de naam Blmet niet, maar ik denk dat ik weet wie je bedoelt. Klopt in
dat geval. Maar waar ik het over had, is de periode daarna. En ik zou hier
veel kunnen zeggen over beweegredenen van vertrek van mensen, die anders
zijn dan vaak naar buiten toe aangegeven, maar dit is hier het forum niet.
Dat is interne keuken.

Feit is dat er met de mensen die er nu zijn al schitterend werk geleverd is,
en dat er nog veel werk te doen is, dat ook zal gedaan worden. Meer is het
niet.


--
Groetjes,

LucV
Scarlet
http://www.scarlet.be

Jaak
11/11/03, 00:30
"Luc Vos" <nospam_lucv@staf.pi.be> schreef in bericht
news:bop52p$5em$1@reader10.wxs.nl...

> hangen. En als jij van Scarlet bent, zou ik je aanraden dit ook niet te
> doen. Dit is geen dreigement hoor, daar hou ik me niet mee bezig, maar er
is
> zoiets als fair blijven tov je werkgever. Wat er ook mag gebeuren.
Daar heb je gelijk in, maar ben niet werkzaam bij jullie.

> We zitten in een overgansperiode, 3 bedrijven die 1 worden, dat is niet
> evident, dat mag je aan eenieder vragen.
Daar kan ik helemaal mee inkomen, toch zou dat niet mogen.

> Ik ga niet beweren dat er geen problemen zijn, die zijn er overal, maar ik
> denk dat je dit best op een andere manier oplost dan door hier Scarlet
zwart
> te maken. Daar ga je de problemen echt niet mee oplossen hoor.
Het vorige antwoord was niet bedoeld om de vuile was van planet buiten te
hangen, maar was bedoeld omdat ik niet akkoord ging met jouw uitspraak

[start quote]
We zijn bezig om alles te optimaliseren en juist te zetten, maar
dat duurt even. We doen het liever goed, dan het rap rap te doen en het de
mist in te laten gaan. We spreken hier over de integratie van 3 bedrijven,
daar is even tijd voor nodig.
[end quote]

Dat jullie aan het optimaliseren zijn, akkoord. Dat duurt even, akkoord.
Het feit dat je het liever goed doet, gelukkig!
Maar het gaat evengoed de mist in hoor

Maar het ligt niet aan jou, of aan het directe management hoor. Het lijkt
of jullie vanuit tientallen verschillende hoeken worden tegengewerkt.

Ik spreek over
- ICT de recessie - maar daar heeft iedereen natuurlijk last van
- de flamboyante arrogantie van BGC tov jullie
- de bovenvernoemde integratie
- enkele beslissingen enkele jaren geleden
- klanten die wegblijven

Waarom blijven klanten bij jullie weg? - niet in het minste veroorzaakt door
jullie dealers -
- superlange aansluittijden (zie BGC)
- geen zekerheden op lange termijn
- facturatieproblemen
(meerdere klanten worden afgesloten, klanten bellen ons. Wij bellen
verder na enkele uren verwoede contactpogingen en wachten is alles
uitgezocht. Geen één van de klanten had achterstallige bedragen, er was
zelfs een klant die ondertussen >500 euro te veel gefactureerd was maar was
wel betaald enz)
- contactproblemen sinds enkele maanden

Gelukkig zijn de telefoonmeiden bij jullie hulpvaardig, anders was het
ondraaglijk.

xeno
11/11/03, 13:00
On Mon, 10 Nov 2003 23:57:00 +0100, "Luc Vos" <nospam_lucv@staf.pi.be>
wrote:

>Ik ken de naam Blmet niet, maar ik denk dat ik weet wie je bedoelt. Klopt in
>dat geval. Maar waar ik het over had, is de periode daarna. En ik zou hier

Ik had het op die periode... de periode net na de glorietijd. Hieruit
kan ik alleen maar concluderen dat je er blijkbaar toen nog niet
werkte, want in de glorietijd kende iedereen bijna iedereen bij PI,
had je aanzien als je op de PI helpdesk zat, en kenden men elkaar
eerder bij zen alias dan bij zen echte naam. Het was ook de tijd dat
je naar de heldesk kon bellen met een probleem, en na 5 minuten
effectief geholpen was.

Maar die zaken zijn inderdaad allemaal voltooid verleden tijd...

houghi
11/11/03, 13:45
xeno wrote:
> Ik had het op die periode... de periode net na de glorietijd. Hieruit
> kan ik alleen maar concluderen dat je er blijkbaar toen nog niet
> werkte, want in de glorietijd kende iedereen bijna iedereen bij PI,
> had je aanzien als je op de PI helpdesk zat, en kenden men elkaar
> eerder bij zen alias dan bij zen echte naam. Het was ook de tijd dat
> je naar de heldesk kon bellen met een probleem, en na 5 minuten
> effectief geholpen was.

Ik kan me vergissen hoor, maar dat kan natuurlijk ook komen door het
verschil in gebruikers van vroeger en nu. Vroeger waren het enkel een
stel nerds die het net op gingen, nu moet iedereen het net op.

Ik ben laats bij iemand geweest die vroeg om te helpen bij het
instaleren van de camera software. Wat ik moest doen? De CD in de PC
steken en af en toe op OK klikken. Indien die personen naar een helpdesk
bellen, worden die echt niet binnen 5 minuten geholpen met het
aanbrengen van een initstring.

Natuurlijk zaten er aan de andere kant ook enkel nerds. Tegenwoordig
zijn het gewoon mensen die een job willen en geld willen verdienen en
thuis niet ook nog eens tot uren in de nacht met een PC bezig zijn.
Vroeger waren het gewoon betaalde amateurs. (Met alle respect voor de
mensen die er nu werken hoor.)

Het 'probleem' komt nu van twee kanten.

--
houghi http://www.houghi.org/jargon
It's people. Source code is made out of people! They're making our source out
of people. Next thing they'll be breeding us like cattle for code. You've
gotta tell them. You've gotta tell them!

Esther
11/11/03, 15:45
Op Tue, 11 Nov 2003 13:34:04 +0100, schreef houghi:

> Ik kan me vergissen hoor, maar dat kan natuurlijk ook komen door het
> verschil in gebruikers van vroeger en nu. Vroeger waren het enkel een stel
> nerds die het net op gingen, nu moet iedereen het net op.

Je vergist je niet het is gewoon de realiteit!

xeno
11/11/03, 16:45
On Tue, 11 Nov 2003 13:34:04 +0100, houghi <houghi@houghi.org> wrote:

>Ik kan me vergissen hoor, maar dat kan natuurlijk ook komen door het
>verschil in gebruikers van vroeger en nu. Vroeger waren het enkel een
>stel nerds die het net op gingen, nu moet iedereen het net op.

Er zit een hemelsgroot verschil in de gebruikers van toen en van nu.
Maar er zit ook een hemelsgroot verschil in de houding van de
bedrijfleiding toen en nu.