- dns-wg - mailman.ripe.net

Re: [dns-wg] Re: IPv6 glue AAAA RRs in the root zone
by geoff＠nominet.org.uk 22 Jul '04

22 Jul '04

Stephane Bortzmeyer <bortzmeyer(a)nic.fr> writes: > Do note that the IPv6 server of ".fr", requested in February 2003, is > still not announced. Maybe only coincidence: JPNIC = ccNSO member KRNIC = ccNSO member AFNIC = ccNSO non-member Regards Geoff

4 5

IPv6 glue AAAA RRs in the root zone
by Peter Koch 22 Jul '04

22 Jul '04

Haven't seen an announcement right here, so FYI: as of SOA# 2004072000 the following AAAA RRs (aka "IPv6 glue") are available from within the root zone: A.DNS.JP. AAAA 2001:DC4:0:0:0:0:0:1 D.DNS.JP. AAAA 2001:240:0:0:0:0:0:53 E.DNS.JP. AAAA 2001:200:0:1:0:0:0:4 F.DNS.JP. AAAA 2001:2F8:0:100:0:0:0:153 G.DNS.KR. AAAA 2001:DC5:A:0:0:0:0:1 -Peter

8 21

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 22 Jul '04

22 Jul '04

>>>>> "Joao" == Joao Damas <Joao_Damas(a)isc.org> writes: BN: cc list has been trimmed as everyone there is already on dns-wg(a)ripe.net >>> Well, what other choice is there? :-) And anyway, since the >>> overwhelming bulk of the world's name servers are IPv4-only, >>> resolution over IPv6 doesn't seem to be a particularly >>> productive exercise. >> True enough. Joao> True enough for what subset of users? If the a user is Joao> interested in only a few and those provide the service that Joao> user needs and uses, what does he/she care about a million Joao> servers out there? It's not that simple Joao. If only it could be that simple... Have you forgotten the IPv6 migration issues that Johan Ihren and others have mentioned at previous WG meetings? Some IPv6 users will drop DNS over IPv4 as soon as they see AAAAs for TLD name servers. Or, worse, for the root servers. They may not realise or understand that this will cut them off from most of the internet. Which you seem to be saying is fine. If all they're interested in is the IPv6 internet, let them just get access to that. I'd agree with that sentiment if we knew for sure we were talking about informed, knowledgeable users. But I'm not convinced that's the case. Even so this approach brings more problems. Firstly, it highlights the lack of a migration strategy for introducing DNS over IPv6. We still don't know what's going to break, how those failures will manifest themselves and what the consequences of that will be. Both for applications/resolvers and for name servers. For instance, what will my IPv6 web browser do when lookups over IPv6 for www.google.com return only A records? Or SERVFAIL? Second of all, a piecemeal introduction of AAAA glue could be destablising for the DNS and the internet. We just don't know either way, so we should proceed carefully with a good understanding of the consequences of these changes. Thirdly, this could also put pressure on other TLDs to add AAAA glue -- "because others are doing this" -- before they're ready to do so. Finally, by encouraging the IPv6-only people to go off into their own little world, we fragment the internet and its name space. At the very least, it will mean some IPv6-ers are likely to develop a mindset that DNS migration to IPv6 is done and there's nothing more for them to do as far as IPv6 and the DNS is concerned.

3 2

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 22 Jul '04

22 Jul '04

>>>>> "Jeroen" == Jeroen Massar <jeroen(a)unfix.org> writes: >> Wrong, several root name servers (of course, not ICANN's one) >> are reachable over IPv6: read http://www.root-servers.org/ >> and edit your db.root. Jeroen> I know those addresses and I also know that all of those Jeroen> boxes have a latency over at least 200ms and very odd Jeroen> routability and those are far far far from to be called Jeroen> production. This could be a good topic for presenting to the WG. Want to volunteer to write up a document and/or presentation on the state of IPv6 deployment in the root and TLD name servers, routing anomalies, etc, etc? It would be good to hear someone's first-hand experiences with this stuff: what went wrong, how it was worked around or solved, what could be done better, future directions. Personally, I don't see why you care about the RTT to a root server. A well-behaved name server will make 4-5 queries to a root server once a week or so. Why optimise that? Please note I'm not suggesting that it's OK for root servers to have lousy RTTs. My name server is in regular, frequent contact with other name servers that have RTTs longer than 200ms. Jeroen> One really doesn't want to use those, just to be able to Jeroen> say that one can use IPv6.... Well, what other choice is there? :-) And anyway, since the overwhelming bulk of the world's name servers are IPv4-only, resolution over IPv6 doesn't seem to be a particularly productive exercise. Jeroen> BTW that list is missing i.root-servers.org which is Jeroen> located in Sweden, but that is a testing address and Jeroen> routes over the US instead of staying inside Europe... Why does it matter where a root name server is physically located? Sorry, I should rephrase that: why does it matter where a route for a root name server gets announced? IMO a 200ms RTT over IPv6 has to be better than an infinite RTT.

