Re: [DNSOP] draft-hoffman-dns-terminology-ter-01.txt - some comments

"Patrik Fältström " <paf@frobbit.se> Wed, 24 July 2019 06:32 UTC

Return-Path: <paf@frobbit.se>
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 4ADFF120276 for <dnsop@ietfa.amsl.com>; Tue, 23 Jul 2019 23:32:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
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 3GANVkX9dlET for <dnsop@ietfa.amsl.com>; Tue, 23 Jul 2019 23:32:28 -0700 (PDT)
Received: from mail.frobbit.se (mail.frobbit.se [IPv6:2a02:80:3ffe::176]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91FAA12011D for <dnsop@ietf.org>; Tue, 23 Jul 2019 23:32:28 -0700 (PDT)
Received: from [169.254.237.203] (unknown [IPv6:2a01:3f0:1:0:50fe:8176:5436:7ffe]) by mail.frobbit.se (Postfix) with ESMTPSA id 150E828A6C; Wed, 24 Jul 2019 08:32:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1563949946; bh=1bryzXbZsJqESrVRCLhWDxpPp//pD6fgR0xUR6s4dz4=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=LkMz1RimvidBDs7HUWX01J4iT7ci1++HcuACBNdjMcGQ6f8K+3XrVkgFBkNTTf59E Q7LaPF3uacWBvH+PCuOnIPp+3dDSQnmdH7f6Vzl7UF1ocH3A3ZIf7F1lNthNlN+0NM YTOmQMDXYcz1hMuaKF2673EX+otyMZIMwU5OyM3o=
From: Patrik Fältström <paf@frobbit.se>
To: Puneet Sood <puneets=40google.com@dmarc.ietf.org>
Cc: Normen Kowalewski <nbkowalewski@gmx.net>, Paul Hoffman <paul.hoffman@icann.org>, DNSOP WG <dnsop@ietf.org>
Date: Wed, 24 Jul 2019 08:32:24 +0200
X-Mailer: MailMate (1.12.5r5635)
Message-ID: <6395B109-F0CA-487C-B05C-47B2D868F92E@frobbit.se>
In-Reply-To: <CA+9_gVtHF-k2-FvwqMw-sZojx8jaE5Agv+SDB0nu+wm6KW2X6g@mail.gmail.com>
References: <7A996832-AD59-4FA4-A6B9-40B39FDAC3D5@gmx.net> <CA+9_gVtHF-k2-FvwqMw-sZojx8jaE5Agv+SDB0nu+wm6KW2X6g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=_MailMate_C0FAD9FB-D124-4095-B290-E79941CA1573_="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/7w8iTVaILyzgD_Hn1ZUo8dhcwUA>
Subject: Re: [DNSOP] draft-hoffman-dns-terminology-ter-01.txt - some comments
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 24 Jul 2019 06:32:31 -0000

On 23 Jul 2019, at 20:10, Puneet Sood wrote:

>> draft-hoffman-dns-terminology-ter-01.txt says:
>>       Applications Doing DNS (ADD):  Applications that act as stub
>>       resolvers.  This is in contrast to the way that applications
>>       traditionally have gotten DNS information, which is to use system
>>       calls to the operating system on the computer, and have the
>>       operating system act as the stub resolver.  "Applications Doing
>>       DNS" is not limited to particular transports: it applies equally
>>       to DNS-over-TLS, DNS-over-HTTPS, Do53, and future DNS transports.
>>       ( Temporary note, to be removed before publication as an RFC:
>>       there is a mailing list discussing Applications Doing DNS at
>>       https://www.ietf.org/mailman/listinfo/add )
>>
>> While I agree that “add” today covers discussion around the case described in here, but the reason that it covers it  is because “add” acts as a "catch all bucket" for “various DNS things not well defined”.
>> If we want to cover the case of an application acts as/embed a stub resolver, we may want to define a term (and draft) that covers exactly that, instead of using the much wider term.
>
> I like this clarification of what people are using ADD to mean. As I am listening to the ADD BoF talks, I want to point out that
> applications *have* been doing - just using a system API. The discussion and activity is now around applications embedding stub resolver functionality. So I propose term like Embedded Application Resolver Stub (EARS).

First of all, the calls being used by applications are not system calls. Not the definition of system calls I know of at least.

The difference between traditional DNS and what we have here to be is that in traditional DNS the configuration and control of where to send the DNS packets is made by the operating system, while with ADD it is done by the application.

The rest of the stuff is very similar. Still RD flag set. Still not much clue on the client side etc.

Then, as others have said, discussion about other transport protocols have been sneaking in here, but that does not really matter for me when talking about traditional DNS or ADD. Do53 or DoT or whatever is just another transport.

Good to define the terms though! But if you have different DoT things for when RD flag is set or not, why not also for Do53?

   Patrik