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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 

> -----Original Message-----
> From: Ted Lemon [mailto:Ted.Lemon@xxxxxxxxxxx] 
> Sent: Thursday, December 01, 2005 3:58 PM
> To: Hallam-Baker, Phillip
> Cc: Sam Hartman; namedroppers@xxxxxxxxxxxx; Bernie Volz 
> (volz); ietf@xxxxxxxx; iesg@xxxxxxxx; dhcwg@xxxxxxxx; 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.

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.

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.


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

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

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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]