• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1900
  • Last Modified:

Domain of sender address does not resolve 451 4.1.8

My company has been having a variety of email issues lately which I believe are DNS or record related but, I am uncertain what exactly is wrong.  We have a variety of different symptoms that have occurred in the last few weeks or so.

Certain incoming emails do not come through to all recipients.  This is intermittent and from senders outside of our domain and sometimes even from users within our domain.  Checking against the Exchange Message Tracking Center confirms that we received the emails and that they were delivered and stored to the local mailbox but, there is also an application error on Exchange at the same time with the message "Domain of sender address does not resolve".  

My company does a lot of business with wal-mart.com.  Lately (as of last week) we have been unable to send out any emails to them.  All emails get a Delivery Status Notification warning and become Undeliverable when they time out.

I was told by a third party to visit http://network-tools.com and rather than getting a response back from ns.lkeeco.com ns1.lkeeco.com and ns2.lkeeco.com I got this...

Retrieving DNS records for lkeeco.com...
Attempt to get a DNS server for lkeeco.com failed: Timed out

I have viewed several EE questions related to issues similar to this and the OP's were told to check their DNS records or MX/A/PTR records.  I am unsure of what needs to be added or what could have changed when we renewed our domain name recently (with /www.networksolutions.com if that matters) because everything was working fine a few months ago.

I would be happy to provide any other additional information about the situation that experts might feel useful in assisting me with this issue.  I am currently waiting to talk to Network Solutions Technical Support to see if they can direct me to the issue(s).

Thank you for your assistance.
0
kflaw3
Asked:
kflaw3
  • 26
  • 24
  • 17
2 Solutions
 
Hypercat (Deb)Commented:
There is a problem with your DNS servers - they aren't responding properly. I got no response using DNSStuff.com also.  Where are these servers located? Do you host your own public DNS zone?
0
 
kflaw3Author Commented:
The servers are located locally.  I do not know what you mean by hosting our own public DNS zone.  Where would I go to look that up?
0
 
schapsCommented:
in your domain registration, your name servers are listed as:

   Name Server: NS.LKEECO.COM
   Name Server: NS1.LKEECO.COM
   Name Server: NS2.LKEECO.COM

The first two do not respond to pings, the third one can be pinged, but does not resolve your domain name. Who (in your company) manages your domain name? That's the place to start.
0
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

 
kflaw3Author Commented:
Using a computer from outside our network I am able to ping all 3 Name Servers.  I have access to the domain name management (the previous IT set it up).

How should our records be setup to correct this?  Initially we had 2 A records in DNS forward lookup pointing to NS.LKEECO.COM and NS2.LKEECO.COM.  We also had a PTR record in DNS reverse lookup pointing to NS1.LKEECO.COM.  I am not familiar with DNS setup in the least so please excuse me.
0
 
Hypercat (Deb)Commented:
You need to find out where the servers that are named ns1.lkeeco.com, ns2.lkeeco.com and ns3.lkeeco.com are physically located and managed.  These are the servers that host your public DNS zone, and they are the ones that are queried by the outside world to find your email server.

These servers have these IP addresses:

ns1.lkeeco.com. [207.90.141.2]
ns2.lkeeco.com. [71.6.36.75]
ns.lkeeco.com. [12.144.183.99]

I did a trace route to 207.90.141.2 and it appears to be at telepacific.net. Is this your ISP?

The trace route to 71.6.36.75 ends at telepacific.net also.

12.144.183.99 traces to a server/router at att.net but then gets blocked by a firewall, so I wasn't able to trace it back to the exact end point.

The problem comes when you try to do a DNS lookup at any of these servers.  All of them seem to respond initially but the request times out when trying to look up your domain name, or a response comes back saying that it couldn't find your domain name.

0
 
Hypercat (Deb)Commented:
You can't manage this problem from inside your own domain.  You need to contact the companies who are managing these servers and find out why they aren't responding properly.  

