Bekijk Volledige Versie : "Kwaliteits eisen sidn"
Gedurende webcast van "ledendag" zei men dat het controleren van zonefiles tot hun taak behoorden om kwaliteit eisen te kunnen waarborgen dat dit één van de punten is waarop real-time "gefrustreerd" zou worden.
Zoals we allen weten is dit geen beletsel voor ALLE grote tld's zoals .COM derhalve de stelling Is het controleren van zonefiles echt noodzakelijk voordat je een domein registreert of verhuisd? .
Graag je mening met onderbouwing.
Is het controleren van zonefiles echt noodzakelijk voordat je een domein registreert of verhuisd?
Ik vind van niet. Als je perse wilt zien in hoeverre je registrars zonefiles correct hebben kun je dat achteraf toetsen. Echter is het de vraag of een registry mag bepalen of en hoe iemand zijn domein gebruikt.
Om een vergelijk te trekken met de bekende "Mercedes" de dealer/fabrikant gaat ook niet vooraf controleren of je wel een rijbewijs hebt, voordat je de auto mag aanschaffen, laat staan dat hij achteraf (blijft) controleren of je een rijbewijs hebt of er überhaupt meerijd.
Een domeinnaam is in feite een bezit, die zolang je betaald aan de instandhouding van de achterliggende infrastructuur tot je beschikking blijft. (net zoals geld een virtueel bezit is)
Het is dan ook eigenlijk gek dat een derde partij die tevens monopolist is kan bepalen wat je met je bezit mag doen.
Zou iemand het accepteren dat voordat je geld opneemt een controle door moet lopen, of voordat je geld overschrijft?
Ja, en van mij mag deze nog wel veel stricter. Nameservers in dezelfde /24 mag direct tot een afwijzing leiden, zoals ze ook in Duitsland doen (laat ik de controle op postmaster@ nog even achterwege).
En ook de Mercedes dealer controleert of jij een rijbewijs hebt, je wilt immers een proefrit maken. En anders kun je hem niet - tenminste niet zonder een bestuurder met rijbewijs te benoemen - verzekeren.
Van de Mercedes na de bank: Voordat ik geld opneem, kijken ze echt wel of mijn saldo toereikend is.
Waar maak je je trouwens druk om, als niet SIDN-deelnemer?
het controleren van de nameservers is debiel, soms willen mensen gewoon de naam vastleggen, en er even nog niets mee doen. Dan moet je een lege zone koppelen aan de naam, enkel en alleen omdat SIDN dat wil.
het controleren van de nameservers is debiel, soms willen mensen gewoon de naam vastleggen, en er even nog niets mee doen. Dan moet je een lege zone koppelen aan de naam, enkel en alleen omdat SIDN dat wil.
En hier komt een register-only functie voor. Domeinen kun je dan al wel registreren, maar ze bestaan niet in de zonefile. Dus geen 'vervuiling' van het Internet met niet bestaande websites.
Er worden gewoon technische eisen gesteld aan een domeinnaam, waaronder een bereikbare en goed-geconfigureerde DNS.
Klote systeem
Ging laatst mijn nameservers updaten gaan ze 1 voor 1 alle domeinen langs.
Hoppa moet ik broken domeinen eerst in DNS plaatsen.
Iets wat ik niet wil sommige domeinen wil ik helemaal niet in DNS hebben
wil ze puur voor "de heb" zoals je met .com en net domeinen kan doen.
Hun technisch systeem doet het ook voor geen moer
zojuist even gekeken
Krijg dit :)
alle correspondentie te vermelden.
De DNS gegevens zijn onjuist.
Voor meer informatie kunt u contact opnemen met Registratie en Service van SIDN:
026-3525555
support@sidn.nl
Met vriendelijke groet,
SIDN
Errors=0, Warnings=0, Informational=2
** Summary: ACCEPTED truongdns.nl.
** Full check report:
* primary name server "ns1.truongdns.nl."
Info: name server looks correctly configured.
* secondary name server "ns2.truongdns.nl."
Info: name server looks correctly configured.
** DNScheck 4.2.4, 2008/10/26 04:57:07 CET+0100
#### success
-----BEGIN PGP SIGNATURE-----
en een lege zone is geen vervuiling?
De taak van sidn is het mogelijk maken van registraties van domeinnamen, en niet het spelen van rechter/politie over de setup van de zones bij derden. Hoeveel keer dat wij problemen hebben met klanten die een domein registreren maar hun eigen zone niet op orde hebben...
en een lege zone is geen vervuiling?
De taak van sidn is het mogelijk maken van registraties van domeinnamen, en niet het spelen van rechter/politie over de setup van de zones bij derden. Hoeveel keer dat wij problemen hebben met klanten die een domein registreren maar hun eigen zone niet op orde hebben...
Tsjah zou eigenlijk dan iets moeten hebben van dat het domein eerst goed werkt op jullie DNS zodra hij geregistreerd is aanpassen.
Niet de meest ideale optie maar SIDN luistert nou eenmaal niet (naar de kleintere onder ons)
Nee, flauwe onzin, is helemaal niet nodig, ik ben het helemaal met Bernard eens! Laat de SIDN nu eens gewoon domeinnamen uitgeven en zorgen dat ze hun zaakjes op orde hebben ipv allemaal nieuwe flauwe onzin verzinnen... oh ja dit had natuurlijk iemand op het domeinnaamdebat voorgesteld daar wordt toch alles beslist?
Absoluut onnodig, volg de stelling van Wonko voor 100%.
Wij hebben veel klanten die een NL domeinnaam willen, maar er nog niets willen met doen. Nu moeten wij onze dns servers 'vervuilen' door die zones totaal onnodig aan te maken. Als het voor de COM's, EU's, BE's niet moet, waarom zou het dan voor de NL's moeten? Omdat zij een superieur systeem hebben .... proesttttt ...
sven
Wij hebben veel klanten die een NL domeinnaam willen, maar er nog niets willen met doen.
Hier luistert de SIDN wel naar en wil daarom een register only functie. Met de nieuwe processen die vanaf EPP komen, kun je een domein registreren. Die wordt dan altijd geregistreerd. Als je de DNS op orde hebt komt hij in de zone en anders niet. Dan is de domein gewoon geregistreerd. Dan heb je toch wat je wil?
Ik vraag me echt af, is het ineens SIDN bash week geworden?
Een domeinnaam is er om bereikbaar te zijn op het internet, je wil er immers een website achter zetten.
Dat er dan DNS eisen door de registar worden gesteld vind ik volkomen normaal, ik zou het zelfs nog strenger willen zien. Zoals al aangegeven werd, de DNS servers mogen niet in het zelfde subnet.
Maar tegenwoordig schijnt iedereen RFC's te negeren onder het mom van marketing en commercieële doeleinden.
Nee, niks mis mee, mag van mij zelfs nog strenger. DNS is de basis van het internet en dat moet gewoon netjes geregeld zijn.
Als je het te veel werk vindt je DNS in orde te hebben vraag ik me af waar je mee bezig bent, maar dat is puur mijn eigen mening.
Met de nieuwe processen die vanaf EPP komen, kun je een domein registreren.Moet er wel eerst EPP komen ;) en gezien het huidige resultaat kunnen we nog wel wachten tot 2010 en dan nog moeten we zien of het gaat werken...
Ik vraag me echt af, is het ineens SIDN bash week geworden?De SIDN begint!! wij niet en die week die kan nog wel eens maanden worden! Ik wil het trouwens geen bashen noemen maar commentaar leveren op hun idioote voorstellen...
Ik ben het eens met Wonko, dus heb NEE gestemd. Het gaat hier om een domein wat je wil vastleggen, je koopt het, je hoeft er (nog) niets mee te doen.
Ik heb Nee gestemt.
Hoewel ik het goed vind dat het gecontroleerd wordt (verhoogd de kwaliteit van het .nl domein) heb ik ook veel gemak van de manier waarop ik domeinen kan registreren bij .com enz.
Wido,
en ja, waarom geen verplichte cursussen organiseren voor deelnemers, waar de basis van dns wordt uitgelegd en examens inrichten enz .... komt ook allemaal ten goede aan de stabiliteit van het dns systeem.
Waar zijn we met bezig zeg, enkele dns servers installeren en inrichten is nu niet bepaald rocket science, als je dat niet kan, dan moet je je niet in de hosting branche begeven (zoals er inderdaad wel zijn, DA als controlepaneel installeren, 2 ip's op hun gehuurde server en aan elk ip een dns server binden).
sven
Triloxigen
14/12/08, 12:07
het controleren van de nameservers is debiel, soms willen mensen gewoon de naam vastleggen, en er even nog niets mee doen. Dan moet je een lege zone koppelen aan de naam, enkel en alleen omdat SIDN dat wil.
Mee eens.
Ik bepaal zelf wel wat ik met de naam wil doen, niet de SIDN. Straks gaan ze nog verplichten dat er een website op moet
:ban:
Ik twijfel nog.
Aan de ene kant vind ik dat SIDN zich hier niet mee hoeft te bemoeien. Dit zou toch de verantwoordelijkheid moeten zijn van de deelnemer.
Maar aan de andere kant vind ik dat SIDN wel voor een bepaalde kwaliteit moet staan. Dus in dat opzicht, als er zo nodig een DNS check moet zijn, doe het dan goed. Zoals Randy en Wido ook al aangeven.
Wil die check goed werken moeten ze toch eerst zorgen dat hun systemen zelf kloppen lijkt me zo.
Regelmatig loop ik er zelf tegenaan en ook con-collega's dat er geen enkele fout in staat en de Sidn gewoonweg teruggeeft er zijn fouten gevonden maar in die check staat alles goed.
Dus willen ze dit inderdaad doen zullen ze bij de sidn toch eerst zelf hun systemen op orde moeten hebben en dat hebben ze dus niet.
Tim.Bracquez
14/12/08, 12:23
ja, zelfs mogen ze iets strenger worden (ander subnet...)
Je moet je zaakje maar goed regelen, enkele dns recordjes meer of minder moet niet echt een probleem/kostelijk zijn.
Is onmiddellijk een soort van 'keurmerk' voor je DNS
Ja, zolang die "register-only" functie er komt.
*ALS* je een domein in de DNS zet, dan moet 'ie ook gewoon aan de standaarden voldoen. Dus inderdaad, niet beide nameservers in hetzelfde subnet. Sterker nog, wat mij betreft gaat dat zelfs nog een stap verder: minimaal 2 nameservers in 2 verschillende AS'en. Anders krijg je weer van die grappenmakers die bij hun colo provider om 2 IP's uit verschillende subnetten gaan vragen, om er alsnog omheen te komen.
En het is nou ook niet zo dat een extra nameserver in een ander AS, nou verschrikkelijk duur hoeft te zijn; de lichtste VPS is al genoeg.
DNS is gewoon een belangrijk onderdeel van de infrastructuur; als je 't doet, doe 't dan goed. De "register-only" functie is dan uiteraard wel een goede optie; wil je een domein niet in DNS, dan moet dat geen probleem zijn en zeker geen reden om registratie te weigeren.
Ik mis de optie "geen van beide" in de poll.
Een domeinnaam registreer je om daarna ooit te kunnen gebruiken. Dat hoeft nog niet meteen te zijn (bijvoorbeeld eerst nog een concept uitwerken) en misschien is het ook wel nooit (alleen om je handelsnaam te beschermen bijvoorbeeld). Een register-only functie zou heel gewenst zijn.
Een domeinnaam is wat mij betreft ook alleen een pointer in het DNS gebeuren. De naam zegt het natuurlijk al. Ook als de naam gebruikt gaat worden, hoeft dat nog niet te betekenen dat er een website op komt! Een website is zo'n ding op poort 80 dat leesbaar is voor humans. Misschien wil ik wel hele andere dingen ermee. Bijvoorbeeld embedded machine dingen. Verplichten dat er dan verplicht @postmaster mail naartoe gestuurd kan worden, vind ik dan ook niet nodig. Via de whois is ook contact te zoeken met de eigenaar.
Voor domeinnamen die wel gebruikt worden, zou de controle nog best strenger mogen. Ik bedoel je staat als zonefile beheerder toch voor een bepaalde kwaliteit. Ook de whois info mag strenger gecontroleerd worden.
Misschien is het een idee om via synchrone registratie methode in eerste instantie alleen een register-only domein aan te maken. En dat je daarna dan opname in de zonefile aan kunt vragen wat dan eerst streng gecontroleerd wordt.
Wouter-Ospito
14/12/08, 14:37
In de huidige situatie heb ik voor 'nee' gekozen. Puur omdat wij er ook regelmatig mee te maken hebben dat klanten enkel een domein willen vastleggen voor toekomstig gebruik. Dan kan ik die wel aanmaken op het DNS cluster, maar als mijn klant (bijv. reseller) dan zelf in de toekomst een account aanmaakt krijgt die de melding dat de DNS zone al bestaat. Nu moet ik dus eerst een domein in de DNS aanmaken, registreren bij SIDN en vervolgens weer verwijderen uit de DNS. Beetje omslachtig en werk voor niets.
Zodra de register-only functie komt mag er wat mij betreft wel op gecheckt worden en vind ik het op zich een goede zaak. Ik ben dan (denk ik) ook voorstander van strengere eisen, aan de andere kant: als iemand de boel niet op orde heeft, wat zal jou dat interesseren? Als jij je zaakjes maar op orde hebt. De eis dat postmaster@... moet bestaan vind ik overigens absoluut belachelijk. Het lijkt me eerlijker dat er dan een check gedaan wordt of het e-mailadres dat in de whois komt te staan wel echt bestaat. En dan uiteraard niet eenmalig bij registratie, maar bijv. elk kwartaal.
En hier komt een register-only functie voor. Domeinen kun je dan al wel registreren, maar ze bestaan niet in de zonefile. Dus geen 'vervuiling' van het Internet met niet bestaande websites.
Er worden gewoon technische eisen gesteld aan een domeinnaam, waaronder een bereikbare en goed-geconfigureerde DNS.
Leuk verhaal, maar onderbouw het eens. Waarom zou het niet resolven van bepaalde domeinnamen het internet vervuilen? Ik kan daar geen enkel argument voor bedenken. Bij een .com domein kan je ook een registratie indienen en maanden later een keer de DNS opzetten. Dit vervuilt het in internet totaal niet, en daarnaast wordt er ondertussen ook gewoon voor het domein betaald.
Ik vind juist dat de vereiste dat een domein moet resolven, bijdraagt aan de vervuiling op het internet. Je verplicht men nu om domeinnamen die niet daadwerkelijk gebruikt worden, te laten resolven, vaak naar een landingspagina zonder nuttige informatie. DAT vervuilt het internet.
Ja, en van mij mag deze nog wel veel stricter. Nameservers in dezelfde /24 mag direct tot een afwijzing leiden, zoals ze ook in Duitsland doen (laat ik de controle op postmaster@ nog even achterwege).
Wat is daar de meerwaarde van ?
Indien je een actieve DNS synchronisatie proces gebruikt kun je redenen hebben omdat juist NIET over verschillende netwerken te verspreiden omdat dit juist stabiliteit in gevaar brengt. Immers de uptime van 1 netwerk kun je wel garanderen (ook al is hij niet aan het internet verbonden zolang locale infrastructuur werk -switches- loopt je actieve sync proces geen gevaar)
En ook de Mercedes dealer controleert of jij een rijbewijs hebt, je wilt immers een proefrit maken. En anders kun je hem niet - tenminste niet zonder een bestuurder met rijbewijs te benoemen - verzekeren.
Domein "proeven" kan niet, dus dit kun je niet vergelijken.
Je kan zonder rijbewijs een auto op naam + verzekering op naam hebben staan. Sterker nog, je kunt zelfs zonder een mens te zijn dit bewerkstelligen (rechtspersoon).
Van de Mercedes na de bank: Voordat ik geld opneem, kijken ze echt wel of mijn saldo toereikend is.
Kijken of het geld beschikbaar is is een metafoor voor Whois, waarin beschikbaarheid van het domein word gecontroleerd. Wanneer en hoe jij je geld gaat toepassen is geen aangelegenheid van de bank.
Waar maak je je trouwens druk om, als niet SIDN-deelnemer?
Er is een reden waarom ik geen SIDN deelnemer ben. Zolang EPP er niet is koop ik goedkoper in dan alle SIDN deelnemers die onder de 2000 domeinen hebben. (4,30 zonder mutatie kosten te hoeven betalen en vanaf volgend jaar als SIDN door gaat 3,80) dat geeft me straks 800 euro concurrentie voordeel. Alleen voor EPP zou ik 800 per jaar willen betalen aangezien je dat zo terug verdiend hebt.
Dus geen 'vervuiling' van het Internet met niet bestaande websites.
Wat is vervuiling ? Als je lameserver kosten gaan omrekenen naar daadwerkelijke kosten die je o.a. aan support and bandbreedte kwijt bent dan is het onzinnig omdat als argument aan te houden.
Hier luistert de SIDN wel naar en wil daarom een register only functie. Met de nieuwe processen die vanaf EPP komen, kun je een domein registreren. Die wordt dan altijd geregistreerd. Als je de DNS op orde hebt komt hij in de zone en anders niet. Dan is de domein gewoon geregistreerd. Dan heb je toch wat je wil?
Dus als een klant eens besluit om zone te gaan gebruiken dienen registrars een handeling te plegen...
Als dat een kwestie is van nameservers middels EPP updaten is dat geen probleem dat kun je automatiseren, maar als dat handmatige handelingen betreft die ook nog eens EERST gecontroleerd worden is dat zeer lastig.
Ik vraag me echt af, is het ineens SIDN bash week geworden?
Volgens mij heb ik 10 jaar geleden veel van de huidige argumenten ook al eens in nl.providers voorbij zien komen, het is alleen nu dat SIDN wederom het voor elkaar krijgt om een groep van haar "leden" te passeren dat het tijd word dat er zaken structureel opgelost worden.
Een domeinnaam is er om bereikbaar te zijn op het internet, je wil er immers een website achter zetten.
Nee hoor, er zijn genoeg domeinen waar helemaal niets of alleen een MX record aan hangt.
Als je een ISDN2 lijn neemt krijg je er ook 4 telefoonnummers bij je hoeft ze niet te gebruiken en ik schat zo in dat de meeste mensen ze ook niet gebruiken aangezien je een ISDN2 telefooncentrale hebt die nummers kunnen routeren naar functie. (b.v. een nummer naar een fax etc..)
Dat er dan DNS eisen door de registar worden gesteld vind ik volkomen normaal, ik zou het zelfs nog strenger willen zien. Zoals al aangegeven werd, de DNS servers mogen niet in het zelfde subnet.
Wat is daar het nut van? Meeste partijen hebben 1 adress space waar al de door hun gehoste zaken in staan.
Dus ook al zouden de nameservers in verschillende subnetten staan dan zal het geresolved adress vaak toch al niet werken.
De verschillende subnetten staan in verbinding met een gateway, meestal een router, dat is nog steeds een single point of failure.
Als je perse wilt dat DNS altijd resolved, dan dien je gebruik te maken van twee verschillende netwerken in twee verschillende DC's. Maar is het resolven van een adres het eind doel ?
Zoals ik begon, wat is het nut? Klanten die ECHT willen dat ze ten alle tijden geresolved kunnen worden omdat ze b.v. niet bij je hosten zullen of hun eigen nameservers hebben of technische eisen aan hun leveranciers stellen.
Voor 95% van de huidige .NL gebruikers is de noodzaak er gewoon weg niet.
Maar tegenwoordig schijnt iedereen RFC's te negeren onder het mom van marketing en commercieële doeleinden.
Sinds wanneer staat er in de RFC's dat dit verplicht is? Welke rfc ?
Nee, niks mis mee, mag van mij zelfs nog strenger. DNS is de basis van het internet en dat moet gewoon netjes geregeld zijn.
En ik maar denken dat IP dat was...
Stelling klopt overigens wel als je het over het WWW hebt.
Als je het te veel werk vindt je DNS in orde te hebben vraag ik me af waar je mee bezig bent, maar dat is puur mijn eigen mening.
Het gaat om de administratieve last en de nut en noodzaak van iets.
Als er in een RFC die in de jaren '90 een advies (geen plicht) is afgegeven voor het hebben van DNS servers in verschillende subnets is dat logisch gezien de stabiliteit van verbindingen in die tijd.
Als alles al gehost staat in 1 subnet en je primaire nameserver staat ook in dat subnet dan maakt het niets uit, want als primaire nameserver om wat voor reden niet bereikbaar is, dan is de kans groot dat de rest van dat subnet ook niet bereikbaar is.
Overigens dien je wel onderscheid te maken met infrastructuur van eindgebruiker (ISP's) en die van registries, die laatste dienen zich te bedienen van niet verschillende subnets, maar van verschillende netwerken en DC's.
Maar aan de andere kant vind ik dat SIDN wel voor een bepaalde kwaliteit moet staan. Dus in dat opzicht, als er zo nodig een DNS check moet zijn, doe het dan goed. Zoals Randy en Wido ook al aangeven.
Welke garanties heb je als DNS check klopt? Na goedkeuring hoeft het niet meer te kloppen.
Als je kwaliteit wenst te waarborgen dan dien je te beginnen bij registrars en onderzoeken of ze organisatorisch en financieel voldoende in huis hebben om duurzaam domeinen te registreren. En zodra je een mogelijke probleem voor houders bemerkt ga je actie ondernemen, zoals bij een faillissement of liever daarvoor al (Registerfly vs ICANN).
Op dat vlak is SIDN afwezig.
Ook zou je minimale "kennis" eisen kunnen stellen en dat middels een examen bij aanvraag registrarschap kunnen toetsen. (zowel technisch, als SIDN regels).
Ik vind juist dat de vereiste dat een domein moet resolven, bijdraagt aan de vervuiling op het internet. Je verplicht men nu om domeinnamen die niet daadwerkelijk gebruikt worden, te laten resolven, vaak naar een landingspagina zonder nuttige informatie. DAT vervuilt het internet.
Bovendien is er dankzij de intrede van M$-directory services een noodzaak om intern een zone te hebben. Er zijn genoeg organisaties die een intern en een extern domein hebben om te voorkomen dat ze 4 nameservers moeten hebben.
Ook de whois info mag strenger gecontroleerd worden.
Dat is een andere discussie overigens zal SIDN hier nooit over beginnen omdat het niet te automatiseren is.
Wouter-Ospito
14/12/08, 17:57
Klanten die ECHT willen dat ze ten alle tijden geresolved kunnen worden omdat ze b.v. niet bij je hosten zullen of hun eigen nameservers hebben of technische eisen aan hun leveranciers stellen.
Voor 95% van de huidige .NL gebruikers is de noodzaak er gewoon weg niet.
@pdu: Als heel het netwerk onbereikbaar is wil je juist dat er nog een nameserver extern is die nog wel resolvt. Al was het alleen maar omdat mail dan minder snel direct retour afzender gestuurd wordt (of nog beter: dat deze doorgestuurd kan worden/opgevangen kan worden door een fallback mailserver). Je bewering dat 95% van de mensen dat niet nodig hebben is daarom m.i. niet correct, maar een heel klein deel zal het geen enkel probleem vinden als mail verloren gaat.
SIDN zou beter eerst de zaken in orde brengen die overal wel in orde zijn (EPP, vereenvoudiging web/mail formulieren, ...) vooraleer extra zaken te gaan doen die bij de meeste extenties niet gebruikt worden.
'k Heb de indruk dat SIDN zeer creatief is om van alle onnodige zaken te implementeren/onderzoeken, terwijl ze de basiszaken nog niet netjes in orde zijn.
Sven
@pdu: Als heel het netwerk onbereikbaar is wil je juist dat er nog een nameserver extern is die nog wel resolvt. Al was het alleen maar omdat mail dan minder snel direct retour afzender gestuurd wordt (of nog beter: dat deze doorgestuurd kan worden/opgevangen kan worden door een fallback mailserver). Je bewering dat 95% van de mensen dat niet nodig hebben is daarom m.i. niet correct, maar een heel klein deel zal het geen enkel probleem vinden als mail verloren gaat.
Mits fallback niet in de zelfde netwerk staat.
Hoelang moet een netwerk onbereikbaar zijn voordat hij niet meer resolved?
Als je TTL's kort hebt staan binnen een paar uur.
Standaard probeert een mailserver 5 dagen mail af te leveren, en de meeste mail komt van servers die of zelf het domein in cache hebben of de door hun gebruikte nameserver heeft het in cache, maar een klein percentage zal voor het eerst een domein resolven.
Wouter-Ospito
15/12/08, 09:43
Maar wie gaat er nu z'n fallback mailserver in hetzelfde netwerk zetten? Begrijp me niet verkeerd, ik ben het grotendeels eens met je (lees mijn eerdere post in dit topic met mening over SIDN), maar deze beweringen van je kloppen niet.
Bij veel hosters staat de TTL op 4 uur, als die dus in de afgelopen 4 uur niet is opgevraagd door die DNS server dan is die weg. M.u.v. enkele veel gebruikte domeinen (hotmail.com, gmail.com etc) lijkt het mij juist dat het meerendeel van de domeinen niet één keer in de 4 uur door vrijwel elke DNS servers wordt opgevraagd. Dus in dat geval is een groot deel direct niet meer te resolven.
Het klopt dat een mailserver het 5 dagen zal moeten blijven proberen, maar geloof me (wij doen erg veel met fallback mail), een heel groot deel lapt deze regel (RCF!) aan z'n laars. Vooral mailservers van grotere access ISP's. Daarnaast, als die al 5 dagen de mail blijft proberen af te leveren zal dit niet gelden voor domeinen die niet te resolven zijn.
M.i. moet je als serieuze hoster dus wel echt een secondary DNS en fallback mail buiten je primaire netwerk hebben staan. Je klanten gaan er niet blij van worden als er mail verloren gaat en die kans is zonder secondary DNS en fallback mail wel zeer groot.
Of SIDN daar op moet controleren is een tweede (zie ook mijn eerdere post)...
Hoelang moet een netwerk onbereikbaar zijn voordat hij niet meer resolved?
Als je TTL's kort hebt staan binnen een paar uur.
Standaard probeert een mailserver 5 dagen mail af te leveren, en de meeste mail komt van servers die of zelf het domein in cache hebben of de door hun gebruikte nameserver heeft het in cache, maar een klein percentage zal voor het eerst een domein resolven.
Als je netwerk onbereikbaar is, resolved het dus gewoon gelijk niet meer; dat sommige DNS servers (en dan is dus echt niet de meerderheid) nog wat cache hebben, is leuk, maar dat valt niet onder resolven. Mailservers die je niet de laatste <x> uur gemailed hebben, gaan mail gewoon direct terugsturen naar de verzender, "domein bestaat niet meer". Als je echter gewoon zoals 't hoort een nameserver in een ander netwerk hebt staan, is er niets aan de hand; die fallback server is niet eens nodig, tenzij je netwerk meerdere dagen offline gaat zijn, maar dan heb je wel grotere problemen. Zolang er wel een DNS server voor je netwerk online is, zal mail vertraagd worden afgeleverd, ipv teruggestuurd naar de afzender.
Het staat nou niet bepaald professioneel als de klanten van jouw klanten bij elke storing te lezen krijgen, "sorry, dat domein bestaat niet meer". Tenzij je 't leuk vindt om je klanten uit te leggen dat je geen 5 tientjes in de maand wil uitgeven om je DNS op orde te hebben en dat ze daardoor die grote opdracht zijn misgelopen.
Als je zelf DNS servers wil draaien, doe 't dan wel netjes. Minimaal 2 DNS servers, in 2 verschillende netwerken. Om helemaal veilig te zitten doe je er een derde bij, met een ander TLD, voor 't geval er iets mis gaat in de zone-generator van je normale TLD, zoals GLUE records die ontbreken.
Vind je dat allemaal maar onzin, besteed je DNS dan uit aan een partij die 't wel serieus neemt.
Wouter-Ospito
15/12/08, 15:37
Als je netwerk onbereikbaar is, resolved het dus gewoon gelijk niet meer; dat sommige DNS servers (en dan is dus echt niet de meerderheid) nog wat cache hebben, is leuk, maar dat valt niet onder resolven. Mailservers die je niet de laatste <x> uur gemailed hebben, gaan mail gewoon direct terugsturen naar de verzender, "domein bestaat niet meer". Als je echter gewoon zoals 't hoort een nameserver in een ander netwerk hebt staan, is er niets aan de hand; die fallback server is niet eens nodig, tenzij je netwerk meerdere dagen offline gaat zijn, maar dan heb je wel grotere problemen. Zolang er wel een DNS server voor je netwerk online is, zal mail vertraagd worden afgeleverd, ipv teruggestuurd naar de afzender.
Zo hoort het inderdaad te zijn, maar kan je melden dat dat toch niet altijd zo is. Er zijn zat mailservers die zich niet aan de RFC houden en de mail direct retour afzender sturen als die niet direct afgeleverd kan worden, dat vang je op met een fallback mailserver. Als bijkomend voordeel heb je dan dat je zelf invloed hebt op wanneer iets wordt afgeleverd zodra de primaire mailserver weer online is.
Echt totaal onzin, heb je net een domeinnaam die snel vastgelegd moet worden, moet je eerst regelen dat er een nameserver respont op deze requests.
Van mij mag het weg, bij alle andere bekende domeinen die ik registreer hoeft dit niet? Waarom is NL hier eigenlijk een uitzondering in?
Echt totaal onzin, heb je net een domeinnaam die snel vastgelegd moet worden, moet je eerst regelen dat er een nameserver respont op deze requests.
Ook totale onzin. Je vult gewoon twee willekeurige niet werkende nameservers in en je domein wordt geregistreerd. Snelheid kan het dus niet zijn. Je moet vervolgens wel binnen 7 dagen de DNS een keer werkend maken.
dan nog, tegen de tijd dat je "die simpele mailtjes" (zie andere thread :)) hebt gestuurd, kun je ook wel een lokale DNS server zo ver hebben dat 'ie resolvt voor die naam (die twee mogen namelijk dezelfde zijn, er is geen replicatie of sync nodig)
Echt totaal onzin, heb je net een domeinnaam die snel vastgelegd moet worden, moet je eerst regelen dat er een nameserver respont op deze requests.
En wat is snel? Waarom zou je geen 5 a 10 minuten kunnen wachten? Waarom zou een klant dit niet kunnen?
Het is niet alsof je midden in een landrush zit en zo snel mogelijk je requests moet indienen (en dan nog, voorbereiding). Als een domeinnaam nu vrij is, gaan die 10 minuten geen lifesaver worden.
Welke garanties heb je als DNS check klopt? Na goedkeuring hoeft het niet meer te kloppen.
Dat mag wat mij betreft ook strenger gecontroleerd worden. Iets wat overigens gaat gebeuren.
Verhoging van de kwaliteit
Door u inzicht te geven in mogelijke DNS-fouten in de geregistreerde
domeinnamen, wil SIDN de kwaliteit van de .nl-zone verhogen. Hoewel de
uitkomsten in de rapportage vooralsnog vrijblijvend zijn, wijst SIDN er
op dat elk domein geacht wordt te voldoen aan de Technische Eisen zoals
deze op de SIDN-website staan vermeld.
Ik ben wel voorstander van de register-only functie. Daarmee lossen ze het wat mij betreft goed op.
Maar wie gaat er nu z'n fallback mailserver in hetzelfde netwerk zetten? Begrijp me niet verkeerd, ik ben het grotendeels eens met je (lees mijn eerdere post in dit topic met mening over SIDN), maar deze beweringen van je kloppen niet.
Ik begrijp wel hoe het niet moet, maar feit wil dat de meeste webhosters geeneens een fallback server hebben. En dan heb ik het niet over zolder kamer hosters. En die hebben buiten hun eigen range verder geen aparte netwerk waarin ze uit continuïteit motieven hun infrastructuur op hebben ingericht. Dat de midden en groot webhosting bedrijven hun zaken wel op orde hebben is eigenlijk van zelf sprekend, in dat kader durf ik ook wel te stellen dat de meeste partijen die hier komen niet aan de bewaarplicht voldoen als ook niet voorbereid zijn om een tapbevel af te handelen, wat beiden een wettelijke verplichting is.
Dit heeft verder niet te maken met SIDN want het is de verantwoording van de ondernemer/bestuurder zelf.
Er is vanuit SIDN geen technische noodzaak om te controleren op domeinnamen laat staan dat nameservers in verschillende subnetten moeten zitten.
Bij veel hosters staat de TTL op 4 uur, als die dus in de afgelopen 4 uur niet is opgevraagd door die DNS server dan is die weg. M.u.v. enkele veel gebruikte domeinen (hotmail.com, gmail.com etc) lijkt het mij juist dat het meerendeel van de domeinen niet één keer in de 4 uur door vrijwel elke DNS servers wordt opgevraagd. Dus in dat geval is een groot deel direct niet meer te resolven.
Ook dat is een keuze van de onderneming, het zal me niets verbazen als maar weinig bedrijven een echte strategisch TTL beleid erop nahouden die gestaafd is op statistieken.
Het klopt dat een mailserver het 5 dagen zal moeten blijven proberen, maar geloof me (wij doen erg veel met fallback mail), een heel groot deel lapt deze regel (RCF!) aan z'n laars. Vooral mailservers van grotere access ISP's. Daarnaast, als die al 5 dagen de mail blijft proberen af te leveren zal dit niet gelden voor domeinen die niet te resolven zijn.
5 dagen is geen harde eis IMHO in de RFC. En inderdaad er is een reden om progressief hier mee om te gaan, als een mail server na 2 dagen nog niet operationeel is, dan heeft ontvangen een structureel probleem.
M.i. moet je als serieuze hoster dus wel echt een secondary DNS en fallback mail buiten je primaire netwerk hebben staan. Je klanten gaan er niet blij van worden als er mail verloren gaat en die kans is zonder secondary DNS en fallback mail wel zeer groot.
Best practices zijn niet vanzelfsprekend, zoals ik eerder stelde een bedrijf die haar zaken professioneel gehost wenst te hebben eist een SLA waarin in detail de continuïteit word afgedwongen, een professionele hoster zal inderdaad geen probleem hebben om daar aan te conformeren.
Of SIDN daar op moet controleren is een tweede (zie ook mijn eerdere post)...
En daar gaat het om, ze doen meer dan waar de meeste hosters om hebben verzocht wat verder geen nut of noodzaak heeft.
Fuck-ups van hosters worden door hun eigen klanten bestraft en ik denk wel dat deze branche met 10.000 hosting aanbieders zelf verschonend werkt. (zie ook bedrijf/klanten te koop rubriek op deze site)
En wat is snel? Waarom zou je geen 5 a 10 minuten kunnen wachten? Waarom zou een klant dit niet kunnen?
Waarom zou je uberhaubt moeten wachten? Geef mij eens 1 zinnig argument waarom domeinen normaliter niet gelijk vastgelegd kunnen worden zonder werkende nameservers (en binnenkort binnen een week dan)?
Wat is hier de meerwaarde van? En kom s.v.p niet met "anders gaat de kwaliteit van de .nl zone achteruit", want dat vind ik echt regelrechte onzin.
</offtopic>
5 dagen is geen harde eis IMHO in de RFC. En inderdaad er is een reden om progressief hier mee om te gaan, als een mail server na 2 dagen nog niet operationeel is, dan heeft ontvangen een structureel probleem.
4.5.4.1 Sending Strategy
Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. The
parameters to the retry algorithm MUST be configurable.
ja dat was leuk in de tijd van het inbellen enzovoort, maar als ik nu mijn mail 5 dagen laat liggen en dan pas tegen m'n klanten zeg dat het niet gelukt is, dan zijn die niet blij
ja dat was leuk in de tijd van het inbellen enzovoort, maar als ik nu mijn mail 5 dagen laat liggen en dan pas tegen m'n klanten zeg dat het niet gelukt is, dan zijn die niet blij
Of voor de klant die fallback mx van je afneemt kunnen zeggen dat zn mail alsnog in zn mailserver komt omdat je gewoon netjes 5 dagen aanhoud?
voor elke situatie is wel een oplossing te vinden. IMHO heb ik liever mail laat dan niet :)
Ik ben voor een DNS check indien een domein niet "register-only" is. Zou graag willen weten of het allemaal goed staat en blijft staan :) Ook klanten met eigen DNS servers zullen die checks waarschijnlijk geforward krijgen voor hun domein(en). Er is niets mis met kwaliteit willen leveren, en blijven garanderen.
IMHO heb ik liever mail laat dan niet :)
Zeker, maar het gaat mij om het verzenden van mail. Als ik een email verstuur en die komt niet binnen een dag terug, dan ga ik er van uit dat die aangekomen is op de server/inbox/spamfilter van de ontvanger. Komt het terug dan kan ik besluiten om m'n klant of leverancier te bellen. Komt het pas na vijf dagen terug dan is dat voor een bedrijf best een probleem. Een dag valt hiermee wat mij betreft nog binnen de menselijke maat, een week niet meer. En zeg nou zelf, wie heeft z'n primary mailserver EN secundary mailserver nou langer dan een dag offline?
rfc2821
4.5.4.1 Sending Strategy
Retries continue until the message is transmitted or the sender gives
up; the give-up time generally needs to be at least 4-5 days. The
parameters to the retry algorithm MUST be configurable.
Zoals ik al schreef is het IMHO geen eis dat het 5 dagen is.
Zoals je in de rest van deze RFC kunt lezen word "MUST" gebruikt voor iets wat als "EIS" gesteld word.
Echter bij de relevante zin staat "generally needs to be at least" en niet "It MUST be at least 4-5 days."
De zin er na geeft ook duidelijk aan dat het verplicht is dat het instelbaar is.
Als er had gestaan "It MUST be at least 4-5 days." dan had de zin er na er niet in hoeven te staan.
Als je ooit eens voor de rechter staat en je word er van beticht dat doordat je je niet aan de "regels" zou houden mail verloren is gegaan, dan zal bovenstaande wel degelijk een groot verschil uitmaken, vandaar ook dat grote partijen zich er niet aanhouden.
er is een verschil tussen TEMINSTE en MOETEN. Vooral als je ze door elkaar haalt. Dat jij er een andere interpetatie voor hebt..
er is een verschil tussen TEMINSTE en MOETEN. Vooral als je ze door elkaar haalt. Dat jij er een andere interpetatie voor hebt..
Je dient het hele document te lezen, consistent word er "MUST" & "SHOULD" gebruikt.
Bij dit specifieke onderdeel staat dat het instelbaar MOET zijn, maar niet dat het TENMINSTE 4-5 dagen moet zijn of 4-5 dagen MOET zijn.
"generally needs to be" is vrij vertaald, over algemeen hoort het 4-5 dagen te zijn, dat is anders dan het moet of tenminste.
Heeft niets met interpretatie te maken, zo zitten de meeste RFC's in elkaar.
Je hebt een verplichting of een advies. In dit geval is er geen uitdrukkelijke verplichting waardoor grote partijen zich er niet aan houden zonder zich te hoeven bekommeren om juridische consequenties.
Je moet je maar eens verdiepen in de discussies over TCP/IP waarbij er vaak bij onduidelijkheid naar TCP/IP Illustrated van Stevens of naar source code implementatie van BSD word verwezen.
Overigens is het ongevraagd gebruik maken van resources strafbaar in Nederland derhalve kan het regelmatig ongevraagd aanbieden van mail aan een server terwijl men kan weten dat server (gezien foutmelding) mail niet zal accepteren, een verdere aanbieding van de mail als ongewenst word beschouwd. Nu zal dit niet zo snel voorkomen, maar bij een spamrun waarbij een server amper meer reguliere mail kan ontvangen omdat je mailserver blijft proberen zijn mail af te leveren, ben je wel degelijk aansprakelijk te houden.
er is een verschil tussen TEMINSTE en MOETEN. Vooral als je ze door elkaar haalt. Dat jij er een andere interpetatie voor hebt..
jij hebt vast nog nooit een RFC gelezen, die zijn over het algemeen 100% duidelijk in wanneer iets moet of mag
overigens, een RFC is vaak nog geen standaard maar een voorstel (het heet niet voor niets een request for comments)
jij hebt vast nog nooit een RFC gelezen, die zijn over het algemeen 100% duidelijk in wanneer iets moet of mag
overigens, een RFC is vaak nog geen standaard maar een voorstel (het heet niet voor niets een request for comments)
En ik maar denken dat wasknijper rfc weldegelijk een nuttige "standaard" is.
RFC 2322 :chinese:
En ik maar denken dat wasknijper rfc weldegelijk een nuttige "standaard" is.
RFC 2322 :chinese:
ot:
Wie maakt er gebruik van RFC1149 om te zeggen dat zijn netwerk redunant is?
Maar voordat SIDN hier op kan checken... Maar gaat SIDN straks ook eisen dat je valide SPF records heb voordat je een domein mag registreren..
ot:
Wie maakt er gebruik van RFC1149 om te zeggen dat zijn netwerk redunant is?
ot: Die kende ik niet wel een strakke RFC.
Maar voordat SIDN hier op kan checken... Maar gaat SIDN straks ook eisen dat je valide SPF records heb voordat je een domein mag registreren..
Dat zie je in deze discussie ook, toch redelijk veel mensen voor "kwaliteit check" maar nergens sluitende onderbouwing.
Ik denk dat je kan stellen dat uitstellen van EPP als ook stellen van eisen die achterhaald zijn juist frustratie brengen aan de groei van deze cc/TLD.
Zeker als je deze "kwaliteit check" als reden gaat noemen voor frustratie aan de voortgang van EPP. (als ook een paar andere onzinnige dingen).
Ik ben het eens met Wonko, dus heb NEE gestemd. Het gaat hier om een domein wat je wil vastleggen, je koopt het, je hoeft er (nog) niets mee te doen.
Ik ben het hier wel mee eens, maar bekijk het ook eens van de andere kant. Wanneer iemand een .nl domein wilt moet hij ook hosting of een dns service kopen. :)
Ik ben het hier wel mee eens, maar bekijk het ook eens van de andere kant. Wanneer iemand een .nl domein wilt moet hij ook hosting of een dns service kopen. :)
"moet" is geen teken van zelfbeschikking.
Als je een pakje sigaretten koopt controleert men ook niet of je wel een aansteker hebt.
Als je een pakje sigaretten koopt controleert men ook niet of je wel een aansteker hebt.
Maar men zou wel moeten controlleren of je 16 jaar of ouder bent.
Maar men zou wel moeten controlleren of je 16 jaar of ouder bent.
Voor een aansteker??
SIDN draaft af en toe ver door. Eerst zorgen dat de zaken op orde zijn voordat je nieuwe dingen introduceert.
Triloxigen
21/12/08, 03:37
Ik ben het hier wel mee eens, maar bekijk het ook eens van de andere kant. Wanneer iemand een .nl domein wilt moet hij ook hosting of een dns service kopen. :)
Wat stelt dat dan voor?