Strange DNS problem

[C Hall]

Good morning,

This past Friday, I was having problems with my DNS. The short version is
that I ended up deleting our zones and am in the process of resolving that
problem. However, when I went to do this last Friday, a DNS server from
another organization showed up as the SOA for the newly created zone. I had
been receiving alerts most of the day that this ip address was doing a nmap
udp port sweep. I talked to the vendor this morning and they had no idea.
For more details, I'm providing the post to the dns forum where I'm trying
to resolve the issue of being able to recreate the zone. It seemed like we
were getting compromised.

DNS Post:
We have three DCs--DC1, DC2, and DC3. We had an AD Integrated zone for our
forward lookup zone. On DC3, the zone showed as a secondary zone, so I tried
to change the type to an AD integrated zone (right-click, properties,
etc...), but it wouldn't allow it. I didn't write down the actual message,
but I was given two options: use the current zone or use the AD zone.
Neither option would work. I decided to delete the zone, thinking that since
the zone was a secondary zone that it would just die and I would be able to
create an AD zone or that the AD zone would replicate over. That didn't
work. In fact, the AD zone disappeared on both DC1 and DC2.

Next, I panicked and posted my previous thread ("Urgent!!!").

I have just tried creating a Primary zone on DC1 and created secondary zones
on DC2 & DC3. Then I ran Netdiag /fix. I wish I could say that I saved the
results to a text file, but I didn't. I did get it printed, though. The DNS
test shows it failed (surprise) with several FATAL errors trying to recreate
dns entries. I had set the zone to allow dynamic updates, accept updates
from all servers and had manually entered NS, A and PTR records for all DCs.
At this point, all zones have once again disappeared--the primary on the
master and the two secondary zones.


Any clues would be appreciated.

 

[Steven L Umbach]

See the link below which may help in rebuilding you dns zones. I suggest
that unless your organization requires otherwise, use only AD integrated
zones, do not allow zone transfers to other dns servers if not needed[ this
is not needed for AD integrated dns zones and never select "to any"], and
require secure updates unless you have a need to not use that. You may also
want to post in the win2000.dns newsgroup. Keep in mind that if you delete
an AD dns zone, that zone will be totally deleted from Active Directory and
not just that server. You also need to have some patience when rebuilding
your dns as replication will not be immediate to other dns servers/domain
controllers. Another alternative could be an authoritative restore of Active
Directory from a recent System State backup of a domain controller for AD
integrated dns zones. --- Steve

http://support.microsoft.com/?kbid=260371 -- see To repair the Active
Directory DNS record registration
http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 --- DNS
best practices.

 

[C Hall]

Steven,

Thanks for the post. It's looking like a rebuild of one DC (not a FSMO role
holder). I didn't allow enough disk space and that's causing problems. Aside
from that, there are a bunch of errors in the logs, I can't open ADU&C to
follow the guidance of the the dns group (Kevin). Armed with new info, I
don't think this is a security problem at this point. I will look at the
links below. Thanks again.

See the link below which may help in rebuilding you dns zones. I suggest
that unless your organization requires otherwise, use only AD integrated
zones, do not allow zone transfers to other dns servers if not needed[ this
is not needed for AD integrated dns zones and never select "to any"], and
require secure updates unless you have a need to not use that. You may also
want to post in the win2000.dns newsgroup. Keep in mind that if you delete
an AD dns zone, that zone will be totally deleted from Active Directory and
not just that server. You also need to have some patience when rebuilding
your dns as replication will not be immediate to other dns servers/domain
controllers. Another alternative could be an authoritative restore of Active
Directory from a recent System State backup of a domain controller for AD
integrated dns zones. --- Steve

http://support.microsoft.com/?kbid=260371 -- see To repair the Active
Directory DNS record registration
http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 --- DNS
best practices.

Good morning,

