Replacing reverse zone delegations by DNAMEs
I don't know whether this is the most appropriate forum to raise this issue --- but if RIRs can be persuaded to support the alternate form of reverse zone delegation suggested here, perhaps other authorities would do the same. Fragmentation of IPv4 space leads to organisations having lots of little reverse zones, each of which requires: managing the contents, maintaining the registration, organising official slaves, DNSSEC signing ... There is much uneconomic effort involved. Locally we have been using a scheme to map such reverse lookups into a single common zone, described at http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones To take full advantage of this, however, requires promoting DNAMEs into the parent reverse zone. Logically, administrators of such zones ought to be delighted to replace delegations (multiple NS records, maybe DS records as well) with a single DNAME. But of course it has not been standard practice to support that. As DNAMEs do not redirect the name itself, there would be a problem for reverse zones containing significant records at the apex, e.g. PTR records pointing to a gateway host. (I think that practice, recommended in RFC 1033, has pretty much fallen into disuse.) If the IETF DNSEXT WG ever get their act together on "XNAME"/"CNAME+DNAME", that would cover that particular point, but meanwhile no-one would be obliged to use DNAMEs if they didn't want to. Anyway, I would welcome opinions on this idea. -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
On 29 Nov 2010, at 21:31, Chris Thompson wrote:
I don't know whether this is the most appropriate forum to raise this issue --- but if RIRs can be persuaded to support the alternate form of reverse zone delegation suggested here, perhaps other authorities would do the same.
It is. You could write this up as a policy proposal if the WG likes your idea. So far, the silence has been deafening. Perhaps you could expand on your original posting and see if that provokes some discussion?
Jim Reid wrote:
On 29 Nov 2010, at 21:31, Chris Thompson wrote:
I don't know whether this is the most appropriate forum to raise this issue --- but if RIRs can be persuaded to support the alternate form of reverse zone delegation suggested here, perhaps other authorities would do the same.
It is. You could write this up as a policy proposal if the WG likes your idea. So far, the silence has been deafening.
Perhaps you could expand on your original posting and see if that provokes some discussion?
I'm quite illiterate when it comes to DNS :-) but I read the proposal and the idea. What I fail to seeat 1st glance is where the RIR and the PDP comes in? Wilfried.
On 1 Dec 2010, at 20:27, Wilfried Woeber, UniVie/ACOnet wrote:
What I fail to see at 1st glance is where the RIR and the PDP comes in?
What Chris is proposing is a different way of dealing with reverse lookups in the DNS. If the idea gets support, this could have implications for the NCC. The WG might decide "We like DNAMEs in the reverse tree. NCC please implement that in your bits of in-addr.arpa and ip6.arpa. Or make it an option. Here's the policy goop to support this request. Oh and maybe that policy goop could/should be hawked around the other RIRs too.". And maybe this idea touches on DB if a DNAME object needs to be created to make the scheme fly for the reverse zones NCC manages. If that's the case, I expect there would need to be some policy done somewhere. A policy emerging from the DNS WG would be a novelty. :-) Please note the extensive qualifiers with should and maybes. I was/am getting ahead of myself. The meta-logic here is if the idea has merit and if the WG supports it, a policy proposal might be needed so that the NCC could implement it. That's all. I originally mentioned the idea of a policy proposal in the hope it would provoke a discussion and maybe wake up the WG. Well, we are having a discussion, but not about the DNAME idea. :-( At least, not yet... The time for invoking the PDP is some way off (if at all). Let's first establish if anyone in the WG cares about the idea. I'm disappointed there has been no reaction yet.
hum... instead of dlegation-only, you could have a dname-only zone... :) certainly argues for less centralization ... --bill On 1December2010Wednesday, at 12:57, Jim Reid wrote:
On 1 Dec 2010, at 20:27, Wilfried Woeber, UniVie/ACOnet wrote:
What I fail to see at 1st glance is where the RIR and the PDP comes in?
What Chris is proposing is a different way of dealing with reverse lookups in the DNS. If the idea gets support, this could have implications for the NCC. The WG might decide "We like DNAMEs in the reverse tree. NCC please implement that in your bits of in-addr.arpa and ip6.arpa. Or make it an option. Here's the policy goop to support this request. Oh and maybe that policy goop could/should be hawked around the other RIRs too.".
And maybe this idea touches on DB if a DNAME object needs to be created to make the scheme fly for the reverse zones NCC manages. If that's the case, I expect there would need to be some policy done somewhere. A policy emerging from the DNS WG would be a novelty. :-)
Please note the extensive qualifiers with should and maybes. I was/am getting ahead of myself. The meta-logic here is if the idea has merit and if the WG supports it, a policy proposal might be needed so that the NCC could implement it. That's all.
I originally mentioned the idea of a policy proposal in the hope it would provoke a discussion and maybe wake up the WG. Well, we are having a discussion, but not about the DNAME idea. :-( At least, not yet... The time for invoking the PDP is some way off (if at all). Let's first establish if anyone in the WG cares about the idea. I'm disappointed there has been no reaction yet.
On 01/12/10 20:27, Wilfried Woeber, UniVie/ACOnet wrote:
What I fail to see at 1st glance is where the RIR and the PDP comes in?
Me too. I think that the approach which Chris is suggesting sits more in LIR territory than with the RIRs. It's a truly nifty idea, IMNSHO. My employer's LIR has found no objection to this approach. Neither has the tunnel broker for my domestic IPv6 connectivity. For example: dig -x 2001:770:13f:1:: dig -x 2001:770:98:200::35:1 Unfortunately, I didn't have the DNAME option whenever I had to set up reverse DNS for a /19 and a /20 in IPv4 as 48 /24's. Now, since this isn't broken, I'm not minded to fix it. /Niall
Moderator, Please kindly unsubscribe my email from the group list. Thank you. Cc_ololo@yahoo.com C. C. Ololo Principal Entratek Systems LLC 9319 LBJ Freeway, Dallas, TX 75243 USA -----Original Message----- From: Niall O'Reilly <Niall.oReilly@ucd.ie> Sender: dns-wg-admin@ripe.net Date: Wed, 01 Dec 2010 22:38:54 To: <dns-wg@ripe.net> Cc: <cet1@cam.ac.uk> Subject: Re: [dns-wg] Replacing reverse zone delegations by DNAMEs On 01/12/10 20:27, Wilfried Woeber, UniVie/ACOnet wrote:
What I fail to see at 1st glance is where the RIR and the PDP comes in?
Me too. I think that the approach which Chris is suggesting sits more in LIR territory than with the RIRs. It's a truly nifty idea, IMNSHO. My employer's LIR has found no objection to this approach. Neither has the tunnel broker for my domestic IPv6 connectivity. For example: dig -x 2001:770:13f:1:: dig -x 2001:770:98:200::35:1 Unfortunately, I didn't have the DNAME option whenever I had to set up reverse DNS for a /19 and a /20 in IPv4 as 48 /24's. Now, since this isn't broken, I'm not minded to fix it. /Niall
On Wed, 1 Dec 2010, Niall O'Reilly wrote:
Me too. I think that the approach which Chris is suggesting sits more in LIR territory than with the RIRs.
What about legacy allocations where the DNAME needs to be placed in a reverse zone maintained by RIPE? Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
* Tony Finch:
On Wed, 1 Dec 2010, Niall O'Reilly wrote:
Me too. I think that the approach which Chris is suggesting sits more in LIR territory than with the RIRs.
What about legacy allocations where the DNAME needs to be placed in a reverse zone maintained by RIPE?
I don't think such a case actually exists. Could you be more specific? -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Thu, 2 Dec 2010, Florian Weimer wrote:
* Tony Finch:
On Wed, 1 Dec 2010, Niall O'Reilly wrote:
Me too. I think that the approach which Chris is suggesting sits more in LIR territory than with the RIRs.
What about legacy allocations where the DNAME needs to be placed in a reverse zone maintained by RIPE?
I don't think such a case actually exists. Could you be more specific?
Ah, now I look they seem to be ARIN's zones. (Our allocations include 128.232, 129.169, and 131.111.) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
* Tony Finch:
On Thu, 2 Dec 2010, Florian Weimer wrote:
* Tony Finch:
On Wed, 1 Dec 2010, Niall O'Reilly wrote:
Me too. I think that the approach which Chris is suggesting sits more in LIR territory than with the RIRs.
What about legacy allocations where the DNAME needs to be placed in a reverse zone maintained by RIPE?
I don't think such a case actually exists. Could you be more specific?
Ah, now I look they seem to be ARIN's zones. (Our allocations include 128.232, 129.169, and 131.111.)
It should still work. In the parent, you'd have: 169.129.in-addr.arpa. IN NS ns1.example.net. 169.129.in-addr.arpa. IN NS ns2.example.net. And ns*.example.net. would serve 169.129.in-addr.arpa. IN DNAME reverse.example.com. This scheme breaks down when you delegate individual /32s because DNAME does not apply to the name itself, only its children. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On Thu, 2 Dec 2010, Florian Weimer wrote:
It should still work. In the parent, you'd have:
169.129.in-addr.arpa. IN NS ns1.example.net. 169.129.in-addr.arpa. IN NS ns2.example.net.
And ns*.example.net. would serve
169.129.in-addr.arpa. IN DNAME reverse.example.com.
The point is to put the DNAME in the parent zone to save the effort of maintaining the delegated zone, i.e. all the stuff you have to do even if the zone is nearly empty. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7, DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR ROUGH. RAIN THEN FAIR. GOOD.
On Dec 2 2010, Tony Finch wrote:
On Thu, 2 Dec 2010, Florian Weimer wrote:
* Tony Finch:
On Wed, 1 Dec 2010, Niall O'Reilly wrote:
Me too. I think that the approach which Chris is suggesting sits more in LIR territory than with the RIRs.
What about legacy allocations where the DNAME needs to be placed in a reverse zone maintained by RIPE?
I don't think such a case actually exists. Could you be more specific?
Ah, now I look they seem to be ARIN's zones. (Our allocations include 128.232, 129.169, and 131.111.)
It's actually rather less likely that we would want to use the scheme for those large reverse zones. We also have 192.152.213/24 and 192.84.5/24 (which are also ERX and ARIN-hosted) for which it would be useful - but that's only two zones, not really worth worrying about. Locally, I have my eye on the several 193.60.x/24 zones we have delegated from JANET. (193.60/16 is delegated to JANET by RIPE.) So why didn't I start off by raising this in a JANET context rather than a RIPE one? Let's just say that I thought here a better place to get useful technical input... -- Chris Thompson University of Cambridge Computing Service, Email: cet1@ucs.cam.ac.uk New Museums Site, Cambridge CB2 3QH, Phone: +44 1223 334715 United Kingdom.
Chris,
Locally we have been using a scheme to map such reverse lookups into a single common zone, described at
http://people.pwf.cam.ac.uk/cet1/prune-reverse-zones
To take full advantage of this, however, requires promoting DNAMEs into the parent reverse zone.
for this particular list it might be advised to focus the discussion on the reverse mapping case (for both v4, still, and v6). Not sure I understand what the implicit problem statement is, but it seems there are two stages: 1) You want to maintain zone data in only one place "first derivative", changes to zone data 2) You also want to set up as few zones as possible "second derivative", changes to zone meta data The proposal/suggestion/hack linked above optimizes all this for a subset of scenarios and all towards the provisioning side. Can it be done? Sure. Would it scale, i.e., what would be the effects if 10%, 50% or 90% of the reverse zones would be replaced by this? I have no idea. Should it be recommended? Probably premature to ask pending understanding of the side effects. Just some questions to chew on, in no particular order and without being exhaustive: o (How) would this work with the parent zone determination for DNS Dynamic Updates? o Would this impose more or less load on the "parents'" name servers? o What would be the scaling effects on (validating) resolvers? o Is the maintenance of multiple zones, including data maintenance and infrastructure maintenance (setting up, checking and changing slaves) really an operational issue of significance? o Will this become better or worse for IPv6 reverse? o To what extent are today's tools, scripts, IPAM solutions _not_ solving the task? o What are the side effects of putting all PTRs in one basket^Wzone?
As DNAMEs do not redirect the name itself, there would be a problem for reverse zones containing significant records at the apex, e.g. PTR records pointing to a gateway host. (I think that practice, recommended in RFC 1033, has pretty much fallen into disuse.) If the
That's probably section 3.3 of RFC1101. Not widely used since CIDR times. There's little to find except meta data at the apex of most v4 reverse zones and that should also be true for v6. -Peter {no hat}
participants (9)
-
bill manning -
Chris Thompson -
Florian Weimer -
Jim Reid -
Niall O'Reilly -
ololocc＠entratek.com -
Peter Koch -
Tony Finch -
Wilfried Woeber, UniVie/ACOnet