If you're talking about the set up of your name servers at Network Solutions, I looked at those records and that's fine. Again, the problem is not that your domain is pointing to these servers for your public DNS zone, the problem is that these servers aren't responding. My guess is that your DNS zone has been somehow removed from these servers, or there's a problem with the ISP that is providing these services to you.
0
 
kflaw3Author Commented:
Telepacific is indeed our ISP.  

I am sure there must be some kind of configuration error in our DNS but I do not know what to look for.
0
 
kflaw3Author Commented:
I am also in the process of contacting Telepacific and will report back here with any information they are able to provide.  Thank you for your assistance and I will let you know what happens.
0
 
Hypercat (Deb)Commented:
Do you have access to your DNS zone on the telepacific.net servers? This is where you need to look.  If you can't get to a control panel to manage these DNS records, then you need to call Telepacific and get them to do it, or get them to tell you how you can do it yourself.  If you can get access to these records, then what you need to do is have at least three DNS records on those servers for your email:

A host (A) record resolving your firm's external IP address to your mail server name. For example, if your external IP address is 1.2.3.4 and your mail server name is "mail.lkeeco.com," then your A record would be for the host name "mail" and the IP address 1.2.3.4.

Then you need to have an MX record that says that your mail server name is "mail.lkeeco.com."

Then you need to have a PTR (rDNS) record pointing the reverse IP address 4.3.2.1.in-addr.arpa to "mail.lkeeco.com" also.

I can't tell you exactly how to do this, since I don't know what type of software your ISP is using to manage the DNS zone nor if you actually will have access to it.
0
 
schapsCommented:
You apparently host the website on your own network, as lkeeko.com resolves to 71.6.36.67, and Keeko owns the block 71.6.36.64 to 71.6.36.79. You also have a name server in this block, therefore hosted on your network, which is not responding:

71.6.36.75 or ns2.lkeeco.com
That's what you have closest access to right now, so I would find out what is going on with that server:

nslookup lkeeco.com 71.6.36.75
;; connection timed out; no servers could be reached

wild guess that ns2 was setup as failover in case telepacific dns went down, but it's not been kept up.
0
 
kflaw3Author Commented:
I pulled this from our DNS server.  Let me know if you see any obvious errors.  Frontbridge is our spam filter.  I apologize if there is unnecessary information in there or possibly not enough information.  If you see something out of line let me know.

Forward Lookup lkeeco.com

Name                              Type       Data
(same as parent folder)  MX         [10] mail.global.frontbridge.com
(same as parent folder)  NS         ad02.lkeeco.com
mail                                  CNAME   exchange-uc.lkeeco.com
(same as parent folder)  NS          ad02.lkeeco.com
(same as parent folder)  NS          ns2.lkeeco.com
ns                                    A            71.6.36.75
ns1                                  A            71.6.36.75
ns2                                  A            71.6.36.75
(same as parent folder)  SOA       [76433], ad02.lkeeco.com., admin.


Reverse lookup 36.6.71 in-addr.arpa

Name                                Type       Data
75                                     PTR         ns.lkeeco.com
75                                     PTR         ns1.lkeeco.com
75                                     PTR         ns2.lkeeco.com
75                                     PTR         vpn.lkeeco.com
(same as parent folder)   MX          [20] exchange-uc.lkeeco.com
(same as parent folder)   NS           ad02.lkeeco.com
(same as parent folder)  SOA         [14], ad02.lkeeco.com., admin.lkeeco.com.
exchange-uc                   CNAME    71.6.36.73
lkeeco                              MX           [30] exchange-uc.lkeeco.com
mail                                  CNAME    exchange-uc.lkeeco.com
0
 
Hypercat (Deb)Commented:
Again, there seems to be some confusion between internal and external DNS servers.  This looks like it is your internal DNS zone running your AD domain using ad02.lkeeco.com and ns2.lkeeco.com as name servers. Could you please explain what your internal IP addressing scheme is?

