[DNSOP] comments on draft-ietf-dnsop-dns-terminology-03

Casey Deccio <casey@deccio.net> Mon, 13 July 2015 21:20 UTC

Return-Path: <casey@deccio.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74B51A897B for <dnsop@ietfa.amsl.com>; Mon, 13 Jul 2015 14:20:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.022
X-Spam-Level:
X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 YB7H2CI35aBf for <dnsop@ietfa.amsl.com>; Mon, 13 Jul 2015 14:20:06 -0700 (PDT)
Received: from mail-ie0-x229.google.com (mail-ie0-x229.google.com [IPv6:2607:f8b0:4001:c03::229]) (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 DB7E01A8977 for <dnsop@ietf.org>; Mon, 13 Jul 2015 14:20:05 -0700 (PDT)
Received: by ietj16 with SMTP id j16so71048970iet.0 for <dnsop@ietf.org>; Mon, 13 Jul 2015 14:20:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=deccio.net; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=B4c75Nr7XLDSXCj6Whitm2Q5Ic9lx+ygc+uES8n8aYc=; b=F8nPsnbWI6ZhT35gl0prqbI/zcBeJLsFJBRFWChn5k/Kf2+bZMhXerEDvNtOJqkJjS DyNV2T6soSvRd9ZN3ZI+f2U/NiKVIqQoSiCxCgzSYOS+2f7fdiiCvDGw0Wu6IACwV8ng DOAkIYNkBCXBNQES4xGbXVUXVTB/rRGXPr6qQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=B4c75Nr7XLDSXCj6Whitm2Q5Ic9lx+ygc+uES8n8aYc=; b=kkRAC7GpETN8L/WgXTrG1lvHdHtweZfrx8SyQYNI6lDA5L4dkyO2Ra9YBGxgGUmR3N naQutGxncVw+C7Tmjz3UgwpVfPiKkMYsA3L7DrVGC1wH36zYgVlq73u0jU4RMzqzMC+7 +ag0uz4p9mzNXak0G/QYxDqnMpMspLsrFAf7uHjHmz+ZqLA38pO7YOIAjsYWI6bpzsJG 6B2df2oi9ngCOMQN2miFQg+JzfW7ZVfpRIXsWPxhU8lBqpwcqewjjvmbS/llX6Hmpo2T xFqVDzjrMQUJbOzrMjW5vQrL0GwAZZihjvq3f7rREozNeOjkmMpOGSLuRFNKr80p7Skb vCOQ==
X-Gm-Message-State: ALoCoQlUqcNfDFZ78UnrkMKWb3+64+P4ysthV/LwloJ30HFI7Bd8HMFE26MazvL+7Jty+D1/zCfZ
MIME-Version: 1.0
X-Received: by 10.50.44.100 with SMTP id d4mr13680778igm.67.1436822404786; Mon, 13 Jul 2015 14:20:04 -0700 (PDT)
Received: by 10.50.240.17 with HTTP; Mon, 13 Jul 2015 14:20:04 -0700 (PDT)
Date: Mon, 13 Jul 2015 17:20:04 -0400
Message-ID: <CAEKtLiQWPM6yJZZASQ5k1bzsbHc3jv5FRsJ6ifgUdj9TRLCmRg@mail.gmail.com>
From: Casey Deccio <casey@deccio.net>
To: dnsop WG <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="e89a8f839f910b0d12051ac849f3"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/GbWxcx9PiMMD9RewWdLGoeDBgvc>
Subject: [DNSOP] comments on draft-ietf-dnsop-dns-terminology-03
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: Mon, 13 Jul 2015 21:20:07 -0000

Hi all,

I have a few comments on the latest draft-ietf-dnsop-dns-terminology
(-03).  There will be more; I'm part way through a review.

Thanks,
Casey

1. (stylistic) There are a number of definitions that quote terminology and
then parenthetically state "quoted from".  It seems more intuitive,
precise, and consistent to mark quoted text using quotation marks instead,
as in other definitions.  Some examples (there are probably more):
  - Canonical name
  - CNAME
  - NODATA
  - Resolver

2. For the public suffix definition, I suggest the following:

"A domain that is controlled by a public registry" (RFC 6265, 5.3).  "For
security reasons many user agents are configured to reject Domain
attributes that correspond to 'public suffixes'" (RFC 6265, section
4.1.2.3).

There is nothing inherent in a domain name to indicate whether or not it is
a public suffix; that can only be determined by outside means.  One
resource for identifying public suffixes is the Public Suffix List (PSL)
maintained by Mozilla (http://publicsuffix.org/).

(optional)
The IETF DBOUND Working Group was chartered to solve the more general issue
of identifying or repudiating relationships between domain names, outside
of the DNS namespace itself, which could change the role of a public suffix.

3. The current text for referral is incomprehensible.  I suggest the
following:

A response "generated using local data" which contains no answer but rather
includes "name servers which have zones which are closer ancestors to the
name than the server sending the reply" (RFC 1034, sections 4.1 and
4.3.1).  These name servers take the form of NS records in the authority
section of the response and come from the "NS RRs marking cuts along the
bottom of a zone" when "a match would take us out of the authoritative
data" (RFC 1034, section 4.3.2).  Referrals are only associated with
non-recursive (i.e., iterative) queries (RFC 1034 section 4.3.1).  In
general, a referral is a way for a server to send an answer saying that the
server does not know the answer, but knows where the resolver should direct
its query should be directed in order to eventually get an answer.

Historically, many authoritative servers answered with a referral to the
root zone when queried for a name for which they were not authoritative,
but this practice has declined.

See also Glue Records.

4. In the definition of RRset, the bit about TTLs needing to be the same
seems out of place for this terminology document.  That is an operational
requirement.