July 2004 - enum-wg - mailman.ripe.net

Proposal for non-geographic ENUM E.164 UPTS for the general public
by Chris Heinze 31 Jul '04

31 Jul '04

hi everyone/anyone... ;) accounting the lack of criticism i suppose the proposal is generally considered acceptable. well then i'd suggest to vote on this proposal on ripe49. kind regards, Chris Heinze

4 3

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 15 Jul '04

15 Jul '04

On 15 Jul 2004, at 14:40, Jim Reid wrote: > So you can try different > delegation approaches and see what works and what doesn't. And aside > from the DNS mechanics, you can consider things like the impact of a > particular approach on interfaces, roles & responsibilities as well as > stuff like competition policy and the public interest. IMO it's far > more important to learn about these things than focus on which name > server(s) some zone sits on. No dispute there! Best regards, Niall O'Reilly UCD Computing Services

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 15 Jul '04

15 Jul '04

On 15 Jul 2004, at 11:07, Jim Reid wrote: > And it will > make DNSSEC deployment (hah!) much harder because the parent can't > secure any delegations with DS records because there are no proper > delegations. So, we'd better make sure our trial doesn't take longer than six months ? 8-) Seriously, though, this is something I need to avoid losing sight of. Thanks. > DNAME is even worse because there are plenty of name > servers and resolvers out there that don't understand this RR. This also. thanks again. > It's > not impossible that some applications will get upset if they get > CNAME-like referrals to their lookups when they only expected to get > NAPTR RRs or conventional referrals. For instance think of someone who > writes a minimal ENUM-aware resolver as a Java applet for their mobile > phone. Nobody with significant market share would be involved in inflicting such a broken application on the unsuspecting customers, would they ? 8-) Best regards, Niall O'Reilly UCD Computing Services

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 15 Jul '04

15 Jul '04

On 15 Jul 2004, at 11:07, Jim Reid wrote: > Another problem -- which won't apply to someone clueful like you -- is > that the introduction of CNAMEs increases the likelihood of looping or > very long CNAME chains. Or dangling CNAMEs that point at nothing. Even > without these administrative errors, the introduction of CNAMEs will > complicate ENUM lookups and could mean they take too long. This would > be somewhat annoying when someone picks up their ENUM-aware phone, > dials a number and then waits for an eternity while the resolver > chases down umpteen CNAME chains before making a phone ring. IMO it's > best not to give people access to that much rope to hang themselves. OTOH, there's a balance to be struck between allowing people to be responsible for their own mistakes and engaging in the diminishing-returns game of protecting them from everything. If registrars or T2 registries can't do their job, how long will they stay in business ? Best regards, Niall O'Reilly UCD Computing Services

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 15 Jul '04

15 Jul '04

On 15 Jul 2004, at 11:07, Jim Reid wrote: > You lose the granularity of control and the flexibility to let > customers manage their delegations. I'm presuming you plan to have all > your numbers CNAME'd into a single zone file rather than discrete zone > files for each zone. I see it quite the other way around: you _gain_ flexibility. The customer has a single point of administration for announcing the delegation and changes thereto. Once the CNAME has aged out from resolver caches, there is no trace left of obsolete data in the 'golden tree'. If the T2 provider which the customer has just deserted delays (or neglects) removing the relevant RRsets, so what ? With NS, on the other hand, you have to make sure that all the obsolete data on still authoritative servers is eliminated. > This might also get you into trouble with the > competition authorities because the people using these CNAME'd numbers > are locked in to your way of doing things. Are you saying that the opportunity for restrictive practices is significantly different according to which method you choose for implementing delegation ? I really don't see this. > For something like a DDI > block for an organisation, this shouldn't be an issue. But if it was > for all numbers in the Dublin area code (say), there would be a > problem. How is this different between the NS and CNAME implementations ? > Registrants won't have the freedom to choose and switch DNS > providers. Or decouple DNS hosting from the ISP/registrar they use to > get their ENUM delegation. See above. Best regards, Niall O'Reilly UCD Computing Services

1 0

Re: [dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 15 Jul '04

15 Jul '04

Jim, Thanks for the comprehensive comments. I'ld like to reply to one chunk at a time. [dns-wg-ers, sorry for the cross-posting; I'ld use enum-wg if it were populated.] On 15 Jul 2004, at 11:07, Jim Reid wrote: > So what? Is disk space and RAM expensive? No. T1 zone-file size is indeed no big deal, mentioned for completeness only. > The T1 registry is going to > be storing so much data about its registrations -- tech & admin > contact details, billing info, authentication/validation tokens, whois > tags, registrar data, etc, etc -- that shaving off a couple of > resource records would be lost in the noise. Only if your (unstated) assumptions about the role of the T1 Registry match the particular instance. My concept of the T1 Registry is much lighter, with delegation only at T1, payload (NAPTR of course, possibly others) at T2, and validation with the registRARs. This distributes customer-related overhead to the front-office, where it can be related directly to each registrar's business. > For the T1, adding CNAMEs > instead of conventional delegations might well be an unwanted > complication: ie it requires changes and on-going support to the > registry database and back-end scripts and tools. IIUC some registry > systems only handle the RRs needed for conventional delegation: NS > records and related glue. IMHO such registry systems are not suited to the ENUM business, and a T1 which takes this approach is unlikely to be winning many tenders for national infrastructure. Of course, that depends on the clue-level available to the local awarding agency. I'm happy to say that, here in +353-land, our trial T1 is taking a more helpful approach. Best regards, Niall O'Reilly UCD Computing Services

1 0

Tier-2 provisioning: NS vs CNAME/DNAME
by Niall O'Reilly 07 Jul '04

07 Jul '04

Hello ENUMmers, I'm about to become responsible for a Tier-2 ENUM registry, part of the Irish ENUM Trial. I expect to use BIND as the name server platform for this purpose. I have supposed (perhaps naïvely) that the conventional delegation mechanism, using NS records in the parent zone, would be appropriate. This involves creating a new zone as each new telephone number is registered, and configuring the zone specifically on each of Tier-2 name servers. I'm not sure I really want to buy in to this level of per-number provisioning activity, and see apparently significant advantages in using the technique of RFC2317 (Classless IN-ADDR.ARPA delegation) to make life simpler. The advantages I see are the following. The Tier-1 zone file becomes smaller, with just one CNAME (or DNAME) record per delegation, rather than two or more NS records. At Tier 2, the named configuration file needs only per-server, rather than per-number- per-server provisioning activity, and propagation of newly-registered numbers is driven by NOTIFY rather than by reloading the updated configuration file on each server. This looks like the way to go, but perhaps I'm missing something ? Best regards, Niall O'Reilly UCD Computing Services

1 0