If it's your internal zone, then you should not have any records (A, NS or PTR) for 71.6.36.75. Certainly having an internal AD server named "ns2" and also a separate host record for "ns2" that points to an external IP address would be a problem.

Also, the MX record should not be there pointing to the Frontbridge server. You could have an MX record pointing to your Exchange server, exchange-uc.lkeeco.com, but this is not necessary internally. I'm also not sure why it appears that you have two NS records for ad02.lkeeco.com. And why you would have a CNAME record pointing "exchange-uc.lkeeco.com" to "mail" seems odd also. Do you have a server named "mail" with a host record anywhere on your domain?
0
 
Hypercat (Deb)Commented:
Sorry - I posted that backwards (LOL).  You have a CNAME record for "mail" that points to "exchange-uc," not the other way around. But I don't see any A record for "exchange-uc".
0
 
schapsCommented:
Something I find odd, but not sure it's related at all - your domain resolves to  71.6.36.67 (when it resolves, that is), and if you go to http://71.6.36.67 , you get a "bad request (invalid hostname)" error. That is not so odd, because your webserver probably does not have a binding for the IP address (which would be a good idea, but anyway...); if you go to http://71.6.36.73, your website shows up just fine. In fact, it changes the URL to the domain, all nice and pretty.
0
 
kflaw3Author Commented:
@hypercat
This was pulled from our internal DNS server so you are correct about our network here.  If there is still some kind of an issue related to Telepacific's servers I will have to wait on that since I have not heard back from them yet.

Not sure why I forgot to add this but 71.6.36.75 is our VPN.  There is also an A record for exchange-uc it is assigned a local address of 192.168.135.26.

The two NS records of AD02 was just a copy error on my part.

What should I be removing from this DNS then?  It sounds like you said basically anything that points to 71.6.36.75 should be removed (although probably not our VPN but I neglected to mention that).

Why should the MX record not point to Frontbridge?  Again I did not set this up so I am unsure why it was setup like this in the first place.

Also Schaps internally I cannot get to our site unless I go to keecoweb but I am glad at least that works for you.

Still waiting on Telepacific.  Thanks again for the assistance folks.
0
 
Hypercat (Deb)Commented:
If your internal IP addressing range is 192.168.135.x, then you should not have any records on your internal DNS server that point to any IP addresses/host names except those on the 192.168.135.x subnet. Also, you should not have any host names in your internal DNS zone except for those that point to actual internal hosts.  NS records are very important specifically because they control the roles of your internal DNS servers, replication between domain controllers on your internal domain, etc.  Basically, your internal DNS zone should only contain records that are relevant to your Active Directory domain.  If your internal domain name and external domain name are the same, there can be a few exceptions to this rule, but at this point you should remove any references to anything other than internal hosts. BIG CAUTION:  DON'T MESS WITH ANY OF THE RECORDS WITH A TYPE OF "NS", as these are required to run your internal Active Directory domain.

Assuming that your Exchange organization is configured properly, you don't need an internal MX record to the Frontbridge server because the Frontbridge server is an incoming mail server only. You DO need an MX record for it on your external (public) DNS zone but not internally.  Internal clients (probably Outlook?) connect to the exchange-uc server over a TCP/IP connection using that address and they use the MAPI protocol to send and receive mail.  An MX record in these conditions is superfluous, although it doesn't really hurt anything.

You normally wouldn't need to use the 71.6.36.75 IP address for your VPN server, either, internally. Are you using VPN connections internally for some reason?
0
 
schapsCommented:
There are things you could do while you are waiting - if you are the keeper of the domain name, you need to fix ns2 which points to 71.6.36.75 from the outside. Your internal DNS should not reference an outside IP address, for starters, but the main point is that the outside world expects to be able to contact 71.6.36.75 to get domain name resolution, because it's in your external dns records. So, something needs to be fixed, regardless of the other two name servers that telepacific is responsible for.
0
 