This past Friday, I was having problems with my DNS. The short version is
that I ended up deleting our zones and am in the process of resolving that
problem. However, when I went to do this last Friday, a DNS server from
another organization showed up as the SOA for the newly created zone. I
had
been receiving alerts most of the day that this ip address was doing a
nmap
udp port sweep. I talked to the vendor this morning and they had no idea.
For more details, I'm providing the post to the dns forum where I'm trying
to resolve the issue of being able to recreate the zone. It seemed like we
were getting compromised.

DNS Post:
We have three DCs--DC1, DC2, and DC3. We had an AD Integrated zone for our
forward lookup zone. On DC3, the zone showed as a secondary zone, so I
tried
to change the type to an AD integrated zone (right-click, properties,
etc...), but it wouldn't allow it. I didn't write down the actual message,
but I was given two options: use the current zone or use the AD zone.
Neither option would work. I decided to delete the zone, thinking that
since
the zone was a secondary zone that it would just die and I would be able
to
create an AD zone or that the AD zone would replicate over. That didn't
work. In fact, the AD zone disappeared on both DC1 and DC2.

Next, I panicked and posted my previous thread ("Urgent!!!").

I have just tried creating a Primary zone on DC1 and created secondary
zones
on DC2 & DC3. Then I ran Netdiag /fix. I wish I could say that I saved the
results to a text file, but I didn't. I did get it printed, though. The
DNS
test shows it failed (surprise) with several FATAL errors trying to
recreate
dns entries. I had set the zone to allow dynamic updates, accept updates
from all servers and had manually entered NS, A and PTR records for all
DCs.
At this point, all zones have once again disappeared--the primary on the
master and the two secondary zones.


Any clues would be appreciated.

 

[Steven L Umbach]

OK. Sounds good. The reason you can not open ADUC is probably because of a
dns problem in that the domain controller _srv records can not be found.
When you ping your domain name you normally should be retuned the IP address
of a domain controller and the same goes for nslookup. --- Steve

Steven,

Thanks for the post. It's looking like a rebuild of one DC (not a FSMO
role
holder). I didn't allow enough disk space and that's causing problems.
Aside
from that, there are a bunch of errors in the logs, I can't open ADU&C to
follow the guidance of the the dns group (Kevin). Armed with new info, I
don't think this is a security problem at this point. I will look at the
links below. Thanks again.

See the link below which may help in rebuilding you dns zones. I suggest
that unless your organization requires otherwise, use only AD integrated
zones, do not allow zone transfers to other dns servers if not needed[ this
is not needed for AD integrated dns zones and never select "to any"], and
require secure updates unless you have a need to not use that. You may also
want to post in the win2000.dns newsgroup. Keep in mind that if you
delete
an AD dns zone, that zone will be totally deleted from Active Directory and
not just that server. You also need to have some patience when
rebuilding
your dns as replication will not be immediate to other dns servers/domain
controllers. Another alternative could be an authoritative restore of Active
Directory from a recent System State backup of a domain controller for AD
integrated dns zones. --- Steve

http://support.microsoft.com/?kbid=260371 -- see To repair the Active
Directory DNS record registration
http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 --- DNS
best practices.

Good morning,

This past Friday, I was having problems with my DNS. The short version is
that I ended up deleting our zones and am in the process of resolving that
problem. However, when I went to do this last Friday, a DNS server from
another organization showed up as the SOA for the newly created zone. I
had
been receiving alerts most of the day that this ip address was doing a
nmap
udp port sweep. I talked to the vendor this morning and they had no idea.
For more details, I'm providing the post to the dns forum where I'm trying
to resolve the issue of being able to recreate the zone. It seemed like we
were getting compromised.

DNS Post:
We have three DCs--DC1, DC2, and DC3. We had an AD Integrated zone for our
forward lookup zone. On DC3, the zone showed as a secondary zone, so I
tried
to change the type to an AD integrated zone (right-click, properties,
etc...), but it wouldn't allow it. I didn't write down the actual message,
but I was given two options: use the current zone or use the AD zone.
Neither option would work. I decided to delete the zone, thinking that
since
the zone was a secondary zone that it would just die and I would be
able
to
create an AD zone or that the AD zone would replicate over. That didn't
work. In fact, the AD zone disappeared on both DC1 and DC2.

