Hi all.
I'm not confident with DNS in general, but I have to find a way to do this:

I'm in a LAN using a Windows Server 2003 as the primary DNS.
We have Mail and Web servers using public addresses, when someone check for
www.ourdomain.it or mail.ourdomain.it from ouside the LAN, they get the
servers' public addresses from our provider authoritative DNS.
That is ok.
When we check look for www.ourdomain or mail.ourdomain.it from inside the
LAN, we also get the public addresses from our internal DNS.
That's not ok. We should get our servers' private IP addresses.
How can I configure our internal DNS to do the job?
Should I add ourdomain.it on the DNS as a stub one?
If I only add a host(A), I do not resolve the problem, as the server
automatically add the ourdomain.locale suffix to the address.

Could someone point me at the right documentation, or tell how to have this
working if it's simple?

thank you very much.

Hi
If I understand you correctly you want that your internal DNS server resolve
your public domain to the private IPAddress, correct?
If yes all you have to do is to create an
Primary Zone, and create the records that point to the private internal Ip
address of your Domain.


--
I hope that the information above s you
Good Luck

Jorge Silva
MCSA
Systems Administrator

"Chino" <chino75@fastwebnet.it> wrote in message
news:ei7dak$2jp$1@newsread.albacom.net...
> Hi all.
> I'm not confident with DNS in general, but I have to find a way to do
> this:
>
> I'm in a LAN using a Windows Server 2003 as the primary DNS.
> We have Mail and Web servers using public addresses, when someone check
> for www.ourdomain.it or mail.ourdomain.it from ouside the LAN, they get
> the servers' public addresses from our provider authoritative DNS.
> That is ok.
> When we check look for www.ourdomain or mail.ourdomain.it from inside the
> LAN, we also get the public addresses from our internal DNS.
> That's not ok. We should get our servers' private IP addresses.
> How can I configure our internal DNS to do the job?
> Should I add ourdomain.it on the DNS as a stub one?
> If I only add a host(A), I do not resolve the problem, as the server
> automatically add the ourdomain.locale suffix to the address.
>
> Could someone point me at the right documentation, or tell how to have
> this working if it's simple?
>
> thank you very much.
>
>
>

> Hi
> If I understand you correctly you want that your internal DNS server
> resolve your public domain to the private IPAddress, correct?
> If yes all you have to do is to create an
> Primary Zone, and create the records that point to the private internal Ip
> address of your Domain.

Yes, this is what I want to do.
If I create a primary zone with one record for each server pointing to the
private IP address, will my DNS announce itself as authoritative to other
DNSs in Internet for this public domain?
I don't want to do that, because the public domain is owned by our provider
and it must remain the same.
Please confirm, and thank you very much!

Hi

You could create a zone called "hostname.domainname.com" and then within
that zone create a blank host A record (same as parent) pointing to the
relevant internal IP

Then your server would only be authorative for the zone "hostname.domainname.
com"and any records within that zone (such as the same as parent host record
you need)

Only drawback to this is you have to create a separate DNS zone for each host
and a same as parent record but it works

Regards

Simon


Chino wrote:
>> Hi
>> If I understand you correctly you want that your internal DNS server
>> resolve your public domain to the private IPAddress, correct?
>> If yes all you have to do is to create an
>> Primary Zone, and create the records that point to the private internal Ip
>> address of your Domain.
>
>Yes, this is what I want to do.
>If I create a primary zone with one record for each server pointing to the
>private IP address, will my DNS announce itself as authoritative to other
>DNSs in Internet for this public domain?
>I don't want to do that, because the public domain is owned by our provider
>and it must remain the same.
>Please confirm, and thank you very much!

--
Message posted via http://www.winserverkb.com

Thanks.
But I need not to propagate this zone to the outside world, otherwise hosts
on the Internet will not be able to resolve the hostname.domainname.com name
into the public ip address.
Can I achieve that with your solution?

> Hi
>
> You could create a zone called "hostname.domainname.com" and then within
> that zone create a blank host A record (same as parent) pointing to the
> relevant internal IP
>
> Then your server would only be authorative for the zone
> "hostname.domainname.
> com"and any records within that zone (such as the same as parent host
> record
> you need)
>
> Only drawback to this is you have to create a separate DNS zone for each
> host
> and a same as parent record but it works
>
> Regards
>
> Simon