6 7

Re: [dns-wg] Re: Re: IPv6 glue AAAA RRs in the root zone
by Jim Reid 21 Jul '04

21 Jul '04

>>>>> "Stephane" == Stephane Bortzmeyer <bortzmeyer(a)nic.fr> writes: >> Unless I completely mis-understood, but isn't that article >> talking about *root* servers and not GTLD servers, which Peter >> showed... Stephane> No, Peter was talking about root name servers I thought he was talking about the name servers for .jp. Which happen to be in the root zone that's served by the root servers.... no?

1 0

Reverse checker out-of-sync with RIPE-203
by Andre Oppermann 19 Jul '04

19 Jul '04

The reverse delegation checker on www.ripe.net seems to be out-of-sync with the recommended values in RIPE-203 (or vice-versa). For example RIPE-203 recommends 3600000 seconds (1000 hours = 5 weeks and something) for the SOA expire value. However if I actually put this into my zone file the checker at http://www.ripe.net/cgi-bin/nph-dc.cgi complains that this is too high and suggests a value between 2-4 weeks. Which is is right? One of these should be changed/corrected to resolve this discrepancy. PS: What are the current actual officially recommended SOA values for revese zones? -- Andre

2 1

Stale restricted IPv6 information at Verisign/IANA
by Bernhard Schmidt 16 Jul '04

16 Jul '04

Good evening, perhaps slightly off-topic, but nethertheless... I've been trying to readd an AAAA glue record to one of my nameservers in .net after the server moved from M"net space (2001:a60::/32) to TNIB (2001:1b18::/32). It worked before, after the move the registrar (dd24.net if anyone is curious) could not add the appropriate record: | [COMMAND] | command=ModifyNameserver | delipaddress0=212.90.120.82 | addipaddress0=81.92.162.8 | delipaddress1=2001:a60:9000:1000::1:11 | addipaddress1=2001:1B18:202:FFFF::53:1:1 | nameserver=auth01.dns.mucip.net | EOF | [RESPONSE] | code = 535 | description = Restricted IP address a quick query of the registrar at Verisign GRS resulted in Verisign claiming | The IPv6 you were trying to add is currently in a restricted range by | IANA. | | The IP 2001:1B18:202:FFFF::53:1:1 falls into the below restricted | range. | | 2001:1A00:: 2001:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF Well, 1b18 is slightly older than a60, so I decided to give Verisign a small hint that their list is out of date. Verisign although claims | WE are currently following the restricted v6 IP list which is mandated | by IANA and is current. | | We recommend that you contact IANA directly in regards to your matter. I tried to contact/blame IANA but I haven't received any reply so far. Anyone having an idea who the culprit is in this game? Bernhard

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Jim Reid 15 Jul '04

15 Jul '04

>>>>> "Niall" == Niall O'Reilly <Niall.oReilly(a)ucd.ie> writes: Niall> IMHO such registry systems are not suited to the ENUM Niall> business, and a T1 which takes this approach is unlikely to Niall> be winning many tenders for national infrastructure. Of Niall> course, that depends on the clue-level available to the Niall> local awarding agency. Niall> I'm happy to say that, here in +353-land, our trial T1 is Niall> taking a more helpful approach. Good. The key thing here is you have a trial. So you can try different delegation approaches and see what works and what doesn't. And aside from the DNS mechanics, you can consider things like the impact of a particular approach on interfaces, roles & responsibilities as well as stuff like competition policy and the public interest. IMO it's far more important to learn about these things than focus on which name server(s) some zone sits on.

2 1

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Jim Reid 15 Jul '04

15 Jul '04

