Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC

"Livingood, Jason" <Jason_Livingood@cable.comcast.com> Tue, 21 February 2012 19:45 UTC

Return-Path: <jason_livingood@cable.comcast.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBC721E805B for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2012 11:45:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.136
X-Spam-Level:
X-Spam-Status: No, score=-106.136 tagged_above=-999 required=5 tests=[AWL=2.327, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+gPlK0CV9Gd for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2012 11:45:33 -0800 (PST)
Received: from pacdcimo01.cable.comcast.com (PacdcIMO01.cable.comcast.com [24.40.8.145]) by ietfa.amsl.com (Postfix) with ESMTP id B63DD21F8501 for <v6ops@ietf.org>; Tue, 21 Feb 2012 11:45:32 -0800 (PST)
Received: from ([24.40.56.114]) by pacdcimo01.cable.comcast.com with ESMTP id 5503620.151920482; Tue, 21 Feb 2012 14:44:51 -0500
Received: from PACDCEXMB06.cable.comcast.com ([fe80::6134:ea50:286a:c0]) by PACDCEXHUB01.cable.comcast.com ([fe80::d1e7:20b5:9b63:21a6%11]) with mapi id 14.01.0355.002; Tue, 21 Feb 2012 14:44:51 -0500
From: "Livingood, Jason" <Jason_Livingood@cable.comcast.com>
To: Joel jaeggli <joelja@bogus.com>, Marc Lampo <marc.lampo@eurid.eu>, Ronald Bonica <rbonica@juniper.net>
Thread-Topic: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
Thread-Index: AQHM8NFGCTjaobpzcUWNbcVExb7NGw==
Date: Tue, 21 Feb 2012 19:44:51 +0000
Message-ID: <CB695DB0.5117A%jason_livingood@cable.comcast.com>
In-Reply-To: <4F42C1E6.7010606@bogus.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
x-originating-ip: [24.40.56.165]
Content-Type: multipart/alternative; boundary="_000_CB695DB05117Ajasonlivingoodcablecomcastcom_"
MIME-Version: 1.0
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Last Call: <draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt> (Considerations for Transitioning Content to IPv6) to Informational RFC
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Feb 2012 19:45:34 -0000

On 2/20/12 4:57 PM, "Joel jaeggli" <joelja@bogus.com<mailto:joelja@bogus.com>> wrote:
IMHO the following applies.

if you have one zone yeah I agree.

If you have two zones one with aaaa and one without (assuming this is done with dns views style implementation) you can sign both and they'll both be valid and complete from the vantage point of a client which resolves one or the other of them but not both.

this is a traditional split horizon problem. it's just not inside/outside.

Exactly, which is one of the reasons section 4.3.4 is there (Similarities to Split DNS). This is two zones (or 'views' of the zone data). Both can be signed.

Jason