From: Sam Hartman [mailto:hartmans-ietf(_at_)mit(_dot_)edu]
"Ted" == Ted Lemon <Ted(_dot_)Lemon(_at_)nominum(_dot_)com> 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
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf