> > 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: [EMAIL PROTECTED]
_______________________________________________
Ietf mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ietf