Hypercat (Deb)Commented:
One thing I just noticed that you need to check carefully is this:

You have an internal NS record for a server named "ns2.lkeeco.com."  You don't want to remove this NS record, as it is part of your Active Directory domain, and that would be a really bad thing to do.   The A record for this host is pointing to "71.6.36.75."  You need to find out what the correct internal IP address of this server is, and then edit the A record and point it to that address instead of 71.6.36.75.

Schaps is correct, except that in reality, since this is an internal DNS server on your own Active Directory domain, no one from the outside world should be able to get to this server for ANYTHING.  This server should be used for internal DNS resolution ONLY.  So, again, once you get access to your external public DNS zone, you need to remove any reference to the DNS server named "ns2" and use only the external Telepacific servers for your public DNS zone. This is a security issue that is important - DNS servers can be compromised and you don't want that to happen to your internal AD DNS server.
0
 
schapsCommented:
I was just leaving room for the possibility that one of their IP points to (or at one time pointed to) a DNS server which they host that has no access to their internal lan. It's not a bad idea to do this, and, if this had been functional, could have greatly lessened the impact of telepacific's outage in this case. If they have IPs and a small server to spare, but don't want to pay for better external DNS, it's an option.
0
 
Hypercat (Deb)Commented:
You're right, schaps, and I did think about that after I posted my comment. However, since this DNS server is listed as an AD name server, it pretty much has to be an internal domain controller, and that wouldn't be a machine where you would want to allow access externally for DNS resolution. Of course, I'm assuming that this is an Active Directory DNS domain, which is a pretty good assumption given that they are running Exchange 2003. However, I also realized after my post that this could be wrong, but I hope kflaw3 will correct me on that if that's the case.
0
 
kflaw3Author Commented:
"You need to find out what the correct internal IP address of this server is, and then edit the A record and point it to that address instead of 71.6.36.75."  

How do I go about doing this?  Pinging ns2.lkeeco.com just results in 71.6.36.75.  Where should I look to find the internal IP?
0
 
Hypercat (Deb)Commented:
Do you know where this server is located physically?  Is it at your local site somewhere? It may actually be assigned that IP address, which would be distinctly odd if your internal subnet is the 192.168.135.x as we think.
0
 
kflaw3Author Commented:
Your assumptions about our architecture are correct.  Still waiting on Telepacific.  I have not yet removed any DNS records but, from what I understand you are saying I should remove the A records that reference NS, NS1, and NS2 and point to 71.6.36.75.  Does that also mean I remove the PTR records from reverse lookup that correspond to NS, NS1, and NS2 as well?

Anything else that seems safe to remove?  I am not touching any NS records as of now.
0
 
kflaw3Author Commented:
I think I misunderstood what you were asking initially.  I believe our ad02 server is the server you are referring to and that does have a local IP that I can use to replace the 71.6.36.75 record.
0
 
Hypercat (Deb)Commented:
Yes, you would want to remove those A records, except for the one for NS2, since that seems to be an internal server. I would say you should leave that one alone until we figure out where that server is and whether it should really have an IP address on the 192.168.135.x subnet. And you would remove the corresponding PTR records as well.

I'd also check on one of your internal workstations to see what they are using for IP addresses, default gateway and name resolution. Just open a command prompt and run "ipcofig /all" and post the results.
0
 
Hypercat (Deb)Commented:
Are you saying that there isn't a separate physical server at your location that is named "ns2"?
0
 
kflaw3Author Commented:
Windows IP Configuration

        Host Name . . . . . . . . . . . . : del-hr-rosalind
        Primary Dns Suffix  . . . . . . . : lkeeco.com
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : lkeeco.com
                                            lkeeco.com

