> From: Mark_Andrews@xxxxxxx [mailto:Mark_Andrews@xxxxxxx] > 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. > > I really don't know why we are arguing about this anymore. > Adding new RR's has not been a real issue this millenia. Because during MARID we looked at the actual tests and discovered that there was a real problem. The last server edition of Windows is Windows 2003. The RFC was published 2003. It is not suprising therefore that Windows 2003 server is not compliant with RFC 3597. Microsoft's development cycles for its server products are long and features have to be proposed several years in advance. Microsoft showed the source code to the MARID group. It simply does not support saving unknown RR blobs. Someone in the DNSEXT working group did a test that showed that if you violate the administration model of Windows it is possible to emit the correct bit strings for new RRs. But that is not a method that any competent system admin would accept in a production service. The reason that this keeps coming up is that empirical observation trumps wishful thinking. The fact is that BIND is not the only DNS server in the universe as some might like to imagine. FACTS are not FUD. In this case the facts are in the code. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf