Hallo, Kan iemand mij hier misschien vertellen waarom SIDN eigelijk nameserver controles uitvoert bij het aanvragen en verhuizen van .NL domeinen, zelf kunnen ze het namelijk niet uitleggen. De reden waarom ik dit vraag is omdat een niet correcte ( lees RFC compliant ) DNS zone mijns inziens niet het probleem van SIDN maar van de provider zelf. Normaal gesproken zou ik me niet storen aan die controle, maar de laatste tijd ligt die controle er regelmatig waardoor er onterrechte afwijzingen onstaan. Maurice P.S: Het begint me zo langzamerhand aaardig op m'n zenuwen te werken hoe SIDN zich verslikt heeft in de introductie van DRS4.0
On Tue, 2006-10-17 at 09:43 +0200, Maurice Sienema wrote:
Kan iemand mij hier misschien vertellen waarom SIDN eigelijk nameserver controles uitvoert bij het aanvragen en verhuizen van .NL domeinen, zelf kunnen ze het namelijk niet uitleggen.
Dat is de erfenis van Piet Beertema, lijkt me. Die weigerde domeinen te registreren als ze niet voldeden aan de (zijn) eisen. Deze gewoonte is doorgezet in SIDN en, zoals ook in religies gebeurt, verheven tot een ritueel. ;-) -- Steven
Kan iemand mij hier misschien vertellen waarom SIDN eigelijk nameserver controles uitvoert bij het aanvragen en verhuizen van .NL domeinen, zelf kunnen ze het namelijk niet uitleggen.
Dat is de erfenis van Piet Beertema, lijkt me. Die weigerde domeinen te registreren als ze niet voldeden aan de (zijn) eisen. Deze gewoonte is doorgezet in SIDN en, zoals ook in religies gebeurt, verheven tot een ritueel. ;-)
Ik zocht meer naar een technisch antwoord, maar blijkbaar is die er niet. Waarschijnlijk hanteert SIDN RFC's alsof het hun wetboek is, en heeft zichzelf als controlerende instantie benoemd. Maurice
On 17 okt 2006, at 13:59, Maurice Sienema wrote:
Kan iemand mij hier misschien vertellen waarom SIDN eigelijk nameserver controles uitvoert bij het aanvragen en verhuizen van .NL domeinen, zelf kunnen ze het namelijk niet uitleggen.
Dat is de erfenis van Piet Beertema, lijkt me. Die weigerde domeinen te registreren als ze niet voldeden aan de (zijn) eisen. Deze gewoonte is doorgezet in SIDN en, zoals ook in religies gebeurt, verheven tot een ritueel. ;-)
Ik zocht meer naar een technisch antwoord, maar blijkbaar is die er niet. Waarschijnlijk hanteert SIDN RFC's alsof het hun wetboek is, en heeft zichzelf als controlerende instantie benoemd.
Wacht... wat zeg je nu? RFC's zijn *niet* de wet?! Dat is nieuws voor me!! -- Niels.
Ik zocht meer naar een technisch antwoord, maar blijkbaar is die er niet. Waarschijnlijk hanteert SIDN RFC's alsof het hun wetboek is, en heeft zichzelf als controlerende instantie benoemd.
Wacht... wat zeg je nu? RFC's zijn *niet* de wet?! Dat is nieuws voor me!!
Uiteraard moet men zich aan RFC's houden, maar ik formuleerde het wat krom, mijn punt is meer dat SIDN een taak opzich neemt, en deze slecht ten uitvoer brengt, waardoor ik twijfel of SIDN hiermee moet blijven doorgaan. Maurice
On Tue, 17 Oct 2006, Maurice Sienema wrote:
Ik zocht meer naar een technisch antwoord, maar blijkbaar is die er niet. Waarschijnlijk hanteert SIDN RFC's alsof het hun wetboek is, en heeft zichzelf als controlerende instantie benoemd.
Wacht... wat zeg je nu? RFC's zijn *niet* de wet?! Dat is nieuws voor me!!
Uiteraard moet men zich aan RFC's houden, maar ik formuleerde het wat krom, mijn punt is meer dat SIDN een taak opzich neemt, en deze slecht ten uitvoer brengt, waardoor ik twijfel of SIDN hiermee moet blijven doorgaan.
Kom, laat ik eens iets riskants doen. En een vraag stellen. Heeft SIDN hier vaker grote steken laten vallen *voor* de migratie naar DRS4? -- Jan http://www.surfnet.nl/organisatie/jame
On 17 okt 2006, at 14:19, Maurice Sienema wrote:
Ik zocht meer naar een technisch antwoord, maar blijkbaar is die er niet. Waarschijnlijk hanteert SIDN RFC's alsof het hun wetboek is, en heeft zichzelf als controlerende instantie benoemd.
Wacht... wat zeg je nu? RFC's zijn *niet* de wet?! Dat is nieuws voor me!!
Uiteraard moet men zich aan RFC's houden, maar ik formuleerde het wat krom, mijn punt is meer dat SIDN een taak opzich neemt, en deze slecht ten uitvoer brengt, waardoor ik twijfel of SIDN hiermee moet blijven doorgaan.
Om de discussie wat realistischer te maken, met welke RFC heb je een probleem en wil je overtreden? Ik vind het op zich niet verkeerd dat SIDN controleert wanneer het een domein uitdeelt of het daadwerkelijk enige kans heeft om op dat moment te gaan werken. Eigenlijk is SIDN dat de eindgebruikers wel verplicht, ergens. -- Niels.
Om de discussie wat realistischer te maken, met welke RFC heb je een probleem en wil je overtreden?
Ik wil helemaal geen RFC's overtreden, skip het verhaal over RFC's...
Ik vind het op zich niet verkeerd dat SIDN controleert wanneer het een domein uitdeelt of het daadwerkelijk enige kans heeft om op dat moment te gaan werken. Eigenlijk is SIDN dat de eindgebruikers wel verplicht, ergens.
SIDN is de enige TLD ( die ik ken ) die de zone test voor aanvraag of verhuizing. Maar de technische kant van de zone is zaak van de ISP en niet $TLD_beheerder, oftewel ik vindt dat ze zich bemoeien met zaken die hun niet aangaan. Deze vraag heb ik me ook al eens afgevraagd voor het hele DRS 4.0 debakel. Maurice
On 17 okt 2006, at 16:55, Maurice Sienema wrote:
SIDN is de enige TLD ( die ik ken ) die de zone test voor aanvraag of verhuizing.
Kijk voor de grap eens wat voor debiele eisen .za heeft als je het wil hebben over technisch onkundige bemoeienis met nameserver- configuratie bij ISP's. (Niet lang geleden was een van de eisen dat de nameservers authoritative zijn voor de hele .in-addr.arpa zone voor de /24 waarin hun eigen IP-adres ligt.)
Maar de technische kant van de zone is zaak van de ISP en niet $TLD_beheerder, oftewel ik vindt dat ze zich bemoeien met zaken die hun niet aangaan.
Ontken je dat SIDN een verantwoordelijkheid heeft voor het correct draaien van de nl. zone? Nogmaals, een minimale controle of veranderingen die ze opnemen in de zone technisch wel een beetje kloppen vind ik wel op z'n plaats. -- Niels.
Kijk voor de grap eens wat voor debiele eisen .za heeft als je het wil hebben over technisch onkundige bemoeienis met nameserver- configuratie bij ISP's.
(Niet lang geleden was een van de eisen dat de nameservers authoritative zijn voor de hele .in-addr.arpa zone voor de /24 waarin hun eigen IP-adres ligt.)
Precies, dus komen we weer precies bij mijn eerste vraag, wat is de technische noodzaak voor deze controles.
Ontken je dat SIDN een verantwoordelijkheid heeft voor het correct draaien van de nl. zone? Nogmaals, een minimale controle of veranderingen die ze opnemen in de zone technisch wel een beetje kloppen vind ik wel op z'n plaats.
voor de CLD .nl is uiteraard SIDN verantwoordelijk, maar voor de subdomains ervan niet, ze worden toch ook niet voor niets gedelegeerd naar andere nameservers. Met die controle op zich heb ik ook geen problemen, maar wel met de manier waarop die wordt toegepast, een waarschuwing geven van misstanden lijkt me gepaster dan een afwijzing van de aanvraag, zoals ze bijvoorbeeld wel doen voor de waarden in de SOA records. Maurice
Maurice Sienema wrote: [...]
voor de CLD .nl is uiteraard SIDN verantwoordelijk, maar voor de subdomains ervan niet, ze worden toch ook niet voor niets gedelegeerd naar andere nameservers. Met die controle op zich heb ik ook geen problemen, maar wel met de manier waarop die wordt toegepast, een waarschuwing geven van misstanden lijkt me gepaster dan een afwijzing van de aanvraag, zoals ze bijvoorbeeld wel doen voor de waarden in de SOA records.
Ik denk dat je met je laatste opmerking raakt aan de crux van de zaak. De (in)correctheid van de diverse waardes in SOA records heeft, in potentie, impact op het functioneren van de globale gedistribueerde database die ook wel bekend staat als het Domain Name System. Bijvoorbeeld, fout gekonfigureerde velden in een SOA kunnen een onnodige verhoging van de query rate op DNS servers opleveren. Dat kan vervelend zijn voor de servers van het domain waar het om gaat (en dat is idd je eigen zaak), maar dit heeft vanzelfsprekend ook impact op de domainservers die 'hoger in de boom' zitten. Waarmee de foute configuratie van een subdomein opeens een zaak van het gehele Internet geworden is. MAW het controleren van de basics in de server setup van gedelegeerde domeinen behoort tot de good housekeeping rules voor een domeinbeheerder. Dat gezegd hebbende... ben ik het volkomen eens met Steven's reactie eerder vandaag; voor SIDN is dit waarschijnlijk meer een religieus ritueel dan dat er iemand verder ooit over nagedacht heeft sinds PB met pensioen is. :-D Romeo
Maurice
_______________________________________________ NLNOG mailing list NLNOG at nlnog.net http://mailman.nlnog.net/mailman/listinfo/nlnog
On Tue, 17 Oct 2006, Romeo Zwart wrote:
Bijvoorbeeld, fout gekonfigureerde velden in een SOA kunnen een onnodige verhoging van de query rate op DNS servers opleveren.
Grappig. Op de laatste IETF was juist een presentatie die het tegendeel aangaf. Bijna alle domeinen hebben een veel te lage SOA TTL waarde. Paul
Paul Wouters wrote:
On Tue, 17 Oct 2006, Romeo Zwart wrote:
Bijvoorbeeld, fout gekonfigureerde velden in een SOA kunnen een onnodige verhoging van de query rate op DNS servers opleveren.
Grappig. Op de laatste IETF was juist een presentatie die het tegendeel aangaf. Bijna alle domeinen hebben een veel te lage SOA TTL waarde.
Right... en een te lage TTL voor een domein levert een te hoge query/refresh rate voor het desbetreffende domein. Dus dat van dat 'tegendeel' volg ik niet helemaal.... :) Romeo
Paul
Bijvoorbeeld, fout gekonfigureerde velden in een SOA kunnen een onnodige verhoging van de query rate op DNS servers opleveren.
Grappig. Op de laatste IETF was juist een presentatie die het tegendeel aangaf. Bijna alle domeinen hebben een veel te lage SOA TTL waarde.
Heb je daar een URL van? Maurice
On Wed, 18 Oct 2006, Maurice Sienema wrote:
aangaf. Bijna alle domeinen hebben een veel te lage SOA TTL waarde.
Heb je daar een URL van?
http://www3.ietf.org/proceedings/06jul/slides/dnsop-3.pdf Lixia Zhang's presentation covers draft-pappas-dnsop-long-ttl-02.txt.
Bijvoorbeeld, fout gekonfigureerde velden in een SOA kunnen een onnodige verhoging van de query rate op DNS servers opleveren. Dat kan vervelend zijn voor de servers van het domain waar het om gaat (en dat is idd je eigen zaak), maar dit heeft vanzelfsprekend ook impact op de domainservers die 'hoger in de boom' zitten. Waarmee de foute configuratie van een subdomein opeens een zaak van het gehele Internet geworden is.
Kijk, dat is een technische verklaring waar ik iets mee kan, maar heb er gelijk vraagtekens bij, want het is heel eenvoudig door SIDN te overrulen met een eigen minimum TTL/expire tijd. Hiermee voorkom je dan ook dat na de NScontrole de waarden alsnog verlaagd worden naar onacceptabele waarden. Maurice
Bijvoorbeeld, fout gekonfigureerde velden in een SOA kunnen een onnodige verhoging van de query rate op DNS servers opleveren. [..]
On 18 okt 2006, at 08:56, Maurice Sienema wrote:
Kijk, dat is een technische verklaring waar ik iets mee kan, maar heb er gelijk vraagtekens bij, want het is heel eenvoudig door SIDN te overrulen met een eigen minimum TTL/expire tijd. Hiermee voorkom je dan ook dat na de NScontrole de waarden alsnog verlaagd worden naar onacceptabele waarden.
Kun je stap voor stap aangeven hoe SIDN invloed kan uitoefenen op TTL's van delegated data? Ik neem aan dat je denkt dat SIDN een TTL van zeg twee dagen aan NS records kan hangen, en dat die data voorrang houdt boven wat de nameservers van het domein zelf zeggen. Bijvoorbeeld voor jou: --- ; <<>> DiG 9.2.4 <<>> ns io.nl @ns.domain-registry.nl ;; AUTHORITY SECTION: io.nl. 7200 IN NS ns.isd-holland.nl. io.nl. 7200 IN NS ns2.isd-holland.nl. ; <<>> DiG 9.2.4 <<>> ns io.nl @ns.isd-holland.nl ;; ANSWER SECTION: io.nl. 86400 IN NS ns2.isd-holland.nl. io.nl. 86400 IN NS ns.isd-holland.nl. --- Zoals je ziet is de TTL die de .nl nameservers meegeven anders dan die jij meegeeft. Als ik aan mijn caching nameserver dezelfde vraag stel krijg ik: --- ; <<>> DiG 9.2.4 <<>> ns io.nl ;; ANSWER SECTION: io.nl. 79302 IN NS ns.isd-holland.nl. io.nl. 79302 IN NS ns2.isd-holland.nl. --- Zoals je ziet wordt de data die mijn cache kreeg van de nl. servers overschreven door de data ontvangen van de daadwerkelijke authoritative servers. Dus SIDN kan data niet 'overrulen'. -- Niels.
Al eens geprobeerd een .fr aan te vragen ? ;-) Die zijn nog veel erger. At 16:55 17-10-2006, you wrote:
SIDN is de enige TLD ( die ik ken ) die de zone test voor aanvraag of verhuizing. Maar de technische kant van de zone is zaak van de ISP en niet $TLD_beheerder, oftewel ik vindt dat ze zich bemoeien met zaken die hun niet aangaan. Deze vraag heb ik me ook al eens afgevraagd voor het hele DRS 4.0 debakel.
Maurice _______________________________________________ NLNOG mailing list NLNOG at nlnog.net http://mailman.nlnog.net/mailman/listinfo/nlnog
Met vriendelijke groet, Jeroen Wunnink, EasyHosting B.V. Systeembeheerder systeembeheer at easyhosting.nl telefoon:+31 (035) 6285455 Postbus 48 fax: +31 (035) 6838242 3755 ZG Eemnes http://www.easyhosting.nl http://www.easycolocate.nl
On Tue, 17 Oct 2006, Steven Bakker wrote:
Kan iemand mij hier misschien vertellen waarom SIDN eigelijk nameserver controles uitvoert bij het aanvragen en verhuizen van .NL domeinen, zelf kunnen ze het namelijk niet uitleggen.
Dat is de erfenis van Piet Beertema, lijkt me. Die weigerde domeinen te registreren als ze niet voldeden aan de (zijn) eisen. Deze gewoonte is doorgezet in SIDN en, zoals ook in religies gebeurt, verheven tot een ritueel. ;-)
Helaas hebben de juristen dat allemaal stukje bij beetje weten af te breken :P Die checks zijn overigens wel beter geworden in recente tijden (net voor drs4), zodat ook DNS fouten via forms konden worden hersteld zonder menselijk contact bij SIDN. Dus ik heb eigenlijk weinig problemen met de checks die ze uitvoeren. Ik heb wel problemen met het feit dat ze dingen verplichten, en bij overtreding ervan zeggen geen sancties te kunnen uitoefenen. Je krijgt dan partijen die domeinen illegaal terug verhuizen (de klant had zijn rekening aan hun nog niet betaald) of die gewoon de klant helemaal droppen en geen dns meer draaien, niet aan ns.nl.net vertellen dat ze niet meer secondary moeten draaien, of geen AXFR's naar/van de andere deelnemer laten werken zodat klant zijn domein enkele dagen flaky of geheel uit de lucht is. Paul
Ik heb wel problemen met het feit dat ze dingen verplichten, en bij overtreding ervan zeggen geen sancties te kunnen uitoefenen. Je krijgt dan partijen die domeinen illegaal terug verhuizen (de klant had zijn rekening aan hun nog niet betaald) of die gewoon de klant helemaal droppen en geen dns meer draaien, niet aan ns.nl.net vertellen dat ze niet meer secondary moeten draaien, of geen AXFR's naar/van de andere deelnemer laten werken zodat klant zijn domein enkele dagen flaky of geheel uit de lucht is.
Paul, zeg eens eerlijk, draait XTDnet 2 weken secondary voor wegverhuisde domeinen? lijkt me een lastige zaak tegenwoordig, want de meeste nameservers hebben inderdaad AXFR uitgeschakeld staan. Ik geef toe dat het bij ons niet gebeurd. Wat ik veel kwalijker vind zijn providers die authoritive nameservers gebruiken als recursive nameserver en een wegverhuisd domein niet verwijderen van hun nameservers. Ik ben hier een aantal keren tegenaan gelopen bij het opsporen van email problemen. Maurice
On Wed, Oct 18, 2006 at 08:56:57AM +0200, Maurice Sienema wrote:
Paul, zeg eens eerlijk, draait XTDnet 2 weken secondary voor wegverhuisde domeinen? lijkt me een lastige zaak tegenwoordig, want de meeste nameservers hebben inderdaad AXFR uitgeschakeld staan. Ik geef toe dat het bij ons niet gebeurd.
Maar jullie zijn zelf onderdeel van het probleem, want jullie nameservers staan voor zover ik kan nagaan zelf ook geen axfr's toe.
Wat ik veel kwalijker vind zijn providers die authoritive nameservers gebruiken als recursive nameserver en een wegverhuisd domein niet verwijderen van hun nameservers. Ik ben hier een aantal keren tegenaan gelopen bij het opsporen van email problemen.
Als iedere isp zonetransfers toe zou staan is het twee weken secondary draaien te automatiseren, en dan is ook dit geen probleem meer. Maarten -- "Voor onze veiligheid moeten we een beetje van onze privacy inleveren." -- Huis-aan-huisfolder "Nederland tegen terrorisme"
On Wed, Oct 18, 2006 at 11:22:27AM +0200, Maarten te Paske wrote:
Als iedere isp zonetransfers toe zou staan is het twee weken secondary draaien te automatiseren, en dan is ook dit geen probleem meer.
Dat zou natuurlijk eventueel op te lossen zijn door iets van een proxy-systeem. We laten allemaal SIDN toe, dus als die op hun beurt een machine openzetten voor gereigistreerde deelnemers zou het kunnen. Hoeven we in ieder geval geen lijstjes te circuleren wie er AXFR mag doen. MarcoH
On Wed, Oct 18, 2006 at 03:24:25PM +0200, Marco Hogewoning wrote:
On Wed, Oct 18, 2006 at 11:22:27AM +0200, Maarten te Paske wrote:
Als iedere isp zonetransfers toe zou staan is het twee weken secondary draaien te automatiseren, en dan is ook dit geen probleem meer.
Dat zou natuurlijk eventueel op te lossen zijn door iets van een proxy-systeem. We laten allemaal SIDN toe, dus als die op hun beurt een machine openzetten voor gereigistreerde deelnemers zou het kunnen.
Hoeven we in ieder geval geen lijstjes te circuleren wie er AXFR mag doen.
Hoezo een lijstje circuleren? Wat mij betreft zet je het voor de hele wereld open. Dichtzetten uit veiligheidsoverwegingen vind ik security by obscurity. Maarten -- "Voor onze veiligheid moeten we een beetje van onze privacy inleveren." -- Huis-aan-huisfolder "Nederland tegen terrorisme"
On Wed, Oct 18, 2006 at 03:24:25PM +0200, Marco Hogewoning wrote:
[..]
Hoeven we in ieder geval geen lijstjes te circuleren wie er AXFR mag doen.
Hoezo een lijstje circuleren? Wat mij betreft zet je het voor de hele wereld open. Dichtzetten uit veiligheidsoverwegingen vind ik security by obscurity.
Maarten
Voor zo ver het de content van de zone betreft, ja. Maar het grondig beperken van het aantal mensen wat uberhaupt met (een deel van) je nameserver proces kan spreken, en daarbij eventuele bugs kan exploiten, of DoS veroorzaken, is wel een re?ele security overweging. Idem voor veel meer (ooit standaard publieke) services zoals dns resolvers, ntp e.a. Hoe jammer ook. Boudewijn
On Wed, Oct 18, 2006 at 04:44:45PM +0200, Boudewijn Visser wrote:
Voor zo ver het de content van de zone betreft, ja. Maar het grondig beperken van het aantal mensen wat uberhaupt met (een deel van) je nameserver proces kan spreken, en daarbij eventuele bugs kan exploiten, of DoS veroorzaken, is wel een re?ele security overweging.
Tsja, ik kan wel wat dingen bedenken die spannender zijn dan een nameserver die zonetransfers toestaat. Apache en het uitvoeren van serverside code bijvoorbeeld :)
Idem voor veel meer (ooit standaard publieke) services zoals dns resolvers, ntp e.a. Hoe jammer ook.
Volgens mij doet men hier veel te dramatisch over. Ik heb bij een tweetal ISP's gewerkt waar dit werd toegestaan zonder dat dat ooit problemen heeft opgeleverd. Ik vind het een hele andere kwestie dan het openzetten van je resolvers voor de hele wereld, waarvan iedereen inmiddels wel weet dat dat onverstandig is. Maarten -- "Voor onze veiligheid moeten we een beetje van onze privacy inleveren." -- Huis-aan-huisfolder "Nederland tegen terrorisme"
Hi!
Hoeven we in ieder geval geen lijstjes te circuleren wie er AXFR mag doen.
Hoezo een lijstje circuleren? Wat mij betreft zet je het voor de hele wereld open. Dichtzetten uit veiligheidsoverwegingen vind ik security by obscurity.
Daar denken een aantal van onze klanten toch echt anders over. En kan ze op zich geen ongelijk geven. Bye, Raymond.
On Wed, Oct 18, 2006 at 11:30:32PM +0200, Raymond Dijkxhoorn wrote:
Daar denken een aantal van onze klanten toch echt anders over. En kan ze op zich geen ongelijk geven.
Ik heb bij twee ISP's gewerkt die dit toestond, en daar waren welgeteld twee klanten die hier ooit bezwaar tegen hebben gemaakt, beiden na een audit door een security bedrijf dat dit had genoemd. Maargoed, dan bied je die klanten de optie het niet voor hun domeinen te doen, met de kanttekening dat domeinverhuizingen hierdoor minder makkelijk zullen verlopen. Dat is iig. mijn ervaring met het verhuizen van domeinnamen: het zou enorm veel problemen de wereld uit helpen. Maarten -- "Voor onze veiligheid moeten we een beetje van onze privacy inleveren." -- Huis-aan-huisfolder "Nederland tegen terrorisme"
On Wed, 18 Oct 2006, Maurice Sienema wrote:
Paul, zeg eens eerlijk, draait XTDnet 2 weken secondary voor wegverhuisde domeinen?
Xtdnet kijkt altijd of het secondary *kan* draaien voor verhuisde domeinen. Dit is al jaren niet meer gelukt. Vroeger stuurden we nog wel een email naar de nieuwe Deelnemer, maar aangezien dat nooit een correctie opleverde zijn we daar mee gestopt.
lijkt me een lastige zaak tegenwoordig, want de meeste nameservers hebben inderdaad AXFR uitgeschakeld staan.
AXFR kun je per domein en per IP aan en uitzetten. Paul
On Wed, 18 Oct 2006, Paul Wouters wrote:
Paul, zeg eens eerlijk, draait XTDnet 2 weken secondary voor wegverhuisde domeinen?
Xtdnet kijkt altijd of het secondary *kan* draaien voor verhuisde domeinen.
En nu ik net een DRS4 verhuizing afgerond heb, kan ik SIDN het volgende melden: Voor DRS3 had ik na enkele jaren het eindelijk voor elkaar dat in het verhuizingsformulier de primary nameserver van de nieuwe Deelnemer genoemd werd, zodat het technisch MOGELIJK is te voldoen aan de eisen om secondary te draaien op de nieuwe Deelnemer. In DRS4 is dat weer verdwenen. Onderstaande domein zal dus gedurende een dag ofzo "stuk" zijn, omdat wij niet weten waar de nieuwe primary nameserver zich bevindt Je moet dus nu eerst toestemming geven voor verhuizing. Dan verhuist SIDN het domein binnen X tijd. Na X tijd kun je dan een whois doen om te zien waar de nieuwe primary staat. En uiteraard: ns.xtdnet.nl# host -t axfr XXXXX.nl ns0.XXXXXXX.net Host XXXXX.nl not found: 5(REFUSED) Paul
On Tue, 17 Oct 2006, Maurice Sienema wrote:
P.S: Het begint me zo langzamerhand aaardig op m'n zenuwen te werken hoe SIDN zich verslikt heeft in de introductie van DRS4.0
Tja. Dat was achter gesloten deuren besloten, ofwel in de woorden van het bestuur "er was een schrijven na enkele partijen gestuurd". Na aandringen van enkele Deelnemers (waaronder xtdnet) op de Deelnemersvergadering is er toen een "publieke oproep" gekomen zodat andere partijen dan vriendjes ook een bod konden brengen voor het nieuwe registratie systeem. Die oproep kwam ergens onderin een hoekje van de website, met een tijdslimiet van enkele dagen. Uiteraard veranderde dit niets aan wie het contract kreeg. Mijn opmerkingen verder toen waren nog: - Zorg dat je het Intellectuele Eigendomsrecht van DRS4 krijgt, zodat je niet vendor locked bent. Lieft opensource, zodat het geld optimaal nuttig gebruikt wordt en andere TLD's het ook kunnen gebruiken. - Flikker Oracle eruit voor Postgres. - Zorg voor simpele PC dozen die je kunt stapelen als de load hoger wordt - Support DNSSEC - Support IPv6 Ik ben aanwezig geweest op twee "feel good" meetings waarin sociologen en Ratelbandachtige figuren probeerden ons te laten voelen dat wij in het beslissingstraject waren opgenomen. Nadat duidelijk werd hoe en wie DRS4 verder ging implementeren, heb ik tevens een punt gezet achter mijn aanwezigheid bij de Deelnemer vergaderingen. Ik heb geen zin op als excuus te gelden voor "de deelnemers hebben ook inspraak". SIDN vraagt zich dan ook nog af waarom Deelnemers niet uitgebreidt aan het "test systeem" hebben lopen testen. Tja, als er zoveel geld wordt weggesmeten voor proprietary software, dan ga ik niet even lekker mijn uren gratis weggeven..... Xtdnet heeft na 1 poging tot registratie de boel even bevroren, maar grotere collega's hebben die luxe natuurlijk niet. Paul
participants (11)
-
bvisser-nlnog＠xs4all.nl -
jan.meijer＠surfnet.nl -
jeroen＠easyhosting.nl -
maarten＠tepaske.net -
marcoh＠marcoh.net -
niels.bakker＠ams-ix.net -
paul＠xtdnet.nl -
raymond＠prolocation.net -
Romeo.Zwart＠ams-ix.net -
sienema＠io.nl -
steven.bakker＠ams-ix.net