Subject: RE: SRV records considered dubious (was: Re: DNS Choices: Was: [ietf-dkim] Re: Last Call: 'DomainKeys)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 22 Nov 2006 06:27:29 -0800

> From: [email-masked] [mailto:[email-masked]] 

> 	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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "william(at)elan.net" <[email-masked]>
Date: Wed, 22 Nov 2006 07:21:44 -0800 (PST)

On Wed, 22 Nov 2006, Hallam-Baker, Phillip wrote:

> 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.

First of competent sysadmin would not run his dns server on windows
(I'll be flamed hard for that statement...) and second if MS really
wanted to they could release code to support new records in binary
(or even specific ones) as part of their servicepack cycle (they in
fact do protocol support updates for their other products if its
something missing and necessary) and whoever needs to host this RR
on their system with MS DNS server would get this update.

Since you were at MARID you should remember that issue that thought
to be more serious was not MS DNS server but MS Proxy server which
is apparently very proprietary and only works with MS clients and 
communicates with them by converting DNS into RPC calls (or something
of the sort - whoever knows more about this weird thingy can correct
me). Unlike DNS the support the update of this would require changes
in both client and server that are deeper and this proxy server also
seems a lot more in use then actual dns server for hosting internet
domains. Info on updates to this piece of software to support unknown
DNS RR types would be most welcome.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Ofer Inbar <[email-masked]>
Date: Wed, 22 Nov 2006 10:47:35 -0500

> > 	No.  It just means that the people spreading FUD have succeeded.
[ ... ]
> 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. 

This thread started with the assertion that DNS is a failure and needs
to be replaced with a new, better protocol; adding new RRs was part of
the evidence.

Mark Andrews said that the new RR problem is not valid evidence,
because it has been solved.

Phillip says no, it hasn't been.

But in the original context, Phillip is supporting Mark's point.
If the reason the new RR problem hasn't been solved is that the
solution is so recent (3 years old) that Microsoft hasn't implemented
it yet, obviously this doesn't constitute evidence that we need to
solve the problem again by developing a new protocol.

  -- Cos (Ofer Inbar)  --  [email-masked]
   "OSI is a beautiful dream, and TCP/IP is living it!"
     -- Einar Stefferud <[email-masked]>, IETF mailing list, 12 May 1992

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Nov 2006 09:08:13 +1100

> 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.
> 

	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.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]