Re: [Inip-discuss] Innovation in DNS

Bauyrzhan Askar <mail@ainasystem.org> Thu, 25 August 2016 16:01 UTC

Return-Path: <mail@ainasystem.org>
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 B129A12D851 for <inip-discuss@ietfa.amsl.com>; Thu, 25 Aug 2016 09:01:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ainasystem-org.20150623.gappssmtp.com
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 zaO8nPSvztE2 for <inip-discuss@ietfa.amsl.com>; Thu, 25 Aug 2016 09:01:49 -0700 (PDT)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E3012D847 for <inip-discuss@iab.org>; Thu, 25 Aug 2016 09:01:48 -0700 (PDT)
Received: by mail-wm0-x22a.google.com with SMTP id o80so79409030wme.1 for <inip-discuss@iab.org>; Thu, 25 Aug 2016 09:01:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ainasystem-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=viX2AJoHgR6dkQPBSXBSXnTgByoaWMBYxAg4Y7MDU04=; b=KtTcW/l+pxoWA2V/CMChtusNSr1BgbvdxUxCT3QreQraV0GDEQ+G5Cc16IYDqcoVwc SI39Yix+0maum5xAkbG3AmpDumPuW6FP1Zyvb33Tcg1ArOdGZPpxPXYI+eGig1fiFwQ5 FFhME+6kwHBnh9O/5L6fBU7kuX9V+7faSrDcHpOA2sYPJhrOq8wfKD1OQCOy3q//uhum eEz8sv3oefh1gNu5fqW4H3Ng068sLeVRtlQ2aRMrTFxmXly4A2NDNRuKCr8oYtVmZY7j kjxcYC9cd0TandZsTrSuP++djm1SlGCzWXRkAiKIIPLA0fXqrTGl2MoDH6jn4FwiGl0Y EL3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=viX2AJoHgR6dkQPBSXBSXnTgByoaWMBYxAg4Y7MDU04=; b=UgBHKVzA7DPwEU50uD+AisrzYtEMs/MgOGL+ZRuc0kfUg+mmaxbY56ihFMaapM9Wnv QbFIaTNWTU3r44ScsWWh6PZxAxpG+lzUiGt0hak5y4kFiN5wJQfM9l5FQAW1LCdbxUBu nneVBFdtKu8kwabpJItLSg1/bLqalrOi/C0LWAu02JH23yQhl+NFITkcYn79eIr/Qv3p p+vOeNo3R+vGvAld0w+RzYoXYbrCHEFWbMO1mU7tL+dOwhBrF9ajnNp6TEkaY89LxyM8 2g5W8K1qaSOt0MePBTYTEb+H99mhNUbCJHY6PrHWTop3LuuYTMhkAcQpSMYikDdrG4cs Xckg==
X-Gm-Message-State: AEkoouvF54/iF8OJPgRyupfU/d5d+PKNTSEsvSkVstJPZ6JEF/QE3u3D2ACO/FzbemHES27bOShdYLrICi/t8w==
X-Received: by 10.194.47.206 with SMTP id f14mr8824149wjn.98.1472140906691; Thu, 25 Aug 2016 09:01:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.74.219 with HTTP; Thu, 25 Aug 2016 09:01:46 -0700 (PDT)
In-Reply-To: <20160823163553.GG17214@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>
From: Bauyrzhan Askar <mail@ainasystem.org>
Date: Thu, 25 Aug 2016 17:01:46 +0100
Message-ID: <CAOvDaJR_YuUqGeDfSQFQ_K_w9sj5TBaEb+Vrdf+Ughy0o+Abiw@mail.gmail.com>
To: inip-discuss@iab.org
Content-Type: multipart/alternative; boundary="047d7b86e4f8cda5ae053ae783df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/inip-discuss/PtoxaR0AsuGkV9XJA-bq4aHITEQ>
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 16:01:51 -0000

Hi there


> Unlike com zone, root zone is accessed every time when DNS resolution for
> unknown domain name is requested no matter which TLD zone the unknown
> domain name belongs to.

>Not true.  That claim ignores the effects of TTLs.

> *So, increase of SLD together with TLD, increases rate of DNS resolution
> query to root nameserver. *

>So?

Andrew, would you explain the effects of TLL related to that claim.


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.


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


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.


Many problems may rise here not from the technical aspect but rather from
political or business interest aspects. And I hopefully believe that the
discussions conducted here is out of that topics.


Thanks

On Tue, Aug 23, 2016 at 5:35 PM, Andrew Sullivan <ajs@anvilwalrusden.com>
wrote:

> On Tue, Aug 23, 2016 at 05:24:21PM +0100, Bauyrzhan Askar wrote:
> > Unlike com zone, root zone is accessed every time when DNS resolution for
> > unknown domain name is requested no matter which TLD zone the unknown
> > domain name belongs to.
>
> Not true.  That claim ignores the effects of TTLs.
>
> > *So, increase of SLD together with TLD, increases rate of DNS resolution
> > query to root nameserver. *
>
> So?
>
> > But the problem here is that when TLD list increases and any entry or
> > update made to the root zone file in master root nameserver, all root
> > nameservers have to be updated which in turn
> >
> > 1)     increases the load to network handling root nameservers. (this may
> > not be a big problem at the moment)
> >
> > 2)     increases the time for update to be finished throughout the world
> > because of increased number of copies of root nameservers.
> >
> > 3)     increases the load to any particular root nameserver, no matter of
> > number of copies of root nameserver, because of the increased rate of
> > updates.
>
> All of this is true of the com zone, too, so I don't see how it's
> relevant at all.  I just don't see that this is a significant
> improvement of the DNS, and it involves adding changes to the system
> that present their own risks.  If we're going to undertake such risks,
> it seems to me a tiny incremental improvement to address no actual
> practical problem anyone has for only one zone seems like a low
> return on the investment.
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> ajs@anvilwalrusden.com
>
> _______________________________________________
> Inip-discuss mailing list
> Inip-discuss@iab.org
> https://www.iab.org/mailman/listinfo/inip-discuss
>