> > No. It just means that the people spreading FUD have succeeded.
> > RFC 3597 (2003) formalised the handling of unknown RR types
> > and classes. The first draft was written in 2000 and it
> > described treating unknown RR's as opaque data blobs.
> > RFC 2535 (1999) (DNSSEC) depended upon unknown RR types being
> > being treated as opaque blobs. While it didn't explictly ban
> > the use of compression pointers in new types it was known not
> > to use compression in new RR types.
> > RFC 1035 even attempted to get unknown RR's treated as
> > opaque data blobs. Unfortunately the description of where
> > compression could be used was flawed.
> maybe I've missed it, but is there a standard way of extending the text
> format of zone files to recognize new RRs without recompiling the
Yes. See RFC 3597.
See also RFC 4701 which shows the DHCID RR in both the
generic format and the type specific format.
> and is there a standard way to distribute machine-readable
> definitions of new RR types?
No. Then again we keep coming up with new methods of
encoding data. Early adoptors of new RR's just need to be
able to handle a binary blob of data. Most (all) dns
libraries have methods to extact domain names, etc. from
the binary blobs.
> (of course there are lots of other reasons to look for a replacement for
> DNS even if the new RR type problem is solved, but that doesn't mean the
> new RR type problem shouldn't be solved)
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
Ietf mailing list