Enhanced DNS (was Re: More RedHat ickyness)

[richb at pioneer.ci.net (Rich Braun)]

> Will any BIND experts please step forward to offer a comment on the
> newer named.conf configuration file.

The main advantage of the v8 config file is security--you can specify
rules which restrict access to the name server, and you can have
different settings for each domain served.

As an example, I have the following access list set up:

  acl can_xfer { 204.96.46.12; 198.145.88.1; 207.31.252.2; };

Then I can apply it to a domain thus:

  zone "213.221.208.in-addr.arpa" {
        type master;
        file "db.208.221.213";
        allow-query { can_query; };
        allow-transfer { can_xfer; };
  };

Anyone trying to do a zone transfer from a machine other than the
secondary servers specifically listed will be denied.  If you have a
server intended for internal or personal use only, you can also
define the "can_query" list mentioned above to prevent outsiders from
listing your server as their resolver.

The zone file format hasn't changed, to my knowledge.  And alas there
isn't a snazzy interface for providing secure access for users to
update DNS records remotely, something I've always thought should have
been part of the spec.  It's still a flat text file rather than a
real database with encryption keys associated with each record.  I've
heard about commercial implementations which purport to make an ISP's
life easier, but they're always expensive and not widely enough adopted
to attract the amount of development effort needed to built a decent
implementation.

A decent implementation would:

- Allow the server administrator to delegate read, modify, create, delete
  authority separately on a per-record basis.
- Authenticate query, zone transfer, and/or modify access based not only
  on source IP address but also public-key encryption.
- Automatically keep the PTR and A records in sync.
- Have support for security zones which serve records differently depending
  on the authorization level of a particular query (this is a bit hard to
  explain--basically, right now if you want to define a set of 'internal'
  names and address translations behind a firewall and a set of 'external'
  names published to the outside world, you need to set up two separate
  DNS servers.  And most companies do--small ones do this by having their
  ISP serve their domain for the outside world, and I'll bet a lot of
  the readership of this mailing list has an 'internal' DNS server which
  lists more names than their ISP serves for their domain.)
- Provide tools to define blocks of similarly-formatted names (let's say
  you've got a /21 group of networks and therefore need to create valid,
  unique inaddr lookups for 2048 addresses--right now you have to cobble
  together a perl script or emacs macro to create the zone files,
  separately for forward and inverse lookups.)
- Provide support for ssh-style encrypted tunnels on zone transfers to
  secondaries.
- Run as a non-privileged user, *not* as user ID 'root'.
- Have a whole lot more fault-tolerant features to prevent crashes or
  slowdowns caused by memory consumption or other resource problems.
- Provide support for IP6 migration, whatever that implies.
- Have a way to 'push' updates to secondaries on a per-record basis, so
  mobile or dynamic-addressed systems can have DNS entries.  (Microsoft's
  WINS implementation does this--who knows how efficient WINS is.)
- Have support for caching-only secondaries, which can run faster without
  the need to write updates to nonvolatile storage.

And so forth.  Even the latest BIND is still primitive relative to what's
ultimately needed.  I'm sure there are a whole list of issues faced by
the admins of root (.COM et al) name servers which I haven't even considered.

Gee I could start a company which does this implementation work.  But
the problem thus far is that not enough paying customers exist for
enhanced software like this (you can't turn much of a profit selling to
just the 30 top deep-pockets ISPs); there's a general expectation that this
kind of ISP-ish software should be free.  What I've seen is that
freeware hackers usually devote 1 to 6 months of time to a project,
and the problem with enhanced DNS is that it's a lot more work than
that.  Maybe this work could be divided up in chunks small enough to
be developed within the freeware community, the way Linux itself has
been.

-rich
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).