how to fix dns issues on novell??

You don't have to, but it would be incredibly helpful if you can tell us the Domain Name.

> internally we cannot get to our own websites that are hosted
> at another company

Do you have an Internal DNS Server? If so, does it have a Forward Lookup Zone configured for the same Domain Name?

If you do, it's a common problem. You would have to add all records you wish to access in your Public Zone onto your Internal DNS Server.

Chris

the domain name is dominicancampus.org, stcecilia.edu, overbrook.edu, and aquinascollege.edu

now when you search on the internet for the host name lookup it cannot find it.  what should i do??

yes i am in the process of building and internal dns server

Okay, but you don't have one at the moment? If not, it can't be that blocking things.

The NS Records are in a sorry state for all of those domains.

> dominicancampus.org

Your parent server says the name servers are:

dominicancampus.org.    86400   IN      NS      nameserver3.concentric.net.
dominicancampus.org.    86400   IN      NS      nameserver2.concentric.net.
dominicancampus.org.    86400   IN      NS      aquinascollege.edu.
dominicancampus.org.    86400   IN      NS      ns1.xo.com.
dominicancampus.org.    86400   IN      NS      ns2.xo.com.

aquinascollege.edu - Does not respond to DNS requests (but does resolve to an IP).

The server answering for the domain says:

dominicancampus.org.    86400   IN      NS      CMPSRV1.dominicancampus.org.
dominicancampus.org.    86400   IN      NS      gateway.dominicancampus.org.

Those lists should match.

Then on the zone itself:

cmpsrv1.dominicancampus.org - Doesn't resolve to an IP

Gateway seems to be listed twice on the same server, kind of bizarre.

gateway.dominicancampus.org. 86400 IN   A       66.89.73.100
gateway.dominicancampus.org. 10800 IN   A       66.89.73.100

Retrieved from nameserver2.concentric.net.

> stcecilia.edu

Your parent server says the name servers are:

stcecilia.edu.          172800  IN      NS      NS1.XO.COM.
stcecilia.edu.          172800  IN      NS      NS2.XO.COM.
stcecilia.edu.          172800  IN      NS      GATEWAY.AQUINASCOLLEGE.edu.
stcecilia.edu.          172800  IN      NS      NAMESERVER2.CONCENTRIC.NET.
stcecilia.edu.          172800  IN      NS      NAMESERVER3.CONCENTRIC.NET.

gateway.aquinascollege.edu - Does not respond to DNS requests (but does resolve to an IP).

We see the same problem as above for the servers claiming authority (they don't match and only one responds).

> overbrook.edu

Same as above.

> aquinascollege.edu

Same again in part, but this time we have an additional NS Record on the authoritative server:

aquinascollege.edu.     86400   IN      NS      66.89.73.100.

This is wrong, NS Records must point to a Name. In fact, it's treating that IP as a name (see the . on the end), it'll never work.

The SOA is also incorrect for every domain, the SOA should be the Primary Name Server and should be included in the Name Server list for the zone. Instead "dominicancampus.org" is listed as SOA in every case. The address does not respond to DNS Requests.

Chris

ok good stuff that was the same things that i was thinking.  our  isp dns servers are ns1.xo.com and ns2.xo.com


i went into the register and changed it, is there somewhere else i have to go to change the dns servers to the xo ones???

wonderful help

Yep, it'll need changing in each of the zones as well (unfortunately wrong in both places). Do you have direct access to those?

It would be worth correcting the SOA record as well.

I would guess that ns1 is the primary Name Server and that ns2 is just a Secondary? If that is the case the SOA Record should be set to something like:

overbrook.edu.          86400   IN      SOA     ns1.xo.com. caind.st
cecilia.edu. 2002022663 10800 3600 604800 86400

The @ symbol is reserved in zone files so shouldn't really be used, I've just noticed that it is in the SOA. In the example above I've replaced "\\\@" with ".". If anyone is using that responsible person address they'll know (or should) that the first period is to be replaced with an @.

Chris

how do i set up the SOA records to be corrected??

WRT reverse lookup on the mail host:  

None of your A records are reverse-resolving from the IP addresses.  It's not just your mail server.  However, it's critical for your mail server.  Without reverse-lookup, you're going to get on a bunch of block lists.

If you get all the records straightened out on your ISP's server, hopefully you can set a short TTL too, so the old entries can fall off the cached referrers faster.  TTL is usually pretty long.  Even if you can, it will take a few days to propagate.

Problem is, I don't see any PTR records at all when I do a lookup on www.dnswatch.info.  The lookup chain doesn't even hit your xo.com nameservers, and the final resolver, nameserver2.concentric.net, returns, on a lookup of 66.89.73.120 thusly:

Domain: 120.73.89.66.in-addr.arpa  Type: CNAME  TTL: 10800  Answer: 120.96/27.73.89.66.in-addr.arpa.

Is concentric.net authoritative for the 66.89.73 IP zone?  It looks like you have a subnet CIDR /27.  If they are authoritative for your IP range, and you do have valid PTRs in your ISP's DNS, Concentric apparently doesn't have the correct subnet forwarding set up to pass the lookup to your ISP.  I think that may be an issue that has to be resolved between your ISP and Concentric.

Note that a lookup of 66.89.73.100 returns two answers, which is also a problem.

One answer is another CNAME like with the mail server address.  The other is actually a PTR that points at said gateway.dominicancampus.org A record, but again, the last resolver responding in the chain is nameserver.concentric.net, not xo.com.  

I don't know that it's valid to return both a CNAME and a PTR for a reverse lookup.  That might tie back to the double A record responses Chris-Dent saw for gateway.domaincampus.com.

What access to the SOA Record do you have? Zone Files are normally just text files, but exactly how you change it depends on where the zone is and what access to it you have.

The SOA record I posted is almost correct, but has an extra space. Should have read:

overbrook.edu.          86400   IN      SOA     ns1.xo.com. caind.stcecilia.edu. 2002022663 10800 3600 604800 86400

Where caind@stcecilia.edu is claiming to be the person responsible for DNS.

Good catch on the Reverse Lookup ShineOn :)

