> > > 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 200 > 3. It is not suprising therefore that Windows 2003 server is not compliant wi > th 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 suppo > rt saving unknown RR blobs. It does however *transmit* and *cache* them. If you want to *publish* new RRs then you need to upgrade your dns server to ones capable of publishing them. Note it is possible to upgrade the DNS servers and *still* have active directory support. > Someone in the DNSEXT working group did a test that showed that if you violat > e 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. No they wouldn't. They would replace the offending component with one that does the job required. A compentent system administator would use all the tools available to them. > The reason that this keeps coming up is that empirical observation trumps wis > hful thinking. The fact is that BIND is not the only DNS server in the univer > se as some might like to imagine. I never said it was. There are multiple nameservers that run under Windows that are capable of do the job. There are even more that run under other OS's that can be intergrated into the solution. The fact that you seem to want to restrict the solution space to only Microsoft Windows servers on a Windows box is what has clouded your judgement. > FACTS are not FUD. In this case the facts are in the code. > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www1.ietf.org/mailman/listinfo/ietf > -- 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