Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

Mark Andrews <marka@isc.org> Wed, 05 July 2017 23:11 UTC

Return-Path: <marka@isc.org>
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 42A7A126B6E; Wed, 5 Jul 2017 16:11:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 HrM3A69TEmxV; Wed, 5 Jul 2017 16:11:12 -0700 (PDT)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) (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 03662120227; Wed, 5 Jul 2017 16:11:12 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.ams1.isc.org (Postfix) with ESMTPS id 8A3AB24AE15; Wed, 5 Jul 2017 23:11:02 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 3C822160098; Wed, 5 Jul 2017 23:11:06 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 2A6F7160099; Wed, 5 Jul 2017 23:11:06 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ts9GJnjE8INH; Wed, 5 Jul 2017 23:11:06 +0000 (UTC)
Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 7F304160098; Wed, 5 Jul 2017 23:11:05 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id E23E77D9B7A1; Thu, 6 Jul 2017 09:11:01 +1000 (AEST)
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Matthew Kerwin <matthew@kerwin.net.au>, dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
From: Mark Andrews <marka@isc.org>
References: <CAHw9_iJQ31wqLavOhtMpPOBhGP4j6CLk45KHGdX5vOA+qj4nQA@mail.gmail.com> <m2a84kzm4y.wl-randy@psg.com> <F98FEA1C-3F3F-4344-8B07-996AAD899CC2@fugue.com> <m2shicxr0h.wl-randy@psg.com> <A70FD34B-000A-4748-B1B2-BF6DF66C7D6C@fugue.com> <m2podgxq97.wl-randy@psg.com> <5F120298-CD66-4CB6-9DC5-0C5DF6F02CC7@fugue.com> <CACfw2hhx+-Z=7ZnnaOkToc+Bd7aKDpBFt+nFUxkt9sKqLn4D8Q@mail.gmail.com> <2DF1AFC7-643B-4610-8EB8-0616D3D0B024@fugue.com> <20170705000229.5918D7D8457F@rock.dv.isc.org> <CACweHNCAi7JcOW9CX=6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA@mail.gmail.com> <20170705031957.834B97D8FBDD@rock.dv.isc.org> <CACweHNCAmZPOUmat5ruh6qkYrECM2fh15n49P+zDcJ0gfoEGvg@mail.gmail.com> <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com>
In-reply-to: Your message of "Wed, 05 Jul 2017 10:29:18 -0700." <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com>
Date: Thu, 06 Jul 2017 09:11:01 +1000
Message-Id: <20170705231101.E23E77D9B7A1@rock.dv.isc.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/MsryrWdwL-L-ITueYhvexpFXBRU>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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, 05 Jul 2017 23:11:14 -0000

In message <765A15BF-8505-4470-9628-70CE9665BC16@gbiv.com>;, "Roy T. Fielding" writes:
> > On Jul 4, 2017, at 9:23 PM, Matthew Kerwin <matthew@kerwin.net.au>; =
> wrote:
> >=20
> > On 5 July 2017 at 13:19, Mark Andrews <marka@isc.org>; wrote:
> >>=20
> >> In message =
> <CACweHNCAi7JcOW9CX=3D6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA@mail.gmail.com>;, =
> Matthew Kerwin writes:
> >>> On 5 July 2017 at 10:02, Mark Andrews <marka@isc.org>; wrote:
> >>>>=20
> >>>> Who owns a name is a different question to what machines serve the
> >>>> <name,type,class> tuple and how do you reach those machines.  There
> >>>> is absolutely no reason why the zones <name,IN> and <name,CLASS56>
> >>>> need to be served by the same machines.  There is a argument for
> >>>> them both being under control of the same people.
> >>>>=20
> >>>> Mark
> >>>>=20
> >>>=20
> >>> Hi, I'm jumping in at a random time with a possibly dumb question, =
> but
> >>> the talk of <name,type> and <name,type,class> tuples got me =
> wondering
> >>> about representation in general, and URLs in particular.
> >>>=20
> >>> RFCs 3986 and 7230 say[*] that every 'host' in a HTTP URL that looks
> >>> like a DNS name is a DNS name, and that they have to be resolved to =
> IP
> >>> addresses if you want to fetch them, but they don't talk =
> meaningfully
> 
> No, RFC3986 does not say anything of the sort.  Neither does 7230.
> 
> >>> [*] https://tools.ietf.org/html/rfc3986#section-3.2.2 :
> >>>=20
> >>>   """A registered name intended for lookup in the DNS uses the =
> syntax
> >>>   defined in Section 3.5 of [RFC1034] and Section 2.1 of =
> [RFC1123]."""
> >>>=20
> >>> I read that as: "if it matches RFC1034 (and isn't overridden by the
> >>> specific URI scheme's rules) it's a DNS name."  It could be read the
> >>> other way, but that just adds more assumptions.
> 
> Just read the text as written:  "A registered name intended for lookup =
> in DNS ..."
> which doesn't limit much at all, and certainly doesn't say that all =
> dot-notations
> are DNS names.
> 
> The sentence immediately preceding that one is:
> 
>    A host identified by a registered name is a sequence of characters
>    usually intended for lookup within a locally defined host or service
>    name registry, though the URI's scheme-specific semantics may require
>    that a specific registry (or fixed name table) be used instead.
> 
> with both "usually" and "locally defined" being relevant.
> 
> And two paragraphs later it has:
> 
>    This specification does not mandate a particular registered name
>    lookup technology and therefore does not restrict the syntax of reg-
>    name beyond what is necessary for interoperability.  Instead, it
>    delegates the issue of registered name syntax conformance to the
>    operating system of each application performing URI resolution, and
>    that operating system decides what it will allow for the purpose of
>    host identification.  A URI resolution implementation might use DNS,
>    host tables, yellow pages, NetInfo, WINS, or any other system for
>    lookup of registered names.  However, a globally scoped naming
>    system, such as DNS fully qualified domain names, is necessary for
>    URIs intended to have global scope.  URI producers should use names
>    that conform to the DNS syntax, even when use of DNS is not
>    immediately apparent, and should limit these names to no more than
>    255 characters in length.
> 
> And that's exactly how it works, in practice.
> 
> ....Roy

And the actual presentation limit for LDH with DNS is 253 (encodes
as 255 octets on the wire).  Remember URI names do not have a final
period and the each label has length octet when encoded as a DNS
name and the name is terminated by the root label (0x00) in DNS
wire form and the DNS wire name is limited to 255 octets.

The name "a" is 0x01 0x61 0x00 on the wire when encoded in the DNS.
The name "a.b" is 0x01 0x61 0x01 0x62 0x00 on the wire when encoded
in the DNS.

An arbitary DNS name may be up to 1004 ascii characters when converted
to presentation format.  0x00 has a presentation format of "\000"
and this may occur up to 250 times as the maximum label length is
63.  Add in seperating periods (3) and a final period the becomes
1004 in absolute form.  As a C NUL terminated string you need a
buffer of 1005 bytes to hold it.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org