I see the delegation for the Reverse Lookup Zone here:

100.73.89.66.in-addr.arpa. 10800 IN     CNAME   100.96/27.73.89.66.in-addr.arpa.

96/27.73.89.66.in-addr.arpa. 10800 IN   NS      gateway.aquinas-tn.edu.
96/27.73.89.66.in-addr.arpa. 10800 IN   NS      gateway.aquinas-tn.edu.

This states that gateway.aquinas-tn.edu should have a Reverse Lookup Zone called:

96/27.73.89.66.in-addr.arpa.

And that it should contain a record called 100.96/27.73.89.66.in-addr.arpa. Basically, the Reverse Lookup Zone for 66.89.73.96/27 has been delegated to aquinas-tn.edu.

However, gateway.aquinas-tn.edu is also not responding to DNS requests.

Classless Reverse Lookup Zone Delegation like this is covered by RFC 2317, it is done correctly except for the final answer from the non-responding server:

http://www.ietf.org/rfc/rfc2317.txt

Chris

Ah.  I didn't see the attempt to hit gateway.aquinas-tn.edu in my reverse lookup trace because it didn't respond to DNS requests...  That makes sense...

That means that even if the PTR records are correct, the delegation isn't, so it's never going to do the reverse lookup until the delegation is fixed.

That would mean that a NS record for the delegated zone has to be plugged in somewhere - presumably on the ISP nameserver - and propagated.

Yep, nothing like making life complicated is there? :)

Chris

I notice that the nameservers listed for XO communications, the owner of the block of IP addresses, are nameserver.concentric.net thru nameserver3.concentric.net.  So hopefully, once their zone records get straightened out, XO communications will zone-transfer the fixes through their nameservers quickly...  That should help a ton.

i have been on the phone with our isp and when they go out to the internet and pull back the records like you did they are getting their nameservers as the primary and the secondary like they should.

i am still not understanding how if all the records that are created in the isp's dns servers how i am not able to go to mxtoolbox.com and see any mx records returned.

do i have to build all the dns stuff from scratch again since the contractor that we had put this together a long time ago screwed it up???

basically do i have to start from scratch with all my domains and network???

if not what do i have to do to fix this stuff and mostly how do i do it???

the isp says that their records and their side is perfectly fine.  everyone from the outside so i thought could get to everything that they needed.  obviously not.  this is a huge mess that i am having to clean up from 12 years of screw ups internally and externally.

You could call them back and tell them that any number of ways of looking up the records, by independent, uninterested parties, result in failures, and you can even give them the specifics we've listed above.

Perhaps telling them that the external lookups are getting stuck in the concentric nameservers, and the concentric nameservers trying to use your old nameservers as authoritative, is the problem.  The lookups aren't getting to the XO.COM nameservers to be resolved.

Better have a list of things to do, quite a lot on this one now.

xo.com are probably saying it's fine, but they're delegating it all to you (I assume) and it seems rather broken once it gets there.

So first, how do you want this to work? Do you want responsibility for all the public DNS Servers? If not, xo.com would be a better place to host them. If you do, you need to build some and xo.com are rather pointless in terms of DNS hosting (that is, it would be better to register your servers at the registrar).


1. Fixing Name Server Records at Registrar

This assumes that ns1.xo.com and ns2.xo.com are the current and only hosts. Changes here are made on the servers answering for .edu.


> dominicancampus.org

Remove:

nameserver3.concentric.net.
nameserver2.concentric.net.
aquinascollege.edu.


> stcecilia.edu

Remove:

GATEWAY.AQUINASCOLLEGE.edu.
NAMESERVER2.CONCENTRIC.NET.
NAMESERVER3.CONCENTRIC.NET.


> overbrook.edu

Remove:

GATEWAY.AQUINASCOLLEGE.edu.
NAMESERVER2.CONCENTRIC.NET.
NAMESERVER3.CONCENTRIC.NET.


> aquinascollege.edu

Remove:

GATEWAY.aquinascollege.edu.
NAMESERVER2.CONCENTRIC.NET.
NAMESERVER3.CONCENTRIC.NET.



2. Fixing Name Server Records in each Zone.

Are xo.com responsible for these? If so, they are not correct at present (testing against Authoritative Server).

> dominicancampus.org

Add:

dominicancampus.org.          IN      NS      ns1.xo.com.
dominicancampus.org.          IN      NS      ns2.xo.com.

Remove:

dominicancampus.org.    IN      NS      CMPSRV1.dominicancampus.org.
dominicancampus.org.    IN      NS      gateway.dominicancampus.org.


> stcecilia.edu

Add:

stcecilia.edu.          IN      NS      ns1.xo.com.
stcecilia.edu.          IN      NS      ns2.xo.com.

Remove:

stcecilia.edu.          IN      NS      gateway.dominicancampus.org.
stcecilia.edu.          IN      NS      CMPSRV1.dominicancampus.org.


> overbrook.edu

Add:

overbrook.edu.     IN      NS      ns1.xo.com.
overbrook.edu.     IN      NS      ns2.xo.com.

Remove:

overbrook.edu.          IN      NS      gateway.dominicancampus.org.
overbrook.edu.          IN      NS      CMPSRV1.dominicancampus.org.


> aquinascollege.edu

Add:

aquinascollege.edu.     IN      NS      ns1.xo.com.
aquinascollege.edu.     IN      NS      ns2.xo.com.

Remove:

aquinascollege.edu.     IN      NS      gateway.aquinascollege.edu.
aquinascollege.edu.     IN      NS      66.89.73.100.
aquinascollege.edu.     IN      NS      CMPSRV1.dominicancampus.org.


Continued...

awesome you are awesome please give me more.  xo.com is hosting our dns.  now when i look in the dns manager on their site i am not seeing anything relating to cmpsrv1.dominicancampus.org

what i see is cmpsrv2.dominicancampus.org which is the valid mail server.

the isp is responsible for the public dns servers i would not like to be responsible for those unless i really have to to get this working correctly.

the concentric.net servers are also some of xo.com'd nameservers but the primary ones that i was told to use are ns1.xo.com and ns2.xo.com


for number 2. that you listed above which is awesome those should be removed from the dns manager at my isp where my dns is hosted right??  just making sure.

also at the bottom you have continued.....

what is next???

you are helping me out so much thank you

3. Fixing the Start of Authority Record.

The Start of Authority Record will be effectively identical for each zone:

@   IN  SOA    ns1.xo.com. hostmaster.xo.com.  (2008042301 10800 3600 604800 86400)

Where @ is shorthand for the Origin, and will represent the Zone Name.

Please note the update to the Serial Number, its based on the date today rather than the one based in 2002.

4. MX Records

The MX Records differ significantly for each domain. All of them need checking:

> dominicancampus.org

dominicancampus.org.    IN      MX      10 mxfw.dominicancampus.org.
dominicancampus.org.    IN      MX      10 mxfw.dominicancampus.org.
dominicancampus.org.    IN      MX      20 mailhost.cnchost.com.

There are two entries for mxfw, they correspond to two separate A Records, both pointing to the same IP.

> stcecilia.edu

stcecilia.edu.          IN      MX      10 mxfw.stcecilia.edu.
stcecilia.edu.          IN      MX      10 mxfw.stcecilia.edu.
stcecilia.edu.          IN      MX      20 mailhost.cnchost.com.

As above.

> overbrook.edu

overbrook.edu.          10800   IN      MX      10 mxfw.overbrook.edu.
overbrook.edu.          86400   IN      MX      10 mxfw.overbrook.edu.
overbrook.edu.          86400   IN      MX      20 mailhost.cnchost.com.

Same again.

> aquinascollege.edu

aquinascollege.edu.     10800   IN      MX      10 mxfw.aquinascollege.edu.
aquinascollege.edu.     86400   IN      MX      10 mxfw.aquinascollege.edu.
aquinascollege.edu.     86400   IN      MX      20 mxfw.aquinascollege.edu.
aquinascollege.edu.     86400   IN      MX      30 mxfw.aquinascollege.edu.
aquinascollege.edu.     86400   IN      MX      60 mailhost.cnchost.com.

Again, but twice as many records listed as MX. Two A records listed for mxfw again.


5. Reverse Lookup

As pointed out by ShineOn the Reverse Lookup must be fixed. However, there's perhaps not much point in addressing it unless you can confirm where mail will be flowing from? It only matters for outbound mail, so doesn't necessarily have to match the MX Record entries.

Chris

> for number 2. that you listed above which is awesome those should be removed
> from the dns manager at my isp where my dns is hosted right??  just making sure.