Ethernet adapter Local Area Connection 3:

        Connection-specific DNS Suffix  . : lkeeco.com
        Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet
        Physical Address. . . . . . . . . : 00-10-18-0B-39-DE
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . : 192.168.135.56
        Subnet Mask . . . . . . . . . . . : 255.255.255.0
        Default Gateway . . . . . . . . . : 192.168.135.1
        DHCP Server . . . . . . . . . . . : 192.168.135.16
        DNS Servers . . . . . . . . . . . : 192.168.135.82
                                            192.168.135.15
                                            66.7.224.17
                                            66.7.224.18
        Primary WINS Server . . . . . . . : 192.168.135.16
        Lease Obtained. . . . . . . . . . : Monday, April 04, 2011 10:22:02 AM
        Lease Expires . . . . . . . . . . : Tuesday, April 05, 2011 10:22:02 AM
0
 
kflaw3Author Commented:
To my knowledge there is no server at this site named NS2.  Does that mean all of the NS, NS1, and NS2 are hosted by Telepacific?
0
 
Hypercat (Deb)Commented:
OK. Let's look at it from this perspective.  What are the names of the servers that are at IP addresses 192.168.135.82, 192.168.135.15, and 192.168.135.16?
0
 
schapsCommented:
Does that mean all of the NS, NS1, and NS2 are hosted by Telepacific?
NS and NS1 are apparently hosted by Telepacific. NS2 is non-existent. Since you use the same internal domain name as you use for external website and email, you have to be really careful to keep your internal and external DNS separate.

The deeper this goes, the weirder it gets. Doing a reverse lookup on 207.90.141.2 (which should return ns1.lkeeco.com) yielded this:
nslookup 207.90.141.2
Non-authoritative answer:
2.141.90.207.in-addr.arpa      name = www.lkeeco.com.


Moreover, doing a whois on the IP 12.144.183.99 tells us that it belongs to a block of IPs assigned to Costco Wholesale. (!!!)

As long as we're making a list of things to fix, your ipconfig you pasted above shows nameservers assigned to DHCP clients are two internal ones (192.168.135.82, 192.168.135.15), then two external nameservers (66.7.224.17, 66.7.224.18).
In your situation, you're going to want to remove those eternal name servers from the DHCP assigned to workstations on your lan. You only put externals in the server's DHCP configuration as forwarders, but all DNS requests on your internal network should be resolved by your own servers.                                        



0
 
kflaw3Author Commented:
ad02 82.
whucsvr 15.
ad04 16.
0
 
Hypercat (Deb)Commented:
OK.  We're pretty sure that ad02 is a domain controller, so let's see if we can find any other DCs on your domain.  Open the DNS Management console and follow these steps:

1.  Click on the DNS server name to expand it, then click on Forward Lookup Zones to expand that.
2.  You should see an object named _msdcs.lkeeco.com. Click on that to expand it.
3.  Under that you should see a folder named dc; click on it to expand it.
4.  Then click on the folder named tcp to expand that.
5.  In the "tcp" folder, you should see a "_kerberos" and a "_ldap" record for each domain controller.

Post back here with the server names that you see there.  
0
 
Hypercat (Deb)Commented:
Also at some point in this process, we need to follow schaps comment regarding removing the external nameservers - 66.7.224.17 and .18) from the list of DNS servers being automatically provided through DHCP to your workstations.  That's a side issue for now, but I don't want to forget about it either. Let's first make sure your domain and internal DNS are functioning properly.
0
 
kflaw3Author Commented:
So I have gotten quite a bit of feedback from various sources.

-------------

I think the problem is that ns still points to an old IP address that no longer exists. How do we get this changed??

NNSns.lkeeco.com12.144.183.9924 hrs         ß old shoreline public ip

NNSns1.lkeeco.com207.90.141.224 hrs

NNSns2.lkeeco.com71.6.36.7524 hrs

------------

From what I’m seeing, we are unable to resolve your email domain when we do a reverse lookup on your sending email IP. I’ve had my vendor take a look at it and this is what he came back with.