Next, I panicked and posted my previous thread ("Urgent!!!").

I have just tried creating a Primary zone on DC1 and created secondary
zones
on DC2 & DC3. Then I ran Netdiag /fix. I wish I could say that I saved the
results to a text file, but I didn't. I did get it printed, though. The
DNS
test shows it failed (surprise) with several FATAL errors trying to
recreate
dns entries. I had set the zone to allow dynamic updates, accept
updates
from all servers and had manually entered NS, A and PTR records for all
DCs.
At this point, all zones have once again disappeared--the primary on
the
master and the two secondary zones.


Any clues would be appreciated.

 

[Herb Martin]

Steven,

Thanks for the post. It's looking like a rebuild of one DC (not a FSMO role
holder). I didn't allow enough disk space and that's causing problems.

It is nearly impossible to do that with a small domain.

The installation (DCPromo) claims it needs 1 Gig for
AD but only needs (less than) 100 MBytes.

This default size will handle thousands of users easily.

Aside
from that, there are a bunch of errors in the logs, I can't open ADU&C to
follow the guidance of the the dns group (Kevin). Armed with new info, I
don't think this is a security problem at this point. I will look at the
links below. Thanks again.

As Steve has said, you likely have DNS problems.

DNS servers do NOT "advertise" nor do they set themselves
up so either you or some other admin must have done this.

Check your DNS first -- it is the KEY to making AD work:


--
DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

....or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /serverC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

 

[Roger Abell]

Do not be so fast on saying you did not have a security problem.
You said "the IP" of some alien host
1. showed up as NS when you attempted to redefine the zone
for your AD
2. your zone on one AD had changed to secondary (a DC/DNS will
not do this, as you discovered when attempting to revert it)
3. you said "the IP" had been seen as the origin of nmap etc scans.
That all sounds to me like you have a security issue.
You perhaps had poisoned cache allowing the bad NS to show up
when the zone redefinition was attempted. You perhaps had a DNS
zone under outside control (sort of implies a DC also) and being used
perhaps for injection of some machine within network communications.

To recover fast, you can always collect together the netlogon.dns files
from each of the three DCs. These you would merge into a single file
in which you would need to adjust the SOA record so that it represents
only one of the NS (DCs) records.
You could use this as a std primary on one DC and secondary on the
other two, in order to bootstrap AD functionality between DCs.
Then change to AD integrated and make sure that you have set it to
allow only secured dynamic updates (and to protect against cache
pollution).

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA

Steven,

Thanks for the post. It's looking like a rebuild of one DC (not a FSMO role
holder). I didn't allow enough disk space and that's causing problems. Aside
from that, there are a bunch of errors in the logs, I can't open ADU&C to
follow the guidance of the the dns group (Kevin). Armed with new info, I
don't think this is a security problem at this point. I will look at the
links below. Thanks again.

See the link below which may help in rebuilding you dns zones. I suggest
that unless your organization requires otherwise, use only AD integrated
zones, do not allow zone transfers to other dns servers if not needed[ this
is not needed for AD integrated dns zones and never select "to any"], and
require secure updates unless you have a need to not use that. You may also
want to post in the win2000.dns newsgroup. Keep in mind that if you delete
an AD dns zone, that zone will be totally deleted from Active Directory and
not just that server. You also need to have some patience when rebuilding
your dns as replication will not be immediate to other dns servers/domain
controllers. Another alternative could be an authoritative restore of Active
Directory from a recent System State backup of a domain controller for AD
integrated dns zones. --- Steve

http://support.microsoft.com/?kbid=260371 -- see To repair the Active
Directory DNS record registration
http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 --- DNS
best practices.