That's correct, yes.

If I ask ns2.xo.com about NS Records for dominican.org I get this response:


dominicancampus.org.    86400   IN      NS      gateway.dominicancampus.org.
dominicancampus.org.    86400   IN      NS      CMPSRV1.dominicancampus.org.
;; Received 113 bytes from 207.155.252.16#53(ns2.xo.com) in 171 ms


You can see the same, but you'll need Dig. NSLookup just doesn't cut into this so well. Running Windows? If so, you can grab a version of Dig here:

http://members.shaw.ca/nicholas.fong/dig/

Follow the installation instructions, nothing will work without the resolv.conf file.

Then you can execute the command:

dig dominicancampus.org ns @ns1.xo.com

It'll give you a slightly different format, I've been using a different command (dig dominicancampus.org ns +trace). Pay careful attention to the server providing the answers when using +trace though, you'll see it varies each time you execute the command.

Chris

awesome i am understanding completely.  please keep going.  this is absolutely wonderful.  you are great.

what else do i need to do???

It would be a good idea to verify any other records you need for this. The extra NS Records for Gateway and CMPSRV1 are probably causing the biggest problem now. Remember that even after you fix these you'll have to wait out the TTL time out.

Once you've got that far things are starting to look fairly clear. It's worth checking and double checking the MX Records.

We should really sort out the Reverse Delegation. Is your mail server, the one sending out mail, on the IP Range suggested by the Delegation? That is, is the mail server in 66.89.73.96 to 66.89.73.127?

If the IP addresses are still correct you need to discuss that with your ISP. For simplicity I recommend you have them take back control of it. Bear in mind that this doesn't have to be xo.com, it's whoever is supplying your network connection (Internet connection).

Once done, make a name for your mail server to send out on, and make sure your ISP add in a Reverse Lookup (PTR) Record for the IP pointing back to the name.

That pretty much covers it, unless there are specific issues after that.

Chris

ok you are wonderful.  this is some of the best help that i have ever gotton.  i will do all of this and let you know tomorrow afternoon what was done.  our isp is not only our internet provider but also hosts our dns so like you said above i wil go over it with them.

thank you so very much for your help and i will post again tomorrow

you are great
cheers

No problem, I hope it all starts to work itself out.

Chris

ok i just changed all the dns records lke was suggested above and now i will wait out the TTL.

i am still a little unclear on how or where i go to change the SOA records so they are correct.

do i do it at the register or the isp???

The SOA is changed at the ISP, they're only held on the authoritative servers.

Chris

cool.  when i log into the dns manager site there is no option anywhere to even look or change the SOA so i am going to call them and see if i can them to help me change them.

any other suggestions???

Not at the moment, hoping to see the NS Records on xo.com's servers soon :)

Chris

on the SOA records that i need to modify should the serial numbers match on all of them or not??

but other than that everything else in the SOA's should match right??

The Serial numbers just need to be higher than the current serial number (to indicate the zone has changed).

Chris

is that something that is changed automatically when i change the records???

also below is what i want to set for the SOA's do you see anything wrong with them??

refresh  3600
retry 600
expire 3600000
Min TTL 86400

so for example the SOA for dominicancampus.org would be

dominicancampus.org. helpdesk.dominicancampus.org. 2002022790 3600 600 3600000 86400

what do you think??

It depends how you edit the records, if you're editing the zone file directly you must increment the Serial number manually. If you're editing the zone files via a web interface of some sort it may take care of it, but depends entirely on the interface.

The expiry is extremely long, over a month, but that's not a bad thing in some cases.

Minimum TTL is just fine.

The serial number is normally (by convention / tradition) written like this:

<year><month><day><changenumber>

Where change number is per day. e.g. first change for today would be:

2008042401

Then the second:

2008042402

Tomorrows serial would be:

2008042501

And so on. Just means it's easy to keep track of when the zone was last changed.

For the record itself the values will be enclosed in parentheses (brackets), making the entire record look like this:

@   IN SOA   ns1.xo.com.  helpdesk.dominicancampus.org.  (2008042501 3600 600 3600000 86400)

Where @ is the domain name (shorthand for the domain name in the zone file), in this case dominicancampus.org, and ns1.xo.com is the primary name server for the domain.

Chris

great.  i will get these changed so they match throughout the SOA's.  since you said the expiry is really long what would you suggest it to be???

Normally ends up being set to a few weeks, so it's not excessively long by that measure. I normally end up with 4 weeks (2419200 seconds), but there's no rule that says you must use that.

Chris

thank you for the suggestion.  i had one other question so i get this right.  

should the domain name for each domain be itself or should all of them be the same dominicancampus.org????  for example see below

for the overbrook.edu SOA
overbrook.edu. helpdesk.dominicancampus.org. 2002022790 3600 600 3600000 86400

for the stcecilia.edu SOA
stcecilia.edu. helpdesk.dominicancampus.org. 2002022790 3600 600 3600000 86400

