Named Servers

Named Servers

Post by Jonathan de Boyne Pollar » Sun, 20 Jul 2003 04:01:57



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 ?

 
 
 

Named Servers

Post by Jonathan de Boyne Pollar » Sun, 20 Jul 2003 04:26:34


HM> you cannot give a built-in way to use
HM> TWO NAMESPACES without a forwarder.

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
records.

 
 
 

Named Servers

Post by Herb Marti » Sun, 20 Jul 2003 17:58:33


Quote:> 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.

Again, I see your problem, the term namespace
is not defined there -- the only use of the word
is "namespace trees".  In that reference it is only
used as an "adjective" to "tree".

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
to "trees".

Here is a clearer definition (#5 is DNS):

Quote:> http://www.webopedia.com/TERM/N/namespace.html #5

Although RFC1107 continues the tradition of using the term
without definition (expecting the read to know this from
general or mathematical education) it uses it in context many
times and distinct from "tree" or "zone".

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.

            root--------
           /      \     ---  \  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
namespace)
            /     \                                              /      \

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

Quote:> http://www.microsoft.com/mspress/products/1031/4th/comd4up6b.asp

namespace
n. A grouping of one or more names that represent individual objects within
the group in a shared computing environment, such as a network. The names
within a namespace are unique, are created according to the same rules, and
can be resolved into a particular identifying item of information, such as
an IP address or a network device. A namespace can be either flat-a single
collection of unique names-or hierarchical, as is the Internet's DNS (Domain
Name System), which is based on a treelike structure that is refined through
successive levels beginning with the root server and the Internet's
top-level domains (.com, .net, .org, and so on). In everyday terms, a
namespace is comparable to a telephone book, in which each name is unique
and resolves to the phone number and address of a particular individual,
business, or other entity.
 
 
 

Named Servers

Post by Jonathan de Boyne Pollar » Wed, 23 Jul 2003 23:03:34


HM> Perhaps you, like Jonathon, are confused about the meaning
HM> of "name space" [...]

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.

 
 
 

Named Servers

Post by Jonathan de Boyne Pollar » Wed, 23 Jul 2003 22:51:32


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 forwarding.
You are saying that forwarding would have to fail before _query resolution_
would begin.

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
resolution attempted.

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 .

 
 
 

Named Servers

Post by Jonathan de Boyne Pollar » Wed, 23 Jul 2003 23:51:07


AF> This thread has veered off the original topic for the original
AF> poster. I thought we're here to help the posters?

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
up.  (-:

 
 
 

Named Servers

Post by Jonathan de Boyne Pollar » Wed, 23 Jul 2003 23:40:14


HM> Second, two entirely different namespaces may be completely
HM> separate to the extent they have NO zones NAMES in common
HM> except "." for root.  -- there is no shadow zone because the
HM> owner of the private namespace does not provide a subset of
HM> any common zones to the other namespace.
HM>
HM>        root                 separte root  (separate namespace)
HM>      /     \                      /      \
HM>     com    net                  local    herb
HM> [...]
HM> A private namespace requires a forwarder to resolve names
HM> from another (e.g., THE Public Internet) namespace.

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.

 
 
 

Named Servers

Post by William Stace » Thu, 24 Jul 2003 04:47:01




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
forwarding.
> You are saying that forwarding would have to fail before _query
resolution_
> would begin.

I'll agree to anything as long as we don't start that again ;-)
My answer is, however, correct based on his question.  Each forwarder would
need to fail or return no answer or server failed for root-hints to get a
chance.  If any forwarder returns NXDOMAIN (which is an answer), then
root-hints would not be used and the query would return NXDOMAIN.  Which is
even worse for this example as it could prevent many queries.

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.

Correct.  If no response or server failed response and maybe a few others.
NXDOMAIN will return NXDOMAIN and iteration will not be used.

Quote:> RFC 1034 section 2.4 .

They are talking about the entire INET namespace.  If I only have
"mydomain.com" internally, then that is *my namespace.  If I have an NT
domain called "MYDOMAIN" then that is my namespace.

--wjs

 
 
 

Named Servers

Post by Ace Fekay [MVP » Thu, 24 Jul 2003 10:13:28




then I replied down below:

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.  (-:

True about the dicussion forum. I have to agree. :-)

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.  (-:

I see what you mean!
:-)

--
Regards,
Ace

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
--
=================================

 
 
 

Named Servers

Post by Jonathan de Boyne Pollar » Thu, 24 Jul 2003 00:09:17


WS> If all your internal DNS servers are forwarding to the internal
WS> root or have their root-hints pointing to the Internal root,
WS> then how are you configuring the forwarders for external rez?  

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
goes on.

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
utter disaster.

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.

 
 
 

Named Servers

Post by Jonathan de Boyne Pollar » Thu, 24 Jul 2003 00:31:36


HM> If you have a private namespace with its own (private) root,
HM> then the only (standard) way to check a second namespace like
HM> the Internet is through forwarding.

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.

 
 
 

Named Servers

Post by Jonathan de Boyne Pollar » Thu, 24 Jul 2003 00:38:50


JdeBP> "Split horizon" DNS service is the only case where the idea
JdeBP> of multiple namespaces actually has meaning.  Every entity
JdeBP> only ever sees one DNS namespace.  That's the way that DNS
JdeBP> works.  "Split horizon" DNS service is where different
JdeBP> entities see different namespaces.

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.

 
 
 

Named Servers

Post by Jonathan de Boyne Pollar » Thu, 24 Jul 2003 00:26:40


WS> This config is flawed.  If your pointing your root-hints to
WS> the internal root, then any uncached internal query will first
WS> need to fail at the forwarder, then will be sent to the internal
WS> root using root hints.  This delay is multiplied if using
WS> multiple forwarders to an ISP for example.  Not the way this
WS> should be setup IMO.

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.

 
 
 

Named Servers

Post by Herb Marti » Thu, 24 Jul 2003 20:07:11


This is the real problem.

If (one of) the forwarders returns NXDomain,
then nothing else happens.

 
 
 

Named Servers

Post by William Stace » Fri, 25 Jul 2003 10:14:22


Agreed.


Quote:> This is the real problem.

> If (one of) the forwarders returns NXDomain,
> then nothing else happens.

 
 
 

1. Name servers list seconday name server as primary name server.

Problem:
    Name servers list secondary name server as primary name server.
Question:
    How can I fix that?

Background:
A few months ago I started to maintain our own name server mainly to make
our sub-domain
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
position, the
secondary name server.

Having problems sending email to our sub-domain mail server from time to
time, I found out

server
as primary name server for our domain.

How can that be and what can I do to force that name servers access our name
server
as primary name server.

Andreas

2. NW 4.11 licenses???

3. How does a name server find/order remote name servers?

4. TOTAL SUM on elements in a list

5. second name server crashing the primary name server

6. I can′t install anything in windows 2000 server

7. Do name servers use ip addresses or resolve domain names

8. DECUS Tape price range

9. indentical caching only name servers.1 having problems resolving domain name

10. Root Name Servers won't respond to named.

11. Working Now: kill -HUP `cat /etc/named.pid` does not reload name server

12. kill -HUP `cat /etc/named.pid` does not reload name server

13. caching-only name server not caching or name serving