Tempfails on their domain appear to be occurring due to what appear to be issues with DNS. Their domain appears to have 3 name servers responsible, but at least a couple of those servers do not appear to be responsive.

lkeeco.com.             21158   IN      NS      ns1.lkeeco.com. (appears to not be responsive)

lkeeco.com.             21158   IN      NS      ns2.lkeeco.com.

lkeeco.com.             21158   IN      NS      ns.lkeeco.com. (appears to not be responsive)

In some brief testing we performed, it appeared that only ns2.lkeeco.com was responsive. The challenge here is that as the system receives a message, it does a reverse DNS check on the incoming connection to determine whether or not it is valid. Since some of the DNS servers appear to be unresponsive, the message is tempfailed until the DNS responds as expected.

------------

I believe that 12.144 IP has likely been reassigned but we are still somehow redirecting to that IP.  As an aside someone @wal-mart.com mentioned we might be blacklisted but I could not determine that when I went to http://www.mcafee.com/threat-intelligence/domain/default.aspx?domain=lkeeco.com.
0
 
kflaw3Author Commented:
DC's.

ad01b
ad02
ad04
0
 
schapsCommented:
ns2, resolving to 71.6.36.75, is your vpn endpoint but also seems to resolve dns externally (sometimes). And it appears to be your exchange server (192.168.135.26) that is doing it. Are you aware of external DNS service running on that server?
0
 
schapsCommented:
someone is doing something, because ns.lkeeco.com is now resolving to 71.6.36.75, too. You really need to figure out what is going on with that exchange server.
0
 
kflaw3Author Commented:
I believe a colleague of mine added in a NS and PTR record for ns.lkeeco.com back on to AD02 to test something.
0
 
schapsCommented:
that should not make any difference externally. I think I asked before, but who is in charge of your domain's registration at Network Solutions? The whois refers to a Kevin Lawrence?
Most probably, you need to login to the lkeeco.com account at Network Solutions to change the nameservers.
0
 
kflaw3Author Commented:
Kevin Lawrence is in charge.  I did login and contacted Network Solutions Tech Support.  I am awaiting an email that will instruct us on how to change the IP of ns.lkeeco.com to something that isn't the old shoreline IP / Costco IP.  We have removed ns1.lkeeco.com for now.
0
 
Hypercat (Deb)Commented:
Ok, right now ns2.lkeeco.com is resolving to your ad02 server, and that server is responding on 71.6.36.75.  Again, I think the way this is set up is hinky and it's not a good idea to have external DNS queries being resolved by your private domain Active Directory server. However, if you want to just get the current issues resolved, you need to do the following:

1.  Log onto your Network Solutions account and remove the other two nameservers, leaving only ns2.lkeeco.com for the present time.
2.  Make sure there is a Host (A), MX and PTR record on your internal domain pointing to the correct external IP address and host names for your Exchange server. I think that's already in place judging by what you posted before.
3.  In the reverse DNS zone, you need a record for 75.36.6.71.in-addr.arpa pointing to your Exchange server. That is, assuming that your Exchange server is sending out email through your Internet router using that IP address.

Again, I believe this is going to be a problem, because your server (ad02) is not responding fast enough to external DNS requests and it's causing time-outs, and that's probably one of the sources of the original problem you posted.  The long-term solution for all of this, IMO, is to segregate your internal and external DNS zones and have the external zone hosted by your ISP, or Network Solutions.
0
 
Hypercat (Deb)Commented:
OK - just checked and your exchange-uc server is set externally to IP address 71.6.36.73, so that's what you need to put in the PTR record for that server.
0
 
kflaw3Author Commented:
We do not seem to have a PTR record for exchange-uc atm just a CNAME.  So per your instructions I am going to add a PTR record for it.

I was told as an aside that we needed to have two name servers.  Is that actually true or can we get away with just ns2 as you suggested?
0
 
schapsCommented:
It's better to have one that works than three which don't -- ;)