for the aquinascollege.edu SOA
aquinascollege.edu. helpdesk.dominicancampus.org. 2002022790 3600 600 3600000 86400

for the dominicancampus.org SOA
dominicancampus.org. helpdesk.dominicancampus.org. 2002022790 3600 600 3600000 86400

or am i way off???

do you where the cmpsrv1.dominicancampus.org is coming from??  it is not in any of the records that are at the isp.  the isp has cmpsrv2.dominicancampus.org which is the right record.

where is the false record coming from??

I would actually expect the SOA to be:

ns1.xo.com. helpdesk.dominicancampus.org. 2002022790 3600 600 3600000 86400

In all cases. The domains themselves aren't the start of authority for the domain (if that makes any sense at all).

ns1 and ns2 are providing those NS Records, they must be listed in the zone file somewhere. I guess you can't see them through your management interface?

I'm getting an authoritative answer from ns1 and ns2 in all cases, it means they're not giving me a cached entry and it's based on data in the zone file at the moment.

Chris

so does that mean that i would have to put ns1.xo.com. helpdesk.dominicancampus.org. 2002022790 3600 600 3600000 86400 in for all the SOA records for my domains??  or is it something that the isp must do once i have edited the SOA's??

awesome help, i am learning so much from you.  you are great.

To show that a little, the debug output from nslookup for overbrook.edu is at the bottom.

We should see that we have an Authoritative Answer here:

> header flags:  response, auth. answer, want recursion

That we asked for the Name Server Records in the question:

>    QUESTIONS:
>        overbrook.edu, type = NS, class = IN

And the response stating that only those two servers are configured with the associated Host (A) Records as relevant associated information.

>    ->  overbrook.edu
>        nameserver = gateway.dominicancampus.org
>        ttl = 86400 (1 day)
>    ->  overbrook.edu
>        nameserver = CMPSRV1.dominicancampus.org
>        ttl = 86400 (1 day)

The TTL isn't relevant in this case as we have an authoritative answer.

If the answer were Non-Authoritative (a response from cache) we would have an extra line added above the final summary stating explicitly that it was non-authoritative.

If you can't see it through the management interface I guess you'll have to raise it with them, might be fun ;)

Chris

C:\> nslookup
> server ns1.xo.com
> set debug
> set type=ns
> overbrook.edu
Server:  ns1.xo.com
Address:  207.155.248.16
 
------------
Got answer:
    HEADER:
        opcode = QUERY, id = 46, rcode = NOERROR
        header flags:  response, auth. answer, want recursion
        questions = 1,  answers = 2,  authority records = 0,  additional = 2
 
    QUESTIONS:
        overbrook.edu, type = NS, class = IN
    ANSWERS:
    ->  overbrook.edu
        nameserver = gateway.dominicancampus.org
        ttl = 86400 (1 day)
    ->  overbrook.edu
        nameserver = CMPSRV1.dominicancampus.org
        ttl = 86400 (1 day)
    ADDITIONAL RECORDS:
    ->  gateway.dominicancampus.org
        internet address = 66.89.73.100
        ttl = 10800 (3 hours)
    ->  gateway.dominicancampus.org
        internet address = 66.89.73.100
        ttl = 86400 (1 day)
 
------------
overbrook.edu
        nameserver = gateway.dominicancampus.org
        ttl = 86400 (1 day)
overbrook.edu
        nameserver = CMPSRV1.dominicancampus.org
        ttl = 86400 (1 day)
gateway.dominicancampus.org
        internet address = 66.89.73.100
        ttl = 10800 (3 hours)
gateway.dominicancampus.org
        internet address = 66.89.73.100
        ttl = 86400 (1 day)
>

Select allOpen in new window

> ns1.xo.com. helpdesk.dominicancampus.org. 2002022790 3600
> 600 3600000 86400 in for all the SOA records for my domains??

Yep.

> or is it something that the isp must do once i have edited the SOA's??

Depends if you have control over the SOA. If it were my system I wouldn't let clients control the SOA except perhaps in most general terms, but it's not mine ;)

Chris

that makes sense but how do i change that becuase i just this morning updated all the records for the domain nameservers??  so i guess i just have to wait or is there something really wrong at the isp that i need them to look into??

the .100 is our firewall
so it is referencing my firewall and gateway.dominicancampus.org as authoritative servers which is incorrect because my firewall is not doing any dns at all.  so is it something internal that is causing this.  or is it the gateway.dominicancampus.org that is at our isp that is causing the trouble, do i have to take out of the dns at the isp the gateway.dominicancampus.org entries on each domain zone???

> that makes sense but how do i change that becuase i just
> this morning updated all the records for the domain
> nameservers??  so i guess i just have to wait or is there
> something really wrong at the isp that i need them to look into??

If you can't see it in the management console I'd advise you have them take a look at it. There's something rather odd going on there, they're definitely returning the answers so it must be in there somewhere.

If it's not in the zone file they have something rather wrong with their DNS Servers.

