MIME-Version: 1.0
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: =?UTF-8?Q?Patrik_Wallstr=C3=B6m?= <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
Precedence: list

--94eb2c07c694165094053fee38f1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 27, 2016 at 4:58 PM, Patrik Wallstr=C3=B6m <pawal@blipp.com> wr=
ote:

> 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 durin=
g
> 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 domai=
n
> 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 tha=
t
> 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 digi=
t

--=20
Bob Harold

--94eb2c07c694165094053fee38f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><div class=3D"gmail_quote">=
On Thu, Oct 27, 2016 at 4:58 PM, Patrik Wallstr=C3=B6m <span dir=3D"ltr">&l=
t;<a href=3D"mailto:pawal@blipp.com" target=3D"_blank">pawal@blipp.com</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px =
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<=
br>
<br>
I just wanted to tell you that we have published a new version of the I-D d=
raft-wallstrom-dnsop-dns-dele<wbr>gation-requirements. It fixes all the com=
ments that we have received so far, both on the mailing list and during the=
 meeting where it was last discussed:<br>
<a href=3D"https://tools.ietf.org/html/draft-wallstrom-dnsop-dns-delegation=
-requirements" rel=3D"noreferrer" target=3D"_blank">https://tools.ietf.org/=
html/dr<wbr>aft-wallstrom-dnsop-dns-delega<wbr>tion-requirements</a><br>
<br>
One thing that have bugged me was a comment to separate the meanings of dom=
ain names and host names. Host names follow a much more strict set of rules=
 (they are all referenced in RFC 7719 under &quot;host names&quot;) than do=
main names that could pretty much contain anything that fit into the DNS pr=
otocol. 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.<b=
r>
<br>
In the document we try to follow the rules that if there is something that =
is required from the DNS protocol perspective, it&#39;s a MUST. If there is=
 anything needed to have a properly configured DNS that is more of a recomm=
endation, it is a SHOULD.<br>
<br>
Please have a look.<br>
<br>
Thanks,<br>
Patrik<br>
<br></blockquote><div><br></div><div>Thanks for working on this.=C2=A0 Some=
 comments...<br>=C2=A0<br></div><div>2.2.=C2=A0 The domain MUST have a pare=
nt domain<br>&quot;do not have a parent zone&quot;<br>-- &#39;do&#39; -&gt;=
 &#39;does&#39;<br><br>2.3.=C2=A0 The domain MUST have at least one working=
 name server<br>&quot;MUST be able to answer&quot; -&gt; &quot;MUST answer&=
quot;<br></div><div><br>4.=C2=A0 Connectivity requirements<br>-- remove &qu=
ot;be able to&quot;<br><br>5.1.=C2=A0 Authoritative name servers SHOULD NOT=
 be recursive<br>&quot;have very specific requirement on&quot;<br>should be=
 either: <br>singular: &quot;have a very specific requirement on&quot;<br>o=
r plural: &quot;have very specific requirements on&quot;<br><br>7.8.=C2=A0 =
Glue records in delegation SHOULD exactly match records<br>-- what about th=
e ttl in the glue records?=C2=A0 The TTL in the parent (TLD) zone is often =
very long (days), but much shorter (minutes) in the child zone.=C2=A0 Same =
for the NS records.=C2=A0 But I might be wrong on this point.<br><br>8.7.=
=C2=A0 The name server MUST include RRSIG in all responses to DNSSEC querie=
s<br>&quot;If the zone is signed, the name servers MUST be able to include =
RRSIG&quot;<br>-- remove &quot;be able to&quot;<br><br>8.8.=C2=A0 The name =
servers MUST include valid NSEC/NSEC3 record in NXDOMAIN responses<br>-- re=
move &quot;be able to&quot;<br><br>9.4.=C2=A0 The NS names MUST NOT be an a=
lias<br>&quot;CNAME&quot; refers to the right side of a CNAME record (the c=
anonical name), but this point is talking about the left side, so change &q=
uot;(CNAME)&quot; to &quot;(CNAME record)&quot; please.<br><br>9.6.=C2=A0 T=
he SOA RNAME MUST be a legal hostname<br>-- Is &#39;hostname&#39; rules a n=
ew requirement in this RFC?<br>-- does the &#39;username&#39; part have to =
conform to hostname rules?<br>Section 3.3 of [RFC1034] -- says domain name =
(not hostname)<br>Section 2.2 of [RFC1912]. -- says to escape dots in usern=
ame<br>Section 2.3.1 of [RFC1035]=C2=A0 -- says to &#39;prefer&#39; ldh typ=
e rules for domain names<br>=C2=A0=C2=A0 and refers to RFC-822, where I had=
 trouble finding specific rules<br>Section 2.1 of [RFC1123].=C2=A0 -- modif=
y hostname rules, allowing starting digit<br><br>-- <br></div><div>Bob Haro=
ld<br><br></div></div><br></div></div>

--94eb2c07c694165094053fee38f1--