Good morning,

This past Friday, I was having problems with my DNS. The short version is
that I ended up deleting our zones and am in the process of resolving that
problem. However, when I went to do this last Friday, a DNS server from
another organization showed up as the SOA for the newly created zone. I
had
been receiving alerts most of the day that this ip address was doing a
nmap
udp port sweep. I talked to the vendor this morning and they had no idea.
For more details, I'm providing the post to the dns forum where I'm trying
to resolve the issue of being able to recreate the zone. It seemed

like

we

our

 

[C Hall]

Roger and everyone,
Thanks for the replies.

Roger,
That was my first thought--DNS cache poisoning. The one reason I thought
that it just may be an internal configuration problem is that the zone I'm
using is already in use as an Internet domain space--a mistake on my part. I
talked to the third party to whom the address belongs and they are a ISP and
it belongs to one of their name servers. After running a trace, they said
they saw our address trying to do a zone transfer, which with the ids still
logging nmap sweeps it appears this is still going on. I'm trying to follow
the suggestions from Kevin in the DNS forum, but the fustrating thing is
that I'm told by my boss to not touch it until after Friday when our
auditors leave. He's concerned that any work on the domain will effect one
of our mission specific applications, but there's no way it can be. People
have local user accounts on that machine and have mapped drives to what they
need on that server. I'm no guru, but he just doesn't understand MS
networking. I'm stuck at the moment. How long can I leave this situation
limping? 60 days (tombstoning limit)?

Do not be so fast on saying you did not have a security problem.
You said "the IP" of some alien host
1. showed up as NS when you attempted to redefine the zone
for your AD
2. your zone on one AD had changed to secondary (a DC/DNS will
not do this, as you discovered when attempting to revert it)
3. you said "the IP" had been seen as the origin of nmap etc scans.
That all sounds to me like you have a security issue.
You perhaps had poisoned cache allowing the bad NS to show up
when the zone redefinition was attempted. You perhaps had a DNS
zone under outside control (sort of implies a DC also) and being used
perhaps for injection of some machine within network communications.

To recover fast, you can always collect together the netlogon.dns files
from each of the three DCs. These you would merge into a single file
in which you would need to adjust the SOA record so that it represents
only one of the NS (DCs) records.
You could use this as a std primary on one DC and secondary on the
other two, in order to bootstrap AD functionality between DCs.
Then change to AD integrated and make sure that you have set it to
allow only secured dynamic updates (and to protect against cache
pollution).

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA

Steven,

Thanks for the post. It's looking like a rebuild of one DC (not a FSMO role
holder). I didn't allow enough disk space and that's causing problems. Aside
from that, there are a bunch of errors in the logs, I can't open ADU&C to
follow the guidance of the the dns group (Kevin). Armed with new info, I
don't think this is a security problem at this point. I will look at the
links below. Thanks again.

See the link below which may help in rebuilding you dns zones. I suggest
that unless your organization requires otherwise, use only AD integrated
zones, do not allow zone transfers to other dns servers if not needed[ this
is not needed for AD integrated dns zones and never select "to any"], and
require secure updates unless you have a need to not use that. You may also
want to post in the win2000.dns newsgroup. Keep in mind that if you delete
an AD dns zone, that zone will be totally deleted from Active

Directory
and

not just that server. You also need to have some patience when rebuilding
your dns as replication will not be immediate to other dns servers/domain
controllers. Another alternative could be an authoritative restore of Active
Directory from a recent System State backup of a domain controller for AD
integrated dns zones. --- Steve

http://support.microsoft.com/?kbid=260371 -- see To repair the Active
Directory DNS record registration

tp://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382 ---
DNS

best practices.


Good morning,

This past Friday, I was having problems with my DNS. The short

version
is

that I ended up deleting our zones and am in the process of

resolving
that

problem. However, when I went to do this last Friday, a DNS server from
another organization showed up as the SOA for the newly created

zone.