Not sure what we can do to prod them in the right direction other than supply them with the output from the queries. If they have a remotely competent DNS administrator they should be able to find it.

> so it is referencing my firewall and gateway.dominicancampus.org
> as authoritative servers which is incorrect because my firewall is not
> doing any dns at all.

Correct. The Start of Authority is normally referred to as the Primary DNS Server for a domain.

It's termed Start of Authority because it should be the only system holding a Writable copy of the zone, all other servers should be Secondary.

The Secondary read the Start of Authority record and make their decision to perform a Zone Transfer from the SOA based on whether or not the Serial Number has been incremented.

So, if ns1.xo.com is the Primary DNS Server for your domain it is also the Start of Authority and should be listed as such in the SOA record.

Chris

awesome.  i am going to call them now and prod them to find out what is going on on their side to see if we can isolate where all this stuff is coming from.  is there anyway you can give me a complete diagnostic of what you are seeing out there so i may give them a copy if i have to???

Sure, the output from Dig should be enough. Please find a full trace from the root servers for each domain and the SOA for most.

Should note that the NS records on the Registrars for dominicancampus.org has updated now and look a hell of a lot better.

Can't get the SOA for acquinascollege.edu at the moment. Doesn't get all the way to the authoritative name servers. Will try again later.

Chris
dominicancampus.org.ns-trace.txt
stcecilia.edu.ns-trace.txt
overbrook.edu.ns-trace.txt
acquinascollege.edu.ns-trace.txt
dominicancampus.org.soa.txt
stcecilia.edu.soa.txt
overbrook.edu.soa.txt

awesome you are a lifesaver.  please post more findings as you see them please.  i will show all of this to the isp.  and i will post again soon.

thank you so much and please if you find anything else that is not looking good please post it and i will try my best to get it resolved.

also i do not know if you had a typo or not but it is aquinascollege.edu

thanks again for all your help that you are giving me your are a tremendous help

Heh that would do it, the trace above is fine, just a typo in the description, which made me check the wrong domain for SOA. Here's the SOA report for aquinascollege.edu.

Chris
aquinascollege.edu.soa.txt

ok most things have been cleaned up but we are still seeing cmpsrv1.dominicancampus.org showing up.  this is wrong.  it should be showing cmpsrv2.dominicancampus.org.  is ths a total isp problem or is there something that i am missing??


also i did notice in the dns manager at my isp where we host our dns there is an entry in there for the gateways.  are those suppose to be there???

I still see NS Records for CMPSRV1 and Gateway on each zone. They shouldn't be there at all. The Name Servers are ns1.xo.com and ns2.xo.com in all cases aren't they?

Chris

after lots of very deep digging into the past 12 years of other people and contractors not knowing what they were doing i found a problem that has been fixed now and that was when all the zone transfers were done the people did not do them right at all there were a lot of lingering records and nameservers floating around.  the changes have been made to correct them and i think that might have been the leading cause of our problems but we will see in about 3-5 hours.

please let me know if you see anything out there later on today that is concerning.

you have been absolutely wonderful and an amazing help.

i will post again soon

Ahh cool, okay, I'll check it out again later on :)

Chris

awesome.  thank you and i look forward to seeing your next post.  you have helped me cleanup a 12yr old dns mess that was created.  thank you so much.

i will post again soon

Hey again,

Hope you had a good weekend :)

I'm still seeing errant NS Records in each of those zones. Here's an example again:

dominicancampus.org.    86400   IN      NS      ns2.xo.com.
dominicancampus.org.    86400   IN      NS      ns1.xo.com.
;; Received 79 bytes from 199.19.56.1#53(a0.org.afilias-nst.info) in 109 ms

dominicancampus.org.    86400   IN      NS      CMPSRV1.dominicancampus.org.
dominicancampus.org.    86400   IN      NS      gateway.dominicancampus.org.
;; Received 113 bytes from 207.155.252.16#53(ns2.xo.com) in 156 ms

The first set is Parent (Registrars) entries and is correct. The second shows us the entries on ns2.xo.com (the answer is the same from ns1.xo.com) and isn't what I'd expect to see.

There's no Host (A) Record for CMPSRV1. Gateway is no good either, it doesn't know anything about the zone.

Chris

yes i had a good weekend and i hope you had a wonderful weekend as well:)

yes i saw that to.  so it looks like the isp is the problem.

there is a record created for gateway, so should i delete it???

also you are correct there is no host record created for cmpsrv1 it was an old email server that was taken out of commission 6 months ago and a new host and PTR was created for cmpsrv2 which is the right one.

why is the isp giving out the wrong records???

please let me know what you think i should do???

should i delete all the gateway records for dominicancampus.org, stcecilia.edu, overbrook.edu, and aquinascollege.edu??

thank you so much for keeping tabs on things with me, you are a life saver

The A Record is harmless on it's own, if you don't want it or need it then it can be removed.

