On Wed, 21 Feb 2001, Paul Francis wrote:
> > b) I don't think any registrar will tell you, "No, people should stop
> > registering domains because the DNS infrastructure won't handle it." :-)
>
> yeah, I know the registrars are happy to take your money. I was thinking of
> the actual core machines.
Oh, right. Those. But I still think it's negligible considering how much
other stuff gets registered for immeasurably little benefit.
> > Kind of. This is along the same lines as domain search paths. If I type
> > "http://www" into my browser, the DNS resolver will return the address for
> > www.litech.org even though I clearly did not type "litech.org" in the
> > address. It might even return the address for www.litech.internal, even
> > if what I expected was www.litech.org.
>
> Heh, I didn't know about this. I just tried it (from home), and sure enough
> got the home page of my ISP! So what happened? Did my browser "complete"
> the URL for me, or did DNS do it?
[...]
> I would guess the former, but nothing will surprise me these days...are DNS
> clients "intelligently" expanding DNS queries for us now?
This is a resolver feature, and AFAIK they've supported this from the
beginning. It's the "domain search path". Check the manpage for
resolver(5). Essentially, if there are fewer than two dots in any name
you're trying to resolve, the resolver will attempt to append every domain
in your search path and resolve the result before trying to resolve the
name alone as a FQDN.
I'm not sure if this behavior is specified in an RFC or not, but every IP
stack/resolver I've encountered has this feature. The search path is a
parameter that can be passed via DHCP, or configured locally in
/etc/resolv.conf in Un*x or in the network control panel in Windows.
> From what I know so far, I believe it may be possible for a site to use
> GULRs today without any changes to any existing implementations, as long as
> they use two-faced DNS. The ability to do this is very attractive for
> obvious reasons. It is probably mainly for that reason that I'm disinclined
> towards the part of your idea that requires change to the DNS client.
Yes, with two-faced DNS you could use GULRs right now. But two-faced DNS
is inconvenient for certain situations like mobile IP and multisite nodes.
Which DNS server would a multisite node query? If it needed to get GULR
addresses for both sites, it would need to have more complicated changes
to its DNS resolver than my proposal would require. Or it would have to
run a full DNS server locally.
In fact, you could implement my proposal today without two-faced DNS by
simply setting the threshhold for search-path lookups higher than 2 dots,
and inserting the unique prefix domain as the first entry in the search
path. Of course, you'd have to configure this on every host at your site.
The advantage to modifying the resolvers is to hard-code (literally) the
format for the unique-local domains. Maybe folks in Australia start using
x0012345678-site-ipv6.net.au instead of the official suffix. Maybe Big
Rich Company(R) accidentally registers and uses x0012345678-site-ip6.net
(misspelled), then a few years down the road tries to take the domain
x0012345678-site-ipv6.net away from the real registered owner. Or worse,
tries to merge sites with them. It is conflicts like these that we are
trying to avoid, and we can enforce the use of the correct format now if
we provide an immediate incentive for getting it right the first time.
> The part of your scheme that uses site-ipv6.net simply for the purpose of
> helping guarantee uniqueness, however, is very nice. I don't think everyone
> would want to use it (rather they would just be lazy and flip the coins but
> not register), but those that do would at least have some legitimate legal
> claim to the number, should the issue arrise in the future.
[They'd have to flip 38 coins then, eh? :-) ]
That was the original motivation behind using domains in the first place.
But the more incentive we can find for sites to register, the more likely
it will be to work. Modifying resolvers to allow hosts to auto-configure
themselves for site-local resolution is a nice incentive, and having
actual data in the domains also ensures that the contact and NS
information for the domains will remain up-to-date in the whois database.
> Another attractive part of this aspect of your scheme is that it would put
> pressure on ICANN to create a true registry for the GULR identifiers. The
> pressure would come from people that are outraged at having to pay for a
> domain name that they don't in fact intend to use as a domain name. So at
> some point the site-IPv6.net's would be grandfathered into a "true"
> registry.
While it would be nice to simply have a TLD (kinda like .arpa) or other
dedicated repository for these registrations, we all know how likely it is
that such an entity would be created at this stage. All the other
arguments against a new repository, such as measures to prevent an
individual from grabbing the whole space, are already resolved for an
established system like DNS. Perhaps at some point in the future we will
have enough motivation and operational experience to move to a better
method of registration.
Regarding the difficulty in modifying the resolvers... I think that would
take the addition of maybe 10 lines of code, don't you? -Nathan
--
+-------------------+---------------------+------------------------+
| Nathan Lutchansky | [EMAIL PROTECTED] | Lithium Technologies |
+------------------------------------------------------------------+
| I dread success. To have succeeded is to have finished one's |
| business on earth... I like a state of continual becoming, |
| with a goal in front and not behind. - George Bernard Shaw |
+------------------------------------------------------------------+
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