I like

for

saved
the

 

[Roger Abell]

Well, I am not tightly envisioning your current state, but the
tombstone timelimit really mostly only impacts your ability
to restore AD authoritatively.

The nmap part is perhaps the most troubling.
Is the transfer that ISP reports seeing a transfer to or transfer
from their DNS server ? I assume they meant from theirs if
they said they see your DNS server IP attempting a transfer.

I will try to find time today to bump over to the DNS NGs
and catch up on your thread there.

However, I really do not understand why that ISPs DNS
is involved in transfer attempts (with your DNS servers?),
and I certainly do not see why you cannot flush its mention
out of the zone. At the very least, you could go into the
zone properties and explicitly list the NSs with which
zone tranfser is allowed, and the boss should be none the
wiser on that one as you would list all of and only your
DNS servers' IP. Also, consider a rule in the firewall
to kill packets to/from that IP. Keep in mind that with
AD integrated zone the SOA record on each DC will be
indicating itself. Check them all.

Is the ISP's DNS server one of those where they allow
their customers to manage zones through some interface?
If so, then I could perhaps understand its being "injected"
into your zone's authority.

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA

Roger and everyone,
Thanks for the replies.

Roger,
That was my first thought--DNS cache poisoning. The one reason I thought
that it just may be an internal configuration problem is that the zone I'm
using is already in use as an Internet domain space--a mistake on my part. I
talked to the third party to whom the address belongs and they are a ISP and
it belongs to one of their name servers. After running a trace, they said
they saw our address trying to do a zone transfer, which with the ids still
logging nmap sweeps it appears this is still going on. I'm trying to follow
the suggestions from Kevin in the DNS forum, but the fustrating thing is
that I'm told by my boss to not touch it until after Friday when our
auditors leave. He's concerned that any work on the domain will effect one
of our mission specific applications, but there's no way it can be. People
have local user accounts on that machine and have mapped drives to what they
need on that server. I'm no guru, but he just doesn't understand MS
networking. I'm stuck at the moment. How long can I leave this situation
limping? 60 days (tombstoning limit)?

Do not be so fast on saying you did not have a security problem.
You said "the IP" of some alien host
1. showed up as NS when you attempted to redefine the zone
for your AD
2. your zone on one AD had changed to secondary (a DC/DNS will
not do this, as you discovered when attempting to revert it)
3. you said "the IP" had been seen as the origin of nmap etc scans.
That all sounds to me like you have a security issue.
You perhaps had poisoned cache allowing the bad NS to show up
when the zone redefinition was attempted. You perhaps had a DNS
zone under outside control (sort of implies a DC also) and being used
perhaps for injection of some machine within network communications.

To recover fast, you can always collect together the netlogon.dns files
from each of the three DCs. These you would merge into a single file
in which you would need to adjust the SOA record so that it represents
only one of the NS (DCs) records.
You could use this as a std primary on one DC and secondary on the
other two, in order to bootstrap AD functionality between DCs.
Then change to AD integrated and make sure that you have set it to
allow only secured dynamic updates (and to protect against cache
pollution).

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA

Steven,

Thanks for the post. It's looking like a rebuild of one DC (not a FSMO role
holder). I didn't allow enough disk space and that's causing problems. Aside
from that, there are a bunch of errors in the logs, I can't open ADU&C to
follow the guidance of the the dns group (Kevin). Armed with new info, I
don't think this is a security problem at this point. I will look at the
links below. Thanks again.

