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

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

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

> >>>>> "Ted" == Ted Lemon <[email-masked]> writes:
> 
>     Ted> On Monday 28 November 2005 20:00, Hallam-Baker, Phillip
>     Ted> wrote:
>     >> OK so why are you proposing a new protocol rather than writing
>     >> a description of the protocols that are already in use?
> 
>     Ted> It's inconvenient to use TXT records, because they are not
>     Ted> specific to the purpose.  If the user wants TXT records on
>     Ted> the name for some *other* purpose than marking the name with
>     Ted> a DHCID, it doesn't work.
> 
> Phil is suggesting something like _dhcid.domain .

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.

Unless wildcards are required the prefix mechanism described in the SRV
rfc allows the existing deployed DNS to be extended without the need for
new code deployment. 

In the cases where wildcards are required for administrative convenience
the semantics of the DNS wildcard mechanism do not meet the use cases
that were described in MARID in any case.

What I suggest is a scheme where we regard the RR type as a means of
defining the syntax of a DNS record and apply a prefix to define the
precise semantics. 

Wildcards are a problem whether or not you cut a new RR. In MARID people
wanted to define an email policy record for "*.example.com" where "*"
has the semantics 'all the nodes in the domain'. The semantics of DNS
wildcards are 'all the undefined nodes in the domain'.

Despite this flaw a DNS admin running a legacy DNS server can if
necessary enter the 'missing' node records by hand. Alternatively the
records could be generated using a perl script that expands an
expression such as "#.example.com" to indicate 'wildcards that behave
the way that you would expect them to'.

There is one problem with this approach, it does not work on prefixed
records. DNS does not support a wildcard of the form
_prefix.*.example.com. This is why specs like DKIM and so on describe
stack walking techniques so that a client can find a record with the
desired scope.

A much better way to solve this problem is to introduce a pointer RR
that obeys the semantics of *.example.com or #.example.com the same as
any other non-prefixed pointer. The resolution process for a prefixed
record then becomes :

1) record = resolve ("_prefix.example.com", {TXT, SRV, ...})
	if record != null return 'found'
2) pointer = resolve (example.com, PTR) 
	if record == null return 'not found'
3) record = resolve ("_prefix." + pointer, {TXT, SRV, ...})
	if record != null return 'found' else return 'not found'

This scheme also provides an additional management advantage, instead of
configuring policy for each machine individually I can define different
policy classes as needed and assign that policy to a particular machine
by specifying the corresponding pointer, eg:

_dkim.servers.example.com     TXT "DKIM policy for servers"
_yaddis.servers.example.com   TXT "Policy for YADDIS"
_dkim.desktop.example.com     TXT "DKIM policy for desktops"

The open question in this scheme is what record to use for the pointer
record. I will accept a situation where we have to do ONE new code
deployment to get the DNS into a state where it can be extended at will
without further code deployments if that is absolutely necessary.

My much prefered solution would be to re-use an existing record. Either
a record that is widely implemented but whose original use has been
deprecated or a record that can be reused without conflict.

A _possible_ candidate for the latter that I have yet to hear a
reasonabe argument against is the PTR record where the use is currently
defined for reverse DNS domains only.

By 'reasoned argument against' I mean 'this will break this existing
deployed code' or 'the XYZ dns server is widely used (>5%) and only
allows PTR records to be defined in the reverse DNS'. I do not accept
'that is not the way we do it' as a reasoned argument.

People are already using prefix records, there is even an unofficial
registry of prefixes. There are also people who spend a lot of time and
effort re-inventing the DNS in order to graft on a very small amount of
policy distribution functionality.

Today people are told to get in line and grovel for an RR assignment.
You then have to grovel to the maintainers of the four or five major DNS
server distributions to implement your record and then wait a few years
for them to take their own sweet time to get around to it. And after all
that is done you have to persuade registrars to provide support.

The minimum time in which that type of change can be achieved in the
Internet as it exists today is a decade. Three years to get your spec to
the point where IANA deigns to give you a RR assignment, another three
years while the DNS implementations get round to adding it onto their
roadmaps, another four or five years for a minimal level of critical
mass to be established.

All it takes to avoid this ten year plus delay is to take a slightly
different view of the DNS architecture, looking at it as a large
DEPLOYED infrastructure and not a collection of specifications.

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Dec 2005 13:57:50 -0700

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

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

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

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

---

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

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

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

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

> the idea is nonsense on stilts.
 
	This is all "horses for courses".

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]