Date: Sat, 1 Dec 2001 14:18:11 +0200 (EET)
From: Pekka Savola <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
| Why do you suggest illegal DNS strings? Why not use a dash or a dot?
There is no such thing as an illegal DNS string (unless it is too long).
Only domain names that can't be used in some other protocols, and these
names aren't likely to be wanted for e-mail, or other stuff like that, so
they're just fine with underscores (or control-g's, or even returns...)
| Why wouldn't this be done as with ip6.int or ip6.arpa?
That's a better question, but the draft does say that "local.arpa" is
just a place holder until the actual domain is picked.
More importantly, the CFG RR design is not well done, DNS RR's that hold
lots of different data types, distinguished by something in the data itself
are almost always a very very very poor idea. There is no shortage of
DNS RR types - just assign a new RR type to each particular record that needs
to be stored, and then if you really need to be able to fetch them all at
once, define a meta-query that does that (but that's to be avoided if
possible).
And yes, I note that the draft also says that the CFG RR design is also just
a placeholder...
A more significant comment might be that there doesn't seem to be much
advantage in using the DNS to store this kind of config info over using
DHCP (DHCPv6). If some central admin is going to have to set it all up
anyway, it is not really harder (in fact, it is generally much easier)
to set it up in a dhcp server, than a DNS server. Easier, because DHCP
servers group config info by topology, DNS servers group systems by admin
boundary. Config info much more often is related to topology.
That is, I find it a little hard to believe in a scenario when a local
admin is going to be willing to configure lots of junk in the DNS, but
wouldn't be willing to configure it in DHCP instead. It isn't as though
either DNS or DHCP servers are hard to acquire - just about every reputable
server comes with one of each.
The use of DNS wildcards is also likely to lead to more trouble than you'd
believe, that is a DNS "feature" that has much less applicability than most
people who see it understand. It is very fragile, and not something to
recommend to most people to attempt to use. Here the manageability of the
design seems to depend upon that, which makes it flawed IMO.
There really are just two scenarios to consider.
Either there is some central management of all of this data, in which case
it should be implemented using DHCP, which is designed for exactly this
purpose (but which does not imply that the host needs to acquire its IPv6
address using DHCP, it can use autoconf for that, and DHCP for the rest if
desired), or there is no central management for the data, in which case
there won't be any place out there that the host can query and get back
magic answers - it needs to do it all for itself (using only what is defined
in the RFCs, like well known anycast addresses, multicast lookups, ...)
kre
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
