Re: [Inip-discuss] Innovation in DNS

Andrew Sullivan <ajs@anvilwalrusden.com> Thu, 25 August 2016 20:48 UTC

Return-Path: <ajs@anvilwalrusden.com>
X-Original-To: inip-discuss@ietfa.amsl.com
Delivered-To: inip-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81DE612D5BF for <inip-discuss@ietfa.amsl.com>; Thu, 25 Aug 2016 13:48:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 hxqRAUL3f0qa for <inip-discuss@ietfa.amsl.com>; Thu, 25 Aug 2016 13:48:07 -0700 (PDT)
Received: from mx2.yitter.info (mx2.yitter.info [IPv6:2600:3c03::f03c:91ff:fedf:cfab]) by ietfa.amsl.com (Postfix) with ESMTP id 1C050126D74 for <inip-discuss@iab.org>; Thu, 25 Aug 2016 13:48:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 1F10F10FB7 for <inip-discuss@iab.org>; Thu, 25 Aug 2016 20:48:06 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca
Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Yyg2RwORb66 for <inip-discuss@iab.org>; Thu, 25 Aug 2016 20:48:05 +0000 (UTC)
Received: from mx2.yitter.info (192-0-220-231.cpe.teksavvy.com [192.0.220.231]) by mx2.yitter.info (Postfix) with ESMTPSA id 5A59210FA7 for <inip-discuss@iab.org>; Thu, 25 Aug 2016 20:48:05 +0000 (UTC)
Date: Thu, 25 Aug 2016 16:48:03 -0400
From: Andrew Sullivan <ajs@anvilwalrusden.com>
To: inip-discuss@iab.org
Message-ID: <20160825204803.GK17214@mx2.yitter.info>
References: <CAOvDaJRu5=03zhT5d=0USHmKc7zfmD89CwZ78QvJ=Lai4TAZ=Q@mail.gmail.com> <20160822233657.GL1712@mx2.yitter.info> <CAOvDaJS+K-8Shu5=z-qWB6PhhuFxHQ_M8V7wqSa14d1ANW1+xQ@mail.gmail.com> <20160823163553.GG17214@mx2.yitter.info> <CAOvDaJR_YuUqGeDfSQFQ_K_w9sj5TBaEb+Vrdf+Ughy0o+Abiw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAOvDaJR_YuUqGeDfSQFQ_K_w9sj5TBaEb+Vrdf+Ughy0o+Abiw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/inip-discuss/c0i9uFO2-bGYSKiVZZs5AUh3E6k>
Subject: Re: [Inip-discuss] Innovation in DNS
X-BeenThere: inip-discuss@iab.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IAB Internet Names and Identifiers Discussion List <inip-discuss.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/inip-discuss>, <mailto:inip-discuss-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/inip-discuss/>
List-Post: <mailto:inip-discuss@iab.org>
List-Help: <mailto:inip-discuss-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/inip-discuss>, <mailto:inip-discuss-request@iab.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Aug 2016 20:48:08 -0000

On Thu, Aug 25, 2016 at 05:01:46PM +0100, Bauyrzhan Askar wrote:
> For the purpose of clarification of the claim, TTL specifies time it will
> be in cache of DNS resolver. I  point you to “request to *unknown domain
> name*” and it means that there is no record data for the unknown domain
> name not just on Internet users PC but also in DNS resolvers cache.

Perhaps I'm misunderstanding you, but it sounds like you think that if
unknown.example.com arrives ar a resolver, it needs to do the whole
resolution chain.  But the fact is that the NS set for com and
possibly for example.com will both be in the cache.  There's no need
to ask the root about com in this case.  Com is almost always hot in
every cache.  This is true for a lot of TLDs.  And with the advent of
the signed root, lots of resolvers just copy the root, so they don't
really have to consult the root servers at all.

> As for the risk it brings, what kind of risk are you mentioning?
> Cybersquatting, risk of switching to AINA System or other risks?

You're changing the system, and making it considerably more complex.
That necessarily brings risk.

> I want to draw your attention to the part where implementation of the AINA
> System is described. As you can see for the purpose of simplicity,
> switching to AINA System can be conducted through three scenarios. (at
> least three and it is up to imagination). The first one is the one which
> has no risk, and what needed is just to direct requests to AINA System in
> case of unknown domain name for root nameservers.

There's not "no risk" to that.  You're introducing a new set of
dependencies.  That automatically brings risk, and I don't see what
the reward is.

Best regards,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com