The NS Records will be the ISPs problem if you can't see them through your DNS management software. They still think everything is fine?

Chris

ok i will call them again and see if i can get them to do their part.

now i have used multiple sites to do reverse lookups on my mail server to make sure that we can receive mail fine and 3 out of five come back positive.  can you do one from where you are and let me know what you see from where you are????

the ip of the mail server is 66.89.73.101
and the name is cmpsrv2.dominicancampus.org

please let me know what you find

That gets back to the broken state of the reverse lookup.

Take a look at the trace below and you'll see a few things:

1. Query and referral from the Root Servers
2. Query and referral from Arin's Servers
3. Query and Alias Response from Concentric's Servers
4. Query for NS Records to resolve Alias (via Concentric)
5. Failure to resolve CNAME to Name via gateway.aquinas-tn.edu.

Gateway.aquinas-tn.edu doesn't respond as a Name Server at all. If it were mine I'd ask Concentric to take charge of the Reverse Lookup again, by far the simplest solution.

Chris

C:\Dig>dig 101.73.89.66.in-addr.arpa +trace
 
; <<>> DiG 9.3.2 <<>> 101.73.89.66.in-addr.arpa +trace
;; global options:  printcmd
.                       516960  IN      NS      A.ROOT-SERVERS.NET.
.                       516960  IN      NS      B.ROOT-SERVERS.NET.
.                       516960  IN      NS      C.ROOT-SERVERS.NET.
.                       516960  IN      NS      D.ROOT-SERVERS.NET.
.                       516960  IN      NS      E.ROOT-SERVERS.NET.
.                       516960  IN      NS      F.ROOT-SERVERS.NET.
.                       516960  IN      NS      G.ROOT-SERVERS.NET.
.                       516960  IN      NS      H.ROOT-SERVERS.NET.
.                       516960  IN      NS      I.ROOT-SERVERS.NET.
.                       516960  IN      NS      J.ROOT-SERVERS.NET.
.                       516960  IN      NS      K.ROOT-SERVERS.NET.
.                       516960  IN      NS      L.ROOT-SERVERS.NET.
.                       516960  IN      NS      M.ROOT-SERVERS.NET.
;; Received 500 bytes from 10.50.0.11#53(10.50.0.11) in 15 ms
 
66.in-addr.arpa.        86400   IN      NS      indigo.ARIN.NET.
66.in-addr.arpa.        86400   IN      NS      epazote.ARIN.NET.
66.in-addr.arpa.        86400   IN      NS      figwort.ARIN.NET.
66.in-addr.arpa.        86400   IN      NS      chia.ARIN.NET.
66.in-addr.arpa.        86400   IN      NS      dill.ARIN.NET.
66.in-addr.arpa.        86400   IN      NS      BASIL.ARIN.NET.
66.in-addr.arpa.        86400   IN      NS      henna.ARIN.NET.
;; Received 194 bytes from 198.41.0.4#53(A.ROOT-SERVERS.NET) in 78 ms
 
89.66.in-addr.arpa.     86400   IN      NS      nameserver3.concentric.net.
89.66.in-addr.arpa.     86400   IN      NS      nameserver.concentric.net.
89.66.in-addr.arpa.     86400   IN      NS      nameserver1.concentric.net.
89.66.in-addr.arpa.     86400   IN      NS      nameserver2.concentric.net.
;; Received 160 bytes from 192.31.80.32#53(indigo.ARIN.NET) in 109 ms
 
101.73.89.66.in-addr.arpa. 10800 IN     CNAME   101.96/27.73.89.66.in-addr.arpa.
 
96/27.73.89.66.in-addr.arpa. 10800 IN   NS      gateway.aquinas-tn.edu.
;; Received 119 bytes from 207.88.20.82#53(nameserver3.concentric.net) in 109 ms

Select allOpen in new window

good stuff.

now i also for another client have done all their dns that was moved to the isp and it is very good.

try op-tn.org and you will see that it is done correctly and pretty good.  this is the one that i did.

the one that we are working on now is junk and was put together by someone that did not know what they were doing.  trust me if you do your tests on op-tn.org which is the one that i did for another client you will see where my frustration is.  i am trying to cleanup a 12 year mess and i do not know if it is recoverable but i am trying very hard to do it.


do i need to restart from scratch and just do everything over again???  what do you think????

aquinas-tn.edu does not exist anymore and has not existed for like 2years.  it was switched over to aquinascollege.edu which now does exist.  this throws another log on the fire because that would mean that the zone transfer was not done properly. right??

> do i need to restart from scratch and just do everything over again???  
> what do you think????

You might well find it easier. I'd certainly be tempted to if the zones only contain simple information. Will xo.com allow you to drop the zones completely and start again?

If they all end up in the state of op-tn.org I'd be a happy man :)

It is recoverable though, ultimately it's only text files, changing them when you have access at that level is trivial.

> this throws another log on the fire because that would mean that
> the zone transfer was not done properly. right??

