Re: [DNSOP] type numbers, was Brief addition to terminology-bis draft

[Mark Andrews <[e-mail]>]

> On 11 Sep 2018, at 8:51 am, John R Levine <[e-mail]> wrote:
> 
> On Tue, 11 Sep 2018, Mark Andrews wrote:
>>> Since the type code is a 16-bit field, if we allocate a new type every
>>> week, it'll take over a thousand years to run out.  I think this is one we
>>> can safely ignore.
>> 
>> If we end up with a type per protocol because people want wildcards to work
>> we will burn through types much faster.  We don’t know exactly what the future
>> will bring.
> 
> Uh, what?  In the past 30 years we've assigned under 100 rrtypes.  If that rate increases by an order of magnitude, we still have a thousand years of them.  Sure we don't know exactly what the future will bring, but we can make some reasonable guesses.

We have assigned 100 types with the myth that it is hard to deploy a new type slowing
down the rate of assignment.

>> I do know that saying that classes can’t work is self defeating and will take a lot, lot, lot more of work to undo than just continuing to support multiple classes.
> 
> Classes were a mistake.  We should deprecate every class except IN, perhaps keeping the one special case for CH server.bind.  That doesn't require changing any of the bits on the wire.

And keeping classes working doesn’t changing any bits on the wire.  Using a second
class is almost all administrative.  The resolver libraries I’ve been using for last
30 years have supported lookups in different classes.  The recursive servers we have
been delivering support multiple classes.  Now the one thing that needs to be done
with a new class is to define what a A record means in that class.

QUERY supports multiple classes.
UPDATE supports multiple classes.
DNSSEC supports multiple classes.
NOTIFY supports multiple classes.

There are no reasons to kill multiple class support.  

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]