Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
On 4 Nov 2020, at 17:47, Wes Hardaker wrote: "Andrew McConachie" writes: 1. Is a special-use domain per [RFC6761], and does not (and will never) exist in the GID. In this document, we refer to this as ".internal" for discussion purposes only following conventions in [draft-wkumari-dnsop-internal]. I read the above text as telling me that .internal will never exist in the GID. Ahh... thanks for the precise reference. Yes, those two bullets are backwards in their examples. Ugh. .internal and .zz should be switched there. (fixed in the source) Thanks Wes. That makes sense. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
"Andrew McConachie" writes: > 1. Is a special-use domain per [RFC6761], and does not (and will never) > exist in the GID. > In this document, we refer to this as ".internal" for discussion purposes > only following > conventions in [draft-wkumari-dnsop-internal]. > > I read the above text as telling me that .internal will never exist in > the GID. Ahh... thanks for the precise reference. Yes, those two bullets are backwards in their examples. Ugh. .internal and .zz should be switched there. (fixed in the source) -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
On 4 Nov 2020, at 2:11, Wes Hardaker wrote:
"Andrew McConachie" writes:
I’m having a hard time understanding the two proposed deployments
in
this document.
It's not as clean as I'd like, certainly. I was pushing up against
the
draft submission deadlines and didn't get all the wording into place.
In 2.2.1 it states that .internal does not exist in the GID. Yet in
the Summary section immediately after it states that .internal is an
unsigned TLD. Which is it?
.internal is an unsigned TLD and is the GID.
1. Is a special-use domain per [RFC6761], and does not (and will
never) exist in the GID. In this document, we refer to this as
".internal" for discussion purposes only following conventions
in
[draft-wkumari-dnsop-internal].
I read the above text as telling me that .internal will never exist in
the GID.
I don't see where in 2.2.1 it says that though.
In 2.2.2 it states that .zz is an unsigned delegation in the GID’s
DNS
root. Yet in the summary section it states that “.zz is a
special-use-like TLD that MUST never be assigned”. Which is it?
The later. .zz is not delegated. Again I'm not sure which sentence
you're referring to though.
2. Is an unsigned delegation within the (GID's) DNS root, with NS
records likely pointing eventually to something like
127.0.53.53.
In this document, we refer to this as ".zz" following convention
in [draft-ietf-dnsop-private-use-tld]. We note that
[draft-ietf-
dnsop-alt-tld] also proposed a private namespace (".alt") that
also fits into this category.
This seems to be saying that .zz is an unsigned delegation. Am I missing
something obvious here?
[someone did note that one of my section names is incorrect as well
and
referred to the wrong one]
My understanding of an unsigned TLD is that it is delegated in the
root zone unsigned. And I take it that GID is simply a synonym for
what many call The Public DNS.
Yep. It's "Global Internet's DNS (GID)", per the document.
There are, unfortunately, more than one naming environments. We've
known this for years with even /etc/hosts being different from the
DNS,
and NIS coming along later, etc. Nowdays, there are so many
split-systems with both internal and externally differing naming sets
I
was trying to use something that included the world "global" to be
super-clear this is the "big one".
--
Wes Hardaker
USC/ISI
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
"Andrew McConachie" writes: > I’m having a hard time understanding the two proposed deployments in > this document. It's not as clean as I'd like, certainly. I was pushing up against the draft submission deadlines and didn't get all the wording into place. > In 2.2.1 it states that .internal does not exist in the GID. Yet in > the Summary section immediately after it states that .internal is an > unsigned TLD. Which is it? .internal is an unsigned TLD and is the GID. I don't see where in 2.2.1 it says that though. > In 2.2.2 it states that .zz is an unsigned delegation in the GID’s DNS > root. Yet in the summary section it states that “.zz is a > special-use-like TLD that MUST never be assigned”. Which is it? The later. .zz is not delegated. Again I'm not sure which sentence you're referring to though. [someone did note that one of my section names is incorrect as well and referred to the wrong one] > My understanding of an unsigned TLD is that it is delegated in the > root zone unsigned. And I take it that GID is simply a synonym for > what many call The Public DNS. Yep. It's "Global Internet's DNS (GID)", per the document. There are, unfortunately, more than one naming environments. We've known this for years with even /etc/hosts being different from the DNS, and NIS coming along later, etc. Nowdays, there are so many split-systems with both internal and externally differing naming sets I was trying to use something that included the world "global" to be super-clear this is the "big one". -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
Hi Wes, I’m having a hard time understanding the two proposed deployments in this document. In 2.2.1 it states that .internal does not exist in the GID. Yet in the Summary section immediately after it states that .internal is an unsigned TLD. Which is it? In 2.2.2 it states that .zz is an unsigned delegation in the GID’s DNS root. Yet in the summary section it states that “.zz is a special-use-like TLD that MUST never be assigned”. Which is it? My understanding of an unsigned TLD is that it is delegated in the root zone unsigned. And I take it that GID is simply a synonym for what many call The Public DNS. Thanks, Andrew On 2 Nov 2020, at 23:50, Wes Hardaker wrote: I've been thinking for a while what approach to take with respect to private name spaces. This document summarizes some of my thinking, and draws some conclusions (that will likely poke some bears and beehives at the same time). -- A new version of I-D, draft-hardaker-dnsop-private-namespace-options-00.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository. Name: draft-hardaker-dnsop-private-namespace-options Revision: 00 Title: DNS Private Namespace Options Document date: 2020-11-02 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/archive/id/draft-hardaker-dnsop-private-namespace-options-00.txt Status: https://datatracker.ietf.org/doc/draft-hardaker-dnsop-private-namespace-options/ Htmlized: https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-private-namespace-options Htmlized: https://tools.ietf.org/html/draft-hardaker-dnsop-private-namespace-options-00 Abstract: This document discusses the trade-offs between various options about creating a private namespace within top level domains within the root zone. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hardaker-dnsop-private-namespace-options
In article you write: > >I've been thinking for a while what approach to take with respect to >private name spaces. This document summarizes some of my thinking, and >draws some conclusions (that will likely poke some bears and beehives at >the same time). Having been around this barn a few times I'm inclined to take a more hard-assed approach and say that if you want to use a private TLD and DNSSEC, it's up to you to figure out how to manage the trust anchors. This means no unsigned delegation or anything else in the root. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] draft-hardaker-dnsop-private-namespace-options
I've been thinking for a while what approach to take with respect to private name spaces. This document summarizes some of my thinking, and draws some conclusions (that will likely poke some bears and beehives at the same time). -- A new version of I-D, draft-hardaker-dnsop-private-namespace-options-00.txt has been successfully submitted by Wes Hardaker and posted to the IETF repository. Name: draft-hardaker-dnsop-private-namespace-options Revision: 00 Title: DNS Private Namespace Options Document date: 2020-11-02 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/archive/id/draft-hardaker-dnsop-private-namespace-options-00.txt Status: https://datatracker.ietf.org/doc/draft-hardaker-dnsop-private-namespace-options/ Htmlized: https://datatracker.ietf.org/doc/html/draft-hardaker-dnsop-private-namespace-options Htmlized: https://tools.ietf.org/html/draft-hardaker-dnsop-private-namespace-options-00 Abstract: This document discusses the trade-offs between various options about creating a private namespace within top level domains within the root zone. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat -- Wes Hardaker USC/ISI ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
