Re: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04

"Klaas Wierenga (kwiereng)" <> Mon, 11 August 2014 06:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 88A1E1A0337; Sun, 10 Aug 2014 23:52:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.169
X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QIPhhr7m7Jr9; Sun, 10 Aug 2014 23:52:49 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D8F51A0334; Sun, 10 Aug 2014 23:52:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2193; q=dns/txt; s=iport; t=1407739969; x=1408949569; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HfJio8GQb21LBxo/A975T88G4OCWcS3AlsYRBpZ5Mk8=; b=mGs7KSlC03S4qDeOBONxq7SU13vwV1MN0Yv96UDbipIaRJAKmBpvVoDl LGLdFh/eqbiVS+8ma7qli+OMQJe6v74Veuwk4AODDJgzjmJQn2TrfiuBo /JBWWJemTZ4PFfiwKA3wsTG5yYJwSX5GQwA7F2GSw07dULsj4qPJ76OuR U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkkFAPRm6FOtJV2a/2dsb2JhbABagw2BKQTUOgGBExZ3hAMBAQEDAXkFCwIBCBguMiUCBA4FiDoIwGIXjxkzB4MvgR0BBJEZixaUe4NcbIFH
X-IronPort-AV: E=Sophos;i="5.01,839,1400025600"; d="scan'208";a="346544747"
Received: from ([]) by with ESMTP; 11 Aug 2014 06:52:46 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s7B6qk5p015332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Aug 2014 06:52:46 GMT
Received: from ([]) by ([]) with mapi id 14.03.0195.001; Mon, 11 Aug 2014 01:52:46 -0500
From: "Klaas Wierenga (kwiereng)" <>
To: Paul Wouters <>
Thread-Topic: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04
Thread-Index: AQHPsiQ3f8OY5L4Ee0OTmhRUsiOAuZvFiEiAgAXJFYA=
Date: Mon, 11 Aug 2014 06:52:45 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>, "" <>, "" <>
Subject: Re: [secdir] secdir review of draft-ietf-dnsop-as112-dname-04
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 11 Aug 2014 06:52:50 -0000

On 07 Aug 2014, at 16:32, Paul Wouters <> wrote:

Hi Paul,

> On Thu, 7 Aug 2014, Klaas Wierenga (kwiereng) wrote:
>> For security considerations relating to AS112 service in general, see RFC6304bis]."
>> And in the introduction
>> "The AS112 project does not accommodate the addition and removal of
>>  DNS zones elegantly.  Since additional zones of definitively local
>>  significance are known to exist”
>> It appears to me that moving from a static list of well known ranges as defined in 6304bis to a dynamic adding and dropping of IP-address ranges that are "of definitively local
>>  significance” is prone to error, potentially leading to blackholing valid address space, either on purpose or by accident. I may show my ignorance here, but I feel that a discussions as to why that risk doesn’t exist is warranted.
> Actually, the static list is much more problematic. Mostly because some
> AS112 instances would not yet have the new addition, while other AS112
> instances would, and the replies would be inconsistent. By using the
> DNAME protocol, it makes anything thrown at an AS112 work. Anyone else
> throwing something in would still cause less packets on the internet
> than those DNS packets leaking out the regular DNS infrastructure. For
> instance, ISPs could run an AS112 instance to take all RFC1918 queries.
> When new ranges are added (like the ISP does not even
> need to update their AS112 instance (they have to do so now). The
> document's main purpose is to get rid of that bad static list. Because
> it is static, an ISP cannot even really add anything to it, without
> causing inconsistency.

OK, that sounds reasonable. So I gather that this list of “definitive local significance” ranges is relatively dynamic? I.e. there is a need for updating this list often? 

> The only people that can make a mistake to "null route" their domain into
> AS112 are the owners of the domain. Don't configure NS records that
> point to AS112 and you are fine.

OK, makes sense (as I pointed out, blame my ignorance ;-)