Named Servers

  • Thread starter Thread starter Nathan Guidry
  • Start date Start date
1) This config is flawed. If your pointing your root-hints to the internal
root, then any uncached internal query will first need to fail at the
forwarder, then will be sent to the internal root using root hints. This
delay is multiplied if using multiple forwarders to an ISP for example. Not
the way this should be setup IMO.

2) You can setup a domain on a internal DNS server with a domain called
"sub1.mydomain.com" for example. "mydomain.com" is on another internal
server. On the sub1.mydomain.com server, make sure root-hints is enabled.
Now sub1.mydomain.com can resolve any queries for that domain and any INET
name - no Forwarding. Now you ask about the parent "mydomain.com". How
does sub1.mydomain.com server resolve that? Add a secondary or add a stub
zone or add a conditional forward zone. So at least two ways to do it
without using forwarding and we have access to external namespace and all
internal ones. Naturally, conditional forwarding is now a common ways to do
this with w2k3.

--wjs
 
In
Are you saying that the forwarder would have to fail before the
recursion would begin? (I don't believe that is right, but it is
definitely interesting if true.)
Click to expand...

If a forwarder is entered, and the "do not use recursion", check box is not
checked, then yes, if the forwarder fails it will go to the roots. Is that
what you're referring to?

--
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
 
Are you saying that the forwarder would have to fail before the
recursion would begin? (I don't believe that is right, but it is definitely
interesting if true.)
Click to expand...

Yes. Forwarding is tried first if configured (as are forward zones) then
root-hints. So, except for cached entries, you will end up with delays
waiting for the forwarder(s) to return nxdomain.
This is not the disccusions for only private zones, but rather for an entire
private namespace (from the root down.)
Click to expand...

If "mydomain.com" is my private domain, then that is my *entire namespace.
It does not have to start from the root to be concidered a namespace. Who
told you that? However if you must use that as your definition then you are
talking about an Private/Internal root. However, if you are using a private
root, then your clients must have either a name exclusion list or a proxy
autoconfiguration (PAC) file to get INET rez. If your forwarding to
external servers, then you not using an internal root. And if we are not
using an internal root anymore, then we can also use root-hints and
forwarding is *not required - period. You may have read that somewhere, but
you can set this up yourself to prove it works as I have.
If you have a private namespace with its own (private) root, then the
only (standard) way to check a second namespace like the Internet
is through forwarding.
Click to expand...

If your using a private root, then your not using forwarding. You don't
have a private root design any longer when you configure the first
forwarder. You can also use Windows Server 2003 DNS stub zones to
facilitate DNS data distribution between separate namespaces. Please see
the following for references:
http://www.microsoft.com/technet/tr...r2003/proddocs/deployguide/dnsbd_dns_vlic.asp

http://www.microsoft.com/windows200...scenarios/dns01_overviewdnsinfrastructure.asp

http://www.microsoft.com/technet/tr...r2003/proddocs/deployguide/dnsbd_dns_rrsz.asp

http://www.microsoft.com/windows2000/techinfo/reskit/samplechapters/cncf/cncf_imp_hhcs.asp
 
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.
 
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:
 
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.
 
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.
 
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.
 
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.
 
Jonathan de Boyne Pollard said:
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.
Click to expand...

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.
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.
Click to expand...

Correct. If no response or server failed response and maybe a few others.
NXDOMAIN will return NXDOMAIN and iteration will not be used.
RFC 1034 section 2.4 .
Click to expand...

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
 
In
Jonathan de Boyne Pollard said:
This is a discussion forum as well. (-:
Click to expand...

True about the dicussion forum. I have to agree. :-)
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. (-:
Click to expand...

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
 
This is the real problem.

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