From: Mark_Andrews(_at_)isc(_dot_)org
[mailto:Mark_Andrews(_at_)isc(_dot_)org]
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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf