IETF Logo Mail Archive

Re: [Geopriv] Proposal for LIS discovery (DNS)

Ray.Bellis@nominet.org.uk Thu, 27 November 2008 16:08 UTC

Return-Path: <geopriv-bounces@ietf.org>
X-Original-To: geopriv-archive@megatron.ietf.org
Delivered-To: ietfarch-geopriv-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7757C3A6922; Thu, 27 Nov 2008 08:08:32 -0800 (PST)
X-Original-To: geopriv@core3.amsl.com
Delivered-To: geopriv@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22083A6922 for <geopriv@core3.amsl.com>; Thu, 27 Nov 2008 08:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VeIQI6tYIoq7 for <geopriv@core3.amsl.com>; Thu, 27 Nov 2008 08:08:29 -0800 (PST)
Received: from mx4.nominet.org.uk (mx4.nominet.org.uk [213.248.199.24]) by core3.amsl.com (Postfix) with ESMTP id 8F1B03A686E for <geopriv@ietf.org>; Thu, 27 Nov 2008 08:08:29 -0800 (PST)
DomainKey-Signature: s=main.dk.nominet.selector; d=nominet.org.uk; c=nofws; q=dns; h=X-IronPort-AV:Received:In-Reply-To:References:To:Cc: Subject:MIME-Version:X-Mailer:Message-ID:From:Date: X-MIMETrack:Content-Type; b=D8KKk0MEdnfkKc9W+Wq6w8ZctOH/mMQryIr0vYfVgavduSr4fxDxB5wa HDSSAOC8GkMEIiEe/szJ2fiTY3wDG8G7e3rqy2qGKLXP23sMguhyPDm/w su2nmLsUgbwvr/R;
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nominet.org.uk; i=Ray.Bellis@nominet.org.uk; q=dns/txt; s=main.dkim.nominet.selector; t=1227802107; x=1259338107; h=from:sender:reply-to:subject:date:message-id:to:cc: mime-version:content-transfer-encoding:content-id: content-description:resent-date:resent-from:resent-sender: resent-to:resent-cc:resent-message-id:in-reply-to: references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:list-owner:list-archive; z=From:=20Ray.Bellis@nominet.org.uk|Subject:=20Re:=20[Geop riv]=20Proposal=20for=20LIS=20discovery=20(DNS)|Date:=20T hu,=2027=20Nov=202008=2016:08:23=20+0000|Message-ID:=20<O F4823B440.6A60559F-ON8025750E.0057CE7E-8025750E.0058A8D2@ nominet.org.uk>|To:=20Richard=20Barnes=20<rbarnes@bbn.com >|Cc:=20geopriv@ietf.org|MIME-Version:=201.0|In-Reply-To: =20<492EAE7A.7020304@bbn.com>|References:=20<E51D5B15BFDE FD448F90BDD17D41CFF10526006B@AHQEX1.andrew.com>=20<492DF3 C6.5090500@bbn.com>=20<OFFD6D86A7.D206C780-ON8025750E.003 45D1D-8025750E.00355895@nominet.org.uk>=20<492EAE7A.70203 04@bbn.com>; bh=+z0aVjdULaiifbDG25wJNfmOPPcNU1sJbz6miXqHqa0=; b=P1qIB5fJajmt7IFO+2pHhRFPjqoeR5L+dXO//o6FjG06wp6E7dz6I7bn 9YQfHj70JFX0DCPAX6CjSgQZlIokkiCT+ygbEvdnF0+/72SQq0+cZ1FOc DbhQMOTgCZhEOE3;
X-IronPort-AV: E=Sophos;i="4.33,675,1220223600"; d="scan'208";a="7081727"
Received: from notes1.nominet.org.uk ([213.248.197.128]) by mx4.nominet.org.uk with ESMTP; 27 Nov 2008 16:08:25 +0000
In-Reply-To: <492EAE7A.7020304@bbn.com>
References: <E51D5B15BFDEFD448F90BDD17D41CFF10526006B@AHQEX1.andrew.com> <492DF3C6.5090500@bbn.com> <OFFD6D86A7.D206C780-ON8025750E.00345D1D-8025750E.00355895@nominet.org.uk> <492EAE7A.7020304@bbn.com>
To: Richard Barnes <rbarnes@bbn.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Build V85_M2_08202008 August 20, 2008
Message-ID: <OF4823B440.6A60559F-ON8025750E.0057CE7E-8025750E.0058A8D2@nominet.org.uk>
From: Ray.Bellis@nominet.org.uk
Date: Thu, 27 Nov 2008 16:08:23 +0000
X-MIMETrack: Serialize by Router on notes1/Nominet(Release 7.0.1FP1 | May 25, 2006) at 27/11/2008 04:08:24 PM, Serialize complete at 27/11/2008 04:08:24 PM
Cc: geopriv@ietf.org
Subject: Re: [Geopriv] Proposal for LIS discovery (DNS)
X-BeenThere: geopriv@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Geographic Location/Privacy <geopriv.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/geopriv>
List-Post: <mailto:geopriv@ietf.org>
List-Help: <mailto:geopriv-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/geopriv>, <mailto:geopriv-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: geopriv-bounces@ietf.org
Errors-To: geopriv-bounces@ietf.org

> I didn't mean to say "if you use Option 15, then you MUST provision 
> NAPTR records".  The MUSTs only apply if the access network wants to 
> enable DNS-based discovery (and maybe they're SHOULDs).

That's sort of the point.  There is _no_ guaranteed linkage between the 
access network and the domain names used by the end-user within the LAN. 
DNS based discovery based on the RDATA of a PTR record could never work 
reliably.

Putting NAPTR records directly into in-addr.arpa (looked up based on a 
STUN/UPnP discovered WAN address) might work better, although there'd 
still be issues where the customer has a routed CIDR block and the ISP has 
delegated some part of in-addr.arpa directly to the end-user.
 
> Were you thinking about a network that supports DNS-based discovery, but 

> doesn't use DHCP to distribute the domain name to clients? (I imagine 
> this is one way you could hack around the "belkin" issue below.)  You're 

> right that argues for the MUSTs to be SHOULDs (at least the first one).
> 
> But even in that case, the network operator should be aware that clients 

> on their network that don't have the static domain configured are still 
> going to try the domain they get from option 15 first.

I strongly believe option 15 should not be used.

1.  It's an abuse of the option
2.  It relies on the incorrect assumption above

> One other thing that would be helpful to add (maybe in S6) is some 
> guidance for middle-box makers on how to do better than this.  If the 
> gateway is provisioned over PPP, maybe you can't do much better, but if 
> the gateway is getting option 15 on its upstream/public face, then it 
> MUST pass it through to option 15 on the downstream/private face.

I've already written a draft about middle-box behaviour 
(draft-bellis-dnsext-dnsproxy-00) which will be available as 
draft-ietf-dnsext-proxy-00 any day now.

Middle boxes absolutely must NOT copy option 15 from WAN DHCP into LAN 
DHCP.  Option 15 is intended for site-network configuration, not access 
provider configuration.

Ray

-- 
Ray Bellis, MA(Oxon)
Senior Researcher in Advanced Projects, Nominet
e: ray@nominet.org.uk, t: +44 1865 332211

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv

v2.23.0 | Report a Bug | By Email