I am somewhat surprised that there has been no discussion of this draft
here. Maybe it is just because of so many vacations in August, but
maybe it is because the implications are not clear.
The idea is that the Internet-standard way to get a host's location, in
order to, for example, include it in an emergency call, depends on
finding the location server for an IP address. This document includes
a method to discover the relevant location server. If this method
becomes a standards-track RFC, you might find legislation requiring its
implementation as a matter of public safety.
Note that method (a) implicitly involves reliance on IN-ADDR.ARPA,
which has been discussed at some length in DNSOP, in which the most
recent (expired) draft-ietf-dnsop-inaddr-required-07.txt says this:
4.2 Application Recommendations
Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
of IN-ADDR, sometimes in conjunction with a lookup of the name
resulting from the PTR record provides no real security, can lead to
erroneous results and generally just increases load on DNS servers.
Further, in cases where address block holders fail to properly
configure IN-ADDR, users of those blocks are penalized.
The alternative method (b) involves NAPTER records throughout the
inverse-address tree, possibly except where there are PTR records
pointing to names that have NAPTER records through which the Location
Server is discovered.
Is this a good idea?
On Aug 11, 2006, at 10:54 PM, Henning Schulzrinne wrote:
Re: [Geopriv] questions/comments regarding
draft-schulzrinne-geopriv-relo
On Aug 11, 2006, at 4:47 PM, Andrew Newton wrote:
... I assume that the following mechanisms are being described:
a - if the hostname of the machine sending the query is
bubba.example.net, then issue a NAPTR query (S-NAPTR/U-NAPTR) at
bubba.exmaple.net. How you managed to get your host named
bubba.example.net is really not important.
b - if your IP address is 192.168.1.2, then send a NAPTR query
(again S-NAPTR/U-NAPTR) to 2.1.168.192.in-addr.arpa.
Is there any thought to which I do first? And what about things like
mDNS?
For the reason you imply in (b), namely NATs, I think doing (a) first
is probably better, although I suspect it doesn't matter much. I can
come up with scenarios for either case. (In the enterprise case, I
suspect (a) is easier. For residential DSL, PPP configuration doesn't
seem to include host names, so only (b) is an option.)
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