You can get by with one to get things back on track. But two name servers, each geographically diverse from each other, is minimum best practice.
0
 
kflaw3Author Commented:
Kevin has logged into the Network Solutions account and has removed ns1.lkeeco.com but also changed ns.lkeeco.com to 71.6.36.76 (may take some time to propagate I think).  I am still planning to add the PTR record for exchange but is there anything else you two can think to add for this particular issue?

I know schaps had mentioned the two external servers from before but for now I just want to get this issue resolved so we can continue doing our business.
0
 
Hypercat (Deb)Commented:
For now, just in terms of troubleshooting the email issues, I think the PTR record is the only additional thing you need.  Let's give it a try like that and see how things go on for a few days.
0
 
kflaw3Author Commented:
Alright I will let the changes to ns.lkeeco.com, removal of ns1.lkeeco.com and the various DNS record changes I have made sit for a day and see if things improve.  Thank you both for your help and hopefully I will only have to login to this issue again to assign points.

As an aside is there a way to go back and edit or delete comments that may have sensitive information about my company?
0
 
schapsCommented:
I thought you might have meant 71.6.36.75 a few posts back, but I just queried both IPs directly, and no dns servers are responding:

$ nslookup lkeeco.com 71.6.36.76
;; connection timed out; no servers could be reached

$ nslookup lkeeco.com 71.6.36.75
;; connection timed out; no servers could be reached
0
 
kflaw3Author Commented:
I meant 76 for my last few posts with regard to ns.lkeeco.com.  Is it possible that Network Solutions is just updating the changes?  I thought you said you were able to reach 75 earlier.
0
 
Hypercat (Deb)Commented:
I think we're getting confused here. The server that is supposed to be left as the sole name server is ns2.lkeeco.com.  That's the one that responds on 71.6.36.75.
0
 
schapsCommented:
This part has nothing to do with Network Solutions - I was querying the two dns servers you run directly.
I did get some lookups to work at .75 yesterday, but not today. .76 does not even respond to pings right now.

In order to make this work, you need to have a server or servers at the end of those two IPs which will respond to DNS requests from the internet looking for lkeeco.com.
0
 
kflaw3Author Commented:
I understand that ns2.lkeeco.com was suggested to be the only server but my associates wanted to try changing ns.lkeeco.com to 76 while removing ns1 and leaving ns2 the way it is.  Will ns.lkeeco.com still cause problems with this change because if so I can try and convince them to just remove it for the time being.
0
 
schapsCommented:
(my last post was sent at the same time as hypercat's, I was responding to kflaw3's previous comment)

.76 will not work unless you actually have a DNS server there responding to requests, which you apparently do not.
0
 
Hypercat (Deb)Commented:
NS.LKEECO.COM resolves to IP address 12.144.183.99, and it isn't responding.  You don't want this server in the mix at this point, but it's still showing up as a nameserver on your Network Solutions account when I do a WHOIS lookup on your domain.

As far as removing sensitive information, you need to ask for a moderator to do that for you by clicking the Request Attention link at the top.
0
 
schapsCommented:
whois info is often delayed - the changes have been made and are viewable with dig--
ie. check Googles dns servers

admin$ dig @8.8.8.8 ns.lkeeco.com

(blah blah deleted)

;; QUESTION SECTION:
;ns.lkeeco.com.                  IN      A

;; ANSWER SECTION:
ns.lkeeco.com.            0      IN      A      71.6.36.75

0
 
Hypercat (Deb)Commented:
See my previous post.  On top of that, if their intention is to add a record to your local AD domain to point ns.lkeeco.com to a DC on your domain, that really doesn't do anything much for you. Especially if they're planning to point it to ad02, since that does nothing but direct the traffic back to the same physical server. If they're planning to direct it to a different DC on your domain, IMO that only doubles the chances that your domain could be compromised security-wise.
0
 
