Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]

From: Mark Andrews <[email-masked]>
Date: Fri, 02 Dec 2005 10:23:28 +1100

>  
> 
> > -----Original Message-----
> > From: Ted Lemon [mailto:[email-masked]] 
> > Sent: Thursday, December 01, 2005 3:58 PM
> > To: Hallam-Baker, Phillip
> > Cc: Sam Hartman; [email-masked]; Bernie Volz 
> > (volz); [email-masked]; [email-masked]; [email-masked]; Steven 
> > M. Bellovin; Pekka Savola
> > Subject: Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last 
> > Call:'Resolution ofFQDN Conflicts among DHCP Clients' to 
> > ProposedStandard]
> > 
> > On Thursday 01 December 2005 12:31, Hallam-Baker, Phillip wrote:
> > > My criteria here are that the DNS should support an extension 
> > > mechanism that allows the definition of new records at will without 
> > > the need to deploy ANY new code at either the client or the server.
> > 
> > Right, we have that.   It's called the RRtype.   Many, many 
> > type codes are 
> 
> NO YOU DO NOT
> 
> The majority of the deployed DNS infrastructure does not have the
> ability to service new RRs.

	Actually the majority of DNS servers are capable of handling
	unknown RRs as are the majority of client resolver libraries.

	If you ignore Windows this is almost 100% of client resolver
	libraries are capable of handling unkown RRs.  The applications
	generally decode them.
 
> The opposite claim has been advanced on several occasions but it is
> untrue. There is NO version of the Windows DNS server capable of
> PRODUCTION publication of new DNS RRs. A registry hack that does not
> survive a reboot does not count. Microsoft has shown the actual DNS code
> for saving a zone file, new RRs are simply not handled.

	The world is not Windows.  Not deploying a new RR type
	because Windows patentently got it wrong is STUPID.

> Its not just the dns servers, it's the firewalls and a whole
> intermediate layer of RPC services that are used to implement DNS calls
> in a large number of real environments.

	Firewalls that block unknown RRs are "broken by design".
	If you choose to deploy such a broken firewall you get what
	you deserve.

	As for client libraries that don't support unknown types.
	They to are "broken by design".  Anyone who has dealt with
	the DNS should be aware that new RRs are being deployed
	pretty regularly.  Failure to allow retrieval of the raw
	records was stupid.

> > available.  Requiring the use of additional labels and not 
> > taking advantage of the very nice DNS update prerequisite 
> > support because someone doesn't want 
> > to support transparent addition of RRtypes is pathetic.  
> 
> The DNSEXT group has yet to explain how a production quality DNS server
> can add support for a new RR without the need for new code. The ability
> to add in blobs of raw hex data does not cut it. 

	Well for this particular application I don't expect humans to
	ever enter the RR's by hand.  All additions and removals are
	expected to be done via UPDATE.

	If it wasn't that it is prettier to display the records in
	master file format there really is no need to add any code
	to nameservers for this record.

	As for the general case.  The hex encoding is a stopgap
	measure until you can upgrade / teach the nameserver to
	know about the type.

	You complaint also makes a assumption that the IETF should
	be involed in defining how implemtations add support for
	new RRs.  In my opinion this should be left to the
	implementation.

	BIND 9 is designed to make adding a new RR easy.  There have
	been plenty of examples where this has been done to test out
	new RRs.

> > We've had the 
> > capacity to extend option codes in every DHCP server (as well as most
> > clients) in existence practically since day one, and that's a 
> > much more complicated problem than handling new RRtypes.
> 
> DHCP should stick to reporting the IP address. The idea that
> configuration services should be configured at the network connection
> level is ridiculous. The fact I am on an ethernet segment does not mean
> that I trust it or want anything to do with it. If I am on public WiFi
> the idea is nonsense on stilts.
 
	This is all "horses for courses".

> I would like to discontinue the practice of assigning the domain name
> prefix and the DNS servers from DHCP by default. The domain name prefix
> should be defined during the MACHINE network configuration alone. The
> use of DHCP discovered DNS servers is a major security hazzard. All DNS
> transactions should be TSIG signed.
>
> I will accept the use of DHCP to assist initial machine configuration
> and local network configuration. Use of an unauthenticated broadcast
> protocol for application configuration is nonsense.
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 1 Dec 2005 13:54:31 -0800

[ Moderators note: Post was moderated, either because it was posted by
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subscribers. 
   Please fix your subscription addresses. ]

NO YOU DO NOT