>>>>> "Niall" == Niall O'Reilly <Niall.oReilly(a)ucd.ie> writes: Niall> OTOH, there's a balance to be struck between allowing Niall> people to be responsible for their own mistakes and Niall> engaging in the diminishing-returns game of protecting them Niall> from everything. Indeed. And in this case, sharp instruments need to be kept well away from the children. That means avoiding some of the obvious rat-holes when it comes to DNS administration. Note too Niall that lots of ISPs can't get RFC2317-style delegation right and these are the guys who should have DNS skills as a core competency. Niall> If registrars or T2 registries can't do their job, how long Niall> will they stay in business ? Long enough to kill off ENUM by making it seem less robust and dependable than it could be? Consumer confidence is going to be critical for ENUM to become widely used. Cheap calls over VoIP may get everyone's attention. But if DNS lookups fail and phones don't ring reliably, nobody's going to use it.

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Jim Reid 15 Jul '04

15 Jul '04

>>>>> "Niall" == Niall O'Reilly <Niall.oReilly(a)ucd.ie> writes: >> You lose the granularity of control and the flexibility to let >> customers manage their delegations. I'm presuming you plan to >> have all your numbers CNAME'd into a single zone file rather >> than discrete zone files for each zone. Niall> I see it quite the other way around: you _gain_ Niall> flexibility. Is the glass half-empty or half-full? It depends on where you look from. Niall> The customer has a single point of administration for Niall> announcing the delegation and changes thereto. Once the Niall> CNAME has aged out from resolver caches, there is no trace Niall> left of obsolete data in the 'golden tree'. If the T2 Niall> provider which the customer has just deserted delays (or Niall> neglects) removing the relevant RRsets, so what ? With NS, Niall> on the other hand, you have to make sure that all the Niall> obsolete data on still authoritative servers is eliminated. Niall, I don't understand what you're saying. Perhaps you could explain your envisaged scheme with some examples: ie what's in zone files. You're now talking about T2 provider. From your earlier posting I'm confused if this is a registry, DNS provider, registrar (or some combination of these) and what RR/zone data they may hold and manipulate. So please, draw me an idiot-proof picture. The roles and interfaces you're outlining seem rather fuzzy. Niall> Are you saying that the opportunity for restrictive Niall> practices is significantly different according to which Niall> method you choose for implementing delegation ? YES! It's not just about how delegation gets implemented. The roles and responsibilities in that process matter too. This is why the UK ENUM Group factored out the DNS Provider as a distinct role in its overall ENUM architecture. [Read its 2002 report.] That meant DNS content and service wasn't necessarily under the control of a registrar, ISP or application service provider. This is a very important distinction IMO. We also envisaged a market for different levels of DNS service. Some might be happy with a no-guarantees free service, while others want something super-robust with 24x7 support, anycasting, DNSSEC and so on. Your CNAME scheme could make it harder to establish that market. Suppose my number is delegated from the T1 registry with a CNAME to some zone of yours. You have the trust relationship with the T1. I have a trust relationship with you. In this scenario, the T1 doesn't know or care about me. So they won't change the CNAME if I asked them to do this. That won't happen unless you tell them. And if we've had a falling out, you're not likely to make that hassle-free. Now suppose you're a telco and I'm a customer wanting to switch to another telco. Or I want to shift my mail URIs from the telco's mail server to say hotmail. Does this help clarify the context now? >> For something like a DDI block for an organisation, this >> shouldn't be an issue. But if it was for all numbers in the >> Dublin area code (say), there would be a problem. Niall> How is this different between the NS and CNAME Niall> implementations ? It's not about that. It's about what can be put in the zone and how that's done. If all the numbers in one block are "delegated" -- for some loose definition of that term -- to a single zone file, there will be less flexibility and granularity of control over the zone's contents. I have to use whatever tools you've provided and onlyaccess ENUM services you'll let me add to the zone for that number. This is tolerable for a number block under one authority where common rules and policy can be enforced -- say the DDI block for an employer. But for the general case, this isn't acceptable. The entity holding that zone file shouldn't be allowed to restrict what NAPTR records exist for my number. Or my neighbour's. For maximum flexibility and fine-grained granularity of control (plus making sure delegations carefully follow the national numbering plan), the T1 registry should delegate individual numbers to discrete zone files that are notionally controlled by the owner of that number. Introducing CNAMEs will add a layer of indirection. [A needless one IMO.] That could mean boundaries of responsibility get blurred and/or more complicated. Which could give an unscrupulous provider enough wiggle room for unsavoury practices.

1 0