[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.