Re: [DNSOP] new version of draft-wallstrom-dnsop-dns-delegation-requirements

Bob Harold <rharolde@umich.edu> Fri, 28 October 2016 15:07 UTC

Return-Path: <rharolde@umich.edu>
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 05964129558 for <dnsop@ietfa.amsl.com>; Fri, 28 Oct 2016 08:07:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu
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 PV_CRsMsREAI for <dnsop@ietfa.amsl.com>; Fri, 28 Oct 2016 08:07:40 -0700 (PDT)
Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 6E7071293F5 for <dnsop@ietf.org>; Fri, 28 Oct 2016 08:07:40 -0700 (PDT)
Received: by mail-yw0-x22b.google.com with SMTP id w3so87661755ywg.1 for <dnsop@ietf.org>; Fri, 28 Oct 2016 08:07:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FwXLZTjjHyX8mEeY7phkFT5GMBz3rC0sJ6jTcl8RZCs=; b=G1yanqOfhZxKnJ27GNiXsoQK+pbiJByAjMxV8FYWHurcMApXXPyCobkmNb2bwTmUcw s5xifrPZ8MkQVd2fn4y4wqGBw/Fv9CRWjyxfcZVb5KbrKHo9WegqONhDeLYSM25tgKkm tYsTbvGusFGso0y+xIL7X63S4jET5qRpFPwAvtzwNJuWfz89L2/meVhpOa6qvj7gxwcL /+sJlXlMn4Gtx6LoDhZV5gPY63+AV2J/76rRc5k3Nz9iG0Q4jYcQmdtBhVk4AQbPRUD0 IKf39LvHEzfoUFOX5/7VQBrucNjBb5Y9d3Eyjrkur5OyOTIRD6lmcpH7KBsNHOWAMlfX tQRQ==
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:cc; bh=FwXLZTjjHyX8mEeY7phkFT5GMBz3rC0sJ6jTcl8RZCs=; b=WRKrZRtWff3pXY/4WvnlHbeZl58IfXpI9sTRwI/vvOksIbRbv86ljfgulx9tRiVlhz AHRhtpBjfhpPWZ36Uj+MbSANlXskXYqnNmymdBPrvOr8xxEDN4nvXUxgivEf/HSiCczC clH6VHu/i9s4XBikx/kWqMLZaRxbq/CImRXvFz5qCF3aHyr+Dk766U1sq9f1MIEKsfXX 7nKZSxpFZTOd8MkAzmD6GEawTulbDUywrO1/hnExKv8Mgn2MVIjV/VJ0S3SrdZRucVV9 EECXVR0t4GcmI+NhOr7Qn1b2bOC9azafn1BiTGl2SQdMVTGpqZj2rIYM7Z44403Jh4Op r8TA==
X-Gm-Message-State: ABUngvdosiKYAKbAT9pKy6f3qkwFuxl5cejMBNDiKzP6Ua/PQT3htIkEVuihBDC7gDeODfzyyTBZAa9QmQpOfeXL
X-Received: by 10.129.130.198 with SMTP id s189mr14064597ywf.116.1477667259278; Fri, 28 Oct 2016 08:07:39 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.13.209.70 with HTTP; Fri, 28 Oct 2016 08:07:38 -0700 (PDT)
In-Reply-To: <58126A66.8020100@blipp.com>
References: <58126A66.8020100@blipp.com>
From: Bob Harold <rharolde@umich.edu>
Date: Fri, 28 Oct 2016 11:07:38 -0400
Message-ID: <CA+nkc8AWuPeq3vYi0Fxn0WO5Xans7m3uv0sE7-mOtLj6Wrv=9g@mail.gmail.com>
To: Patrik Wallström <pawal@blipp.com>
Content-Type: multipart/alternative; boundary="94eb2c07c694165094053fee38f1"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RgaczrtD1aIgBWoOOrouzOzj2Gg>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
Subject: Re: [DNSOP] new version of draft-wallstrom-dnsop-dns-delegation-requirements
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 28 Oct 2016 15:07:43 -0000

On Thu, Oct 27, 2016 at 4:58 PM, Patrik Wallström <pawal@blipp.com> wrote:

> Hi,
>
> I just wanted to tell you that we have published a new version of the I-D
> draft-wallstrom-dnsop-dns-delegation-requirements. It fixes all the
> comments that we have received so far, both on the mailing list and during
> the meeting where it was last discussed:
> https://tools.ietf.org/html/draft-wallstrom-dnsop-dns-delega
> tion-requirements
>
> One thing that have bugged me was a comment to separate the meanings of
> domain names and host names. Host names follow a much more strict set of
> rules (they are all referenced in RFC 7719 under "host names") than domain
> names that could pretty much contain anything that fit into the DNS
> protocol. Right now we reference section 2.1 of RFC1123, but 7719 refers to
> 3.1 of 1034. Not that much of a difference, but at least worth mentioning.
>
> In the document we try to follow the rules that if there is something that
> is required from the DNS protocol perspective, it's a MUST. If there is
> anything needed to have a properly configured DNS that is more of a
> recommendation, it is a SHOULD.
>
> Please have a look.
>
> Thanks,
> Patrik
>
>
Thanks for working on this.  Some comments...

2.2.  The domain MUST have a parent domain
"do not have a parent zone"
-- 'do' -> 'does'

2.3.  The domain MUST have at least one working name server
"MUST be able to answer" -> "MUST answer"

4.  Connectivity requirements
-- remove "be able to"

5.1.  Authoritative name servers SHOULD NOT be recursive
"have very specific requirement on"
should be either:
singular: "have a very specific requirement on"
or plural: "have very specific requirements on"

7.8.  Glue records in delegation SHOULD exactly match records
-- what about the ttl in the glue records?  The TTL in the parent (TLD)
zone is often very long (days), but much shorter (minutes) in the child
zone.  Same for the NS records.  But I might be wrong on this point.

8.7.  The name server MUST include RRSIG in all responses to DNSSEC queries
"If the zone is signed, the name servers MUST be able to include RRSIG"
-- remove "be able to"

8.8.  The name servers MUST include valid NSEC/NSEC3 record in NXDOMAIN
responses
-- remove "be able to"

9.4.  The NS names MUST NOT be an alias
"CNAME" refers to the right side of a CNAME record (the canonical name),
but this point is talking about the left side, so change "(CNAME)" to
"(CNAME record)" please.

9.6.  The SOA RNAME MUST be a legal hostname
-- Is 'hostname' rules a new requirement in this RFC?
-- does the 'username' part have to conform to hostname rules?
Section 3.3 of [RFC1034] -- says domain name (not hostname)
Section 2.2 of [RFC1912]. -- says to escape dots in username
Section 2.3.1 of [RFC1035]  -- says to 'prefer' ldh type rules for domain
names
   and refers to RFC-822, where I had trouble finding specific rules
Section 2.1 of [RFC1123].  -- modify hostname rules, allowing starting digit

-- 
Bob Harold