See the link below which may help in rebuilding you dns zones. I suggest
that unless your organization requires otherwise, use only AD integrated
zones, do not allow zone transfers to other dns servers if not needed[
this
is not needed for AD integrated dns zones and never select "to

any"],
and

require secure updates unless you have a need to not use that. You may
also
want to post in the win2000.dns newsgroup. Keep in mind that if you delete
an AD dns zone, that zone will be totally deleted from Active Directory
and
not just that server. You also need to have some patience when rebuilding
your dns as replication will not be immediate to other dns servers/domain
controllers. Another alternative could be an authoritative restore of
Active
Directory from a recent System State backup of a domain controller

for
AD

integrated dns zones. --- Steve

http://support.microsoft.com/?kbid=260371 -- see To repair the Active
Directory DNS record registration
tp://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382 ---
DNS
best practices.


Good morning,

This past Friday, I was having problems with my DNS. The short version
is
that I ended up deleting our zones and am in the process of resolving
that
problem. However, when I went to do this last Friday, a DNS server from
another organization showed up as the SOA for the newly created

zone.

I
had
been receiving alerts most of the day that this ip address was

doing

a for

so

I be
able though.
The for
all on
the

 

[C Hall]

Thanks for the info, Herb. And the input RE: Subject in the DNS forum...I
hit panic mode;->

Steven,

Thanks for the post. It's looking like a rebuild of one DC (not a FSMO role
holder). I didn't allow enough disk space and that's causing problems.

It is nearly impossible to do that with a small domain.

The installation (DCPromo) claims it needs 1 Gig for
AD but only needs (less than) 100 MBytes.

This default size will handle thousands of users easily.

Aside
from that, there are a bunch of errors in the logs, I can't open ADU&C to
follow the guidance of the the dns group (Kevin). Armed with new info, I
don't think this is a security problem at this point. I will look at the
links below. Thanks again.

As Steve has said, you likely have DNS problems.

DNS servers do NOT "advertise" nor do they set themselves
up so either you or some other admin must have done this.

Check your DNS first -- it is the KEY to making AD work:


--
DNS for AD
1) Dynamic for the zone supporting AD
2) All internal DNS clients NIC\IP properties must specify SOLELY
that internal, dynamic DNS server (set.)
3) DCs and even DNS servers are DNS clients too -- see #2
4) If you have more than one Domain, every DNS server must
be able to resolve ALL domains (either directly or indirectly)

netdiag /fix

...or maybe:

dcdiag /fix

(Win2003 can do this from Support tools):
nltest /dsregdns /serverC-ServerNameGoesHere
http://support.microsoft.com/kb/q260371/

Ensure that DNS zones/domains are fully replicated to all DNS
servers for that (internal) zone/domain.

Also useful may be running DCDiag on each DC, sending the
output to a text file, and searching for FAIL, ERROR, WARN.

Single Label domain zone names are a problem Google:
[ "SINGLE LABEL" domain names DNS 2000 | 2003 microsoft: ]

 

[C Hall]

At the moment, my dns zone won't stay created. I'm going to try to get the
f/w rule created. See the thread: "active directory integrated zone delted,
can't create secondary zone" for more dns details...

Well, I am not tightly envisioning your current state, but the
tombstone timelimit really mostly only impacts your ability
to restore AD authoritatively.

The nmap part is perhaps the most troubling.
Is the transfer that ISP reports seeing a transfer to or transfer
from their DNS server ? I assume they meant from theirs if
they said they see your DNS server IP attempting a transfer.

I will try to find time today to bump over to the DNS NGs
and catch up on your thread there.

However, I really do not understand why that ISPs DNS
is involved in transfer attempts (with your DNS servers?),
and I certainly do not see why you cannot flush its mention
out of the zone. At the very least, you could go into the
zone properties and explicitly list the NSs with which
zone tranfser is allowed, and the boss should be none the
wiser on that one as you would list all of and only your
DNS servers' IP. Also, consider a rule in the firewall
to kill packets to/from that IP. Keep in mind that with
AD integrated zone the SOA record on each DC will be
indicating itself. Check them all.

Is the ISP's DNS server one of those where they allow
their customers to manage zones through some interface?
If so, then I could perhaps understand its being "injected"
into your zone's authority.

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA

Roger and everyone,
Thanks for the replies.

Roger,
That was my first thought--DNS cache poisoning. The one reason I thought
that it just may be an internal configuration problem is that the zone I'm
using is already in use as an Internet domain space--a mistake on my

part.

I
talked to the third party to whom the address belongs and they are a ISP and
it belongs to one of their name servers. After running a trace, they said
they saw our address trying to do a zone transfer, which with the ids still
logging nmap sweeps it appears this is still going on. I'm trying to follow
the suggestions from Kevin in the DNS forum, but the fustrating thing is
that I'm told by my boss to not touch it until after Friday when our
auditors leave. He's concerned that any work on the domain will effect one
of our mission specific applications, but there's no way it can be. People
have local user accounts on that machine and have mapped drives to what they
need on that server. I'm no guru, but he just doesn't understand MS
networking. I'm stuck at the moment. How long can I leave this situation
limping? 60 days (tombstoning limit)?

ADU&C
to

info,

I

don't think this is a security problem at this point. I will look at the
links below. Thanks again.

See the link below which may help in rebuilding you dns zones. I suggest
that unless your organization requires otherwise, use only AD integrated
zones, do not allow zone transfers to other dns servers if not needed[
this
is not needed for AD integrated dns zones and never select "to any"],
and
require secure updates unless you have a need to not use that. You may
also
want to post in the win2000.dns newsgroup. Keep in mind that if you
delete
an AD dns zone, that zone will be totally deleted from Active Directory
and
not just that server. You also need to have some patience when
rebuilding
your dns as replication will not be immediate to other dns
servers/domain
controllers. Another alternative could be an authoritative restore of
Active
Directory from a recent System State backup of a domain controller for
AD
integrated dns zones. --- Steve

http://support.microsoft.com/?kbid=260371 -- see To repair the Active
Directory DNS record registration

tp://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382 ---

DNS
best practices.


Good morning,

This past Friday, I was having problems with my DNS. The short version
is
that I ended up deleting our zones and am in the process of resolving
that
problem. However, when I went to do this last Friday, a DNS server
from
another organization showed up as the SOA for the newly created zone.
I
had
been receiving alerts most of the day that this ip address was

doing

a
nmap
udp port sweep. I talked to the vendor this morning and they had no
idea.
For more details, I'm providing the post to the dns forum where I'm
trying
to resolve the issue of being able to recreate the zone. It seemed
like
we
were getting compromised.

DNS Post:
We have three DCs--DC1, DC2, and DC3. We had an AD Integrated

zone
for

our
forward lookup zone. On DC3, the zone showed as a secondary

zone,

so thinking
that

primary

on

 

[Herb Martin]

That was my first thought--DNS cache poisoning. The one reason I thought
that it just may be an internal configuration problem is that the zone I'm
using is already in use as an Internet domain space--a mistake on my part.

First, your internal zone using an internal name the
same as a public name doesn't really interact with
cache poisoning.

Holding your zones, it distinct from the resolution
you do for clients (beyond those zones) and poisoning
is worked through that resolution.

 

[C Hall]

Thanks for the lesson, Herb.

part.

First, your internal zone using an internal name the
same as a public name doesn't really interact with
cache poisoning.

Holding your zones, it distinct from the resolution
you do for clients (beyond those zones) and poisoning
is worked through that resolution.

 

[Herb Martin]

Thanks for the lesson, Herb.

 

[C Hall]

I hear you....it seems that one of the main problems is that on our F/W
there was a statement to NAT our dns server ip to an outside address and
that's why it was trying to transfer the public zone to our private zone.
Not sure how/when that happened, but am glad to know what needs to happen to
resolve the problem.

Chris

 

[Herb Martin]

I hear you....it seems that one of the main problems is that on our F/W
there was a statement to NAT our dns server ip to an outside address and
that's why it was trying to transfer the public zone to our private zone.
Not sure how/when that happened, but am glad to know what needs to happen to
resolve the problem.

Ok, that sounds like it might fix it or at least change
the symptoms to something simple.