Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa

Philip Homburg <pch-dnsop-3@u-1.phicoh.com> Fri, 06 July 2018 09:00 UTC

Return-Path: <pch-bCE2691D2@u-1.phicoh.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54930130E8D for <dnsop@ietfa.amsl.com>; Fri, 6 Jul 2018 02:00:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbKmOlTIMqGt for <dnsop@ietfa.amsl.com>; Fri, 6 Jul 2018 02:00:00 -0700 (PDT)
Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2763130DF3 for <dnsop@ietf.org>; Fri, 6 Jul 2018 01:59:59 -0700 (PDT)
Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fbMar-0000HxC; Fri, 6 Jul 2018 10:59:57 +0200
Message-Id: <m1fbMar-0000HxC@stereo.hq.phicoh.net>
To: dnsop@ietf.org
From: Philip Homburg <pch-dnsop-3@u-1.phicoh.com>
Sender: pch-bCE2691D2@u-1.phicoh.com
References: <m1fb194-0000FpC@stereo.hq.phicoh.net> <A61E2913-891E-4F14-82AF-A8A40F39F47F@isc.org> <m1fbMB8-0000FkC@stereo.hq.phicoh.net> <FA54B85D-EBD7-4852-86F2-672B918A96E1@isc.org>
In-reply-to: Your message of "Fri, 6 Jul 2018 18:50:44 +1000 ." <FA54B85D-EBD7-4852-86F2-672B918A96E1@isc.org>
Date: Fri, 06 Jul 2018 10:59:57 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Ip1L9gMwbgcVhw4TTV2wK3JSrYk>
Subject: Re: [DNSOP] AD sponsoring draft-cheshire-sudn-ipv4only-dot-arpa
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jul 2018 09:00:02 -0000

In your letter dated Fri, 6 Jul 2018 18:50:44 +1000 you wrote:
>All it does is ensure that the DNS queries get to the DNS64 server. 

The way RFC 7050 works that you send queries to your local recursive
resolver. The problem there is that if the user manually configured
a public recursive resolver then you don't learn the translation prefix.

In this context I don't see how serving ipv4only.arpa from dedicated addresses
would help. 

We can define a new prefix discovery protocol where the node that needs to
discover the prefix directly queries the authoritative servers for
ipv4only.arpa. That would solved the issue with manually configured 
resolvers. But it would also add yet another way off discovering the prefix
that needs to be supported.