Subject: [dnsop] PTR or NAPTR in IN-ADDR to discover Location Servers

From: John Schnizlein <[email-masked]>
Date: Mon, 28 Aug 2006 04:47:11 -0400

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

---

From: Edward Lewis <[email-masked]>
Date: Wed, 30 Aug 2006 17:12:34 +0800

Is this a good idea?

It all depends on who is more knowledgeable - the IP address zone 
administrator or the domain name zone administrator.

Assuming no malicious activity (i.e., unauthorized activity, no 
source address spoofing), in some cases the IP address zone 
administrator will be directly linked to the authority on the 
physical location of the address.  In other cases, it will be the 
domain name zone administrator.

In the more elementary cases, the IP address will be linked to a 
physical location up to the reliability of the network operations to 
keep track of what's allocated where.  In more sophisticated cases, a 
user may be tunneling traffic back to a "home" and be in better 
position (via the domain name) to indicate location.

If the 192.168.1.2 (example below) happens to be in use in a house in 
11212 Main Street, Paramus, NJ, according to the local cable 
operator, but bubba.example.net is a laptop VPN'd back to the home 
site and seen via a NAT box, you might have a conflict in looking at 
the 192.168.1.2 NAPTR ("I'm in NJ") and the bubba NAPTR ("I'm in 
Seattle").  Which is more accurate?  I don't think you can really 
tell.  It could be that the box is in Seattle and the NAT is in 
Paramus.  It could be the box was in Seattle and is now back home 
with the NAT in Paramus.  And it could be that the box went from 
Seattle to San Diego without the traveller updating the entry.  From 
what's in the DNS, you can't determine which is the case.

Is it a good idea?  You mean to place a level of trust in data 
depending on where it is in DNS?  Probably not.  Under in-addr.arpa 
(and ip6.arpa) you will find a varying level of interest in 
maintaining data's accuracy.  This isn't a slam at ISP's, a lot of 
the reverse map is "legacy."  The same can be said for the non-arpa 
side of the DNS.

I would say that placing trust in data based on where it is in the 
DNS is a bad idea.  Unless you also know something about the 
administration of the particular zone.

An analogous situation - is the number of labels in a name an 
indication of the kind of zone it is?  "com." is a lot like 
"198.in-addr.arpa." but nothing like "root-servers.net."  A 2 (com 
and dot) label zone and a 4 label zone (198, in-addr, arpa, and dot) 
have more in common than the 3 label zone (2<3<4). This came up in 
HTTP cookie policy.  And to some extent in policy discovery for 
things like DKIM.  I don't mean to say these are futile attempts, but 
it seems that more times than not, placing trust based on where has 
not been an overwhelmingly triumphant success.

OTOH, data is data, whether or not it is information.

At 4:47 -0400 8/28/06, John Schnizlein wrote:
>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.
>
>pointing to names that have NAPTER records through which the 
>Location Server is discovered.
>
>Is this a good idea?
>
>Re: [Geopriv] questions/comments regarding draft-schulzrinne-geopriv-relo
>>
>>>  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.)
>.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Secrets of Success #107: Why arrive at 7am for the good parking space?
Come in at 11am while the early birds drive out to lunch.
.
dnsop resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html