On Mon, Jul 06, 2015 at 06:48:18AM +, Evan Hunt wrote:
>
> The remark prefaced with "by convention" doesn't strike me as particularly
> definitive.
I suppose I'd feel better about that if LDH weren't enshrined at least
in operational policies all over the Internet. But I suppose you're
right
On Sun, Jul 05, 2015 at 10:01:55PM -0400, Andrew Sullivan wrote:
> Since the RDATA for a CNAME or DNAME is another point in the tree, the
> above convention would suggest in fact that you _can't_ point to a
> different alias (or else, we'd get a very unusual meaning of the terms
> "parallel" and "s
While not Paul or Stephane, I would like to point out that repeated, empirical
evidence shows that simply dropping or ignoring queries has the
operational effect of link saturation. A quicker, more reliable DDoS vector
may not exist. I could not agree that dropping queries is sensible or
prud
Two message replies in one:
On Sun, Jul 05, 2015 at 05:16:05PM +, Evan Hunt wrote:
> What *does* happen is unclear; maybe nothing. To the best of my
> knowledge, nobody currently uses non-IN namespaces except for strictly
> local authoritative data such as version.bind/CHAOS/TXT. I'm not su
On 05/07/2015 18:16, Evan Hunt wrote:
> On Sun, Jul 05, 2015 at 10:44:40AM -0400, Andrew Sullivan wrote:
>> Imagine the alternative-resolution class FAKE. In the IN class,
>> example.com has a DNAME entry pointing to example.net. What should
>> happen when someone performs a query for QNAME loc
On Sun, Jul 05, 2015 at 10:44:40AM -0400, Andrew Sullivan wrote:
> Imagine the alternative-resolution class FAKE. In the IN class,
> example.com has a DNAME entry pointing to example.net. What should
> happen when someone performs a query for QNAME localentry.example.com,
> TYPE , and CLASS F
On Sun, Jul 05, 2015 at 08:17:03AM +0100, Ray Bellis wrote:
>
> Sure, CNAME is *defined* for all classes, but AFAIK there's no way to "jump"
> out of one class into another using a CNAME.
No, that's correct. But if the point of using a class is to create a
separate namespace, then the fact of cl
On Sun, Jul 05, 2015 at 04:56:21AM -0700,
Steve Crocker wrote
a message of 23 lines which said:
> It would be acceptable to simply dump requests for those names if
> the load is too high.
In that case, resolvers try and try again, which is even worse for the
authoritative name servers. Also,
Stephane and Paul,
I’m ok with anything that provides effective negative feedback. Dropping
queries or redirecting them is ok with me.
Thanks,
Steve
On Jul 5, 2015, at 5:11 AM, P Vixie wrote:
> Delay is expensive for responders since it requires state. Steve's goal of
> making some tld str
Right. Cname does not cross classes.
In original DNS, class was incoherently sometimes an attribute of zone data and
sometimes a namespace selector. In modern DNS it is coherently always the
latter.
On July 5, 2015 8:17:03 AM GMT+01:00, Ray Bellis wrote:
>
>
>On 05/07/2015 01:35, Andrew Sulliv
Delay is expensive for responders since it requires state. Steve's goal of
making some tld strings flaky so as to encourage developers to avoid DNS for
those names could be met statelessly. For example delegate them to localhost.
On July 5, 2015 12:51:08 PM GMT+01:00, Stephane Bortzmeyer
wrote
On Jul 5, 2015, at 4:51 AM, Stephane Bortzmeyer wrote:
> On Sat, Jul 04, 2015 at 09:16:17AM -0700,
> Steve Crocker wrote
> a message of 21 lines which said:
>
>> except for the additional load it places on the root servers,
>
> RFC 7535 could be a solution.
>
>> I propose augmenting the DNS
On Sat, Jul 04, 2015 at 09:16:17AM -0700,
Steve Crocker wrote
a message of 21 lines which said:
> except for the additional load it places on the root servers,
RFC 7535 could be a solution.
> I propose augmenting the DNS to include entries in the root that
> serve the purpose of giving slow
On 05/07/2015 01:35, Andrew Sullivan wrote:
> Classes don't work in the general case, because CNAME (and following
> it, DNAME) is class-independent. This is arguably a bug in the
> protocol, but it's a fact nevertheless. As a result, different
> classes aren't really different namespaces.
A
Avoiding collisions between DNS and non-DNS use of domain names is
probably important to us (to some degree that’s what we’re trying to
decide). But I have thought, and continue to think, that we make a
serious mistake if we regard it as our purpose to “say what strings in
the name space should
On Fri, Jul 03, 2015 at 06:43:13AM -0700, manning wrote:
> Actually, there IS an escape method already defined. We just don’t use it
> much these days.
> It’s called “class”
Classes don't work in the general case, because CNAME (and following
it, DNAME) is class-independent. This is arguably a
On 4 Jul 2015, at 18:29, Suzanne Woolf wrote:
> It seems to me, from long experience of both organizations, that ICANN says
> what names should and shouldn’t be in the DNS root zone—
Well, I have never seen ICANN saying "definite no" to any string. ICANN only
say "no, this string is not to be o
(no hats)
> On Jul 4, 2015, at 3:12 AM, Patrik Fältström wrote:
>
> Once again:
>
> ICANN do say what strings in the name space should be TLDs.
>
> IETF do say what strings in the name space should NOT be TLDs.
In the interests of precision in our discussion: I’m not convinced that’s
actuall
See the end for something provocative.
> ICANN do say what strings in the name space should be TLDs.
>
> IETF do say what strings in the name space should NOT be TLDs.
>
> The rest are just strings waiting to end up in one of the two groups.
>
> Patrik
Perfectly stated. There is really just
On 4 Jul 2015, at 8:31, John Levine wrote:
> I guess my question here is, what would prevent House Finch Feathers OY from
> applying
>> for the DNS(IN) string ONION from ICANN because they want that as a TLD in
>> the IN
>> class?
>
>
> At the moment, nothing.
>
> Remember, we also have a draft
On 4 Jul 2015, at 1:56, manning wrote:
> So I -think- we are on the same page here, although I would replace your use
> of the phrase, “name space” with domain. We have empirical evidence of
> multiple domains using the same name space.
> (Fred Baker persuaded me that there is a single name spa
>I guess my question here is, what would prevent House Finch Feathers OY from
>applying
>for the DNS(IN) string ONION from ICANN because they want that as a TLD in the
>IN
>class?
At the moment, nothing.
Remember, we also have a draft about .HOME and .CORP and .MAIL. ICANN
says they're not p
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 7/3/2015 4:56 PM, manning wrote:
> Borrowing a snippet from the operational community (h/t Chris
> Morrow). If one replaces “subnet” with “domain”…
Indeed -- subnet <--> domain do not map properly in the current landscap
e.
- - ferg
- --
Pau
Borrowing a snippet from the operational community (h/t Chris Morrow).
If one replaces “subnet” with “domain”…
——
this is really a form of: "A subnet should contain all things of a
like purpose/use."
that way you don't have to compromise and say: "Well... tcp/443 is OK
for ABC units but deadly f
On 3 Jul 2015, at 20:11, manning wrote:
> I guess my question here is, what would prevent House Finch Feathers OY from
> applying for the DNS(IN) string ONION from ICANN because they want that as a
> TLD in the IN class?
Nothing, if that is the goal, which I claim it is not.
The goal is to ens
On Fri, Jul 3, 2015 at 2:11 PM, manning wrote:
>
> On 3July2015Friday, at 9:26, Suzanne Woolf wrote:
>
>>
>> It does seem to me that an important feature here is that "TLD" as we're
>> using it is "name in the root zone (or root zone space), to be managed
>> within a context that assumes DNS pr
On 3July2015Friday, at 9:26, Suzanne Woolf wrote:
>
> It does seem to me that an important feature here is that "TLD" as we're
> using it is "name in the root zone (or root zone space), to be managed within
> a context that assumes DNS protocol and semantics as well as DNS-compatible
> name
Hi,
On Jul 3, 2015, at 11:18 AM, Patrik Fältström wrote:
> Unfortunately I think we all in this discussion [again] mix up discussion
> about DNS with the discussion about the name space that is in use for example
> by what we know as "the domain name system rooted at the root zone managed by
On 7/3/15 7:01 AM, Warren Kumari wrote:
> On Fri, Jul 3, 2015 at 9:43 AM, manning wrote:
>> Actually, there IS an escape method already defined. We just don’t use it
>> much these days.
>> It’s called “class”
>>
>> There is no reason these alternate namespaces should sit in the IN class.
>> t
Perhaps. The Domain Name System is just that. A naming system for domains,
one of which is the Internet. Being lazy, and in the absence of significant
development in other
domains (save the CHAOS domain), our community conflates the DNS(IN) as the
entire DNS. Which is false. The DNS, class
e only thing you can
use". P Vixie
From: DNSOP [dnsop-boun...@ietf.org] on behalf of manning [bmann...@karoshi.com]
Sent: Friday, 3 July 2015 15:43
To: Robert Edmonds; Andrew Sullivan
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] Some distinctions and a
Unfortunately I think we all in this discussion [again] mix up discussion about
DNS with the discussion about the name space that is in use for example by what
we know as "the domain name system rooted at the root zone managed by IANA".
I think we just must force ourselves to stay focused on nam
Thanks for that. The original claim was that these name spaces were global in
scope, but not part of the Internet.
So I took that as face value. Your example, while perhaps a valid
interpretation, is not what was asked for.
If it is, then namespace/class specific applications/extentions need to
On Fri, Jul 3, 2015 at 9:43 AM, manning wrote:
> Actually, there IS an escape method already defined. We just don’t use it
> much these days.
> It’s called “class”
>
> There is no reason these alternate namespaces should sit in the IN class.
> they could/should be in their
> own class, like t
Actually, there IS an escape method already defined. We just don’t use it much
these days.
It’s called “class”
There is no reason these alternate namespaces should sit in the IN class. they
could/should be in their
own class, like the old CHAOS protocols. So a class “ONION” or “P2P” would
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Andrew Sullivan wrote:
> On Tue, Jun 30, 2015 at 11:43:42AM +, Edward Lewis wrote:
>> I'm not aware of "the rule" that declares Onion names as part of
>> the domain name space. Not an argument, just a data point. I've
>> always heard, and have
On Tue, Jun 30, 2015 at 04:27:10PM +, Edward Lewis wrote:
>
> So this is about words - what you call a negative registration is a
> registration nonetheless, with an responsible party.
Well, it's about conceptual clarity. If we want to call that
"negative registration" instead "skippy the wo
On 6/30/15, 11:18, "DNSOP on behalf of Andrew Sullivan"
wrote:
>This is a different use of "positively|negatively registered" than I
>outlined. The case that I was talking about I think _does_ have an RP
>for the negaitve registration. But that registration is there to
>prevent delegation. A
On Tue, Jun 30, 2015 at 11:43:42AM +, Edward Lewis wrote:
> You can then divide the list into names that have a responsible party and
> those that don't - and call that (positively registered) and not (or
> negatively) registered.
This is a different use of "positively|negatively registered"
On 6/30/15, 7:48, "DNSOP on behalf of Ray Bellis" wrote:
>So can I, but that's because my computer's name service stub used mDNS
>to find it, not DNS.
Would the same code handle .onion? (Perhaps a new version via RPM push.)
Is relying on software updates scaleable?
This is the flip side of wh
On 30/06/2015 12:43, Edward Lewis wrote:
> Is being an entry a barrier to being used in the DNS? This is
> not clear - I can ssh to a .local machine.
So can I, but that's because my computer's name service stub used mDNS
to find it, not DNS.
Ray
___
On 6/29/15, 13:43, "DNSOP on behalf of Andrew Sullivan"
wrote:
>In my view, the namespace is the logical space of all possible domain
>names.
That certainly narrows the discussion for me.
>In those registries are two kinds of registrations: ones
>that are there to enable further delegation (a "
Hi Ed,
On Thu, Jun 25, 2015 at 12:51:46PM +, Edward Lewis wrote:
> >It seems to me that, for any domain name, there are three things that
> >are relevant:
> >
> >1. The namespace.
> >2. The registry for that name (in the old-fashioned, not ICANN, sense)
> >3. The zone at that name.
>
> I h
On 6/23/15, 13:07, "DNSOP on behalf of Andrew Sullivan"
wrote:
>It seems to me that, for any domain name, there are three things that
>are relevant:
>
>1. The namespace.
>2. The registry for that name (in the old-fashioned, not ICANN, sense)
>3. The zone at that name.
I have to admit that thi
Dear colleagues,
Perhaps it's to do with blood flow to my brain due to my experiences
this week, but I've been contemplating some distinctions that we have
perhaps not made as clearly as we might in respect of RFC 6761. This
message is an attempt to lay those out.
RFC 6761 contains a number of q
45 matches
Mail list logo
