> > 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 > server? 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: Mark_Andrews@xxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf