On Tue, Feb 07, 2017 at 10:01:23AM -0500, Bob Harold wrote:
> What I envision for the future is an insecure delegation of .alt, and an
> option in future cable modems to enable a local "homenet.alt" domain, which
> would just work, even if some stub resolvers in the house are validating.
> The cabl
On Wed, Feb 08, 2017 at 12:36:23PM -0800, Brian Dickson wrote:
> So, while technically the instruction (SHOULD NOT) applies to full .onion
> names,
> it is a SHOULD NOT, not a MUST NOT.
Note also that the original request was that it be a MUST NOT, and
some of us tried to explain that RFCs do not
On Fri, Feb 10, 2017 at 12:57:25PM +1100,
Mark Andrews wrote
a message of 29 lines which said:
> Even with everything working properly QNAME minimisation DOES NOT
> STOP THE QUERIES.
>
> RFC 4035 + RFC 7816 -> leaks (synthesis of negative answers is banned by RFC
> 4035)
RFC 4035 (if more s
On Thu, Feb 09, 2017 at 04:40:23PM -0800,
Brian Dickson wrote
a message of 78 lines which said:
> If you really care about privacy, IMHO, the place to instantiate the
> private namespace, is under one of the heavily used AS112 zones.
[...]
> even if a leak
> occurs, it will be hiding among the
On Fri, Feb 10, 2017 at 11:48:01AM +1100,
Mark Andrews wrote
a message of 36 lines which said:
> No, it will ask for foo.alt because:
This is false (and Ted Lemon was correct in describing QNAME
minimisation). Here, with a recent Unbound, when I ping foo.alt, I see only:
09:05:55.233366 IP6
On Fri, Feb 10, 2017 at 09:48:51AM +1100,
Mark Andrews wrote
a message of 43 lines which said:
> and has agressive negative caching (so the answer from the minimised
> QNAME query get turned into a answer for *.alt).
As I already said here, if by "agressive negative caching", you mean
draft-i
On Fri, Feb 10, 2017 at 06:57:22AM +1100,
Mark Andrews wrote
a message of 40 lines which said:
> Only if you are willing to break lookups for names where there are
> missing delegations in parent zone and the parent and child zones
> share the same nameservers or the nameserver just misimpleme
Could your concern be addressed with secure denial of existence plus the
right text about how to configure recursive resolvers?
On Feb 10, 2017 1:02 AM, "Mark Andrews" wrote:
>
> In message , Ted Lemon
> writes
> :
> >
> > On Feb 9, 2017, at 8:57 PM, Mark Andrews wrote:
> > > I'm developing sof
In message , Ted Lemon writes
:
>
> On Feb 9, 2017, at 8:57 PM, Mark Andrews wrote:
> > I'm developing software that will be run on private internets with
> > various degrees of compentence from the adminitrators as well as
> > the public Internet. That private internet may have a ENT for ALT
>
On Feb 9, 2017, at 8:57 PM, Mark Andrews wrote:
> I'm developing software that will be run on private internets with
> various degrees of compentence from the adminitrators as well as
> the public Internet. That private internet may have a ENT for ALT
> that returns NXDOMAIN. The server has to w
In message <20170210015725.bf777636c...@rock.dv.isc.org>, Mark Andrews writes:
>
> In message <653a3403-dfc8-491a-b083-7873d1886...@fugue.com>, Ted Lemon writes:
> >
> > On Feb 9, 2017, at 7:48 PM, Mark Andrews wrote:
> > > 1) there is too much brokeness out there that returns NXDOMAIN instead
>
In message <653a3403-dfc8-491a-b083-7873d1886...@fugue.com>, Ted Lemon writes:
>
> On Feb 9, 2017, at 7:48 PM, Mark Andrews wrote:
> > 1) there is too much brokeness out there that returns NXDOMAIN instead
> > of a NODATA for a ENT.
>
> So you're saying that a root nameserver is going to return
On Feb 9, 2017, at 7:48 PM, Mark Andrews wrote:
> 1) there is too much brokeness out there that returns NXDOMAIN instead of
> a NODATA for a ENT.
So you're saying that a root nameserver is going to return an incorrect result?
And what does this have to do with intelligent trees?_
In message , Ted Lemon writes:
>
> On Feb 9, 2017, at 6:28 PM, Mark Andrews wrote:
> > Because QNAME minimization does not stop on NXDOMAIN. Too much
> > broken stuff out there to stop on NXDOMAIN. The purpose of QNAME
> > minimization is prevent leaking too much information about the qname
> >
On Thu, Feb 9, 2017 at 3:47 PM, Mark Andrews wrote:
>
> In message 54s...@mail.gmail.com>
> , Brian Dickson writes:
>
> > Are you saying that leakage when the local namespace is non-existent, is
> > a/the issue?
>
> Because when TPB go on a witch hunt for all users of .alt we
> don't want th
On Feb 9, 2017, at 6:28 PM, Mark Andrews wrote:
> Because QNAME minimization does not stop on NXDOMAIN. Too much
> broken stuff out there to stop on NXDOMAIN. The purpose of QNAME
> minimization is prevent leaking too much information about the qname
> to the parent zone. It does nothing to pre
In message
, Brian Dickson writes:
>
> On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews wrote:
>
> >
> > In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon
> > writes:
> > >
> > > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote:
> > > > At the moment we have Ted saying that if
In message
, Ted Lemon writes:
> How does a query for, e.g., super-s3kr1t.alt leak if your caching resolver
> is doing qname minimization?
Because QNAME minimization does not stop on NXDOMAIN. Too much
broken stuff out there to stop on NXDOMAIN. The purpose of QNAME
minimization is prevent lea
On Thu, Feb 9, 2017 at 2:48 PM, Mark Andrews wrote:
>
> In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon
> writes:
> >
> > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote:
> > > At the moment we have Ted saying that if you want privacy you MUST
> > > also turn on DNSSEC vali
How does a query for, e.g., super-s3kr1t.alt leak if your caching resolver
is doing qname minimization?
On Thu, Feb 9, 2017 at 5:48 PM, Mark Andrews wrote:
>
> In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon
> writes:
> >
> > On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote
In message <12d7473b-3a22-4a8d-9c13-2aeedeabb...@fugue.com>, Ted Lemon writes:
>
> On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote:
> > At the moment we have Ted saying that if you want privacy you MUST
> > also turn on DNSSEC validation and implement QNAME minimisation and
> > implement agressive
On Feb 9, 2017, at 3:45 PM, Mark Andrews wrote:
> At the moment we have Ted saying that if you want privacy you MUST
> also turn on DNSSEC validation and implement QNAME minimisation and
> implement agressive negative caching (still a I-D).
No, I am _not_ saying that. I am saying that an unsign
In message <0394528c-99cd-41d4-9ab6-844d13182...@gmail.com>, Brian Dickson writ
es:
> Maybe DNS authority server software could auto-generate TXT records for what=
> would otherwise be ENTs, or zone administrators could add them manually,
>
> E.g. ent.example.com TXT "This object intentionally l
Maybe DNS authority server software could auto-generate TXT records for what
would otherwise be ENTs, or zone administrators could add them manually,
E.g. ent.example.com TXT "This object intentionally left blank."
This avoids the ENT issue.
I can't think of any way that would break anything. T
In message <20170209163123.56hdbzaluekmv...@nic.fr>, Stephane Bortzmeyer writes
:
> On Wed, Feb 08, 2017 at 12:36:23PM -0800,
> Brian Dickson wrote
> a message of 258 lines which said:
>
> > - upon startup, do a query for "onion" (the non-existent TLD), with DO=1.
> > - cache the response, an
On Wed, Feb 08, 2017 at 12:36:23PM -0800,
Brian Dickson wrote
a message of 258 lines which said:
> - upon startup, do a query for "onion" (the non-existent TLD), with DO=1.
> - cache the response, and as appropriate, re-query periodically.
> - If a query for .onion is received, reply with the
On Thu, Feb 09, 2017 at 09:41:31AM +1100,
Mark Andrews wrote
a message of 38 lines which said:
> And only because people are too scared to ask for changes to the
> root zone to add a delegation.
Being afraid to ask ICANN to do something is not cowardice, it is
common sense :-)
__
> On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews wrote:
>
> In message , Ted Lemon writes:
> >
> > On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote:
> > > And if the service has the same privacy issues as .onion has?
> > >
> > > So we leak names until every recursive server in the world is
> > > vali
On Wed, Feb 8, 2017 at 2:41 PM, Mark Andrews wrote:
>
> In message , Ted Lemon
> writes:
> >
> > On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote:
> > > And if the service has the same privacy issues as .onion has?
> > >
> > > So we leak names until every recursive server in the world is
> > > val
In message , Ted Lemon writes:
>
> On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote:
> > And if the service has the same privacy issues as .onion has?
> >
> > So we leak names until every recursive server in the world is
> > validating (what % is that today?) and supports agressive negative
> > cac
On Feb 8, 2017, at 3:30 PM, Mark Andrews wrote:
> And if the service has the same privacy issues as .onion has?
>
> So we leak names until every recursive server in the world is
> validating (what % is that today?) and supports agressive negative
> caching (still a I-D).
I feel like I am arguing
On Wed, Feb 8, 2017 at 11:42 AM, Mark Andrews wrote:
>
> In message , Ted Lemon
> writes:
> >
> > On Feb 8, 2017, at 1:02 AM, Mark Andrews wrote:
> > > Which assumes agggressive negative caching. I'm going to make a
> > > realistic assumption that it will take 10+ years for there to be
> > > m
In message <00767076-fa43-42c0-a4af-39f4e1087...@fugue.com>, Ted Lemon writes:
> charset=us-ascii
>
> On Feb 8, 2017, at 2:42 PM, Mark Andrews wrote:
> > 4. Caching DNS servers SHOULD recognize these names as special and
> > SHOULD NOT, by default, attempt to look up NS records fo
On Feb 8, 2017, at 2:42 PM, Mark Andrews wrote:
> 4. Caching DNS servers SHOULD recognize these names as special and
> SHOULD NOT, by default, attempt to look up NS records for them,
> or otherwise query authoritative DNS servers in an attempt to
> resolve these names. Instea
In message , Ted Lemon writes:
>
> On Feb 8, 2017, at 1:02 AM, Mark Andrews wrote:
> > Which assumes agggressive negative caching. I'm going to make a
> > realistic assumption that it will take 10+ years for there to be
> > meaningful (>50%) deployment of aggressive negative caching.
>
> First
On Wed, Feb 08, 2017 at 09:53:07AM -0500,
Ted Lemon wrote
a message of 37 lines which said:
> > Why are they different, by the way?
>
> There is more than one way to handle a special-use name.
Yes, but "serve it locally" is just one way, and it has its own
registry, which is not the case wit
On Feb 8, 2017, at 1:02 AM, Mark Andrews wrote:
> Which assumes agggressive negative caching. I'm going to make a
> realistic assumption that it will take 10+ years for there to be
> meaningful (>50%) deployment of aggressive negative caching.
First of all, this probably isn't true, since most
On Feb 8, 2017, at 3:43 AM, Stephane Bortzmeyer wrote:
> Why are they different, by the way?
There is more than one way to handle a special-use name. That's why we're
debating which way to handle .alt, after all! :)
___
DNSOP mailing list
DNSOP@ie
On Wed, Feb 08, 2017 at 11:26:28AM +,
Tony Finch wrote
a message of 23 lines which said:
> For RFC 8020 to suppress these .alt leaked queries properly, you
> also need qname minimization.
Yes, but anyone uses RFC 7816, anyway :-)
___
DNSOP mail
Stephane Bortzmeyer wrote:
> Mark Andrews wrote:
> > Ted Lemon wrote:
> > >
> > > If it has proof of non-existence for .alt cached, it doesn't need
> > > to ask any further questions to deny the existence of any
> > > subdomain of .alt.
> >
> > Which assumes agggressive negative caching.
>
> If
On Mon, Feb 06, 2017 at 04:55:19PM +,
Tony Finch wrote
a message of 36 lines which said:
> > Yes, that's right, with the caveat that all existing locally
> > served zones are in the reverse space - there's no forward zones
> > registered (yet).
>
> There are several :-) RFC 6761 specifies
On Mon, Feb 06, 2017 at 06:12:31PM +,
Ray Bellis wrote
a message of 28 lines which said:
> The "locally served zones" and "special use domains" registries are
> different.
Why are they different, by the way? I really do not understand
that. The "locally served zones" registry should be a
On Wed, Feb 08, 2017 at 05:02:08PM +1100,
Mark Andrews wrote
a message of 30 lines which said:
> > If it has proof of non-existence for .alt cached, it doesn't need
> > to ask any further questions to deny the existence of any
> > subdomain of .alt.
>
> Which assumes agggressive negative cach
In message , Ted Lemon writes:
>
> On Feb 8, 2017, at 12:25 AM, Mark Andrews wrote:
> > And how does the server get the proof of non-existence? It needs
> > to leak a query.
>
> If it has proof of non-existence for .alt cached, it doesn't need to ask
> any further questions to deny the existence
On Feb 8, 2017, at 12:25 AM, Mark Andrews wrote:
> And how does the server get the proof of non-existence? It needs
> to leak a query.
If it has proof of non-existence for .alt cached, it doesn't need to ask any
further questions to deny the existence of any subdomain of .alt. Leaking a
quer
In message , Ted Lemon writes:
>
> On Feb 7, 2017, at 4:48 PM, Mark Andrews wrote:
> > Go add a empty zone (SOA and NS records only) for alt to your
> > recursive server. This is what needs to be done to prevent
> > privacy leaks.
>
> No, the recursive server can just cache the proof of nonexist
On Feb 7, 2017, at 4:48 PM, Mark Andrews wrote:
> Go add a empty zone (SOA and NS records only) for alt to your
> recursive server. This is what needs to be done to prevent
> privacy leaks.
No, the recursive server can just cache the proof of nonexistence. I didn't
query the root when I did m
In message
, Brian Dickson writes:
> --001a1140fee44d9e500547f98cf1
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews wrote:
>
> >
> > In message > mail.gmail.com>
> > , Brian Dickson writes:
> > > --f403045fbba86cf7240547f82103
> > > Content-Type: tex
On Tue, Feb 7, 2017 at 3:44 PM, Mark Andrews wrote:
>
> In message mail.gmail.com>
> , Brian Dickson writes:
> > --f403045fbba86cf7240547f82103
> > Content-Type: text/plain; charset=UTF-8
> >
> > On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote:
> >
> > >
> > > In message <18f2eb0d-5bd0-4cc5-
In message
, Brian Dickson writes:
> --f403045fbba86cf7240547f82103
> Content-Type: text/plain; charset=UTF-8
>
> On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote:
>
> >
> > In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon
> > writes:
> > > Hm. When I look for foo.alt
In message
, Brian Dickson writes:
> On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote:
>
> >
> > In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon
> > writes:
> > > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL.
> > > When I validate, I get a secure
On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote:
>
> In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon
> writes:
> > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL.
> > When I validate, I get a secure denial of existence. This is the
> > correct beha
On Tue, Feb 7, 2017 at 1:48 PM, Mark Andrews wrote:
>
> In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon
> writes:
> > Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL.
> > When I validate, I get a secure denial of existence. This is the
> > correct beha
In message <18f2eb0d-5bd0-4cc5-b02c-2e5ea0b8c...@fugue.com>, Ted Lemon writes:
> Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL.
> When I validate, I get a secure denial of existence. This is the
> correct behavior. Why do you think we would get a SERVFAIL?
Because your t
Hm. When I look for foo.alt, what I get is NXDOMAIN, not SERVFAIL. When I
validate, I get a secure denial of existence. This is the correct behavior.
Why do you think we would get a SERVFAIL?
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ie
In message <5ca637ee-c0b6-4e5c-a446-a84431176...@fugue.com>, Ted Lemon writes:
>
> On Feb 7, 2017, at 11:45 AM, Warren Kumari wrote:
> > I don't think I've seen a good argument for NOT doing the above -- why
> > (other thabn the sunk time / effort) don't we do two?
>
> Right, this just seems obvi
On Feb 7, 2017, at 1:49 PM, John Levine wrote:
> I really doubt that if we bless both .alt and .lcl (or whatever) that
> the people building stuff will use the one we want them to use.
Then it won't work for them. But fashionable though this sort of cynicism is,
clear specifications do get rea
>I don't think I've seen a good argument for NOT doing the above -- why
>(other thabn the sunk time / effort) don't we do two?
I checked with the protocol police who told me that even with their
tasers set to maximum, they can't force people to use the right one.
I really doubt that if we bless bo
On Feb 7, 2017, at 11:45 AM, Warren Kumari wrote:
> I don't think I've seen a good argument for NOT doing the above -- why
> (other thabn the sunk time / effort) don't we do two?
Right, this just seems obvious to me. If we do two, we can tailor each
solution to the need it is intended to fill,
Yay! Centithread!
On Tue, Feb 7, 2017 at 8:06 AM, Ted Lemon wrote:
> On Feb 7, 2017, at 12:50 AM, Brian Dickson
> wrote:
>
> I don't think the use cases for most of the sandbox involving alt, and/or
> the homenet use case, requires support for validating stubs.
>
>
> If .alt is being used for
On Mon, Feb 6, 2017 at 10:37 PM, Brian Dickson <
brian.peter.dick...@gmail.com> wrote:
> TL;DR: it is possible to have a signed DNAME in the root for alt (to
> empty.as112.arpa), AND have a local signed alt. Things under this local alt
> can be signed or unsigned.
>
> On Fri, Feb 3, 2017 at 1:09 P
On Feb 7, 2017, at 12:50 AM, Brian Dickson
wrote:
> I don't think the use cases for most of the sandbox involving alt, and/or the
> homenet use case, requires support for validating stubs.
If .alt is being used for non-DNS names, you are correct, because non-DNS names
cannot be validated, and
Brian Dickson wrote:
>
> Does the existence of query rewriting matter, as long as the end result
> RDATA is the expected value?
> I.e. If the query is "my-thing.foo.alt", returns a combo of "alt DNAME
> empty.as112.arpa" plus "my-thing.foo.empty.as112.arpa ",
> is that acceptable, as long as ther
On Mon, Feb 6, 2017 at 11:27 PM, Mark Andrews wrote:
>
> In message <99431a77-7b62-4655-89ef-faa32f2a8...@gmail.com>, Brian
> Dickson writes:
> > The suggestion of DNAME to empty.as112.arpa involves some subtle details,
> > which IMHO may in combination be the right mix here.
> >
> > The DNAME ta
In message <99431a77-7b62-4655-89ef-faa32f2a8...@gmail.com>, Brian Dickson
writes:
> The suggestion of DNAME to empty.as112.arpa involves some subtle details,
> which IMHO may in combination be the right mix here.
>
> The DNAME target is an insecure empty zone.
>
> This avoids the validation issu
The suggestion of DNAME to empty.as112.arpa involves some subtle details, which
IMHO may in combination be the right mix here.
The DNAME target is an insecure empty zone.
This avoids the validation issue, and facilitates use of local "alt" namespaces.
The default response to queries under alt w
In message <3581be55-b178-4298-8ee8-73fd16b42...@gmail.com>, Brian Dickson
writes:
> Mark,
>
> I don't think the use cases for most of the sandbox involving alt, and/or
> the homenet use case, requires support for validating stubs. If stubs
> aren't already validating, the incremental addition
Mark,
I don't think the use cases for most of the sandbox involving alt, and/or the
homenet use case, requires support for validating stubs. If stubs aren't
already validating, the incremental addition of a local alt, only requires
distribution of the trust anchor to the resolvers. That is a so
In message
, Brian
Dickson writes:
>
> TL;DR: it is possible to have a signed DNAME in the root for alt (to
> empty.as112.arpa), AND have a local signed alt. Things under this local alt
> can be signed or unsigned.
So now there is the problem of distributing trust anchors for the
locally signe
> On 06/02/2017 16:55, Tony Finch wrote:
> > Ray Bellis wrote:
> >>
> >> Yes, that's right, with the caveat that all existing locally served
> >> zones are in the reverse space - there's no forward zones registered (yet).
> >
> > There are several :-) RFC 6761 specifies localhost, invalid, test as
TL;DR: it is possible to have a signed DNAME in the root for alt (to
empty.as112.arpa), AND have a local signed alt. Things under this local alt
can be signed or unsigned.
On Fri, Feb 3, 2017 at 1:09 PM, Mark Andrews wrote:
>
> In message mail.gmail.com>
> , Brian Dickson writes:
> >
> >- I
In message <203e2636-1391-4100-9b1a-4f2dcc9a3...@gmail.com>, Ralph Droms writes:
>
> > On Feb 3, 2017, at 9:10 PM, Andrew Sullivan wrote:
> >
> > On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote:
> >> Mark, I don't think you've actually given an answer to my question.
> >> I understoo
> On Feb 3, 2017, at 9:10 PM, Andrew Sullivan wrote:
>
> On Fri, Feb 03, 2017 at 07:59:24PM -0500, Ted Lemon wrote:
>> Mark, I don't think you've actually given an answer to my question.
>> I understood that .ALT was for alternative naming systems, not for
>> DNS locally-served zones. We simpl
On 06/02/2017 16:55, Tony Finch wrote:
> Ray Bellis wrote:
>>
>> Yes, that's right, with the caveat that all existing locally served
>> zones are in the reverse space - there's no forward zones registered (yet).
>
> There are several :-) RFC 6761 specifies localhost, invalid, test as
> locally
In article you write:
>> Yes, that's right, with the caveat that all existing locally served
>> zones are in the reverse space - there's no forward zones registered (yet).
>
>Could you clarify why that�s relevant?
Perhaps because the management rules follow more or less mechanically
from the mana
Ray Bellis wrote:
>
> Yes, that's right, with the caveat that all existing locally served
> zones are in the reverse space - there's no forward zones registered (yet).
There are several :-) RFC 6761 specifies localhost, invalid, test as
locally served zones. RFC 6762 specifies local. RFC 7686 spe
On 06/02/2017 16:18, Suzanne Woolf wrote:
>> Yes, that's right, with the caveat that all existing locally
>> served zones are in the reverse space - there's no forward zones
>> registered (yet).
>
> Could you clarify why that’s relevant?
>
> Does it just come down to the assumption that revers
> On Feb 6, 2017, at 11:15 AM, Ray Bellis wrote:
>
>> For now, let’s keep it relevant to the decision this WG has to make,
>> about what to do with .alt and whether it’s important to us to
>> accommodate cases like .homenet. So far, it seems that the .homenet case
>> is much like “locally-served
Hi,
Before this goes any further, I’m not sure an incomplete rehashing of the
consensus in another WG is a good use of our time.
For now, let’s keep it relevant to the decision this WG has to make, about what
to do with .alt and whether it’s important to us to accommodate cases like
.homenet.
On 06/02/2017 16:12, Suzanne Woolf wrote:
> Hi,
>
> Before this goes any further, I’m not sure an incomplete rehashing of
> the consensus in another WG is a good use of our time.
+1 :)
> For now, let’s keep it relevant to the decision this WG has to make,
> about what to do with .alt and wheth
On Feb 6, 2017, at 10:57 AM, Ólafur Gudmundsson wrote:
> A WG can come to a consensus on a topic without all information available.
> Now go back and see if reality changes consensus.
I presented a detailed explanation of the tradeoffs, which the working group
considered. If you think somethin
On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson wrote:
> What RFC are you referring to?
I wasn't referring to an RFC—I was referring to the homenet naming architecture
document that we've been working on.
> Why do you think .ARPA is for services?
> It's for infrastructure and homenet wants to j
Ralph,
A WG can come to a consensus on a topic without all information available.
Now go back and see if reality changes consensus.
Just my .02 cents.
Ólafur
On February 6, 2017 9:52:53 AM CST, Ralph Droms wrote:
>
>
>> On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson
>wrote:
>>
>> Ted,
>>
On 06/02/2017 15:29, Ólafur Gudmundsson wrote:
> Ted,
>
> What RFC are you referring to?
>
> Why do you think .ARPA is for services?
> It's for infrastructure and homenet wants to join the infrastructure.
>
> It is waste of time arguing if name A or B is better take the one you
> can get faste
> On Feb 6, 2017, at 10:29 AM, Ólafur Gudmundsson wrote:
>
> Ted,
>
> What RFC are you referring to?
>
> Why do you think .ARPA is for services?
> It's for infrastructure and homenet wants to join the infrastructure.
>
> It is waste of time arguing if name A or B is better take the one you c
> On 6 Feb 2017, at 15:29, Ólafur Gudmundsson wrote:
>
> It is waste of time arguing if name A or B is better take the one you can get
> faster.
+100
Says he wishing the arguments over A or B (for some definition of both) would
just go away and never return.
Ted,
What RFC are you referring to?
Why do you think .ARPA is for services?
It's for infrastructure and homenet wants to join the infrastructure.
It is waste of time arguing if name A or B is better take the one you can get
faster.
Ólafur
On February 5, 2017 10:22:35 PM CST, Ted Lemon wrote
The working group has consensus to give it a try. We may change our minds
of it takes too long, but it seems worth exploring from a process
perspective anyway.
On Feb 5, 2017 11:18 PM, "John R Levine" wrote:
> I'm pretty sure I've explained it enough times on this mailing list and in
>> the rel
I'm pretty sure I've explained it enough times on this mailing list and in
the relevant documents by now. If you don't agree, maybe we should just
accept that. If you don't remember the explanation, it's in the homenet
naming architecture doc I wrote.
Well, OK, I took another look, and from what
I'm pretty sure I've explained it enough times on this mailing list and in
the relevant documents by now. If you don't agree, maybe we should just
accept that. If you don't remember the explanation, it's in the homenet
naming architecture doc I wrote.
On Feb 5, 2017 11:05 PM, "John Levine" wrote:
In article <6391b5bb-19bd-4717-b9bb-ecd145f7b...@fugue.com> you write:
>On Feb 5, 2017, at 9:51 PM, Olafur Gudmundsson wrote:
>> What is wrong with homenet.arpa ?
>
>homenet.arpa sounds like a service out there on the arpanet somewhere, not
>something local.
Why would that be important? It's m
On Feb 5, 2017, at 9:51 PM, Olafur Gudmundsson wrote:
> What is wrong with homenet.arpa ?
homenet.arpa sounds like a service out there on the arpanet somewhere, not
something local.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/l
> On Feb 4, 2017, at 4:46 AM, Ray Bellis wrote:
>
>
>
> On 04/02/2017 02:13, Andrew Sullivan wrote:
>> Right, that's always been the problem with using this _for the DNS_.
>> Homenet has no choice in that, because the whole point of the homenet
>> name is precisely to enable in-homenet DNS wit
On Sun, Feb 05, 2017 at 12:26:08AM +1100, Mark Andrews wrote:
>
> Given there are no rules for this type of namespace
Which "type of namespace" do you mean?
I think there are three possible namespaces you're talking about:
1. Domain names. There are rules for these, though they're
pos
On Sun, Feb 05, 2017 at 10:16:20AM -0500, Warren Kumari wrote:
> [0]
> Reservation of .internal as a Special Use
> Name. ...
>
> This document reserves the string "internal" for use as an internal
> DNS
>
> [ Ed note: Text inside square brackets ([]) is additional backg
On Fri, Feb 3, 2017 at 9:40 PM, Ted Lemon wrote:
> On Feb 3, 2017, at 9:10 PM, Andrew Sullivan wrote:
>
> My memory is that only after that
> did we start thinking of a sort of 1918-style part of the DNS as
> well. That may have been a mistake, since as this discussion is
> showing the propertie
DNAME was considered early in the IDN evaluations, so it's not exactly
unknown in the Icann community
On Fri, Feb 3, 2017 at 15:33 Steve Crocker wrote:
> We (ICANN) have no mechanism or process for inserting a DNAME record into
> the root. We do have a process for considering the general issue
> On Feb 4, 2017, at 4:46 AM, Ray Bellis wrote:
>
>
>
> On 04/02/2017 02:13, Andrew Sullivan wrote:
>> Right, that's always been the problem with using this _for the DNS_.
>> Homenet has no choice in that, because the whole point of the homenet
>> name is precisely to enable in-homenet DNS wit
In message <9920bdf2-e676-4262-9226-46652896e...@fugue.com>, Ted Lemon writes:
>
> On Feb 4, 2017, at 8:29 AM, Mark Andrews wrote:
> >
> > It's a problem for ALL special names. BOGUS / SERVFAIL isn't the
> > response leaked names should get. Its bad engineering.
>
> What is the response leaked
On Feb 4, 2017, at 8:29 AM, Mark Andrews wrote:
>
> It's a problem for ALL special names. BOGUS / SERVFAIL isn't the
> response leaked names should get. Its bad engineering.
What is the response leaked names should get, and why is that the correct
response? Why is SERVFAIL not the correct r
1 - 100 of 148 matches
Mail list logo