Probably, or if it was the delegation wasn't updated on Concentric's network.

That's why giving the responsibility for reverse DNS back to the ISP feels like a good choice. No point in being responsible for it unless you have a lot of changes to make. For a single record it's not worth the trouble / effort.

Chris

yes if i can get the dns like i got the op-tn.org i would be a very happy man to.

i will ask xo if they have updated the delegation for concentric since concentric is xo's to.

what would entail dropping the zones and redoing them???  time??  down time?? etc

i will also ask the isp to take control of the reverse dns if they will.   they are not very helpful though

I guess it depends a little, you're very reliant on a third party to make the changes. Fantastic when things are working well, but a pain in the proverbial getting things changed when you need them to be.

From my point of view there's little difference between dropping the zones and fixing them. I'd go with whatever is easiest for the host, replacing them with a default blank zone should, at least in theory, be easier than encouraging them to debug each.

Any idea how many records you'll have to add back in?

Chris

if i was to start the zones over i have 4 zones and a total of 40 records.


how long would i be down for if i started from scratch???

i had a question for you.  could you a dig report on the ip address instead of the domain???

the ip of the mail server is 66.89.73.101

i just did one and i get the correct records back.  please tell me what you see.

How long depends very much on your hosts, it's the kind of question that can only be answered by whoever is holding the DNS Server. 4 Zones and 40 records wouldn't take a great deal of time to redo from scratch, even through a web interface.

For the IP I always get stuck here:

101.73.89.66.in-addr.arpa. 10800 IN     CNAME   101.96/27.73.89.66.in-addr.arpa.
 
96/27.73.89.66.in-addr.arpa. 10800 IN   NS      gateway.aquinas-tn.edu.

That's how IP Addresses are stored in DNS, in reverse and suffixed with in-addr.arpa.

Chris

cool.  i had a nice long talk with xo and they have admitted a lot of the mistakes that were floating around and they are fixing them.

i am working on trying to find out where the aquinas-tn.edu is coming from and that might be at the isp to.

please let me know if you find anything else.

you are awesome and i will post again soon.

I have a feeling that Concentric and XO are two pieces of the same ISP, since the WHOIS on concentric.net shows it's owned by XO Communications Inc. and XO.COM says it's owned by Concentric Network Corporation.

Maybe, now that XO has admitted falling down on the job, the Concentric nameserver issues will finally be resolved, fixing your reverse-lookup.

Not holding my breath, but hoping for your sake it will happen soon...

yes i will have to wait approx 2 days for them to clean up what they have done on their side.  i also hope for my sake it all works out.  but please if you see anything on your side that looks concerning please post it.

have you seen any good changes from your end???

Only the changes you made with your Registrar. The SOA and NS Records are still messy on xo.com. Hopefully that'll start to fix itself if they're properly committed to looking at it now.

Anyway, I'll keep an eye on it and post again if anything changes. Or if you let us know they've done something.

Chris

xo is still working on their part.  i have to wait another day and they said the NS records would be clear by then.  we will see if they do their part.  please let me know if you see anything that changes for the better.

ok the isp fixed their end.  they had some problems and now they assure me that everything is the way it should be.

could you please do a dig from your side and let me know if you see anything strange???

Sure :)

I've tested NS, SOA and MX Records in each of those, and...

dominicancampus.org = perfect
overbrook.edu = perfect
stcecilia.edu = perfect
aquinascollege.edu = perfect

The Reverse Lookup is still broken, I take it you're still working on that one?

Chris

i am still working on the reverse problem.

when you do a reverse from where you what are you seeing??

Identical to the trace we did before.

Concentric have delegated responsibility for the Reverse Lookup Zone to gateway.aquinas-tn.edu. It breaks because it can't contact that DNS Server to get the final answer it needs.

Chris

see aquinas-tn.edu does not exsist anymore.  there is nothing in the zone.

should i tell the isp to delete that zone so we can get rid of the aquinas-tn.edu???

Concentric ideally need to remove the Delegation, then add correct PTR Records for your mail server.

Deleting the zone isn't the same thing because you have no control of the zone performing the delegation.

Chris

see that is what they said they did was fix the delegation and they manually deleted some the lingering records.  they keep on saying from the side that the reverse lookup is working fine from their end.

i will call them again and let them know that outside we are still seeing the bad records.

any other suggestions??

Hmmm, am I looking at the correct PTR Record?

101.73.89.66.in-addr.arpa.
Or
66.89.73.101

I still see that as Delegated on each of Concentric's name servers.

Chris

i had a question.  what is the difference between mxfw records and mx records??  are they the same thing or different?

in our zones on the isp we have all mxfw records not mx for mail

thank you i understand now.

still working on the isp though

ok the isp has lots of work to do because we have isolated it with the isp.  thank you so much for all your expert help it has been absolutely wonderful.

awesome help truly wonderful help.  this has been some of the best help that i have ever gotten

You're welcome, hope it all works in the end :)

Chris