Maar weer eens SIDN en glue records
Rob van der Putten
Mijn beide nameservers zijn dual stack IPv4 en IPv6. De primary sinds
kort en de secundary reeds jaren.
Beide staan echter alleen maar met IPv4 in de NL zone (NL staat wel IPv6
in de root).
Vandaag mijn registrar gemaild met het verzoek een glue record toe te
voegen. Deze meld echter dat SIDN dit automatisch moet oppikken. Maar
dan zou mijn secondary er dus al in moeten staan.
Hoe zit dat nu?
Vr.Gr,
Rob
--
Slim Meten is Slinks Weten;
http://www.wijvertrouwenslimmemetersniet.nl/
Maarten te Paske
> Vandaag mijn registrar gemaild met het verzoek een glue record toe te
> voegen. Deze meld echter dat SIDN dit automatisch moet oppikken. Maar
> dan zou mijn secondary er dus al in moeten staan.
> Hoe zit dat nu?
Bij de deelnemer waar ik mijn NL-domeinen registreer kan ik gluerecords
voor zowel IPv4 als IPv6 opgeven. Als ik nameservers definieer die
binnen hetzelfde domein vallen vult hij dat zelf voor mij in, maar dat
doet de webinterface van de deelnemer; niet SIDN.
Maarten
Rob van der Putten
Maarten te Paske wrote:
> Bij de deelnemer waar ik mijn NL-domeinen registreer kan ik gluerecords
> voor zowel IPv4 als IPv6 opgeven. Als ik nameservers definieer die
> binnen hetzelfde domein vallen vult hij dat zelf voor mij in, maar dat
> doet de webinterface van de deelnemer; niet SIDN.
Moet ik een andere registrar nemen?
Kan iemand er een aanbevelen?
Zijn er ook bij die secondaries draaien?
Wat kost dat?
MarcoH
Oh en lukte dat, want de laatste poging die ik deed ging behoorlijk mis op
de nameserver check. Ik kreeg een melding dat de server niet auhtorative
was, wat vreemd is want het IPv4 adres van dezelfde bind kwam wel door de
test en tcpdump toonde duidelijk aan dat er zelfs geen poging gedaan werd
om iets op te vragen.
Daarop kreeg ik 2 antwoorden:
- er is iets veranderd aan de firewall en het is een bug
- je mag geen NS record met alleen IPv6 glue gebruiken
Op de 1e was de laatste feedback dat er geen prioriteit gegeven wordt want
niemand gebruikt IPv6 en de 2e is ronduit bullshit en zeker op de lange
termijn niet houdbaar.
En nu claim jij dat je het voor elkaar hebtr. Gods wegen zijn
ondoorgrondelijk en van de onverharde paden van de SIDN snap ik echt niets
meer. Gelukkig hebben ze meer verstand van rechtszaken, oh wacht dat was
natuurlijk ook de mislukking die iedereen ervan verwachtte.
MarcoH
--
who used to be at Demon NL
Operator
MarcoH <bitb...@example.com> writes:
[ glue records invoeren bij SIDN zou werken volgens M te P ]
> Oh en lukte dat, want de laatste poging die ik deed ging behoorlijk mis op
> de nameserver check.
Op de een of andere manier kan bit.nl het wel:
$ host nsauth1.bit.nl
nsauth1.bit.nl has address 213.136.12.51
nsauth1.bit.nl has IPv6 address 2001:7b8:3:2c::53
Is er hier iemand van bit.nl die dat kan uitleggen?
(Of iemand van surfnet.nl want daar is ook geen probleem...)
MarcoH
Die zijn:
- misschien wel aangemaakt voor de introductie van de bug
- hebben zowel een IPv4 als IPv6 adres
Vergelijk:
marcoh.net. 14m20s IN NS ns2.marcoh.net.
marcoh.net. 14m20s IN NS ns6.marcoh.net.
marcoh.net. 14m20s IN NS ns1.marcoh.net.
;; ADDITIONAL SECTION:
ns2.marcoh.net. 22h18m41s IN A 213.222.27.181
ns6.marcoh.net. 23h59m56s IN AAAA 2001:888:22a5::2
ns1.marcoh.net. 12h17m36s IN A 195.64.86.162
Die constructie lukte dus niet met SIDN, ns6 wordt niet geaccepteerd als
valid nameserver.
Operator
[ in gesprek met SIDN ]
> - er is iets veranderd aan de firewall en het is een bug
> - je mag geen NS record met alleen IPv6 glue gebruiken
>
> Op de 1e was de laatste feedback dat er geen prioriteit gegeven wordt want
> niemand gebruikt IPv6 en de 2e is ronduit bullshit en zeker op de lange
> termijn niet houdbaar.
Niemand gebruikt IPv6 omdat iedereen zit te wachten tot SIDN
zijn zaakjes voor elkaar heeft.
Zou het kunnen zijn dat ze niet mogen omdat de "bewaarplicht"
niet klaar is voor IPv6?
MarcoH
> Zou het kunnen zijn dat ze niet mogen omdat de "bewaarplicht"
> niet klaar is voor IPv6?
Welke bewaarplicht ? Is SIDN wel een aanbieder van een openbaar
telecommunicatie netwerk ?
Operator
MarcoH <bitb...@example.com> writes:
> Operator <ro...@dragon.doktercom.nl> wrote:
>
>> Zou het kunnen zijn dat ze niet mogen omdat de "bewaarplicht"
>> niet klaar is voor IPv6?
>
> Welke bewaarplicht ? Is SIDN wel een aanbieder van een openbaar
> telecommunicatie netwerk ?
De SIDN zelf niet, de meeste deelnemers wel.
Hebben die allemaal al voldoende IPv6 spullen in huis om aan
de wet te voldoen?
Maarten te Paske
> Maarten te Paske <maa...@tepaske.net.invalid> wrote:
>
>> Bij de deelnemer waar ik mijn NL-domeinen registreer kan ik gluerecords
>> voor zowel IPv4 als IPv6 opgeven. Als ik nameservers definieer die
>> binnen hetzelfde domein vallen vult hij dat zelf voor mij in, maar dat
>> doet de webinterface van de deelnemer; niet SIDN.
>
> Oh en lukte dat, want de laatste poging die ik deed ging behoorlijk mis op
> de nameserver check. Ik kreeg een melding dat de server niet auhtorative
> was, wat vreemd is want het IPv4 adres van dezelfde bind kwam wel door de
> test en tcpdump toonde duidelijk aan dat er zelfs geen poging gedaan werd
> om iets op te vragen.
[...]
> En nu claim jij dat je het voor elkaar hebtr. Gods wegen zijn
> ondoorgrondelijk en van de onverharde paden van de SIDN snap ik echt niets
> meer. Gelukkig hebben ze meer verstand van rechtszaken, oh wacht dat was
> natuurlijk ook de mislukking die iedereen ervan verwachtte.
Nee, ik heb het niet zelf voor elkaar. Ik ben IPv6 aan het omnummeren op
mijn server en wilde daarna IPv6 glue records laten aanmaken. Maar ik
hoor om mij heen van mensen dat het werkt. Ik zal je anders een
voorbeeld mailen van iemand waarvan ik weet dat hij het onlangs heeft
opgezet.
Maarten
Frits Letteboer
Bij TransIP lukt het wel (alleen nog niet getest met IPv6-only
NS-records. Beide zijn dual.):
Domain nameservers:
ns1.radiotwenterand.nl 82.94.217.218
ns1.radiotwenterand.nl 2001:888:2234::2
ns3.radiotwenterand.nl 194.109.64.66
ns3.radiotwenterand.nl 2001:888:2234:0:194:109:64:66
Rob van der Putten
Frits Letteboer wrote:
> Bij TransIP lukt het wel (alleen nog niet getest met IPv6-only
> NS-records. Beide zijn dual.):
>
> Domain nameservers:
> ns1.radiotwenterand.nl 82.94.217.218
> ns1.radiotwenterand.nl 2001:888:2234::2
> ns3.radiotwenterand.nl 194.109.64.66
> ns3.radiotwenterand.nl 2001:888:2234:0:194:109:64:66
https://www.transip.nl/domein-registratie/
https://www.transip.nl/domein-registratie/screenshots/
Is nu € 4.99. Wat kost het normaal?
Maarten te Paske
Dat omnummeren ben ik nu mee klaar, dus ik heb nu ook maar een glue
record voor mijn primaire nameserver aangemaakt:
Domain name:
analogue.nl
[...]
Domain nameservers:
ns.analogue.nl 94.142.244.30
ns.analogue.nl 2a02:898::77:1
Als er dus een bug was is die inmiddels verholpen.
Maarten
Rob van der Putten
Maarten te Paske wrote:
> Dat omnummeren ben ik nu mee klaar, dus ik heb nu ook maar een glue
> record voor mijn primaire nameserver aangemaakt:
>
> Domain name:
> analogue.nl
>
> [...]
>
> Domain nameservers:
> ns.analogue.nl 94.142.244.30
> ns.analogue.nl 2a02:898::77:1
>
> Als er dus een bug was is die inmiddels verholpen.
Ook al TransIp.
Zitten 1 a 2 stoplichten bij mij vandaan.
Rotterdamse Aad
"Rob van der Putten" <r...@sput.nl> komt geen meter verder:
> Zitten 1 a 2 stoplichten bij mij vandaan.
Blijven de verkeerslichten op rood staan? ;-)
--
Rotterdamse Aad
www.ditisrotjeknor.nl
Niemand is perfect; mijn naam is Perfect
__________ Information from ESET NOD32 Antivirus, version of virus signature database 3964 (20090326) __________
The message was checked by ESET NOD32 Antivirus.
Rob van der Putten
Rotterdamse Aad wrote:
> Blijven de verkeerslichten op rood staan? ;-)
Niet erg lang.
Operator
> - er is iets veranderd aan de firewall en het is een bug
Maarten te Paske heeft het nu voorelkaar.
Zou je het nogmaals kunnen proberen voor de xs4all.nl NS-en?
Rob van der Putten
Operator wrote:
> Maarten te Paske heeft het nu voorelkaar.
Een kennis is zoeven in een half uur verhuisd en heeft nu ook een IPv6
glue record.
> Zou je het nogmaals kunnen proberen voor de xs4all.nl NS-en?
Operator
Rob van der Putten <r...@sput.nl> writes:
[ het kan wel ]
> Een kennis is zoeven in een half uur verhuisd en heeft nu ook een IPv6
> glue record.
Ga jij nu ook overstappen?
Of eerst Caveo aan de tand voelen?
MarcoH
> De SIDN zelf niet, de meeste deelnemers wel.
> Hebben die allemaal al voldoende IPv6 spullen in huis om aan
> de wet te voldoen?
Ik gok dat 50 % niet weet hoe je het spelt en 75 % helemaal niets met IPv6
doen, laat staan tappen. Daarnaast zou de bewaarplicht geen issue moeten
geven, die gaat over protocollen (mail/web) en is dus in theorie niet
afhankelijk van adressen.
MarcoH
Dit gaat niet over de xs4all nameservers. Nog een keer gechecked:
* secondary name server "ns2.marcoh.net."
Info: name server looks correctly configured.
* secondary name server "ns6.marcoh.net."
Error: name server at 2001:888:22a5:0:0:0:0:2 does not know about domain
"springbreek.nl."
Doe maar een dig, die nameserver is authorative. Als je dan door graaft op
de website is het enige relevante wat ik kan vinden:
(...)
Technische eisen voor registratie van .nl-domeinnamen
4. De voor opname in de .nl zone file opgegeven nameservers dienen vanaf
het hele internet bereikbaar te zijn via IPv4 en bij voorkeur ook via
IPv6.
(...)
Dat is gelul, er staat nergens dat het internet IPv4 is. Ik heb een IPv6
only host juist om te kijken wat er gebeurd als je een IPv6 only host
hebt en zelfs als ik die discussie uit de weg ga is de foutmelding
aantoonbaar niet correct, die server is namelijk bereikbaar en geeft
antwoord.
Hiervan is in prive communicatie tussen mij en SIDN al bevestigd dat dit
een bug is en tevens dat het geen prioriteit heeft.
Over ongeveer 800 dagen zal de eerste gedwongen v6 only host een feit zijn
en het zou fijn zijn als de SIDN voor die tijd onder hun steen vandaan
komen en zorgen dat ze hun zaakjes op orde hebben. De dienst daar wordt
echter uitgemaakt door een stel mensen die denken dat de wereld zich wel
aan SIDN aanpast, zie ook die achterlijke rechtszaak tegen lycos.
En dan ook nog potsierlijk de statuten wijzigen in:
'SIDN heeft ten doel ten behoeve van en vanuit Nederland toegevoegde
waarde
te leveren voor de internetgemeenschap middels het tegen verantwoorde
tarieven ontwikkelen en in stand houden van diensten en producten op het
gebied van digitale registratie en/of resolving in netwerken, zoals
domeinnaamsystemen (waaronder in elk geval .nl) en voorts al hetgeen
hiermee rechtstreeks of zijdelings verband houdt of daartoe bevorderlijk
kan zijn, alles in de ruimste zin des woords.'
De weigerachtige houding om serieus werk te maken van die bug die nu al
meer dan 3 maanden bekend is vind ik nu niet bepaald een toegevoegde
waarde voor de internetgemeenschap.
Rob van der Putten
Rob van der Putten wrote:
> Een kennis is zoeven in een half uur verhuisd en heeft nu ook een IPv6
> glue record.
Staat naast in whois nu ook in ns1.nic.nl. Het kan dus wel snel.
Rob van der Putten
Operator wrote:
> Ga jij nu ook overstappen?
> Of eerst Caveo aan de tand voelen?
Even kijken of er toch niet wat gebeurt.
Als over een paar dagen de whois niet is aangepast ga ik over.
Rob van der Putten
MarcoH wrote:
<Knip>
> Over ongeveer 800 dagen zal de eerste gedwongen v6 only host een feit zijn
Hoe zit het met de XS4ALL name servers (dus niet de resolvers)?
Zitten die ook achter IPv4 only load balancers?
<Knip>
Operator
>>
>> Zou je het nogmaals kunnen proberen voor de xs4all.nl NS-en?
>
> Dit gaat niet over de xs4all nameservers.
Wellicht iets voor een ander draadje.
Het zou fijn zijn als de rDNS-en van de door xs4all uitgedeelde
sub-netjes ook door IPv6-only resolvers gevonden kunnen worden.
> Nog een keer gechecked:
>
> * secondary name server "ns6.marcoh.net."
> Error: name server at 2001:888:22a5:0:0:0:0:2 does not know about domain
> "springbreek.nl."
Een work-around:
Voeg tijdelijk een IPv4 adres toe aan ns6.marcoh.net
Sleep springbreek.nl door de check
Haal de IPv4 glue weer uit de .net zone.
[snip SIDN ellende]
Er lopen daar zeker managers rond....
Frits Letteboer
> Moguh
>
>
> Frits Letteboer wrote:
>
>> Bij TransIP lukt het wel (alleen nog niet getest met IPv6-only
>> NS-records. Beide zijn dual.):
>>
>> Domain nameservers:
>> ns1.radiotwenterand.nl 82.94.217.218
>> ns1.radiotwenterand.nl 2001:888:2234::2
>> ns3.radiotwenterand.nl 194.109.64.66
>> ns3.radiotwenterand.nl 2001:888:2234:0:194:109:64:66
>
> https://www.transip.nl/domein-registratie/
> https://www.transip.nl/domein-registratie/screenshots/
>
> Is nu € 4.99. Wat kost het normaal?
>
€7.50
MarcoH
> Een work-around:
> Voeg tijdelijk een IPv4 adres toe aan ns6.marcoh.net
> Sleep springbreek.nl door de check
> Haal de IPv4 glue weer uit de .net zone.
Bedankt maar ik ben niet op zoek naar een workaround, die had ik zelf ook
al verzonnen.
> [snip SIDN ellende]
>
> Er lopen daar zeker managers rond....
Ik heb ze net maar weer eens gemailed en wat formeel gevraagd of ze in
staat zijn die rare eis te onderbouwen.
Rob van der Putten
MarcoH wrote:
> Ik heb ze net maar weer eens gemailed en wat formeel gevraagd of ze in
> staat zijn die rare eis te onderbouwen.
RFC 3901 DNS IPv6 Transport Operational Guidelines;
http://www.ietf.org/rfc/rfc3901.txt
4. DNS IPv6 Transport recommended Guidelines
In order to preserve name space continuity, the following
administrative policies are recommended:
- every recursive name server SHOULD be either IPv4-only or dual
stack,
This rules out IPv6-only recursive servers. However, one might
design configurations where a chain of IPv6-only name server
forward queries to a set of dual stack recursive name server
actually performing those recursive queries.
- every DNS zone SHOULD be served by at least one IPv4-reachable
authoritative name server.
This rules out DNS zones served only by IPv6-only authoritative
name servers.
Note: zone validation processes SHOULD ensure that there is at least
one IPv4 address record available for the name servers of any child
delegations within the zone.
Mogelijk is hier verwarring over authorative vs recursive name servers.
Een IPv6 only master met dual stack slave lijkt me een heel praktische
oplossing.
Overigens is J.GTLD.BIZ. Ipv6 only.
Hans
"MarcoH" <bitb...@example.com> wrote in message
news:49cada50$0$193$e4fe...@news.xs4all.nl...
Waarom noem je de IPV6 versie ns6 ?
En dan maak je een AAAA record voor ns1 of zo iets.
Een NS record verwijst naar een RR.
En die RR kan een A en/of een AAAA zijn.
Blijkbaar is het een probleem dat het het "alleen" een AAAA is.
MarcoH
> RFC 3901 DNS IPv6 Transport Operational Guidelines;
> http://www.ietf.org/rfc/rfc3901.txt
>
> 4. DNS IPv6 Transport recommended Guidelines
>
> In order to preserve name space continuity, the following
> administrative policies are recommended:
>
> - every recursive name server SHOULD be either IPv4-only or dual
> stack,
>
> This rules out IPv6-only recursive servers. However, one might
> design configurations where a chain of IPv6-only name server
> forward queries to a set of dual stack recursive name server
> actually performing those recursive queries.
Hmmm, dat is een leuke...want dan moet er dus de garantie zijn dat mijn
nameserver altijd een IPv4 adres zal hebben. Daarvoor zie ik een aantal
mogelijkheden:
- iedere domeinhouder komt automatisch in aanmerking voor v4 resources
- domainname servers worden gratis beschikbaar gesteld door SIDN voor
iedereen die niet aan de eisen kan voldoen.
Rob
> 4. De voor opname in de .nl zone file opgegeven nameservers dienen vanaf
> het hele internet bereikbaar te zijn via IPv4 en bij voorkeur ook via
> IPv6.
>
> (...)
>
> Dat is gelul, er staat nergens dat het internet IPv4 is. Ik heb een IPv6
> only host juist om te kijken wat er gebeurd als je een IPv6 only host
> hebt en zelfs als ik die discussie uit de weg ga is de foutmelding
> aantoonbaar niet correct, die server is namelijk bereikbaar en geeft
> antwoord.
In een andere groep loopt een discussie waarin Piet Beertema in een
dergelijk geval door blijft hameren dat ANDEREN niet kunnen lezen als
ze zo'n melding letterlijk interpreteren. We mogen absoluut geen waarde
hechten aan de woorden "en", "of" en "niet" in een zin, als het aan
hem ligt.
Het lijkt er op dat die interpretatie ook binnen SIDN is gaan gelden.
Maar het wordt wel lastig om meldingen of eisen te interpreteren als
die bodem er onder weg valt...
MarcoH
> Waarom noem je de IPV6 versie ns6 ?
Leek me logisch
> En dan maak je een AAAA record voor ns1 of zo iets.
Omdat het uitgangspunt is dat ik een v6 only server creeer
> Een NS record verwijst naar een RR.
> En die RR kan een A en/of een AAAA zijn.
> Blijkbaar is het een probleem dat het het "alleen" een AAAA is.
Dat is alleen een probleem in de ogen van SIDN althans het is de meest
logische verklaring en daar gaat het om. Er zijn geen technische
argumenten waarom het niet kan.
MarcoH
> In een andere groep loopt een discussie waarin Piet Beertema in een
> dergelijk geval door blijft hameren dat ANDEREN niet kunnen lezen als
> ze zo'n melding letterlijk interpreteren. We mogen absoluut geen waarde
> hechten aan de woorden "en", "of" en "niet" in een zin, als het aan
> hem ligt.
- welke groep ?
> Het lijkt er op dat die interpretatie ook binnen SIDN is gaan gelden.
> Maar het wordt wel lastig om meldingen of eisen te interpreteren als
> die bodem er onder weg valt...
Misschien moeten we eens proberen een correcte vertaling te maken van
http://www.ietf.org/rfc/rfc2119.txt
"Key words for use in RFCs to Indicate Requirement Levels"
Dan loop je een stuk minder kans op interpretatie fouten al bljven die
aanwezig.
Rob
> Rob <nom...@example.com> wrote:
>> In een andere groep loopt een discussie waarin Piet Beertema in een
>> dergelijk geval door blijft hameren dat ANDEREN niet kunnen lezen als
>> ze zo'n melding letterlijk interpreteren. We mogen absoluut geen waarde
>> hechten aan de woorden "en", "of" en "niet" in een zin, als het aan
>> hem ligt.
>
> - welke groep ?
nl.internet.providers
Osiris
Een resolver kan niet ruiken of een NS-record een A of AAAA-record-bevattende
RR heeft. Dus bestaat de kans dat een IPv4-only-resolver een nutteloze A-query
richting jouw ns6.~ maakt. Niet echt superboeiend, maar wellicht willen ze dat
niet.
Miquel van Smoorenburg
Verwarring alom :)
Met IPv4-only-resolver wordt bedoeld, een resolver die alleen een
IPv4 netwerk stack heeft. Dit heeft niets te maken met het feit of
een resolver A en/of AAAA records retourneert, staat er los van.
Het lijkt me vrij onmogelijk dat een resolver met een IPv4-only
netwerk stack een query naar een IPv6 adres gaat sturen.
Mike.
MarcoH
> Een resolver kan niet ruiken of een NS-record een A of AAAA-record-bevattende
> RR heeft. Dus bestaat de kans dat een IPv4-only-resolver een nutteloze A-query
> richting jouw ns6.~ maakt. Niet echt superboeiend, maar wellicht willen ze dat
> niet.
Hij zou glue meekrijgen en hoeft dus zelf geen query te doen voor A/AAAA.
Miquel van Smoorenburg
Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
>In article <49cbd63e$0$200$e4fe...@news.xs4all.nl>,
>Osiris <osi...@none.invalid> wrote:
>>MarcoH wrote:
>>> Hans <nobody@localhost.> wrote:
>>>
>>>> Waarom noem je de IPV6 versie ns6 ?
>>>
>>> Leek me logisch
>>>
>>>> En dan maak je een AAAA record voor ns1 of zo iets.
>>>
>>> Omdat het uitgangspunt is dat ik een v6 only server creeer
>>>
>>>> Een NS record verwijst naar een RR.
>>>> En die RR kan een A en/of een AAAA zijn.
>>>> Blijkbaar is het een probleem dat het het "alleen" een AAAA is.
>>>
>>> Dat is alleen een probleem in de ogen van SIDN althans het is de meest
>>> logische verklaring en daar gaat het om. Er zijn geen technische
>>> argumenten waarom het niet kan.
>>>
>>> MarcoH
>>
>>Een resolver kan niet ruiken of een NS-record een A of AAAA-record-bevattende
>>RR heeft. Dus bestaat de kans dat een IPv4-only-resolver een nutteloze A-query
>>richting jouw ns6.~ maakt. Niet echt superboeiend, maar wellicht willen ze dat
>>niet.
>
>Verwarring alom :)
Ook bij mij geloof ik. Never mind. Teveel glue gesnoven ofzo :)
Mike.
Osiris
Maar dan moet ie wel slim genoeg zijn om éérst naar de IP-adressen die eraan
geglued zijn te kijken voordat ie een resolver kiest uit de results van de "IN
NS"-query. :P Anders komt ie van een koude kermis thuis als blijkt dat er
alleen een AAAA/IPv6-IP aangeglued zit :P
Hans
> Hans <nobody@localhost.> wrote:
>
>> Waarom noem je de IPV6 versie ns6 ?
>
> Leek me logisch
>
>> En dan maak je een AAAA record voor ns1 of zo iets.
>
> Omdat het uitgangspunt is dat ik een v6 only server creeer
Waarom moet dat een eigen NS record hebben ?
Het A record wat bij ns1 hoort en het AAAA wat bij ns1 hoort hoeven niet de
zelfde server te zijn.
>
>> Een NS record verwijst naar een RR.
>> En die RR kan een A en/of een AAAA zijn.
>> Blijkbaar is het een probleem dat het het "alleen" een AAAA is.
>
> Dat is alleen een probleem in de ogen van SIDN althans het is de meest
> logische verklaring en daar gaat het om. Er zijn geen technische
> argumenten waarom het niet kan.
Dat weet ik niet.
Argument waarom zou dus wel handig zijn als jij vind dat er geen technisch
argument is.
Er zit een volgorde in de A versus AAAA die bij het NS hoort.
In ieder geval heeft bind(9) een preference voor IPV6 en dus de AAAA.
En ik weet effe niet uit het hoofd of de RTT's worden bij gehouden op NS
record nivo of op IP adres nivo.
Ik zou moeten checken hoever SIDN is met IPV6.
Helaas niet recent naar gekeken moet ik toegeven.
Maar in het verleden was IPV6 glue in ieder geval niet mogelijk.
Wel kon en mocht je NS record's hebben die IPV4 EN IPV6 (A en AAAA) waren.
Glue is zo en zo een issue bij alle TLD's.
De meesten maken er een zooitje van.
Op dat punt mag het protocol wel een aanpassing hebben want het model zou
beter kunnen.
Hans
"Osiris" <osi...@none.invalid> wrote in message
news:49cbd63e$0$200$e4fe...@news.xs4all.nl...
Anders om gebeurt helaas heel erg veel.
Een nutteloze AAAA voor RR's van de NS record's.
Ik zou even niet weten hoe je er anders achter moet komen of en DNS server
IPv6 enabled is.
MarcoH
> Maar dan moet ie wel slim genoeg zijn om ??rst naar de IP-adressen die eraan
> geglued zijn te kijken voordat ie een resolver kiest uit de results van de "IN
> NS"-query. :P Anders komt ie van een koude kermis thuis als blijkt dat er
> alleen een AAAA/IPv6-IP aangeglued zit :P
Als je geen v6 stack hebt en alleen AAAA treft in je additional sectie is
het einde verhaal zoals Mike al aangaf.
MarcoH
> Waarom moet dat een eigen NS record hebben ?
> Het A record wat bij ns1 hoort en het AAAA wat bij ns1 hoort hoeven niet de
> zelfde server te zijn.
Dat kan wel, maar is buitengewoon onverstandig....hoe weet je dan nog wie
wie is ?
> Argument waarom zou dus wel handig zijn als jij vind dat er geen technisch
> argument is.
Het argument is een v6 only host te creeren als experiment, voorbereiden
op de toekomst.
> Glue is zo en zo een issue bij alle TLD's.
> De meesten maken er een zooitje van.
> Op dat punt mag het protocol wel een aanpassing hebben want het model zou
> beter kunnen.
Ik zou zeggen doe eens een voorstel over hoe je het DNS protocol aan kan
passen zodat er geen afhankelijkheid meer is van glue ?
Rob van der Putten
Rob van der Putten wrote:
> Even kijken of er toch niet wat gebeurt.
> Als over een paar dagen de whois niet is aangepast ga ik over.
Ik heb het maar in gang gezet.
Philip Homburg
Ten eerste gaat dit over een recursive name server. Dus dat gaat volgens mij
om resolvers. Voor de discussie met SIDN is het tweede item van belang.
Maar verder is het een SHOULD. En SHOULD betekent dat als er een goede reden
is om het anders te doen (bijv. lijkt me, als je helemaal geen IPv4 adressen
hebt), je dat gewoon kan doen. Als er nou een MUST had gestaan...
Verder is het natuurlijk maar een BCP.
--
That was it. Done. The faulty Monk was turned out into the desert where it
could believe what it liked, including the idea that it had been hard done
by. It was allowed to keep its horse, since horses were so cheap to make.
-- Douglas Adams in Dirk Gently's Holistic Detective Agency
Hans
>> Waarom moet dat een eigen NS record hebben ?
>> Het A record wat bij ns1 hoort en het AAAA wat bij ns1 hoort hoeven niet
>> de
>> zelfde server te zijn.
>
> Dat kan wel, maar is buitengewoon onverstandig....hoe weet je dan nog wie
> wie is ?
Dat snap ik niet.
Wie 1 is het verkeer op IPv4 en wie 2 is het verkeer op IPv6.
Of je daar 1 NS record met zowel een A als een AAAA voor gebruikt of 2 NS
record's waarbij er 1 is die een A record heeft en de andere een AAAA
record.
Ik zie het verschil helaas niet.
Zoals ik al eerder aan gaf het hoeft niet de zelfde server zijn.
>
>> Argument waarom zou dus wel handig zijn als jij vind dat er geen
>> technisch
>> argument is.
>
> Het argument is een v6 only host te creeren als experiment, voorbereiden
> op de toekomst.
>
>> Glue is zo en zo een issue bij alle TLD's.
>> De meesten maken er een zooitje van.
>> Op dat punt mag het protocol wel een aanpassing hebben want het model zou
>> beter kunnen.
>
> Ik zou zeggen doe eens een voorstel over hoe je het DNS protocol aan kan
> passen zodat er geen afhankelijkheid meer is van glue ?
Ik zou dat graag doen.
Heb je hier een sponser voor ?
Mijn huidige werkgever geeft me daar geen tijd voor.
Geen tijd is mogelijkheid tot.
Operator
Rob van der Putten <r...@sput.nl> writes:
> Rob van der Putten wrote:
>
>> Even kijken of er toch niet wat gebeurt.
>> Als over een paar dagen de whois niet is aangepast ga ik over.
>
> Ik heb het maar in gang gezet.
Mmm... Zo te zien nog niet veel schot in de zaak...
Rob van der Putten
Operator wrote:
> Mmm... Zo te zien nog niet veel schot in de zaak...
Net echt. Rolf was in 25 min over. Heb wel een email domain-registry.nl.
Rob van der Putten
Rob van der Putten wrote:
> Net echt. Rolf was in 25 min over. Heb wel een email domain-registry.nl.
Bleek dus een kwestie van bij de oude registrar hostmaster ipv sales mailen.
Anyway, voor de liefhebbers nog maar even een cron jobje geknutselt;
http://www.sput.nl/internet/root-zone.html
Armenia, Belize, Gibraltar, Honduras, Liberia, Philippines, Tanzania en
St. Vincent and The Grenadines hebben al hun TLD servers dual stack.
Daarnaast ook Asia, Mobi, Info en Org.
Rob van der Putten
Rob van der Putten wrote:
> Niet erg lang.
Heb inmiddels ook een stoplicht vrije route bedacht. Je weet maar nooit.
Rob van der Putten
MarcoH wrote:
<Knip>
> Over ongeveer 800 dagen zal de eerste gedwongen v6 only host een feit zijn
Er zijn plenty (6/7) dual stack 8.0.1.0.0.2.ip6.arpa servers, echter de
8.8.8.0.1.0.0.2.ip6.arpa servers (ns.xs4all.nl en ns2.xs4all.nl) zijn
dat niet. Wellicht aardig een IPv6 only server voor
8.8.8.0.1.0.0.2.ip6.arpa op te zetten (bv ns6.xs4all.net) en deze aan te
melden.
Zoveel verkeer zal zo'n doos toch niet te verwerken krijgen.
<Knip>
Operator
>
>> Over ongeveer 800 dagen zal de eerste gedwongen v6 only host een feit zijn
>
> Er zijn plenty (6/7) dual stack 8.0.1.0.0.2.ip6.arpa servers, echter de
> 8.8.8.0.1.0.0.2.ip6.arpa servers (ns.xs4all.nl en ns2.xs4all.nl) zijn
> dat niet. Wellicht aardig een IPv6 only server voor
> 8.8.8.0.1.0.0.2.ip6.arpa op te zetten (bv ns6.xs4all.net) en deze aan te
> melden.
Ik ben voor.
> Zoveel verkeer zal zo'n doos toch niet te verwerken krijgen.
Het zou mooi zijn als ie het druk kreeg.
Rob van der Putten
Operator wrote:
> Ik ben voor.
> Het zou mooi zijn als ie het druk kreeg.
Maar dan krijg je dat load balancer verhaal weer. Wel een mooie test
natuurlijk.
Maar round robin kan natuurlijk ook. En heel veel adressen is natuurlijk
geen probleem in IPv6.
MarcoH
> 8.8.8.0.1.0.0.2.ip6.arpa op te zetten (bv ns6.xs4all.net) en deze aan te
> melden.
> Zoveel verkeer zal zo'n doos toch niet te verwerken krijgen.
Er lopen allerlei dingen intern, beleid is echter dat we dingen pas
aankondigen als het werkt en er zitten momenteel nog diverse haken en ogen
aan.
Danny Terweij
"Rob van der Putten" <r...@sput.nl> schreef in bericht
news:49d0b4da$0$193$e4fe...@news.xs4all.nl...
> Anyway, voor de liefhebbers nog maar even een cron jobje geknutselt;
> http://www.sput.nl/internet/root-zone.html
Rob, kun je bovenin een table zetten met top 5/10 green lijst?
En wat zijn de X voor tld's?
Gr Danny.
Operator
"Danny Terweij" <spam...@p-s.nl> writes:
>
> "Rob van der Putten" <r...@sput.nl> schreef in bericht
> news:49d0b4da$0$193$e4fe...@news.xs4all.nl...
>
>> Anyway, voor de liefhebbers nog maar even een cron jobje geknutselt;
>> http://www.sput.nl/internet/root-zone.html
>
> Rob, kun je bovenin een table zetten met top 5/10 green lijst?
Of iets met een ander sort crit met knoppen?
> En wat zijn de X voor tld's?
Iets met IDN van UTF naar ASCII.
Operator
MarcoH <bitb...@example.com> writes:
> Rob van der Putten <r...@sput.nl> wrote:
>
>> 8.8.8.0.1.0.0.2.ip6.arpa op te zetten (bv ns6.xs4all.net) en deze aan te
>> melden.
>> Zoveel verkeer zal zo'n doos toch niet te verwerken krijgen.
>
> Er lopen allerlei dingen intern, beleid is echter dat we dingen pas
> aankondigen als het werkt en er zitten momenteel nog diverse haken en ogen
> aan.
Zijn die dingen politiek/wet gedoe of slechts tech?
In het laatste geval kan ik gratis bijdragen.
Rob van der Putten
Operator wrote:
> Of iets met een ander sort crit met knoppen?
Een lijstje groenen is misschien wel aardig.
Ben trouwens met ene reverse versie bezig.
> Iets met IDN van UTF naar ASCII.
On the fly converteren is misschien ook wel leuk.
Ik zal eens opzoeken hoe het werkt.
Heel inspirerend, dat 6.
Hans
"Operator" <ro...@dragon.doktercom.nl> wrote in message
news:49d169f9$0$193$e4fe...@news.xs4all.nl...
Das Punycode http://en.wikipedia.org/wiki/Punycode .
Zie http://en.wikipedia.org/wiki/Top-level_domain voor details.
Operator
"Hans" <nobody@localhost.> writes:
>
> "Operator" <ro...@dragon.doktercom.nl> wrote in message
> news:49d169f9$0$193$e4fe...@news.xs4all.nl...
>> In article <49d10635$0$193$e4fe...@news.xs4all.nl>,
>> "Danny Terweij" <spam...@p-s.nl> writes:
>>>
>>> "Rob van der Putten" <r...@sput.nl> schreef in bericht
>>> news:49d0b4da$0$193$e4fe...@news.xs4all.nl...
>>>
>>>> Anyway, voor de liefhebbers nog maar even een cron jobje geknutselt;
>>>> http://www.sput.nl/internet/root-zone.html
>>
>>
>> Iets met IDN van UTF naar ASCII.
>
> Das Punycode http://en.wikipedia.org/wiki/Punycode .
> Zie http://en.wikipedia.org/wiki/Top-level_domain voor details.
Ow ja. Klok klepel geval.
ISC
Rob van der Putten
Rob van der Putten wrote:
> Een lijstje groenen is misschien wel aardig.
> Ben trouwens met ene reverse versie bezig.
Werruk.
> On the fly converteren is misschien ook wel leuk.
> Ik zal eens opzoeken hoe het werkt.
> Heel inspirerend, dat 6.
Er is een CLI util 'idn' die dit kan;
测试
परीक्षा
испытание
테스트
טעסט
測試
آزمایشی
பரிட்சை
δοκιμή
إختبار
テスト
Er staat (voor zover gecheckt) dus gewoon 'test'. Beetje flauw dus.
Operator
Rob van der Putten <r...@sput.nl> writes:
>> Ben trouwens met ene reverse versie bezig.
>
> Werruk.
Dat is dus: http://www.sput.nl/cgi-bin/rns6
En waar het bij mij mis gaat is:
<q>
8.8.8.0.1.0.0.2.ip6.arpa
At least one of these should have an IPv6 address.
8.8.8.0.1.0.0.2.ip6.arpa name server ns2.xs4all.nl.
ns2.xs4all.nl has address 194.109.9.100
8.8.8.0.1.0.0.2.ip6.arpa name server ns.xs4all.nl.
ns.xs4all.nl has address 194.109.6.67
</q>
en dat was al duidelijk.
Rob van der Putten
Operator wrote:
> Dat is dus: http://www.sput.nl/cgi-bin/rns6
Er hoort een formpje bij;
http://www.sput.nl/internet/chkip6rev.html
Is erg primitief, experimenteel en mogelijk buggy.
> En waar het bij mij mis gaat is:
>
> <q>
> 8.8.8.0.1.0.0.2.ip6.arpa
> At least one of these should have an IPv6 address.
>
> 8.8.8.0.1.0.0.2.ip6.arpa name server ns2.xs4all.nl.
> ns2.xs4all.nl has address 194.109.9.100
>
> 8.8.8.0.1.0.0.2.ip6.arpa name server ns.xs4all.nl.
> ns.xs4all.nl has address 194.109.6.67
> </q>
>
> en dat was al duidelijk.
En word volgens MarcoH aan gewerkt. Het is vast wel binnen een jaar af.
Anders is er inderdaad een probleem.