Re: ETSI on Minimum Requirements for European ENUM Trials

[Jim Reid <]

>>>>> "Richard" == Stastny Richard <Richard.Stastny@localhost writes:

    Richard>    It has to be discussed if WHOIS (or a comparable
    Richard> protocol/ information query method) is needed in
    Richard> production, but i consider it to be useful during trials.

I'm not convinced whois is relevant, desirable or necessary for ENUM
at all.

    Richard>    "Technical and administrative ... " - No one will tell
    Richard> you the OS version and configuration details of his name
    Richard> server. I consider it useful to have contact information,
    Richard> but requiring anything beyond that will scare DNS
    Richard> providers off.

If it does, it will scare off the incompetent ones who have good
reason for concealing the fact they're using buggy software or
whatever. For any serious DNS service for infrastructure zones, it is
*critical* there are no single points of failure. That means having
name servers running different DNS software on different hardware and
operating systems. They only way of ensuring that is to find out from
the DNS providers what platform(s) they are offering.

    Richard> - 12.: "Name servers should support authentication of DNS
    Richard> queries.."  Whilst this is of course a desireable
    Richard> capability, it's way off the current state of the art of
    Richard> production DNS. It adds another chance of failure to the
    Richard> trials (imho).

What is the rationale for this claim? Authentication of DNS lookups
*HAS* to be an essential part of any serious trial. Unless this is
done, there is no way of verifying ENUM lookups. You can't tell if the
answer came from the real name servers or not or if the data a name
server sent was what the client received. DNSSEC solves this
problem. And introduces others of course. It is unrealistic to expect
people to use ENUM for telephony-like services if they cannot rely on
the integrity of the DNS data that underpins those services. What if a
bad guy spoofs the DNS to direct customers to a premium-rate phone
line? That would be catastrophic for ENUM. And the trials.

ENUM trials present the perfect opportunity to look at the issues
surrounding the deployment of DNSSEC. [Nobody has done this, so any
claims DNSSEC is "way off the current state" are not based on hard
facts or real-world experience. The truth is nobody knows either way
because DNSSEC hasn't been deployed beyond trivial proof-of-concept
setups.] The reality is DNSSEC exists and works. It can verify answers
from the DNS are the truth, the whole truth and nothing but the
truth. Deployment is another story because the problems of key
management, signing policies, key lengths, signature expire times, key
rollover and so on are not understood for non-trivial zones in a
production setting. And of course these problems won't get tackled
because nobody wants to experiment with significant production data,
like a TLD zone for example.

ENUM trials present the perfect way to look at this stuff without
breaking production services. This will tell us if DNSSEC is actually
deployable or not. That is a valuable learning exercise in its own
right. And if DNSSEC can be deployed, the experience from a trial will
give incredibly valuable insight into how to handle things like key
management and so on. Oh, and using DNSSEC would not affect ENUM users
or applications that don't bother to check the signatures: they won't
even see the crypto gunk if they follow RFC3225 (as they should).

BTW, development of the DS record has generally been accepted by the
IETF DNS & security experts as making DNSSEC much easier to deploy. So
this technology is a lot closer to prime time than some people seem to
think. It will be better to test DNSSEC deployment in a trial setting
than try to figure out how to deploy it for a production ENUM service
in N month's time that will *have* to use it.

    Richard>    "Bind version 9.1 _should_": DON'T require specific
    Richard> software versions. Bind 9 is much slower than Bind 8 and
    Richard> (imho) overfeatured for production use. For that reason,
    Richard> Bind 8 is still the most widely used Name server.

This is misleading or incorrect. First of all BIND9 is fast enough for
just about everybody. It's not yet fast enough for a root server that
gets 5-10k queries a second (sustained) unless it runs on really fast
hardware. But no other name servers ever get near that level of
traffic, except for things like DoS attacks which BIND8 wouldn't be
any better at surviving than BIND9.

Secondly, BIND9 is not "overfeatured", at least not in comparison with
BIND8. It has just about as many features as BIND8 has. [Some BIND8
features did not make it into BIND9.] All things being equal, the new
features should only incur a noticable performance hit if they are
switched on: complex view setups for instance. Whether these features
are needed for ENUM trials is debatable. There are a number of things
that BIND9 gets right, unlike BIND8. BIND9 follows the protocol
specs. much more rigourously than BIND8. It implements incremental
zone transfers properly. And provides the correct semantics at zone
cuts. BIND9 is threaded so it can load zones and answer queries at the
same time. BIND8 can't. I wouldn't call these things "overfeatured".

The main reason BIND9 is not widely used is that few UNIX vendors ship
it with their OS yet. This is hardly surprising given the lead times
vendors have for distributing their system software. IIRC one major
vendor has just got around to stop shipping BIND4 with their OS! The
next reason people don't use BIND9 is it's much stricter at demanding
syntatically correct zone files. So rather than fix their broken zone
files, many DNS administrators stick with older code that tolerates
and encouarges those errors.

    Richard>    What were the reasons to require Bind 9.1?

    Richard>    Stastny: The reason for 9.1 was mainly DNAME.

BIND9 also has a working IXFR. This will be very useful when
propagating small changes for huge zones to their slave servers.