[dns-wg] Fwd: [enum-wg] Tier-2 provisioning: NS vs CNAME/DNAME

>>>>> "Niall" == Niall O'Reilly <Niall.oReilly at ucd.ie> writes:

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

Actually I think it will make life harder. 2317-style delegation is
trickier to set up and maintain than conventional delegation.

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

So what? Is disk space and RAM expensive? 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. 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.

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

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

Using some sort of CNAME/DNAME trickery may limit your options for the
future. ie It imposes a certain way of working or mindset that seems
reasonable today. But it may not be the case in a year or so. And then
all sorts of silliness happens as the original CNAME/DNAME model gets
perverted to support the then prevailing orthodoxy. How often have we
met bizarre DNS setups that have been inherited from an earlier DNS
administrator who kludged a configuration and then kept tweaking it
instead of doing the job properly?

    >> This looks like the way to go, but perhaps I'm missing
    >> something ?

Using CNAME trickery for ENUM is unwise. It opens the door to all
sorts of evils, like the accommodation of alternate trees. 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. DNAME is even worse because there are plenty of name
servers and resolvers out there that don't understand this RR. 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. 

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.