This is a common problem when your have internal server with externally
accessible resources.

What you need to do is create what I call a GHOST forward look up zone on
your internal DNS servers. This zone will be for the "ourdomain.it". And it
must only be visible by internal users. You need to populate this zone with
all of the appropriate A records (www, mail, etc) and assign them either
internal IPs or External IPs which ever is appropriate.

The down side of this configuration is, any time there is a change, a
resource is added, removed, or moved to a different server, you now have to
contend with two separate DNS servers that have to be configured. You must
contact your ISP so they can update the DNS server that they host for the
world to see, and you must update the DNS server that you host for the
internal users to see.

This seems easy enough, but you would be surprised how often one or the
other is forgotten about.


"Chino" <chino75@fastwebnet.it> wrote in message
news:ei7dak$2jp$1@newsread.albacom.net...
> Hi all.
> I'm not confident with DNS in general, but I have to find a way to do
> this:
>
> I'm in a LAN using a Windows Server 2003 as the primary DNS.
> We have Mail and Web servers using public addresses, when someone check
> for www.ourdomain.it or mail.ourdomain.it from ouside the LAN, they get
> the servers' public addresses from our provider authoritative DNS.
> That is ok.
> When we check look for www.ourdomain or mail.ourdomain.it from inside the
> LAN, we also get the public addresses from our internal DNS.
> That's not ok. We should get our servers' private IP addresses.
> How can I configure our internal DNS to do the job?
> Should I add ourdomain.it on the DNS as a stub one?
> If I only add a host(A), I do not resolve the problem, as the server
> automatically add the ourdomain.locale suffix to the address.
>
> Could someone point me at the right documentation, or tell how to have
> this working if it's simple?
>
> thank you very much.
>
>
>

Why would Internet based clients be querying your DNS server for the
"mydomain.it" domain? The chain down from the root servers should point to
your ISP's DNS servers and not to yours as being authoritative.

Why are your DNS servers even accessible to the Internet? If you are not
hosting any Internet Domains on them, then they shouldn't be.


"Chino" <chino75@fastwebnet.it> wrote in message
news:ei7mka$62k$1@newsread.albacom.net...
>> Hi
>> If I understand you correctly you want that your internal DNS server
>> resolve your public domain to the private IPAddress, correct?
>> If yes all you have to do is to create an
>> Primary Zone, and create the records that point to the private internal
>> Ip address of your Domain.
>
> Yes, this is what I want to do.
> If I create a primary zone with one record for each server pointing to the
> private IP address, will my DNS announce itself as authoritative to other
> DNSs in Internet for this public domain?
> I don't want to do that, because the public domain is owned by our
> provider and it must remain the same.
> Please confirm, and thank you very much!
>

I think the only problem is that I don't know how exactly the world DNS
system works at all.
My DNS is not accessible FROM the Internet, but it can access THE Internet
to query other DNSs and other things.
Do you think this could be a problem?


"Harvey Colwell" <harveyc@sds400.com> wrote in message
news:uWKKG$Q$GHA.1224@TK2MSFTNGP05.phx.gbl...
> Why would Internet based clients be querying your DNS server for the
> "mydomain.it" domain? The chain down from the root servers should point to
> your ISP's DNS servers and not to yours as being authoritative.
>
> Why are your DNS servers even accessible to the Internet? If you are not
> hosting any Internet Domains on them, then they shouldn't be.
>
>

