HM> Perhaps you, like Jonathon, are confused about the meaning
HM> of "name space" [...]
I'm using the definition of the term from RFC 1034 section 2.4.
What are you using ?
Neither he nor you can give a way to use two namespaces _with_ forwarding,
either. There's no way to use two namespaces, full stop. As I said, (and
with the given that we are restricting the discussion to the "IN" class) every
entity making use of DNS sees exactly _one_ DNS namespace.
HM> Two namespaces require a forwarder because a single DNS server
HM> can only check ONE ROOT and the namespace it anchors. Clients
HM> only query one server (the one that responds to them.) To query
HM> another namespace you MUST use a forwarder that is attached to
HM> the second namespace through another root.
The notion here of querying a second DNS namespace simply makes no sense. The
only way that one re-combines data sources in DNS, overriding what the
delegations do, is by picking some point in the namespace tree and specifying
that for all domain names on one side of that point data are fetched from the
public DNS database and that for the other domain names data are fetched from
a private DNS database. This doesn't provide two namespaces. The DNS
database content that one "sees" may comprise private and public content
obtained from many sources stiched together in a complex patchwork, but
there's still just the one namespace for the owner names of the resource
Again, I see your problem, the term namespaceQuote:> HM> Perhaps you, like Jonathon, are confused about the meaning
> HM> of "name space" [...]
> I'm using the definition of the term from RFC 1034 section 2.4.
I am referring to SEPARATE namespaces
The earliest use of the term "namespace" in the RFC is
apparently RFC984 where is used in context expecting
the definition to be taken from common knowledge or
understanding of similar terms in mathematics such as
"memory space" or "problem space" or just "space"
in a technical sense.
Several other RFCs use the term before RFC1034 uses
it without definition in a peripheral manner as an adjective
Here is a clearer definition (#5 is DNS):
Although RFC1107 continues the tradition of using the termQuote:> http://www.webopedia.com/TERM/N/namespace.html #5
First, many split horizon DNS systems are used where the private
copy DNS servers are actually providing direct access to the
public namespace by searching it from the root down.
/ \ --- \ private DNS
In this situation all names are searched within the public namespace,
with the distinction that the OUTSIDE clients only see a portion of
the companies DNS records for their domain -- but the compannies
machines see the complete (internal plus external) record set for that
domain and of course the Internet public namespace
All names in the private DNS zone are necessarly valid in the public zone
even if some of them are not reachable from the outside. -- in this
example there is not SEPARATE private namespace with it's own
naming rules, root, or hierarchies. There are some private names in
a private version of a shadow zone.
Second, two entirely different namespaces may be completely
separate to the extent they have NO zones NAMES in common
except "." for root. -- there is no shadow zone because the owner
of the private namespace does not provide a subset of any common
zones to the other namespace.
root separte root (separate
/ \ / \
No shadowing; presumably this company on the right with it's own
namespace offers no resources to the internet or uses completely
different names (e.g., .Com publicly, and .Local privately.), i.e. they
are in a SEPARATE NAMESPACE.
Of course, there are shades of gray between the two, where the
private namespace hews largely to the Internet public naming rules,
creating parallel name trees.
The discussion is a private NAMESPACE.
A private namespace requires a forwarder to resolve names from
another (e.g., THE Public Internet) namespace.
My discussion of forwarders (rule #1) was always about SEPARATE,
disjoint DNS namespaces.
In fact, namespaces exist that have nothing to do with DNS,
e.g., WINS namespaces.
Microsoft Press Computer Dictionary
JdeBP> I'm using the definition of the term from RFC 1034
JdeBP> section 2.4.
HM> Again, I see your problem, the term namespace
HM> is not defined there -- the only use of the word
HM> is "namespace trees". In that reference it is only
HM> used as an "adjective" to "tree".
"name space" _is_ defined there. That's why it is in capital letters there.
HM> I am referring to SEPARATE namespaces
Different query classes aside (We are only talking about the "IN" class here.)
there is no such thing outside of "split horizon" DNS service. And even in
"split horizon" DNS service there is no concept akin to the one that you are
trying to propound - that of a single entity seeing multiple namespaces. A
single entity only ever sees _one_ (Internet class) domain namespace. The DNS
database content may comprise private and public content obtained from many
sources stiched together in a complex patchwork, but there's still just the
_one_ namespace for the owner names of the resource records.
You are putting forward a nonsense concept, and then saying that this nonsense
concept requires forwarding.
Actually, the correct answer is "No.". That's not what you are saying.
Forwarding _is_ recursion, remember ? So recursion begins with forwarding.
You are saying that forwarding would have to fail before _query resolution_
WS> Forwarding is tried first if configured (as are forward zones)
WS> then root-hints. So, except for cached entries, you will end
WS> up with delays waiting for the forwarder(s) to return nxdomain.
If forwarding results in a "no such name" response being obtained from the
forwardee, _it has not failed_. Only if forwarding _fails_ is query
WS> It does not have to start from the root to be concidered a
WS> namespace. Who told [Herb] that?
RFC 1034 section 2.4 .
This is a discussion forum as well. (-:
AF> D&B> Each unit of data in DNS's distributed database is
AF> D&B> indexed by a name. These names are essentially just
AF> D&B> paths in a large inverted tree, called the 'Domain
AF> D&B> Name Space'.
Of course, it's only by convention that the tree is considered to be
inverted. One _could_ simply place all of the pretty diagrams the other way
Wrong. In the above scenario there is in fact _one_ namespace seen by
entities within the company, and it looks like this:
com. net. local. herb.
There are three possibilities for what happens here:
1. The server with the "local." and "herb." database content is a mixed
server that provides both proxy and content DNS service. It has no "." "zone"
and forwards to a proxy DNS server that can resolve queries for the rest of
the namespace tree.
2. The server with the "local." and "herb." database content is just a
content DNS server, and proxy DNS service is provided by another server, which
has database overrides (in the form of "stub zones" or "conditional
forwarders") telling it to graft the "local." and "herb." subtrees on in order
to form the entire namespace tree.
3. The server with the "local." and "herb." database content is a "."
content DNS server, and delegates "com." and "net." to the public "com." and
"net." content DNS servers. Proxy DNS service is provided by another server,
configured to use that content DNS server as its starting point instead of any
public "." content DNS servers. The proxy DNS server simply follows the
delegations as part of the normal process of query resolution.
The namespace for the records in the internal content DNS server's database is
different to the namespace that entities see. But that's irrelevant. _All_
content DNS servers have their own namespace in that respect. But only they
ever see it. And all entities looking at the DNS see a single DNS database
with a single namespace. They do this because they always look at DNS through
resolving proxy DNS servers, which (through the process of query resolution)
join (subsets of) all of these disparate DNS databases together to form a
single "virtual" DNS database with a single namespace. Every entity sees just
_one_ namespace, the one that it sees through its proxy DNS server.
I suspect, from your choice of examples, that you are conflating the notion of
multiple DNS databases (in the individual content DNS servers) with the notion
of multiple namespaces. Your example shows multiple databases, not multiple
namespaces. You claim that forwarding is necessary because there are multiple
namespaces. But in fact all entities see just _one_ namespace, through the
proxy DNS server. Forwarding is _not even_ necessary for the proxy DNS server
to join (the subsets of) those multiple DNS databases together. As I said, it
can be done with "stub zones" or with delegation.
I'll agree to anything as long as we don't start that again ;-)Quote:> HM> Are you saying that the forwarder would have to fail before
> HM> the recursion would begin?
> WS> Yes.
> Actually, the correct answer is "No.". That's not what you are saying.
> Forwarding _is_ recursion, remember ? So recursion begins with
> You are saying that forwarding would have to fail before _query
> would begin.
Correct. If no response or server failed response and maybe a few others.Quote:> If forwarding results in a "no such name" response being obtained from the
> forwardee, _it has not failed_. Only if forwarding _fails_ is query
> resolution attempted.
They are talking about the entire INET namespace. If I only haveQuote:> RFC 1034 section 2.4 .
True about the dicussion forum. I have to agree. :-)Quote:>> This thread has veered off the original topic for the original
>> poster. I thought we're here to help the posters?
> This is a discussion forum as well. (-:
I see what you mean!Quote:
>> D&B> Each unit of data in DNS's distributed database is
>> D&B> indexed by a name. These names are essentially just
>> D&B> paths in a large inverted tree, called the 'Domain
>> D&B> Name Space'.
> Of course, it's only by convention that the tree is considered to be
> inverted. One _could_ simply place all of the pretty diagrams the
> other way up. (-:
Please direct all replies to the newsgroup so all can benefit.
Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
HM> This really isn't that hard, if all your INTERNAL Servers are
HM> set to use the Internal Namespace by pointing at internal root
Hm> servers this requires that they use forwarders to check ANOTHER
HM> NameSpace (e.g., The Internet.)
If all of one's internal proxy DNS servers are configured with root hints
pointing at an internal "." content DNS server, they'll get _all_ of their
answers, both positive and negative, from that server and the content DNS
servers that it delegates to. There is no "checking another namespace" that
If one's internal proxy DNS servers are also configured to forward an external
(resolving) proxy DNS server, they'll get _all_ of their answers, both
positive and negative, from that server; unless it fails, in which case they
will fall back to query resolution and once again get all of their answers,
both positive and negative, from the internal "." content DNS server and the
servers that it delegates to. Again, there is no "checking another namespace"
that goes on.
Of course, in the latter case one's internal proxy DNS servers are recursing
to two different (sets of) DNS servers that provide two different views of the
DNS database, depending from whether the forwarding fails (not results in a
negative answer, note, but _fails_) for any given query. This is a recipe for
HM> Thus, rule #1 which you guys have gone on so much about:
HM> You need a forwarder if you want to check two distinct
HM> namespaces, e.g., a private namespace and The Internet.
"Rule #1" is predicated on the existence of a single entity somehow seeing and
"checking" multiple namespaces. But this isn't the way that DNS works, and
doesn't happen. Each entity only ever sees _one_ namespace. The only place
where the notion of multiple namespaces makes reasonable sense is in "split
horizon" DNS service, where different entities see different namespaces, but
having (conditional) forwarding is but one way of achieving "split horizon"
DNS service. There are at least two others that do not require forwarding,
both of which are better.
If one has one's own private root, then either one has grafted on some public
DNS database content at some point in the tree (using conditional forwarders,
"stub" "zones", or simply delegations) or one has not. In both cases there is
still one single namespace. In neither case does "checking a second
namespace" occur. And in neither case is forwarding a requirement.
HM> No, this above incorrect and likely based on a
HM> misunderstanding of the term "namespace".
As I said, this is the meaning of the term from RFC 1034 section 2.4.
HM> A split horizon may nor may not be associated with a separate
HM> namespace (e.g., private vs. the Internet namespaces).
"Split horizon" DNS service is always associated with multiple namespaces.
The whole essence of "split horizon" DNS service is that different entities
see different namespaces. However, even in "split horizon" DNS service there
is no "checking a second namespace" that occurs. Different entities see
different namespaces, but no individual entity sees more than one namespace.
That's simply not the way that DNS works.
Indeed, that's not even its _major_ flaw. The major flaw is that,
unpredictably, according to whether or not it is able to query the forwardee
successfully, the internal proxy DNS server recurses to one of two different
(sets of) DNS servers which present two different views of the DNS database.
This is a recipe for utter disaster.
Name servers list secondary name server as primary name server.
How can I fix that?
A few months ago I started to maintain our own name server mainly to make
visible via DNS. Our main web server and mail server is still hosted by an
ISP which until then
was maintaining our DNS entries in full. Around May this year I registered
our name server
as primary name server and shifted the ISP name server to the second
secondary name server.
Having problems sending email to our sub-domain mail server from time to
time, I found out
as primary name server for our domain.
How can that be and what can I do to force that name servers access our name
as primary name server.