> From: Sam Hartman [mailto:hartmans-ietf@xxxxxxx] > >>>>> "Ted" == Ted Lemon <Ted.Lemon@xxxxxxxxxxx> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf