DNS Forward lookup problem - now having problems with a period (.)

Discussion in 'DNS Server' started by pbrill1, Aug 15, 2005.

  1. pbrill1

    pbrill1 Guest

    Recently, we had a DNS server go down, and in the process, the forward lookup
    zone was deleted. We are a relatively small shop, so we were able to
    recreate the forward lookup zone on our AD-integrated DNS Server (which also
    holds all 5 FSMO roles), by looking at the reverse lookup zone entries.

    the forward lookup zone was recreated to look something like this:
    company.com

    After this was done, we have had sporadic problems on our network. I am
    wondering if I should have created our forward lookup zone as " company.com.
    " (with a period after the .com )

    Any assistance would be greatly appreciated!

    Additional notes to assist:

    I ran the "netdiag /debug" utility, and found NUMEROUS errors that are all
    similar. One section looks as follows:
    ***************************************************
    CHECK NAME DomainDnsZones.homeruninn.net. on DNS server 10.0.0.9
    ***************************************************
    The record is different on DNS server '10.0.0.9'.
    DNS server has more than one entries for htisname, usually this means that
    there are multiple DCs for this domain.
    Your DC entry is one of them on DNS server '10.0.0.9', no need to re-register.
    -------------------------------------------
    The record on you r DC is
    DNS Name = Domain DnsZones.homeruninn.net.
    DNS Data =
    A 10.0.0.9

    The record on DNS server 10.0.0.9 is:
    DNS Name = DomanDnsZones.homeruninn.net
    DNS Data =
    A 10.0.0.9
    A 10.0.2.3

    (ALSO: Again, we are using Windows 2003 AD-Integrated DNS.
    The 10.0.0.9 server holds all the FSMO roles
    the 10.0.2.3 server is a remote server; it does not seem to be able to
    replicate the forward lookup zone

    I'm just not sure how to best resolve the situation of
    company.com
    vs.
    company.com.

    SUGGESTIONS TO RESOLVE THIS PROBLEM WOULD BE GREATLY APPRECIATED!
     
    pbrill1, Aug 15, 2005
    #1
    1. Advertisements

  2. pbrill1

    Herb Martin Guest

    After this was done, we have had sporadic problems on our network. I am
    There is an implied period there whether you put it in physically
    or not -- some tools would require it be manually present (manual
    zone files, nslookup) to be 'official' but the MMC usually is usually
    DWIM (do what I mean) and gets it right.

    The zone for AD needs to be dynamic and EVERY machine for the
    domain needs to be using (this) INTERNAL DNS servers SOLELY.
    Chances are you have some that are still pointing at the lost DNS
    server (maybe even the DC itself.)

    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 /server:DC-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: ]
     
    Herb Martin, Aug 16, 2005
    #2
    1. Advertisements

  3. This looks like part of a normal netdiag output.
    If you post the output from netdiag /test:dns /v from both DCs and run
    dcdiag /e /v from both DCs and look for errors.

    --
    Best regards,
    Kevin D4 Dad Goodknecht Sr. [MVP]
    Hope This Helps
    ===================================
    When responding to posts, please "Reply to Group"
    via your newsreader so that others may learn and
    benefit from your issue, to respond directly to
    me remove the nospam. from my email address.
    ===================================
    http://www.lonestaramerica.com/
    ===================================
    Use Outlook Express?... Get OE_Quotefix:
    It will strip signature out and more
    http://home.in.tum.de/~jain/software/oe-quotefix/
    ===================================
    Keep a back up of your OE settings and folders
    with OEBackup:
    http://www.oehelp.com/OEBackup/Default.aspx
    ===================================
     
    Kevin D. Goodknecht Sr. [MVP], Aug 16, 2005
    #3
  4. pbrill1

    pbrill1 Guest

    Thanks, both Herb and Kevin, for your input - the tests have been very
    helpful. In one case, it found a MESSENGER service on both DC's that was
    disabled, which I started on both machines.

    I've noticed that I'm having FRS errors - that the local DC cannot resolve
    the remote DC name (NtFRS error 13508). (the local and remote dc's have FRS
    running, too).

    Is there an FRS tool?

    As a temporary fix for the remote site, I added a forward lookup zone with
    the same name, company.net , and added a few host (A) records, which
    temporarily got the computers in the remote area to work.

    Should I remove the dupliate forward lookup zone from the remote DC? Will
    the replication process (if I can get it working again) sync up with this
    duplicated forward lookup zone?

    If I can 'repair' the duplicate forward lookup zone, I've noticed that it
    doesn't have the IP address of the local DC in the ForestDNSZone and
    DomainDNSZone. Should I add these entries to the remote DC's duplicate
    forward lookup zone, or am I creating "Kerberos" trouble by doing so?
     
    pbrill1, Aug 16, 2005
    #4
  5. In
    Registration into DNS is automatic by the Netlogon service. Depending on the
    problem would dictate how to "repair" this. Replication is done via AD's
    replication process. If you're saying the ForestDNSZone and DomainDNSZone
    partitions are not replicating, then it's telling me you do have a
    replication problem and nothing really to repair the FLZ.

    There's an frsdiag tool.
    Active Directory Diagnostics, Troubleshooting, and Recovery in Windows
    Server 2003, April 19, 2004:
    http://www.microsoft.com/technet/community/chats/trans/windowsnet/wnet0419.mspx

    Using Ultrasound to Monitor and Troubleshoot File Replication Service (FRS),
    February 4, 2003:
    http://www.microsoft.com/technet/community/chats/trans/windowsnet/wnet0204.mspx

    1. Can you describe your topology?
    2. How many domains do you have?
    3. How did you set the replication scopes in the zone's properties in DNS on
    each DNS server?
    4. What sort of WAN or ISP link do you have (T1, ADSL, SDSL, Cable, etc)?
    5. The router/VPN devices you are using?
    6. The MTU settings in the router (or if they've been altered).
    7. Please provide an unedited ipconfig /all from 10.0.0.9 and10.0.2.3

    --
    Regards,
    Ace

    Please direct all replies ONLY to the Microsoft public newsgroups
    so all can benefit.

    This posting is provided "AS-IS" with no warranties or guarantees
    and confers no rights.

    Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
    Microsoft Windows MVP - Windows Server - Directory Services
    Infinite Diversities in Infinite Combinations.
    =================================
     
    Ace Fekay [MVP], Aug 22, 2005
    #5
  6. pbrill1

    pbrill1 Guest

    Thank you for the links - there seems to be good information to build my
    knowledge AD diagnostics and FRS. To address your response (a question
    remains at the end of this, too!):

    1. Can you describe your topology?
    W2K3 Single Forest/Single Domain
    They had been "only to servers listed on the name servers tab", with the
    2 DC's listed in the name server's tab

    I modified it to "only to the following servers" and placed only 10.0.2.3 in
    the 10.0.0.9 DNS's tab, and 10.0.2.3 in the 10.0.0.9 server's tab

    The 10.0.0.9 server is on a T1 link - it connects via a VPN tunnel
    to the remote 10.0.2.3 server, which runs on cable (we are working on
    bringing the remote DC to T1, but not until mid-September)

    Question : * Could our non-T1 connection at the remote server be so 'slow'
    as to cause 13508 errors?? What should change, if this were so?
    - CISCO PIX devices
    - the settings on the routers have not been altered since the
    replication was working successfully
    Windows IP Configuration

    Local Server
    Host Name . . . . . . . . . . . . : primarydc
    Primary Dns Suffix . . . . . . . : internalnetwork.net
    Node Type . . . . . . . . . . . . : Hybrid
    IP Routing Enabled. . . . . . . . : No
    WINS Proxy Enabled. . . . . . . . : No
    DNS Suffix Search List. . . . . . : internalnetwork.net

    Ethernet adapter Local Area Connection:
    Connection-specific DNS Suffix . :
    Description . . . . . . . . . . . : HP NC3163 Fast Ethernet NIC
    Physical Address. . . . . . . . . : 01-05-02-41-0D-A3
    DHCP Enabled. . . . . . . . . . . : No
    IP Address. . . . . . . . . . . . : 10.0.0.9
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 10.0.0.2
    DNS Servers . . . . . . . . . . . : 10.0.0.9
    10.0.2.3
    Primary WINS Server . . . . . . . : 10.0.0.9
    Secondary WINS Server . . . . . . : 10.0.2.3


    Remote Server
    Windows IP Configuration
    Host Name . . . . . . . . . . . . : secondarydc
    Primary Dns Suffix . . . . . . . : internalnetwork.net
    Node Type . . . . . . . . . . . . : Hybrid
    IP Routing Enabled. . . . . . . . : No
    WINS Proxy Enabled. . . . . . . . : No
    DNS Suffix Search List. . . . . . : internalnetwork.net
    Ethernet adapter Local Area Connection:
    Connection-specific DNS Suffix . :
    Description . . . . . . . . . . . : HP NC7760 Gigabit Server Adapter
    Physical Address. . . . . . . . . : 01-2F-25-CF-43-3E
    DHCP Enabled. . . . . . . . . . . : No
    IP Address. . . . . . . . . . . . : 10.0.2.3
    Subnet Mask . . . . . . . . . . . : 255.255.255.0
    Default Gateway . . . . . . . . . : 10.0.2.2
    DNS Servers . . . . . . . . . . . : 10.0.2.3
    10.0.0.9
    Primary WINS Server . . . . . . . : 10.0.2.3
    Secondary WINS Server . . . . . . : 10.0.0.9


    Additional note: Since my previous message, I replicated DNS info to the
    remote DC by unchecking "store zone in AD", making the local the primary,
    and the remote the secondary DNS server. It worked - although for security
    reasons, I'd like to return the DNS Servers to AD-integrated, secure only!

    I also checked dcdiag, netdiag, repadmin, and frsdiag utilities, and was
    able to clean up a few instances of our "dctemp" dc that was removed from our
    network.

    REMAINING PROBLEM: I am STILL getting 13508 messages, with only occasional
    13509 messages.

    Any suggestions to improve the quality of our site link/dns replication
    would be much appreciated.
     
    pbrill1, Aug 22, 2005
    #6
  7. In
    Thanks for posting the info.

    The ipconfigs look good, as I first thought they would be. What I mean about
    the "replication scope" is the setting in the zone properties, general tab,
    AD integration scope, meaning in what part of the AD database is the zone
    set to be stored in, not actually the zone transfer tab, which is different
    and doesn't apply to AD integrated zones unless there is a secondary zone
    pulling from it, but isn't the case here.

    What could be happening are two things:
    1. PIX is not allowing querying thru it based on EDNS0 support. Win2003
    implemented the new industry standard to allow UDP query response traffic
    greater than 512 bytes. The PIX device will need to be upgraded to support
    this new industry implementation. Read more on it and how to:

    828263 - DNS query responses do not travel through a firewall in Windows
    Server 2003:
    http://support.microsoft.com/?id=828263

    832223 - Some DNS Name Queries Are Unsuccessful After You Upgrade Your DNS
    Server to Windows Server 2003:
    http://support.microsoft.com/?id=832223

    828731 - An External DNS Query May Cause an Error Message in Windows Server
    2003:
    http://support.microsoft.com/?id=828731


    OR

    2. Cable is not allowing querying traffic inbound. Many cable providers do
    not allow server type of traffic inbound to eliminate any possiblity of
    subscribers running servers on the connection. Either that, or in
    combination with, the slow 'upload' speed that the cable companies throttle
    bandwidth. Sure, download is 3-6 mbps, but you would be lucky if the upload
    speed is greater than 384 kbps. That can cause problems.

    So it's either/and/or between the cable link and PIX.

    Ace
     
    Ace Fekay [MVP], Aug 23, 2005
    #7
    1. Advertisements

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 (here). After that, you can post your question and our members will help you out.