Proposal to Change the Dash ('-') Notation in Reverse DOMAIN Objects
[Apologies for duplicate emails] Dear Colleagues, What follows is a short proposal to change the process of creating and updating reverse DOMAIN objects in the RIPE Database. Because this is a proposed RIPE Database change, please direct any discussion to the RIPE Database Working Group mailing list to keep it focused in one place. Regards, Denis Walker Business Analyst RIPE NCC Database Group Proposal to change the dash ('-') notation in reverse DOMAIN objects Introduction ------------ Reverse delegation DOMAIN objects allow the use of a dash ('-') in the syntax. The current arrangement causes problems with DNSSEC. We propose to drop the current behaviour. We would also introduce a new syntax using the dash notation to avoid the need for manual intervention for classless delegations. Both the current and the new behaviour described in this document only apply to IPv4 delegations. Feature to be deprecated ------------------------ Currently, we allow a dash in the third octet of an IPv4 reverse delegation. So, for the address range 10.2.1.0 - 10.2.100.255, the syntax allows a reverse delegation DOMAIN object to be submitted as 1-100.2.10.in-addra.arpa. The RIPE Database update software will expand this into 100 separate objects in the database with prefixes from 1.2.10.in-addra.arpa to 100.2.10.in-addra.arpa. Apart from the prefix, all the other data in the submitted object will be duplicated in all 100 objects. To modify or delete this set of objects, the user has to process all 100 objects individually. No bulk operations are possible after the original object has been expanded in the database. This feature is not compatible with using DNSSEC. The value of the "ds-rdata:" attribute is a hash that includes the delegation. By definition, this must be different for each DOMAIN object. These different hash values for multiple objects cannot be entered by submitting a single object with the dash notation. This issue was raised by members of the DNS community, and the RIPE NCC now proposes to deprecate this update feature. Feature to be added ------------------- Classless delegations, according to RFC2317 (http://www.ietf.org/rfc/rfc2317.txt), are currently handled manually by the DNS Department at the RIPE NCC. Although the objects can be created in the RIPE Database, they will not be propagated to the zone files. The RIPE NCC proposes to allow a dash in the fourth octet of an IPv4 reverse delegation. So, for the address range 10.2.1.6 - 10.2.1.25, the syntax would allow a reverse delegation DOMAIN object to be submitted as 6-25.1.2.10.in-addra.arpa. This object would not be expanded by the RIPE Database update software into 20 separate objects, as it is with the feature described above. It would be created in the database as a single object, including the dash in the range. New DNS provisioning software would handle the new dash notation and propagate this delegation to the zone file. However, the range 0-255 is a special case and would not be allowed in the fourth octet. Modification and deletion can be performed on the single object in the database. Any change would be propagated into the zone file by the new delegation software.
does this not arise from some confusion. that the delegation request object allows a macro that has a dash does not mean any dns objects have a dash. so there is no actual dns problem. or am i confused as usual? randy
It's not a DNS problem exactly. But since the macro in question can allow a RIPE db user to incorrectly duplicate DS record data for multiple zones, an unsuspecting entrant to the world of DNSSEC will have a rather awkward time. You could argue buyer beware, but off the cuff I see no general issue with trying to remove potential errors before frustration sets in. Cheers, Terry On 18/04/2011, at 7:34 PM, "Randy Bush" <randy@psg.com> wrote:
does this not arise from some confusion.
that the delegation request object allows a macro that has a dash does not mean any dns objects have a dash. so there is no actual dns problem.
or am i confused as usual?
randy
It's not a DNS problem exactly. But since the macro in question can allow a RIPE db user to incorrectly duplicate DS record data for multiple zones, an unsuspecting entrant to the world of DNSSEC will have a rather awkward time. You could argue buyer beware, but off the cuff I see no general issue with trying to remove potential errors before frustration sets in.
does this not arise from some confusion.
that the delegation request object allows a macro that has a dash does not mean any dns objects have a dash. so there is no actual dns problem.
and we should also prevent folk such as mycroft-jones from asking for dns delegation. brilliant. randy --- Q: Because it reverses the logical flow of conversation. A: Why is top posting frowned upon?
Hi, On Mon, Apr 18, 2011 at 10:04:41PM +0900, Randy Bush wrote:
and we should also prevent folk such as mycroft-jones from asking for dns delegation. brilliant.
I'm not exactly sure why we want to support mycroft-jones.1.0.0.2.ip6.arpa in the RIPE DNS tools... or maybe I am misunderstanding something now, but this whole apparatus is to automate delegation of *reverse* zones, and those usually don't consist of people's surnames. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
I'm not exactly sure why we want to support
mycroft-jones.1.0.0.2.ip6.arpa
in the RIPE DNS tools... or maybe I am misunderstanding something now, but this whole apparatus is to automate delegation of *reverse* zones, and those usually don't consist of people's surnames.
and the zones do not consist of 120-127.42.66.in-addr.arpa either. the hyphen syntax is a macro in a language that is not in the dns. therefor that it is not acceptable dns syntax is not relevant. randy
Hi, On Mon, Apr 18, 2011 at 10:15:27PM +0900, Randy Bush wrote:
I'm not exactly sure why we want to support
mycroft-jones.1.0.0.2.ip6.arpa
in the RIPE DNS tools... or maybe I am misunderstanding something now, but this whole apparatus is to automate delegation of *reverse* zones, and those usually don't consist of people's surnames.
and the zones do not consist of 120-127.42.66.in-addr.arpa either.
the hyphen syntax is a macro in a language that is not in the dns. therefor that it is not acceptable dns syntax is not relevant.
So what exactly would be the benefit of delegating all names from "mycroft" to "jones" with this mechanism? Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
I'm not exactly sure why we want to support
mycroft-jones.1.0.0.2.ip6.arpa
in the RIPE DNS tools... or maybe I am misunderstanding something now, but this whole apparatus is to automate delegation of *reverse* zones, and those usually don't consist of people's surnames.
and the zones do not consist of 120-127.42.66.in-addr.arpa either.
the hyphen syntax is a macro in a language that is not in the dns. therefor that it is not acceptable dns syntax is not relevant.
So what exactly would be the benefit of delegating all names from "mycroft" to "jones" with this mechanism?
see http://en.wikipedia.org/wiki/Analogy randy
On 18 apr 2011, at 15:34, "Gert Doering" <gert@space.net> wrote:
those usually don't consist of people's surnames.
Well, have you followed the work in zeroconf? Patrik
Hi, On Mon, Apr 18, 2011 at 03:57:11PM +0200, Patrik Faltstrom (pfaltstr) wrote:
On 18 apr 2011, at 15:34, "Gert Doering" <gert@space.net> wrote:
those usually don't consist of people's surnames. Well, have you followed the work in zeroconf?
I haven't, admittedly. Could you point me to the relevant documents? (There's *lots* of work in zeroconf) Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279
On 18 apr 2011, at 16.40, Gert Doering wrote:
On Mon, Apr 18, 2011 at 03:57:11PM +0200, Patrik Faltstrom (pfaltstr) wrote:
On 18 apr 2011, at 15:34, "Gert Doering" <gert@space.net> wrote:
those usually don't consist of people's surnames. Well, have you followed the work in zeroconf?
I haven't, admittedly. Could you point me to the relevant documents?
(There's *lots* of work in zeroconf)
I missed a few thousand smileys...of course NOONE can follow everything in zeroconf... In short, we have things live like this: lb._dns-sd._udp.0.0.168.192.in-addr.arpa. IN PTR example.com. The result is similar to do the same queries in .local TLD (but then most of the time using mDNS). See section 11 of http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt for example. Patrik
Denis, all, {ncc services stripped as requested, but dns and db wg kept for now}
What follows is a short proposal to change the process of creating and
it appears that these are actually three proposals that are linked together but might deserve discussion of their own merits.
Feature to be deprecated ------------------------ Currently, we allow a dash in the third octet of an IPv4 reverse delegation. So, for the address range 10.2.1.0 - 10.2.100.255, the syntax allows a reverse delegation DOMAIN object to be submitted as 1-100.2.10.in-addra.arpa. The RIPE Database update software will expand this into 100 separate objects in the database with prefixes from 1.2.10.in-addra.arpa to 100.2.10.in-addra.arpa. Apart from the prefix, all the other data in the submitted object will be duplicated in all 100 objects. To modify or delete this set of objects, the user has to process all 100 objects individually. No bulk operations are possible after the original object has been expanded in the database.
So, there is a macro feature in there that isn't explicit but overlays the object name and key. Also it seems this macro is only useful at object creation time. Can you share any numbers in terms of objects an LIRs that have been using this feature?
This feature is not compatible with using DNSSEC. The value of the "ds-rdata:" attribute is a hash that includes the delegation. By
Well, this is only a consequence of chosing the DS data as the registration object. If that were the only obstacle and provided LIRs are using the same DNSKEY for multiple zones, this could of course be changed to allow for registration of the DNSKEY (identical across whatever macro expansion) to make the data part consistent for all those objects covered.
Feature to be added -------------------
in the RIPE Database, they will not be propagated to the zone files. The RIPE NCC proposes to allow a dash in the fourth octet of an IPv4 reverse delegation. So, for the address range 10.2.1.6 - 10.2.1.25, the syntax would allow a reverse delegation DOMAIN object to be submitted as 6-25.1.2.10.in-addra.arpa. This object would not be expanded by the RIPE Database update software into 20 separate objects, as it is with the feature described above. It would be created in the database as a single object, including the dash in the range.
Sounds reasonable to me for those direct assignments smaller than /24.
New DNS provisioning software would handle the new dash notation and propagate this delegation to the zone file. However, the range 0-255 is a special case and would not be allowed in the fourth octet.
This would suggest the fourth label is evaluated and checked also against the governing inetnum object or authorization? -Peter {no hats}
participants (7)
-
Denis Walker -
Gert Doering -
Patrik Faltstrom (pfaltstr) -
Patrik Fältström
-
Peter Koch -
Randy Bush -
Terry Manderson