R
rommel
How will I set my ISP DNS Server to be the forwarding
server of my Intranet DNS Server.
server of my Intranet DNS Server.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an alternative browser.
You should upgrade or use an alternative browser.
L
Lanwench [MVP - Exchange]
All servers and workstations should specify the internal AD-integrated DNS
server's IP address in their network settings. The AD-integrated DNS server
should be set up with forwarders to several public DNS servers (or use root
hints) for external resolution.
See http://support.microsoft.com/default.aspx?scid=kb;en-us;300202 for more
info.
server's IP address in their network settings. The AD-integrated DNS server
should be set up with forwarders to several public DNS servers (or use root
hints) for external resolution.
See http://support.microsoft.com/default.aspx?scid=kb;en-us;300202 for more
info.
H
Herb Martin
How will I set my ISP DNS Server to be the forwarding
Hint (two actually): read LanWench's reply to you
#2: Forwarders don't really have to know that they are forwarders,
rather it is the DNS server that forwards TO THEM that specifies
their address.
Usually the forwarder is one of: Your gateway/NAT to the next
bigger network (HQ, the Internet, etc), a DNS server on the other
side of a WAN, e.g, at the ISP (or HQ etc.)
You forwarder to avoid multiple calls over the WAN, build a consolidated
cache on ONE machine rather than having them all do that separately,
and/or to allow a machine on the FAR side of the WAN to use faster
lines and less precious bandwidth to do the resolution.
server of my Intranet DNS Server.
Hint (two actually): read LanWench's reply to you
#2: Forwarders don't really have to know that they are forwarders,
rather it is the DNS server that forwards TO THEM that specifies
their address.
Usually the forwarder is one of: Your gateway/NAT to the next
bigger network (HQ, the Internet, etc), a DNS server on the other
side of a WAN, e.g, at the ISP (or HQ etc.)
You forwarder to avoid multiple calls over the WAN, build a consolidated
cache on ONE machine rather than having them all do that separately,
and/or to allow a machine on the FAR side of the WAN to use faster
lines and less precious bandwidth to do the resolution.
R
rommel
I followed the in Microsoft Knowledge Base Article -
300202, in Forwarders Tab the Enable Forwarders checkbox
was grayed. Forwarders are not available because this is a
root server.
300202, in Forwarders Tab the Enable Forwarders checkbox
was grayed. Forwarders are not available because this is a
root server.
R
rommel
Thank you very much. I already configured it correctly.
J
Jonathan de Boyne Pollard
HM> Forwarders don't really have to know that they are forwarders, [...]
Forwarders have to know that they are forwarders. It is forwardees
that don't have to know that they are forwardees.
Forwarders have to know that they are forwarders. It is forwardees
that don't have to know that they are forwardees.
L
Lanwench [MVP - Exchange]
So you removed the root zone (".") as per the article, to enable forwarders,
right?
right?
H
Herb Martin
HM> Forwarders don't really have to know that they are forwarders, [...]
You have the terminology backwards.
See BIND (options statements in BIND) or the ARM 1.4.5.1,
"DNS and BIND" (chapter 10 I believe), or MS DNS dialogs &
%systemroot%\Help\DNSconcepts.chm::/sag_DNS_pro_EnableForwarders.htm
The "Forwarding" server, usually the internal server,
configures the "address of the forwarder".
I agree that in English this could have gone either way
(e.g., a forwarder does the initial forwarding, or a forwarder
handles the forwarded queries -- they opted for the latter.)
Forwarders have to know that they are forwarders. It is forwardees
that don't have to know that they are forwardees.
You have the terminology backwards.
See BIND (options statements in BIND) or the ARM 1.4.5.1,
"DNS and BIND" (chapter 10 I believe), or MS DNS dialogs &
%systemroot%\Help\DNSconcepts.chm::/sag_DNS_pro_EnableForwarders.htm
The "Forwarding" server, usually the internal server,
configures the "address of the forwarder".
I agree that in English this could have gone either way
(e.g., a forwarder does the initial forwarding, or a forwarder
handles the forwarded queries -- they opted for the latter.)
A
Ace Fekay [MVP]
In
Then taking into consideration all what you said, why do they call it the RA
bit, recursion is available bit, and it needs to be turned on to offer
responses for other machines querying it? A simple DIG or dnsqry will show
that bit is on. If on, I can forward requests to it.
Unless I got it all wrong.... But it seems to work in previous tests for me
when testing (by checking the RA bit if "on"), if a DNS server "out there"
will respond to being used as a "forwarder".
--
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
posted their urgent concerns said:That's right -- the one actually finishing the query is the Forwarder.
It's defined this way.
No, that's backwards. The one which forwards adds the "forwarder
addresses" in it's dialog.
As I said, "The forwarder doesn't even know it's a forwarder" -- you
configure the originating server to forward to the forwarder.
It has very little to do with recursion -- the forwarder probably
recurses, but it could technically forwarder to ANOTHER forwarder.
No, because the 'option' is on the FIRST server that originated the
request - the forwarder treats this request as it would for any other
client, it tries to resolve it using the methods for which it is
configured, zones, cache, forwarding, or actual recurions from the
root down.
This confusion from people who are actually very good with DNS
is the reason I put a POINT on this issue for the fellow who was
obviously new at it.
If the experts (like you) are having trouble keeping it straight it
is obvious that beginners will do better if they learn it right from
the start and get it really straight.
Then taking into consideration all what you said, why do they call it the RA
bit, recursion is available bit, and it needs to be turned on to offer
responses for other machines querying it? A simple DIG or dnsqry will show
that bit is on. If on, I can forward requests to it.
Unless I got it all wrong.... But it seems to work in previous tests for me
when testing (by checking the RA bit if "on"), if a DNS server "out there"
will respond to being used as a "forwarder".
--
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
H
Herb Martin
Then taking into consideration all what you said, why do they call it the
RA
Forwarders can be willing to do recursions, only forward
to ANOTHER forwarder, or only check their cache --
most do 2 or 3 or these.
When a client creates a "recursive" query -- or a server
offers "recursion available -- this doesn't mean any
RECURSING will happen.
The confusion on the recursion issue is cause by people
defining 'recursion' as "the handling of a recursive query".
Sometimes that query requires no recursion, sometimes
the server may refuse to peform that behavior.
Recursing as a VERB has a specific meaning common
to DNS RFCs and programmers but this is NOT identical
to the meaing of "recursive query" AS A NOUN, to describe
the clients request.
Most of the time the distinction is insignificant since
most Forwarders also support recursion and most
queries sent to forwarders request recursion, and
many of those requests REQUIRE the forwarder
to recurse (verb) to actually resolve the query.
The times it is significant are precisely when we are
troubleshooting (or occasionally when we are designing,
but good design is a lot like "pre-troubleshooting").
At these times we need to be specific in the terminology
(as you see all the time when a beginner writes something
like "my ISP routes DNS" and the experts here cannot
be sure if they really mean "DNS" or really mean "routing"
or both.)
If we don't use the words correctly it requires a lot of
extra explanation, false starts, backing up, and correcting
previous suggestions.
A Forwarder may or may not be a "caching only" server.
A Forwarder may or may not support "recursive" queries.
A caching-only server may or may not be a Forwarder.
A caching-only server may or may not recursively resolve
queries from the root down
A recursive query may or may not REQUIRE any actual
recursion to happen for it to be resolved.
(many recursive queries are answered directly from an
authoritative zone database on that specific server)
Many people are confused by these distinctions (or lack
of distinctions) because it is VERY COMMON for a
caching only server to USE a forwarder and it is very
common for a forwarder to be "caching only".
The concept however are different.
RA
bit, recursion is available bit, and it needs to be turned on to offer
responses for other machines querying it? A simple DIG or dnsqry will show
that bit is on. If on, I can forward requests to it.
Forwarders can be willing to do recursions, only forward
to ANOTHER forwarder, or only check their cache --
most do 2 or 3 or these.
When a client creates a "recursive" query -- or a server
offers "recursion available -- this doesn't mean any
RECURSING will happen.
The confusion on the recursion issue is cause by people
defining 'recursion' as "the handling of a recursive query".
Sometimes that query requires no recursion, sometimes
the server may refuse to peform that behavior.
Recursing as a VERB has a specific meaning common
to DNS RFCs and programmers but this is NOT identical
to the meaing of "recursive query" AS A NOUN, to describe
the clients request.
Unless I got it all wrong.... But it seems to work in previous tests for me
when testing (by checking the RA bit if "on"), if a DNS server "out there"
will respond to being used as a "forwarder".
Most of the time the distinction is insignificant since
most Forwarders also support recursion and most
queries sent to forwarders request recursion, and
many of those requests REQUIRE the forwarder
to recurse (verb) to actually resolve the query.
The times it is significant are precisely when we are
troubleshooting (or occasionally when we are designing,
but good design is a lot like "pre-troubleshooting").
At these times we need to be specific in the terminology
(as you see all the time when a beginner writes something
like "my ISP routes DNS" and the experts here cannot
be sure if they really mean "DNS" or really mean "routing"
or both.)
If we don't use the words correctly it requires a lot of
extra explanation, false starts, backing up, and correcting
previous suggestions.
A Forwarder may or may not be a "caching only" server.
A Forwarder may or may not support "recursive" queries.
A caching-only server may or may not be a Forwarder.
A caching-only server may or may not recursively resolve
queries from the root down
A recursive query may or may not REQUIRE any actual
recursion to happen for it to be resolved.
(many recursive queries are answered directly from an
authoritative zone database on that specific server)
Many people are confused by these distinctions (or lack
of distinctions) because it is VERY COMMON for a
caching only server to USE a forwarder and it is very
common for a forwarder to be "caching only".
The concept however are different.
A
Ace Fekay [MVP]
In
Sure, because *it* may be forwarding to another where the recursion bit is
"off" and the buck stops there, unless of course the forwardee uses it's
Roots to resolve the query forwarded it by it's forwardee.
As we all know, those definitions being discussed in depth before.
Or else it wouldn't work. My point. At least we agree there.
If the bit is off, no.
It could use the Roots.
It could be authorative for the zone.
And this discussion/argument goes on...
--
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
posted their urgent concerns said:Forwarders can be willing to do recursions, only forward
to ANOTHER forwarder, or only check their cache --
most do 2 or 3 or these.
When a client creates a "recursive" query -- or a server
offers "recursion available -- this doesn't mean any
RECURSING will happen.
Sure, because *it* may be forwarding to another where the recursion bit is
"off" and the buck stops there, unless of course the forwardee uses it's
Roots to resolve the query forwarded it by it's forwardee.
The confusion on the recursion issue is cause by people
defining 'recursion' as "the handling of a recursive query".
Sometimes that query requires no recursion, sometimes
the server may refuse to peform that behavior.
Recursing as a VERB has a specific meaning common
to DNS RFCs and programmers but this is NOT identical
to the meaing of "recursive query" AS A NOUN, to describe
the clients request.
As we all know, those definitions being discussed in depth before.
Most of the time the distinction is insignificant since
most Forwarders also support recursion and most
queries sent to forwarders request recursion, and
many of those requests REQUIRE the forwarder
to recurse (verb) to actually resolve the query.
Or else it wouldn't work. My point. At least we agree there.
The times it is significant are precisely when we are
troubleshooting (or occasionally when we are designing,
but good design is a lot like "pre-troubleshooting").
At these times we need to be specific in the terminology
(as you see all the time when a beginner writes something
like "my ISP routes DNS" and the experts here cannot
be sure if they really mean "DNS" or really mean "routing"
or both.)
If we don't use the words correctly it requires a lot of
extra explanation, false starts, backing up, and correcting
previous suggestions.
Frustrating.
A Forwarder may or may not be a "caching only" server.
A Forwarder may or may not support "recursive" queries.
If the bit is off, no.
A caching-only server may or may not be a Forwarder.
It could use the Roots.
A caching-only server may or may not recursively resolve
queries from the root down
A recursive query may or may not REQUIRE any actual
recursion to happen for it to be resolved.
It could be authorative for the zone.
(many recursive queries are answered directly from an
authoritative zone database on that specific server)
Right.
Many people are confused by these distinctions (or lack
of distinctions) because it is VERY COMMON for a
caching only server to USE a forwarder and it is very
common for a forwarder to be "caching only".
The concept however are different.
And this discussion/argument goes on...
--
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
H
Herb Martin
When a client creates a "recursive" query -- or a server
Yes, this was the issue with the Forwarder that could not
resolve the name and returned NXDOMAIN -- it defeated
further actual recursion by the requesting DNS server since
that meant "non-existent domain and you won't find it either".
This this the reason that I rigged a BIND server to return
either "REFUSE" or "SERVERFAIL" to the client DNS
server -- in that case if it doesn't have the "Do NOT use
Recursion" box checked it will use it's own Root Hints to
keep looking -- this method allows that checking of two
separate (disjoint) namespaces:
Configure the public DNS server to REFUSE for all internal
names -- then the internal server can recurse the internal
root.
[Snip a lot that was agreed and correct]
No, there is really no 'bit' on a packet here -- we are talking about the
Forwarder's CONFIGURATION (the config file in BIND
and that Advanced check box in MS DNS.)
If the Forwarder doesn't support recursion then the bit on the
packet is irrelevant.
No that's not the point; a forwarder may or may not use Roots
too. (It might forward to another forwarder or it might recurse
the roots if so configured.)
Being a forwarder is A CONCEPT, not a configuration of that
server -- this is the reason for the point to be made that "a forwarder
does NOT know it's a forwarder."
When a beginner asks, "How do I configure my DNS server to
be a forwarder?" Do they mean what settings do they make on
the forwarder (none probably, at least nothing specific to forwarding)
or do they want to know "How do I configure my internal machines
to use the forwarder?"
Perhaps they mean, "Explain this whole idea of forwarders to me..."
Yes, or it might be in cache or it could forward.
ICS machines are conceptually CACHING only DNS
servers that ONLY Forward but are not themselves forwarders.
Caching only because they have no zones
User a forwarder at the ISP
Not a forwarder because you normally don't/cannot use other
internal DNS servers (which might have forwarder to ICS)
with ICS
There is no argument here -- it is merely clarification;
these are simple and well-defined terms that any expert
in DNS (like you) needs to be rock solid clear on.
It makes you even smarter.
Sure, because *it* may be forwarding to another where the recursion bit is
"off" and the buck stops there, unless of course the forwardee uses it's
Roots to resolve the query forwarded it by it's forwardee.
Yes, this was the issue with the Forwarder that could not
resolve the name and returned NXDOMAIN -- it defeated
further actual recursion by the requesting DNS server since
that meant "non-existent domain and you won't find it either".
This this the reason that I rigged a BIND server to return
either "REFUSE" or "SERVERFAIL" to the client DNS
server -- in that case if it doesn't have the "Do NOT use
Recursion" box checked it will use it's own Root Hints to
keep looking -- this method allows that checking of two
separate (disjoint) namespaces:
Configure the public DNS server to REFUSE for all internal
names -- then the internal server can recurse the internal
root.
[Snip a lot that was agreed and correct]
If the bit is off, no.
No, there is really no 'bit' on a packet here -- we are talking about the
Forwarder's CONFIGURATION (the config file in BIND
and that Advanced check box in MS DNS.)
If the Forwarder doesn't support recursion then the bit on the
packet is irrelevant.
It could use the Roots.
No that's not the point; a forwarder may or may not use Roots
too. (It might forward to another forwarder or it might recurse
the roots if so configured.)
Being a forwarder is A CONCEPT, not a configuration of that
server -- this is the reason for the point to be made that "a forwarder
does NOT know it's a forwarder."
When a beginner asks, "How do I configure my DNS server to
be a forwarder?" Do they mean what settings do they make on
the forwarder (none probably, at least nothing specific to forwarding)
or do they want to know "How do I configure my internal machines
to use the forwarder?"
Perhaps they mean, "Explain this whole idea of forwarders to me..."
It could be authorative for the zone.
Yes, or it might be in cache or it could forward.
ICS machines are conceptually CACHING only DNS
servers that ONLY Forward but are not themselves forwarders.
Caching only because they have no zones
User a forwarder at the ISP
Not a forwarder because you normally don't/cannot use other
internal DNS servers (which might have forwarder to ICS)
with ICS
And this discussion/argument goes on...
There is no argument here -- it is merely clarification;
these are simple and well-defined terms that any expert
in DNS (like you) needs to be rock solid clear on.
It makes you even smarter.
I have my DNS sconfigured to forward to a Bind DNS server. Everything seems to work except when a change is made on the Bind server, it nevermakes it back over to our Forwarders.. I have to clear the cache.. Which is a problem..
I set the MAXTTL reg entry but this does not correct the problem.. is there an option on a DNS server to Forward to not cache?
Please let me know
I set the MAXTTL reg entry but this does not correct the problem.. is there an option on a DNS server to Forward to not cache?
Please let me know
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.