Inline
> If I create a primary zone with one record for each server pointing to the
> private IP address, will my DNS announce itself as authoritative to other
> DNSs in Internet for this public domain?
No it won't because the server only servs internal requests.
Note: I only stated the Primary zone as an option, however there're many
ways to do this, you can configure conditional forwarding, stub zones,
etc...
- Forwarding: DNS server will forward any query it can't answer, Checks zone
data and cache then forwards. ("All other Domains" option - pointing to TLD
DNS Servers) all queries will go to tld DNS server (including Internet
resolution queries), if the link with tld is down then queries will fail for
domains but the DNS server will attempt to use its root hints to resolve the
these queries (unless you select the option don't use recursion for this
domain- this can represent security problems because the DNS goes to public
network trying to resolve all queries that isn't authoritative for).
-Please note, only a failure to respond will cause the DNS client to switch
Preferred DNS servers; receiving an authoritative but incorrect response
does not cause the DNS client to try another server. As a result,
configuring a Domain Controller with itself and another DNS server as
Preferred and Alternate servers s to ensure that a response is received,
but it does not guarantee accuracy of that response. DNS record update
failures on either of the servers may result in an inconsistent name
resolution experience
- Conditional Forwarding: you can have better control by defining which DNS
servers will the server contact for zones that the server isn't
authoritative for, and if the link is down to any particular domain/site,
that doesn't mean that other queries will fail as long as you have the link
up to these domains/sites. Each domain name used for forwarding associated
with a forwarders list, Checks zone data and cache for answer, then uses
forwarders list to resolve, DNS server compares queried name to list of
domain name conditions
- Stub zones: Stub zones contain a read-only copy with specific records
(SOA, NS and related A) the big advantage of stub zones is that they'll
refresh automatically, a server hosting stub zone contacts zone master for
zone transfer, A master server may be a primary or secondary server for
actual zone, you don't need to allow zone transfer for stub zones to work
(Careful- Stub zones do not remove the requirement for delegations, Stub
zone data doesn't transfer during zone transfers like delegation information
does, Can be dangerous to use instead of delegation, If parent zone is
transferred without delegation information, how will server find child
zones?). Typically contiguous namespaces will not benefit using stub zones,
only disjoint namespaces may benefit using stub zones.
- Secondary Zones: also contains a Read-Only copy of the zone, all queries
can be resolved locally, but you need to allow zone transfer on each zone.
- Active Directory Integrated Zones (require that the DNS is also a DC),
the zone is replicated with AD replication, is better from security
perspective, you can always choose by replicate them across the domain or
forest. This can have a significant impact on your replication traffic if
you choose to replicate all zones across the forest.
The _msdcs.domain.tld contain information about Global catalog and other
domain/forest important records and they only exist in parent (root) DNS
server, so is always a good practice to replicate the root
_msdcs.domain.tld across the forest.

--
I hope that the information above s you
Good Luck

Jorge Silva
MCSA
Systems Administrator

"Chino" <chino75@fastwebnet.it> wrote in message
news:ei7mka$62k$1@newsread.albacom.net...
>> Hi
>> If I understand you correctly you want that your internal DNS server
>> resolve your public domain to the private IPAddress, correct?
>> If yes all you have to do is to create an
>> Primary Zone, and create the records that point to the private internal
>> Ip address of your Domain.
>
> Yes, this is what I want to do.
> If I create a primary zone with one record for each server pointing to the
> private IP address, will my DNS announce itself as authoritative to other
> DNSs in Internet for this public domain?
> I don't want to do that, because the public domain is owned by our
> provider and it must remain the same.
> Please confirm, and thank you very much!
>

Not at all. This is normal.

See my other post about creating a ghost zone on your internal servers. I've
done this many times for customers.


"Chino" <chino75@fastwebnet.it> wrote in message
news:ei80u0$a7t$1@newsread.albacom.net...
>I think the only problem is that I don't know how exactly the world DNS
>system works at all.
> My DNS is not accessible FROM the Internet, but it can access THE Internet
> to query other DNSs and other things.
> Do you think this could be a problem?
>
>
> "Harvey Colwell" <harveyc@sds400.com> wrote in message
> news:uWKKG$Q$GHA.1224@TK2MSFTNGP05.phx.gbl...
>> Why would Internet based clients be querying your DNS server for the
>> "mydomain.it" domain? The chain down from the root servers should point
>> to your ISP's DNS servers and not to yours as being authoritative.
>>
>> Why are your DNS servers even accessible to the Internet? If you are not
>> hosting any Internet Domains on them, then they shouldn't be.
>>
>>
>
>

Thank you very much, it is pretty much clear to me!

"Jorge Silva" <jorgesilva_pt@hotmail.com> wrote in message
news:%238u$aob$GHA.4328@TK2MSFTNGP03.phx.gbl...
> Inline
[...]