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
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 same).
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.
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
On Sat, Jul 04, 2015 at 09:16:17AM -0700,
Steve Crocker st...@shinkuro.com 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
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 p...@redbarn.org wrote:
Delay is expensive for responders since it requires state. Steve's goal of
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 r...@bellis.me.uk wrote:
On 05/07/2015
On Jul 5, 2015, at 4:51 AM, Stephane Bortzmeyer bortzme...@nic.fr wrote:
On Sat, Jul 04, 2015 at 09:16:17AM -0700,
Steve Crocker st...@shinkuro.com 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
On Sun, Jul 05, 2015 at 04:56:21AM -0700,
Steve Crocker st...@shinkuro.com 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
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
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
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
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 sure
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 space,
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
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 about .HOME
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 one
(no hats)
On Jul 4, 2015, at 3:12 AM, Patrik Fältström p...@frobbit.se 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
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 ok in
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
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
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
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”
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
. 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 request - Have some class?
Actually
On Fri, Jul 3, 2015 at 9:43 AM, manning bmann...@karoshi.com 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
On 7/3/15 7:01 AM, Warren Kumari wrote:
On Fri, Jul 3, 2015 at 9:43 AM, manning bmann...@karoshi.com 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
Hi,
On Jul 3, 2015, at 11:18 AM, Patrik Fältström p...@frobbit.se 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
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
On 3July2015Friday, at 9:26, Suzanne Woolf suzworldw...@gmail.com 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
-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
- --
Paul
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 for
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
On Fri, Jul 3, 2015 at 2:11 PM, manning bmann...@karoshi.com wrote:
On 3July2015Friday, at 9:26, Suzanne Woolf suzworldw...@gmail.com 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
34 matches
Mail list logo
