# $Id: rapport-enum4.txt,v 1.7 2002/10/27 23:57:17 dufberg Exp $ * ENUM4 - Description of the DNS infrastructure for the Swedish ENUM trial Editor: Mats Dufberg, Skanova ** 1. Background In the prestudy phase of the ENUM test activity organized by PTS, the ENUM4 work group was to [1] ENUM4 is to study the requirements concerning a common infrastructure for ENUM on the country code level (TIER 1) for the test activities, and collect basic data concerning the delegation of the .6.4.e164.arpa domain etc. In this document, a proposal for a solution of the DNS level of the future Swedish ENUM infrastructure is presented. (For a description of DNS, or Domain Name System, see [2, 3]). It it not within the scope of this report to suggest any cost model for the operation of the ENUM Tier 1 Registry. In the report of the ENUM2 work group, there is a charging model on page 20 [4]. ** 2. Limitations In this proposal the target is the common part of the infrastructure. It does not concern which technique is used by an ENUM Tier 2 Nameserver Provider (for definition see the ENUM-2 report [4]) for its customer's zone. This proposal is built on the current IETF standard for ENUM [5]. ** 3. ENUM Tier 1 Registry, ENUM Tier 2 Nameserver Provider and the ENUM Domain Name The Tier 1 Manager (as defined by ITU-T [6]) will in the the Swedish ENUM solution accept the responsibility of the 6.4.e164.arpa zone. We assume that ENUM Tier 1 Manager will be a neutral body, such as PTS, the Post- och telestyrelsen [7]. That does not mean that PTS will run the ENUM Tier 1 Registry, which includes the responsibility for the zone file. Rather, that task can be designated to some other body. The responsibility of the ENUM Tier 1 Registry is to register the ENUM Domain Names, the TIER 1 zone and its nameservers [8]. The ENUM Domain Name (for a definition see the ENUM2 report [4])is the domain in which the ENUM DNS data, i.e. the NAPTR records, are to be stored for ENUM to work in accordance with the ENUM protocol [5]. This means that for each E.164 number there is one and only one ENUM Domain Name, i.e. the one corresponding to the E.164 number. Reversely, there is exactly one E.164 number corresponding to each ENUM Domain Name. Given the E.164 number 08-384859 in Sweden, the corresponding ENUM Domain Name is 9.5.8.4.8.3.8.6.4.e164.arpa. The service provider that is responsible for running DNS with the NAPTR records for a ENUM Domain Name is called a ENUM Tier 2 Nameserver Provider. There are two clear alternatives, either TIER 1 and TIER 2 is run by the same entity on one level, or we have a hierarchical structure in which TIER 1 for each E.164 number refers to [9] the ENUM Tier 2 Nameserver Provider that keeps the NAPTR records for that E.164 number. In the first case, the TIER 1 zone would include all NAPTR records, which would lead to a centralized responsibility on TIER 1, with a requirement to include a solution that can handle many updates. At first sight it seems to lead to a large zone, but there is nothing that prevents TIER 1 from cutting the zone into several parts. However, TIER 1 would have to be run by an organization that could handle such a load. Such a solution would also be an obstacle for flexible solutions that would meet the need of the E.164 subscriber, such as dynamic update via DNS. The second solution, to split the responsibility for TIER 1 and TIER 2, is in line with desire to minimize the parts that must be run under monopoly, and to create a possibility for competition when it is technically and practically possible without risking the stability. *** Proposal 1 The work group suggest that TIER 1 and TIER 2 are kept apart so that TIER 1 contains no ENUM DNS data, but only referrals to ENUM Tier 2 Nameserver Providers. ** 4. The assignments and ported E.164 numbers A telephony service provider (TSP) [10] is assigned series of E.164 numbers on request by PTS. Such series are called number assignments. The TSP can use these E.164 numbers for the telephony service that their customers subscribe to. The customer has then become a subscriber of an E.164 number. The subscriber can via number portability request to port its E.164 number to another TSP, which will lead to non-contiguous number assignments for the TSP originally assigned the E.164 number series from PTS. A move of an E.164 number from one TSP to another is called a porting, and it must be reported to the central reference database (CRefDB) for number portability (presently run by SNPAC [11]), which makes the information (reference data) on where the number belongs available to all entities that subscribe on the service from SNPAC. A porting can be definite, i.e. it does not have to be reversed when the subscriber of the E.164 number has canceled its subscription of the E.164 number. The number can instead stay where it is if the recipient TSP wants to keep it. After a porting, the original TSP, who was assigned the number by PTS, has no longer any responsibility for the operation of the number. One could therefore say that the portation creates holes in the assignments. Only the TSP that the E.164 number is currently registered on, knows who the subscriber is. ** 5. DNS delegation according to TSP number assignment from PTS One proposal has been that from the TIER 1 should make DNS delegations according to the number assignments already made to different TSPs. By doing so, the TIER 1 zone would be extremely stable because it would only have to be updated when a new E.164 number assignment is made. We are however questioning if this really would be a good solution. The equivalent in DNS of a range of E.164 numbers is a subtree. If the range is +468380000-+498389999 then the DNS tree is 8.3.8.6.4.e164.arpa. If one number, say +468384859, is ported then either the tree cannot be delegated, or the ported number (ENUM Domain Name) will be included in the tree and delegated to the TSP that originally received the number assignment. Delegation of a tree minus some specific ENUM Domain Names does not work on technical grounds. If a E.164 number is ported, then the original TSP without any responsibility for the E.164 number would have to be forced to do operation for the equivalent ENUM Domain Number, if the DNS delegation is based on the number assignment. And that would not be reasonable. It would also be a problem in that an E.164 subscriber with an E.164 number no longer managed by the TSP that originally got the number assignment from PTS would still be dependent on that TSP. This could easily lead to unclear conditions of responsibility. A TSP would also have to differentiate between a E.164 number in an original E.164 number assignment the TSP has received from PTS and a E.164 number ported to the TSP from another TSP when it comes to service levels. Since E.164 numbers ported to a TSP from another TSP still would be depending on a party outside the TSPs control it cannot guarantee the same level of service for that E.164 number towards a E.164 subscriber. It is true that the law requires that there should not be any lack of quality due to porting, but one can easily forsee scenarios where that could happen if the DNS delegation is based on the number assignments. Say that a E.164 number was assigned TSP-A, but later ported to TSP-B. The ENUM Domain Name would still depend on TSP-A to work. TSP-A has bad service of its nameservers, and an accident causes the DNS data to be lost. The empty zone is transfered to all slaves within minutes, and there is no working backup. TSP-B could never guarantee that TSP-A runs the ENUM DNS structure following good technical standards without reaching an agreement with TSP-A, which could turn out to be impossible. Also, a mandatory DNS delegation based on number assignment would result in two levels of monopoly which most likely would result in less competition among ENUM Tier 2 Nameserver Providers. *** Proposal 2 The work group suggest that no DNS delegations be made based on the number assignments from PTS. ** 6. Hand over from ENUM Tier 1 Registry to ENUM Tier 2 Nameserver Provider The hand over from TIER 1 to TIER 2, meaning the point in the DNS tree where the responsibility changes from TIER 1 to TIER 2, is to be chosen in such a way that a stable DNS structure is obtained and in a way that the ENUM Tier 2 Nameserver Providers and E.164 subscribers (i.e. the ENUM Domain Name holder) can accomplish effective technical DNS solutions. Since number portability in principal is possible for any given E.164 number the DNS delegation normally will have to be for the single ENUM Domain Name. This means that for our example E.164 number (08-384859) there will be a delegation in TIER 1 to TIER 2 for 9.5.8.4.8.3.8.6.4.e164.arpa. Technically this means there will be an entry for 9.5.8.4.8.3.8.6.4.e164.arpa in the TIER 1 zone file but there will be no ENUM DNS data (NAPTR records) there - only referrals to the ENUM Tier 2 Nameserver Provider responsible for the ENUM Domain Name in question. The TIER 2 zone file for the ENUM Domain Name will contain the ENUM DNS data the ENUM subscriber requests. Even if we were to disregard the possibility that a E.164 number has been ported away from the TSP who initially got the E.164 number assignment from PTS (which we cannot) we can't disregard the possibility that a subscriber for a E.164 number changes ENUM Tier 2 Nameserver Provider. Since DNS does not permit ENUM Tier 1 Registry to delegate all of 8.3.8.6.4.e164.arpa to one ENUM Tier 2 Nameserver Provider but only 9.5.8.4.8.3.8.6.4.e164.arpa to another ENUM Tier 2 Nameserver Provider, the delegation from TIER 1 to TIER 2 must be at the ENUM Domain Name so that a future break out of one number from a block assignment does not require massive changes to the existing delegation. The latter would contradict our stability requirements. *** Proposal 3 The work group suggests that the hand over from TIER 1 level to TIER 2 level is the ENUM Domain Name itself, except in the case outlined below. The reasoning above was based on the assumption that there were different E.164 subscribers inside the number blocks which would be technically possible to delegate as a block in DNS. In the cases where a block of number have the same E.164 subscriber the situation is different. If for example all numbers 384800-384899 (inside area code 08) have the same E.164 subscriber and use the same TSP it is not a problem to make a delegation of 8.4.8.3.8.6.4.e164.arpa to a single ENUM Tier 2 Nameserver Provider, instead of making 100 delegations of individual ENUM Domain Names. *** Proposal 4 The work group suggests that it should be possible to request that ENUM Tier 1 Registry delegates higher up in the DNS hierarchy when the same E.164 subscriber with a single TSP disposes over a consecutive series of E.164 numbers that are technically possible to delegate with a single delegation in the Swedish ENUM tree [12]. ** 7. Delegation using the DNAME resource record DNAME [13] is a new DNS record type that could be used for handing over from one DNS zone to another. Even if DNAME can seem to be an attractive alternative for delegations, the status of DNAME is not clear. DNAME currently have the status "proposed standard", but DNAME will probably seize to be a recommendation for reverse lookups of IPv6 addresses and thereby loose its position. It is obvious that DNAME is not fully accepted, and it is uncertain what support there is for DNAME in different name servers. Considering this, DNAME should not be used. *** Proposal 5 The work group proposes that DNAME not be used for delegations from TIER 1 to TIER 2. ** 8. Delegations using the NS resource record With NS delegations a normal DNS delegation, just like with any domain used on the Internet, is achieved. There are no limitations for what data is permitted in the zone besides that there cannot exist a CNAME resource record for the ENUM Domain Name itself since it is a zone apex and therefor contains other resource records (a CNAME is invalid if there are other DNS resource records for that particular DNS label) [14]. For delegations of whole blocks of numbers (proposal 4), an NS delegation is the only possible form of delegation. There are however other drawbacks with NS delegations. First, it generates overhead since every ENUM delegation (either a single ENUM Domain Name, or a block delegation) must have it's own zone file. Even if the zone file can be programmatically genereated, it is a increased load on the name server compared to just the load generated by serving the ENUM DNS data (NAPTR records). If there is much ENUM DNS data this overhead is of less importance. Secondly, it becomes a great burden for DNSsec administration if and when the ENUM DNS data is to be protected with DNSsec. Every ENUM zone must have a corresponding key with associated key management. ** 9. Delegations using the CNAME resource record With CNAME, the ENUM Tier 2 Nameserver Provider can put all ENUM DNS data for its customers in one single zone. For example, if a Tier 2 Nameserver Provider with, say, the DNS domain op1.se is responsible for the two swedish E.164 numbers 08-384859 and 070-2582588 creates the zone enum.op1.se for it's customers ENUM DNS data the Tier 2 Nameserver Provider can have TIER 1 delegate using CNAMEs like this : $ORIGIN 6.4.e164.arpa. 9.5.8.4.8.3.8 CNAME 9.5.8.4.8.3.8.6.4.enum.op1.se. 8.8.5.2.8.5.2.0.7 CNAME 8.8.5.2.8.5.2.0.7.6.4.enum.op1.se. Besides resulting in less zone data by not having to have NS and SOA resource records for each and every ENUM Domain Name the DNSsec administration would be easier since it is enough with one key pair per zone, which in this case would be enum.op1.se. There are however drawbacks with CNAME. First, it would only be possible to have ENUM DNS data for the ENUM Domain Name. If there is a application that requires a sub domain to the ENUM Domain Name to store data, for example _kerberos._udp.9.5.8.4.8.3.8.6.4.e164.arpa, this would not work since delegations using CNAME only include the exact ENUM Domain Name as opposed to NS delegations that comprise of the ENUM Domain name and everything below it in the DNS tree. Secondly, it is perfectly possible to have circular references where the delegated node points back at the delegating node. *** Proposal 6 The work group suggests that delegation using normal NS resource records from TIER 1 to TIER 2 always should be possible when a ENUM Tier 2 Nameserver Provider requests it, and that it is the only possible type of delegation for whole blocks of E.164 numbers. Delegations of single ENUM Domain Names using CNAME shall also be possible when requested. ** 10. ENUM and DNSsec There are well-known weaknesses in DNS which could be used by an attacker to do harm, for instance by blocking a E.164 number. DNSsec is a solution to the problem, though at the time of writing not entirely standardized or widely implemented. Using DNSsec, the risk of getting false data is significantly reduced. Even before DNSsec is fully deployed on the Internet it will be possible to allow the Swedish ENUM tree be fully secured by DNSsec by creating a separate DNSsec zone for the Swedish ENUM tree. *** Proposal 7 The group suggests that the Swedish ENUM tree [12] be secured using DNSsec as soon as it is technically and administratively possible to do so without waiting for the root-zone to deploy DNSsec. ** 11. Servers Since ENUM DNS data must be seen as a national resource it is important that access to ENUM DNS data is wide-spread. It is therefore important that no company is given a competitive advantage or is given the possibility to limit the access to ENUM DNS data to competitors. The DNS servers which constitute the Swedish ENUM infrastructure must therefor be placed as publicly as possible. For permanent operation of ENUM, there must exist formal regulation for the central parts of the DNS structute, i.e. for the ENUM Tier 1 Registry, the ENUM Tier 1 zone file and its nameservers. We expect PTS to set that regulation. Other parts of the ENUM DNS structure, i.e. the ENUM Tier 2 structure, is of course also of vital importance, but do not expect any regulation of them. A "best current practice" for ENUM Tier 2 operation is needed, which we expect the involved parties to agree on. During the test period consensus between the trial participants must be reached. *** Proposal 8 The group suggests that PTS, as a neutral party on the market, should be the the Tier 1 Manager during the test period, and that PTS designates the task of technical operation of the TIER 1 to a suitable party (i.e. the ENUM Tier 1 Registry). The group also suggests that PTS requires the use of publicly available name servers in accordance with DNS operational practices [2, 3]. *** Proposal 9 The group suggests that for permanent operation in a commercial environement beyond the test period that the demands be raised requiring at least four name servers on highly available locations and good distribution across the Swedish part of the Internet. All publicly announced servers must respond to DNS queries in accordance with the recommendations in place for root name servers [15]. DNS queries can be time critical, especially when used to distribute information about telephony services. It is therefore desirable that TSP create guaranteed access to the DNS database, which can be acheived by have a server that the TSP can download a copy of the Tier 1 zone file. *** Proposal 10 The group suggests that operational requirement for permanent Operations in a commercial environment must include the requirement that beside the four publicly available servers, a fifth publicly available server is made available for zone transfer to interested parties including TSPs. ** Notes [1] PTS ENUM-site is too long for one line and is presented broken. Type it in without spaces or newlines: [2] RCF 1034, P.V. Mockapetris, "Domain names - concepts and facilities", . [3] RFC 1035, P.V. Mockapetris, "Domain names - implementation and specification", . [4] "ENUM 2 - Description of Administrative Routines for ENUM and Prestudy for the Trial", report to PTS. Editor: Staffan Hagnell. [5] RFC 2916, P. Faltstrom, "E.164 number and DNS", . [6] Draft ITU-T Supplement, "Operational & Administrative Issues Associated with National Implementations of the ENUM Functions", Draft #11. [7] Post- och telestyrelsen is the Telecommunications authority of Sweden, . [8] See section 5.6 in the ENUM 2 report [4]. [9] Here we use the DNS neutral phrase "refers to" or "referral" to include different DNS techniques to achieve what is often done with a DNS delegation. [10] By a TSP (telephony service provider) we mean a company fulfilling the Swedish telecommunications act and PTS demands for the assignment of E.164-numbers for subscribers. [11] SNPAC Swedish Number Portability Administrative Center AB, . [12] By the Swedish ENUM tree we mean the part of the global DNS below the node 4.6.e164.arpa. [13] RFC 2672, M. Crawford, "Non-Terminal DNS Name Redirection", .. [14] Excuse a technical discussion of DNS. The claims are, however, not controversial. [15] RFC 2870, R. Bush, D. Karrenberg, M. Kosters, R. Plzak., "Root Name Server Operational Requirements", .