Subject: [dnsext] Compression labels & rrtype partitioning

From: Phil Pennock <[email-masked]>
Date: Fri, 21 Jan 2011 20:12:32 -0500

My understanding is that the biggest problem with introducing new
RRTYPEs that contain names is that existing resolvers won't know to use
compression for the names and so libraries for applications to use do
not expose decent interfaces and it's hard to provide validation and
inspection for data with such new types.  So we get left with people
using existing RRs with special resource names in DNS, co-opting part of
the namespace.

If the standard changes to fix this, then existing resolvers won't
handle it, but if nothing changes then we're stuck with a broken
situation forever and just a lot of unproductive acrimony between those
just wanting to get a product out and those wanting to keep a clean
system.  If we make a change, then it will take a while to percolate
out, but a sufficiently simple change stands a strong chance of being
adopted by the resolvers and as the years go by, it will become easier
for people to do The Right Thing, adding a new rrtype which uses label
compression.

I'll emphasise that this is entirely about rules for new allocations, to
make them easier to support, and absolutely NOT about any kind of
renumbering for existing allocations.

So, flaky proposal 1 for people to consider:

  RRTYPE 0x8000 - 0x8FFF SHALL be used only for records where the RDATA
  consists entirely of a DNS name, with compression semantics.

  Resolvers may evaluate ((rrtype & 0xF000) == 0x8000) and for all
  matching RRTYPEs apply this rule.

  New RRTYPE allocation where the data is a DNS name SHOULD be assigned
  from this range.

Resolvers which do not follow this specification will not be any worse
off than they already are, so no harm done.

As an experiment, this buys 4096 values which have clear semantics and
let us figure out if this is useful.  If more space is needed, the mask
can be adjusted to expand the assignment range and we should know in
plenty of time if this is proving likely to ever be needed.  If the
experiment fails, it's "only" 1/16th of the space wasted.

Then, flaky proposal 2 for consideration:

  RRTYPE 0xC000 - 0xCFFF SHALL only be used for records where a trailing
  portion of the RDATA consists of a DNS name, with compression
  semantics.

  The second octet SHALL encode how many leading octets of the RDATA are
  non-NAME binary data not subject to encoding.

  The third and fourth octets shall provide the option space.

  Thus the 0xC0hh range is equivalent to 0x8hhh in semantics; a new
  record with the same layout as an SRV record would be assigned an
  RRTYPE from the 0xC6hh range, as 6 leading octets of the RDATA would
  be for Priority, Weight and Port, at 2 octets each, with the rest of
  the RDATA payload being subject to compression semantics.

Again, resolvers which don't follow this specification will not be any
worse off than they already are.

This "only" buys us 256 RRTYPEs for each layout, but again at a cost of
only 1/16th of the option space.

Both proposals together use 1/8th of the option space; current
assignments are consuming less than 1/256th of the option space, so this
does not appear to be dangerous.

Is this sufficiently non-crazy that it's worth putting together a draft?

Constructive feedback welcome,
-Phil
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: Mark Andrews <[email-masked]>
Date: Sat, 22 Jan 2011 13:46:03 +1100

In message <[email-masked]>, Phil Pennock writes:
> inspection for data with such new types.

No.  The biggest problem is people not applying for types.  The
nameservers will handle them.  The resolvers will handle them.  The
applications will handle them.

We realised a decade ago that compression of new types doesn't work
without signalling and even if you have signaling you need to do
lossless compression by preserving case.  As a consequence compression
is banned in all new types.  There is a short list of types where
compression is allowed.

We can always add hop-by-hop signalling in the future if we want
to but there really isn't any need to.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]
_______________________________________________
dnsext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dnsext

---

From: John Levine <[email-masked]>
Date: 22 Jan 2011 04:06:57 -0000

>applications will handle them.

Partly that, partly the provisioning systems.  Even if your copy of
BIND is ready to support a new RR type, you still can't do it if your
user friendly web front end doesn't let you create the new records.

When we were setting up DKIM, I was surprised how much trouble people
had adding TXT records with underscores in the names, because cruddy
provisioning systems "knew" you weren't supposed to do that.

R's,
John

---

From: Mark Andrews <[email-masked]>
Date: Sat, 22 Jan 2011 23:34:24 +1100

> user friendly web front end doesn't let you create the new records.

Well complain to the administrators of the front end.  There has
been as standardised representation for unknown records for nearly
a decade now.