Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
-Original Message- From: Ted Lemon [mailto:[EMAIL PROTECTED] Sent: Thursday, December 01, 2005 3:58 PM To: Hallam-Baker, Phillip Cc: Sam Hartman; namedroppers@ops.ietf.org; Bernie Volz (volz); ietf@ietf.org; iesg@ietf.org; dhcwg@ietf.org; 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 Ietf@ietf.org 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 PROTECTED
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 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. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
On Wed, Nov 30, 2005 at 03:51:13AM -0500, Sam Hartman wrote: Phil is suggesting something like _dhcid.domain . Except the difference between NXDOMAIN and NXRRSET is important for the DHCID. -- David W. HankinsIf you don't do it right the first time, Software Engineer you'll just have to do it again. Internet Systems Consortium, Inc. -- Jack T. Hankins ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
From: Sam Hartman [mailto:[EMAIL PROTECTED]
Ted == Ted Lemon [EMAIL PROTECTED] 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
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
-Original Message- From: Ted Lemon [mailto:[EMAIL PROTECTED] Sent: Thursday, December 01, 2005 3:58 PM To: Hallam-Baker, Phillip Cc: Sam Hartman; namedroppers@ops.ietf.org; Bernie Volz (volz); ietf@ietf.org; iesg@ietf.org; dhcwg@ietf.org; 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 Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
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
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
On Monday 28 November 2005 20:00, Hallam-Baker, Phillip wrote: OK so why are you proposing a new protocol rather than writing a description of the protocols that are already in use? It's inconvenient to use TXT records, because they are not specific to the purpose. If the user wants TXT records on the name for some *other* purpose than marking the name with a DHCID, it doesn't work. We aren't defining a new protocol - just a new RRtype. The DNSEXT working group passed this through last call. The only reason we're not yet using it is that, well, it's been very slow getting the entire package through last call, as witness this current conversation. I appreciate that you like an opportunity to pontificate about DNSSEC, and am duly amused that you saw one here and leapt upon it. However, those of us who have been working on standardizing a method by which DHCP servers may interoperate while maintaining DNS records for DHCP clients, for the past decade, would appreciate it if you would leave off it in this case. This protocol has absolutely nothing to do with DNSSEC, other than that, like DNSSEC, it is related to the DNS. Thanks. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
there is one thing buried in here that's worth answering: Hallam-Baker, Phillip wrote: From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernie Volz (volz) This technique has been in use for years by implementations using TXT records because we've been unable to get the DHCID RR approved. OK so why are you proposing a new protocol rather than writing a description of the protocols that are already in use? Correctly prefixed TXT records work just as well as new RRs and are completely compatible with the deployed infrastructure. If you attempt to cut new DNS RRs you will hit the problem that your proposal is now dependent on deployment of a new infrastructure which has no deployment strategy. what we are trying to do is to produce something that allows interoperability. that's different from documenting existing similar-but-not-quite implementations. there is no compatible at this time - but we would like to get there. -- Mark ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bernie Volz (volz) This technique has been in use for years by implementations using TXT records because we've been unable to get the DHCID RR approved. OK so why are you proposing a new protocol rather than writing a description of the protocols that are already in use? Correctly prefixed TXT records work just as well as new RRs and are completely compatible with the deployed infrastructure. If you attempt to cut new DNS RRs you will hit the problem that your proposal is now dependent on deployment of a new infrastructure which has no deployment strategy. Lets get back to the idea that a standard is a description of running code. The DNS group has become a bottleneck for deployment of a lot of technology. This should not be acceptable. There is a fundamental extensibility flaw in DNS, new RRs must be understood by the sender, receiver and intermediate infrastructure. The DNSEXT group appears to believe that their objectives should be to create as much of an incentive to upgrade to DNSSEC capable infrastructure as possible and that the way to do this is to gate all proposed uses of the DNS on cutting a new RR. This is not a good strategy, DNSSEC is a double ended adoption problem, the problem is not that the promise of DNSSEC is insufficient incentive for deployment, the problem is that early adopter deployment of DNSSEC has negligible incentive. The Pareto optimal solution here is for the IAB to specify a method of introducing new features that use the DNS that is entirely compatible with deployed DNS infrastructure. These in turn create new dependencies on the DNS that create a near term demand for DNSSEC and an early adopter incentive. The DNSSEC people get an early adopter market for their proposal, people looking to extend the DNS can do so without committing error 33. For example one of the discussions in DKIM is on what to do with the ESTG vehicle set up for early development. The idea that most people seem to think is a good one is to turn it into a branding vehicle similar to WiFi. So that just as people advertise that their product is WiFi compatible to mean 'yes it really works' there would be an ESTG brand that a registrar could use to say 'yes I do provide the services necessary to support DKIM signed email'. This then leads naturally to the question of levels of support, a level 1 registrar might do the bare minimum necessary to support DKIM (allow the relevant records to be defined), the requirements for level 2 might well include support for DNSSEC (at least I would argue that they should require DNSSEC support). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [dhcwg] Re: DHCID and the use of MD5 [Re: Last Call:'Resolution ofFQDN Conflicts among DHCP Clients' to ProposedStandard]
This technique has been in use for years by implementations using TXT records because we've been unable to get the DHCID RR approved. OK so why are you proposing a new protocol rather than writing a description of the protocols that are already in use? Correctly prefixed TXT records work just as well as new RRs and are completely compatible with the deployed infrastructure. If you attempt to cut new DNS RRs you will hit the problem that your proposal is now dependent on deployment of a new infrastructure which has no deployment strategy. Not this old chestnut again. Lets get back to the idea that a standard is a description of running code. The DNS group has become a bottleneck for deployment of a lot of technology. This should not be acceptable. There is a fundamental extensibility flaw in DNS, new RRs must be understood by the sender, receiver and intermediate infrastructure. Incorrect. Only the DHCP elements need to understand this. For everything else it should be treated as a opaque blob. The intent of RFC 1034/1035 was for new RRs to be treated as opaque blobs. You don't need RDLEN if you don't expect to treat unknown as opaque blobs. This was clear to me when I first read those RFC's back in the early 90's. RFC2535 (March 1999) made it absolutely clear that unknown RR's were to be treated as opaque blobs. It is now 6 years later and you are saying we should be worrying about implementations that were clearly broken on the first day they deployed. The DNSEXT group appears to believe that their objectives should be to create as much of an incentive to upgrade to DNSSEC capable infrastructure as possible and that the way to do this is to gate all proposed uses of the DNS on cutting a new RR. Hogwash. This is not a good strategy, DNSSEC is a double ended adoption problem, the problem is not that the promise of DNSSEC is insufficient incentive for deployment, the problem is that early adopter deployment of DNSSEC has negligible incentive. This has absolutely nothing to do with the deployment of DNSSEC. The Pareto optimal solution here is for the IAB to specify a method of introducing new features that use the DNS that is entirely compatible with deployed DNS infrastructure. These in turn create new dependencies on the DNS that create a near term demand for DNSSEC and an early adopter incentive. The DNSSEC people get an early adopter market for their proposal, people looking to extend the DNS can do so without committing error 33. For example one of the discussions in DKIM is on what to do with the ESTG vehicle set up for early development. The idea that most people seem to think is a good one is to turn it into a branding vehicle similar to WiFi. So that just as people advertise that their product is WiFi compatible to mean 'yes it really works' there would be an ESTG brand that a registrar could use to say 'yes I do provide the services necessary to support DKIM signed email'. This then leads naturally to the question of levels of support, a level 1 registrar might do the bare minimum necessary to support DKIM (allow the relevant records to be defined), the requirements for level 2 might well include support for DNSSEC (at least I would argue that they should require DNSSEC support). ___ Ietf mailing list Ietf@ietf.org 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 PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