schapsCommented:
agreed, this is really a mess. The mess is compounded by the OP's associates who didn't want to use ns2, etc. I am not sure they are open to help.
0
 
kflaw3Author Commented:
We cannot remove ns.lkeeco.com from Network Solutions.  Apparently it requires you to have two name servers specified.  Any thoughts?
0
 
Hypercat (Deb)Commented:
OK, in that case you have no choice for now. You can point them both to the same IP address (.75) if NS will allow that, or point the second one to .76.  Someone is going to have to assign that IP address to one of your internal DNS servers - I would recommend just point it to ad02, since that server is already acting as a public nameserver for your domain.
0
 
kflaw3Author Commented:
How would I get someone to assign 76 to one of our internal DNS servers?  Is this something I can do or is this someone related to Network Solutions or Telepacific?
0
 
schapsCommented:
My thought right now is to find out from your IP provider (telepacific) if you can have lkeeco.com in their dns point to your website, and then put telepacfic's name servers in your Network Solutions account. Part of the problem here is the custom name servers, which do more harm than good. No real good, actually. Just harm.
0
 
Hypercat (Deb)Commented:
Schaps is right, but it needs to be more than just your website. The external nameservers would have to have your Exchange information on their DNS servers as well. This should be your long-term goal - to have either Telepacific or Network Solutions host your external DNS zone on their servers. This zone would include the host, MX and PTR records for all of your public servers, like your website server and your Exchange server.  

Barring that - to assign .76 to one of your internal DNS servers, you first need to be sure that you own .76.  It is likely that you do, since normally an ISP (Telepacific) will assign each business client a subnet that includes 6 usable IP addresses.  Once you're certain of that, then you need someone who knows how to program the router/firewall that sits between your Internet connection and your internal servers. This router/firewall would need to be programmed to forward incoming DNS queries that are addressed to .76 to the internal IP address (192.168.135.x) of the DNS server you want to respond to those queries.
0
 
kflaw3Author Commented:
Alright I will work on that (.76 firewall routing).  Thank you both and I will report back if we have any improvements tomorrow when Network Solutions finishes updating.
0
 
schapsCommented:
Good luck, and here is a simplified example, but basically this is what happens when someone types your url into the browser:

--> "I am looking for www.lkeeco.com" goes out to your ISP's name servers
<-- "I am not sure. Ask Network Solutions, the registrar for that domain"
--> "Hey, Network Solutions, I am looking for www.lkeecom.com"
<-- "I am not sure. Ask lkeeco.com's name servers at 71.6.36.76 or 71.6.36.75"
--> "Hey, 71.6.36.76, I am looking for www.lkeeco.com"
-- no response, times out
--> "Hey, 71.6.36.75, I am looking for www.lkeeco.com"
no response, times out

It fails to resolve the domain name to give the answer of 71.6.36.67 -
That is what your name servers *must* do, and you should be able to test it with the commands I posted earlier, which are queries directed right at your own name servers:

nslookup lkeeco.com 71.6.36.76
and
nslookup lkeeco.com 71.6.36.75

.....should return 71.6.36.67

If they do not, then nothing will work, so that's your starting point. Once at least ONE of them is responding, you should be on your way back to business.

Good luck...
0
 
kflaw3Author Commented:
Both excellent Experts.  Thank you.
0
 
kflaw3Author Commented:
For the record (was not expecting a close just yet on point distribution) we have resolved the current issue at hand by removing ns1.lkeeco.com and correcting various DNS records.  We still have to configure the firewall correctly to route .74 or some other 71.6.36.XX to our other name server but for now we are back in business.  Thank you hypercat and schaps.
0
 
Hypercat (Deb)Commented:
Thanks for the points kflaw3. If you run into additional issues or want to pursue the path of moving your public DNS to an external server and need help with that, please post back again with a new question.

Cheers!

Deb
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

  • 26
  • 24
  • 17
Tackle projects and never again get stuck behind a technical roadblock.
Join Now