In message <765A15BF-8505-4470-9628-70CE9665BC16(_at_)gbiv(_dot_)com>, "Roy T.
Fielding" writes:
On Jul 4, 2017, at 9:23 PM, Matthew Kerwin
<matthew(_at_)kerwin(_dot_)net(_dot_)au> =
wrote:
=20
On 5 July 2017 at 13:19, Mark Andrews <marka(_at_)isc(_dot_)org> wrote:
=20
In message =
<CACweHNCAi7JcOW9CX=3D6FViv1wUoe5fhn7deJ2eieP2-D_FhaSA(_at_)mail(_dot_)gmail(_dot_)com>,
=
Matthew Kerwin writes:
On 5 July 2017 at 10:02, Mark Andrews <marka(_at_)isc(_dot_)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(_at_)isc(_dot_)org