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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Hallam-Baker, Phillip

> From: Sam Hartman [mailto:[hidden email]]

> >>>>> "Ted" == Ted Lemon <[hidden email]> 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.

_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

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

Ted Lemon-2
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
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.


_______________________________________________
dhcwg mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/dhcwg
Reply | Threaded
Open this post in threaded view
|

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

Hallam-Baker, Phillip
In reply to this post by Hallam-Baker, Phillip
 

> -----Original Message-----
> From: Ted Lemon [mailto:[hidden email]]
> Sent: Thursday, December 01, 2005 3:58 PM
> To: Hallam-Baker, Phillip
> Cc: Sam Hartman; [hidden email]; Bernie Volz
> (volz); [hidden email]; [hidden email]; [hidden email]; 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 mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

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

Douglas Otis
In reply to this post by Hallam-Baker, Phillip

On Dec 1, 2005, at 11:31 AM, Hallam-Baker, Phillip wrote:

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

This approach would create several challenges.  With respect to  
DNSsec, additional lookups will be required to investigate above the  
set of PTR RRs, in addition to obtaining the PTR RRs.  Even with  
normal DNS, extra sequential DNS lookups amplify the effects of an  
embedded reference.  When a domain is publishing a large DNS wildcard  
record, even when not directly involved in a DDoS, the impact may  
still result in filtering by name at the referencing protocol.  This  
method would be difficult to defend from being abused.

-Doug






_______________________________________________
Ietf mailing list
[hidden email]
https://www1.ietf.org/mailman/listinfo/ietf
Reply | Threaded
Open this post in threaded view
|

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

Mark Andrews
In reply to this post by Hallam-Baker, Phillip

>  
>
> > -----Original Message-----
> > From: Ted Lemon [mailto:[hidden email]]
> > Sent: Thursday, December 01, 2005 3:58 PM
> > To: Hallam-Baker, Phillip
> > Cc: Sam Hartman; [hidden email]; Bernie Volz
> > (volz); [hidden email]; [hidden email]; [hidden email]; 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
> [hidden email]
> https://www1.ietf.org/mailman/listinfo/ietf
>
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [hidden email]

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