ietf-mxcomp
[Top] [All Lists]

RR-type considerations

2004-04-16 15:37:46

On Sat, Apr 17, 2004 at 12:11:35AM +0200, Markus Stumpf wrote:
| 
| If we want to define a new RR type we should do it /now/!
| Starting with a TXT record and later switching to a MARID RR record
| is a kludge that will (i.e. the TXT record) live for the next 50 years
| and all software engineers and DNS maintainers will curse us, because
| they will still have to care about a TXT record that is obsolete for 49
| years.

I agree that a dedicated record type would be ideal.

However, we should aim to minimize the cost of the protocol.

People are lazy, or at least busy: doing it right may just be too much
work.  I don't want this to be the straw that breaks the camel's back.

Right now the wizard says "ok, now paste this line into your zone file".
People are quite happy to do that and move on.

If the wizard says "ok, paste this line into your zone file, but first
you have to upgrade your DNS server" that's an order of magnitude more
work.  I guess it's actually more like a log that breaks the camel's
back.

If we're going to put effort into RRtype issues, I would rather see the
next generation of DNS software accept numeric RRtypes in zone files
directly.  Right now (correct me if I'm wrong) symbolic->numeric
mappings are hardcoded deep in the guts of the nameserver software.

Numeric types would make DNS a little more extensible.  Today, DNS
RRtypes are, ironically, stuck in an "/etc/hosts" era.  If nameserver
software accepted numeric DNS types we could at least move to an
"/etc/services" model.

The implementation/deployment burden is about the same, and you get more
modularity.  The next time we need to add a new record type, the work
will already have been done.

IANA could run the type codes registry, etc.