Been trying to figure out where to insert this.
https://tools.ietf.org/html/draft-sullivan-dns-class-useless-03
Abstract
Domain Name System Resource Records are identified in part by their
class. The class field is not effective, and it is not used the way
it appears to have been intended. This memo suspends additions to
the DNS class registry pending greater clarity on how classes might
be used, and until such clarification requires those defining new
RRTYPEs to define them for all classes.
Answer wrote a draft about this a few months / years ago.
W
On Tue, Jul 4, 2017 at 10:36 PM, william manning
<chinese(_dot_)apricot(_at_)gmail(_dot_)com> wrote:
Most of the other application (besides dns) presume a single class, IN,
hence the URL presumption of "DNS name" will -always- be in the IN class.
Technically imprecise and sloppy, but pragmatically it works... until some
loons come along and do something creative with classes. Then all bets are
off.
RFC 1034 also uses IN in its examples and most folks forget inheritence
rules.
/Wm
On Tue, Jul 4, 2017 at 7:23 PM, Matthew Kerwin
<matthew(_at_)kerwin(_dot_)net(_dot_)au>
wrote:
On 5 July 2017 at 10:02, Mark Andrews <marka(_at_)isc(_dot_)org> wrote:
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.
Mark
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.
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
about how to do that resolution. Given that we always assume class=IN
(not to mention type=A|AAAA via happy eyeballs), how would we go about
practically presenting an alternative class in things like URLs?
(Registering a new "alt-http" URL scheme doesn't strike me as a great
idea.)
Because it's all well and good setting up your own .org hierarchy
under class=FOO or whatever, but there's not much point if you can't
send people to www.not-icann.org using it. Unless you don't want to
expose your new hierarchy to the web ...?
Cheers
[*] https://tools.ietf.org/html/rfc3986#section-3.2.2 :
"""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]."""
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.
--
Matthew Kerwin
http://matthew.kerwin.net.au/
_______________________________________________
DNSOP mailing list
DNSOP(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/dnsop
--
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
---maf