Secondary service on ns.ripe.net for reverse delegations.
As mentioned in my presentation at RIPE 54 last week we have become aware that there is an inconsistency between ipv4 and ipv6 with regard to obtaining reverse delegation. The reverse delegation procedure listed at http://www.ripe.net/rs/ reverse/reverse_howto.html has the following listed: -----snip Secondary Service by the RIPE NCC For IPv4: If your zone is a /16 reverse zone, you will need to set up ns.ripe.net as a secondary server For IPv6: If your zone is a /32 reverse zone, you may use ns.ripe.net as a secondary -----snip We think it would be a good idea to address this inconsistency, this could be done in several ways including but not limted to: Make ns.ripe.net mandatory on ipv4 and ipv6 delegations Make ns.ripe.net optional on ipv4 and ipv6 delegations Discontinue the secondary service on ns.ripe.net for new delegations. Our suggestion and preference would be to make ns.ripe.net optional on both ipv4 and ipv6 delegations. We would welcome and encourage input from the dns community on this subject. Regards Brett -- Brett Carr Manager -- DNS Services Group RIPE Network Coordination Centre Amsterdam
Hi, I hope this does not become mandatory, only optionally or discontinue it. A very few amount of LIRs would have to send a zonefile in the size of (2^96 ) * 32 * 4 * 20 bytes to ns.ripe.net if it becomes mandatory. I take it for granted that RIPE (in addition to the LIR) does not have the bandwidth or the harddrive capacity for these zones. Additionally, such a requirement would limit the amount of supported RRs and degrading competitive (dis)advantages. Example 1: These LIRs run software that updates any record/zone instant on all nameservers at once (milliseconds) when the customer performs changes. I am unsure if this is possible with RIPEs nameserver (NOTIFY probably limited to SOA changes etc). j -----Original Message----- From: dns-wg-admin@ripe.net [mailto:dns-wg-admin@ripe.net] On Behalf Of Brett Carr Sent: 14. mai 2007 10:21 To: dns-wg@ripe.net Subject: [dns-wg] Secondary service on ns.ripe.net for reverse delegations. As mentioned in my presentation at RIPE 54 last week we have become aware that there is an inconsistency between ipv4 and ipv6 with regard to obtaining reverse delegation. The reverse delegation procedure listed at http://www.ripe.net/rs/ reverse/reverse_howto.html has the following listed: -----snip Secondary Service by the RIPE NCC For IPv4: If your zone is a /16 reverse zone, you will need to set up ns.ripe.net as a secondary server For IPv6: If your zone is a /32 reverse zone, you may use ns.ripe.net as a secondary -----snip We think it would be a good idea to address this inconsistency, this could be done in several ways including but not limted to: Make ns.ripe.net mandatory on ipv4 and ipv6 delegations Make ns.ripe.net optional on ipv4 and ipv6 delegations Discontinue the secondary service on ns.ripe.net for new delegations. Our suggestion and preference would be to make ns.ripe.net optional on both ipv4 and ipv6 delegations. We would welcome and encourage input from the dns community on this subject. Regards Brett -- Brett Carr Manager -- DNS Services Group RIPE Network Coordination Centre Amsterdam
On May 14, 2007, at 10:20, Jørgen Hovland wrote:
I hope this does not become mandatory, only optionally or discontinue it. A very few amount of LIRs would have to send a zonefile in the size of (2^96 ) * 32 * 4 * 20 bytes to ns.ripe.net if it becomes mandatory.
Let's step back. Slave service for reverse zones was something the NCC has been doing since the dawn of time. In the early days, connectivity was sometimes erratic, bandwidth was limited, lame delegations were common and DNS skills were worse than they are today. It made sense to have a robust and stable DNS platform and the NCC was in the position to provide that service. That was then. But this is now. The environment has changed. And there's less reliance on reverse DNS lookups these days too, even more so in an IPv6 world. So the questions for the WG should be IMO: * Is there value in having the NCC provide DNS service for big/ important reverse zones? * If the answer to the above question is yes, under what conditions? ie What do we mean by big or important? * If the answer is still yes, should this service be compulsory or optional? And under what conditions would optional use become compulsory and vice versa? * If the answer to the orginal question is no, what, if anything, does the NCC do about things like lame delegations for reverse zones and the operational problems these cause the NCC?
In the light of this: Jim Reid wrote:
So the questions for the WG should be IMO:
* Is there value in having the NCC provide DNS service for big/important reverse zones? * If the answer to the above question is yes, under what conditions? ie What do we mean by big or important? * If the answer is still yes, should this service be compulsory or optional? And under what conditions would optional use become compulsory and vice versa? * If the answer to the orginal question is no, what, if anything, does the NCC do about things like lame delegations for reverse zones and the operational problems these cause the NCC?
I'd like to mention that slaving Tier 1 ENUM zones on ns.ripe.net is also purely optional only - for very good reasons. Some of them are hidden in Jim's questions. Best, Carsten
As there was very little response to Jim's posting I am replying (hoping to stimulate further discussion) to his post as an individual interested in DNS and it's stability and after having removed my RIPE NCC hat. On May 14, 2007, at 12:25 PM, Jim Reid wrote:
On May 14, 2007, at 10:20, Jørgen Hovland wrote:
I hope this does not become mandatory, only optionally or discontinue it. A very few amount of LIRs would have to send a zonefile in the size of (2^96 ) * 32 * 4 * 20 bytes to ns.ripe.net if it becomes mandatory.
Let's step back. Slave service for reverse zones was something the NCC has been doing since the dawn of time. In the early days, connectivity was sometimes erratic, bandwidth was limited, lame delegations were common and DNS skills were worse than they are today. It made sense to have a robust and stable DNS platform and the NCC was in the position to provide that service. That was then. But this is now. The environment has changed. And there's less reliance on reverse DNS lookups these days too, even more so in an IPv6 world.
So the questions for the WG should be IMO:
* Is there value in having the NCC provide DNS service for big/ important reverse zones?
Yes I think that this adds stability to the reverse dns, although I would say it is not as critical as it once was.
* If the answer to the above question is yes, under what conditions? ie What do we mean by big or important?
I would class them as those allocations which encompass large amounts of address space (relatively within ipv4 and ipv6 respectivley) probably taking the largest normal allocation sizes and hitting the nearest bit boundary for reverse delegation would be sufficient.
* If the answer is still yes, should this service be compulsory or optional? And under what conditions would optional use become compulsory and vice versa?
I think it should be optional under all circumstances. The knowledge of DNS and it's stability has been greatly improved in the past decade so I don't see any issues with moving to an optional model as opposed to the current mandatory in some cases model.
* If the answer to the orginal question is no, what, if anything, does the NCC do about things like lame delegations for reverse zones and the operational problems these cause the NCC?
Well of course the NCC have a seperate project to notify and report on lame delegations expect more news, statistics and notifications (if you have lame servers) within the next six months. -- Brett Carr
At 3:13 PM +0200 6/4/07, Brett Carr wrote:
As there was very little response to Jim's posting I am replying (hoping to
Okay, so if it's discussion you want...
On May 14, 2007, at 12:25 PM, Jim Reid wrote:
* Is there value in having the NCC provide DNS service for big/important reverse zones?
This isn't the question I would ask. It's not a matter if yet-another-well-managed slave is a good thing or not (obviously yes), it's a matter if the expense incurred to do this worth it. There's the basic cost benefit question, to which I suspect the answer would be "it's worth it." Then there's the opportunity question of whether the budget of the RIPE NCC is better spent elsewhere. And then there's the question if whether not doing so permits miscreant children for doing bad things.
* If the answer to the above question is yes, under what conditions? ie What do we mean by big or important?
I think the answer is yes, so long as Brett Carr hasn't gone insane and moved all of the servers to an X.25 network. Big or important - big is anything over 12 units of any measure and important is "if I use it."
* If the answer is still yes, should this service be compulsory or optional? And under what conditions would optional use become compulsory and vice versa?
This comes down to the question of how much responsibility does a registry/parent zone assume for its child delegations. In the domain name world, there is little need for the parent to enforce proper operation by the child (in terms of preventing protocol failures, I'm not including "fast flux" issues). However in the reverse map world, I'm not as sure of an answer. What is the experience of having an ISP that fails to maintain their reverse map delegation by customers that want to have their reverse map data available? I.e., once I wanted to have the reverse map for my new v6 (PA) subnet running, but our provider didn't have reverse map service for v6.
* If the answer to the orginal question is no, what, if anything, does the NCC do about things like lame delegations for reverse zones and the operational problems these cause the NCC?
There are two questions here. Do lame delegations cause problems and what should the RIPE NCC do about it? 5 years ago, there was software that behaved badly in a big way when there was a lame delegation. I don't know if that software is still a problem. Given the experience of lame delegation work I have done, it seems like the problem has mostly "just gone away." Do lame delegations cause operational problems for the RIPE NCC? The only thing I would suspect is an elevated query rate for stuff that belongs to lame servers. I suspect that that could be measured if we wanted. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Sarcasm doesn't scale.
Jim Reid wrote:
On May 14, 2007, at 10:20, Jørgen Hovland wrote:
I hope this does not become mandatory, only optionally or discontinue it. A very few amount of LIRs would have to send a zonefile in the size of (2^96 ) * 32 * 4 * 20 bytes to ns.ripe.net if it becomes mandatory.
Pardon my ignorance, but even if that were the case, what's the issue? I would assume that by the time you become an LIR you should have the bandwidth to do this, and the requisite DNS experience to make it as painless as possible. But is there some hidden cost or problem that I'm missing?
Let's step back. Slave service for reverse zones was something the NCC has been doing since the dawn of time. In the early days, connectivity was sometimes erratic, bandwidth was limited, lame delegations were common and DNS skills were worse than they are today.
That's a scary thought. :)
It made sense to have a robust and stable DNS platform and the NCC was in the position to provide that service. That was then. But this is now. The environment has changed. And there's less reliance on reverse DNS lookups these days too,
Less in some areas, but more in others (like mail, for better or worse). I would argue that we're in a weird world where if it doesn't matter, it doesn't matter at all, but if it matters it matters a lot.
even more so in an IPv6 world.
I would argue here that this is yet to be seen, given the (sadly) low rate of current IPv6 deployment.
So the questions for the WG should be IMO:
* Is there value in having the NCC provide DNS service for big/important reverse zones?
I think you're asking the wrong question (although I like Ed's definitions of "big" and "important." :) I would ask, "Is there value in the NCC making slave service for reverse zones available to those who receive allocations from us?" Which sort of sets the stage for the rest of the answers.
* If the answer to the above question is yes, under what conditions? ie What do we mean by big or important?
I think the answer to your first question is no, it should be available to everyone.
* If the answer is still yes, should this service be compulsory or optional?
Optional, always.
And under what conditions would optional use become compulsory and vice versa?
To get closer to answering the spirit of your original question, I don't think there is any value in requiring reverse zones from anyone. If a network operator wants to do a good job of providing reverse DNS, they will. If they don't, they won't, and short of pulling their allocation you can't enforce a mandatory policy anyway.
* If the answer to the orginal question is no, what, if anything, does the NCC do about things like lame delegations for reverse zones and the operational problems these cause the NCC?
Here's the tricky part. I think it would be a nice service for the NCC to offer, _if_ there are some rudimentary checks in place to make sure that the information is still up to date, and if the zones are dropped when it isn't. My opinion is that providing stale data is worse than providing no data at all, but I know reasonable minds can differ on this point. I'd like to add one more issue indirectly raised by Ed's post. I think he was right to bring up cost in regards to this discussion, more so if you agree with my perspective that this should be an optional service supplied to allocees. But if you assume that the NCC is going to be providing DNS services for something anyway (which of course they are) the marginal cost of adding reverse service for allocations is not zero, but I don't think it's overwhelming either. hth, Doug -- If you're never wrong, you're not trying hard enough
Hi, Brett Carr schrieb:
As mentioned in my presentation at RIPE 54 last week we have become aware that there is an inconsistency between ipv4 and ipv6 with regard to obtaining reverse delegation.
The reverse delegation procedure listed at http://www.ripe.net/rs/reverse/reverse_howto.html has the following listed: [...] We think it would be a good idea to address this inconsistency, this could be done in several ways including but not limted to:
Make ns.ripe.net mandatory on ipv4 and ipv6 delegations Make ns.ripe.net optional on ipv4 and ipv6 delegations Discontinue the secondary service on ns.ripe.net for new delegations.
Our suggestion and preference would be to make ns.ripe.net optional on both ipv4 and ipv6 delegations.
We would welcome and encourage input from the dns community on this subject.
i support the suggestion to make it optional. Discontinuation makes no sense - i don't really think this service causes a high workload or costs too much money. Making it mandatory for ALL allocations(?) would eventually cause operational problems for the LIR/customer in some cases, not really worth the effort. ==> Make it optional for all delegations, IPv4&IPv6 as suggested if you feel any needs to change the current situation (which i don't actually consider bad either). As a service, i would like to use RIPE as 2ndary in some cases. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 14 May 2007, at 09:21, Brett Carr wrote:
Our suggestion and preference would be to make ns.ripe.net optional on both ipv4 and ipv6 delegations. We would welcome and encourage input from the dns community on this subject.
I'm in favour of this suggestion. ERX migration could have been much less grief if we had done this back a bit. Best regards, Niall O'Reilly University College Dublin IT Services PGP key ID: AE995ED9 (see www.pgp.net) Fingerprint: 23DC C6DE 8874 2432 2BE0 3905 7987 E48D AE99 5ED9 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFGSXZSeYfkja6ZXtkRAoFKAJ9CyN5Nz+O5YIgZgIZBQcWFFRkHXACfQ+hZ OfwkYf94XRErml15SgH+pY0= =V9Lw -----END PGP SIGNATURE-----
participants (8)
-
Brett Carr -
Carsten Schiefner -
Doug Barton -
Edward Lewis -
Jim Reid -
Jørgen Hovland -
Niall O'Reilly -
Sascha Lenz