Thanks. I will change up the batch file for the dig. Understood about the PTR. IMCU.ORG ended up being completely fine but IndianaMembersInsurance.COM was messed up by the ISP making Mail.IndianaMembersInsurance.com into Mail.IndianaMembersInsurance.IndianaMembersInsurance.com. Made for a long day of testing.... Thanks again.
-----Original Message----- From: Ben Scott [mailto:[email protected]] Sent: Thursday, June 10, 2010 8:04 PM To: NT System Admin Issues Subject: Re: DNS settings tool On Thu, Jun 10, 2010 at 9:44 AM, David W. McSpadden <[email protected]> wrote: > I have created a batch file and copied the output below it. Ahhhh... there's better ways to do what I think you're trying to do. dig +noall +ques +ans ANY imcu.org. www.imcu.org. ftp.imcu.org. mail.imcu.org. webmail.imcu.org. pop.imcu.org. smtp.imcu.org. mx.imcu.org. mx1.imcu.org. board.imcu.org. @pdns1.ultradns.net. The "+noall" option shuts off all output that you don't explicitly turn on. Then we say we're only interested in the question (query/request) and answer sections. (Note that hiding so much information can sometimes be misleading, but it's good if you just want to know what records exist and don't care about how/why they don't.) What I see is that some of the names you're asking about exist, and some do not. Subdomains for <www>, <mail>, and <mx1> all exist under <imcu.org.>. The rest do not exist. Also, all I see are NS and A records. No MX records, no TXT records. > I don't think my ISP set the PTR records? One thing to understand is that DNS records are basically all independent of each other. So the lack of PTR records won't keep you from getting other records (assuming those other records exist). In other words, lack of PTR records isn't causing <webmail.imcu.org.> to not work. :) Another thing is that PTR records don't come from forward lookup zones like <imcu.org.>. PTR records come from reverse lookup zones, which will be "owned" by your network connectivity provider. That's usually not your domain registrar, web host, etc. DNS has to play some tricks on you to make reverse lookup work. When you ask DNS "What name is associated with 206.18.123.221?", the resolver library turns that into a query for PTR records with the domain name <221.123.18.206.in-addr.arpa.>. The order of the IP address octets is reversed because DNS puts the most significant labels to the right. You can tell DIG to build that kind of query for you with the -x switch: dig -x 206.18.123.221 That gives me a PTR record with RHS (right hand side) of <03030611n4m055.imcu.local.>. That's not a valid domain name for the public Internet, so you've got something wrong there, too. But it's unrelated to the problems with the forward lookups. On Thu, Jun 10, 2010 at 9:48 AM, David W. McSpadden <[email protected]> wrote: > If I asked them to make these changes: [table cut] > I should see: [output cut] The TXT and MX records look good, as far as DNS goes. (Meaning: I can't tell you if you have the right IP address, and I don't know enough about your mail infrastructure to tell you what your SPF records should say.) You're requesting an "Add" for an A record for the <mail.imcu.org.> domain name. That domain already has an A record, at the IP address you give. DNS generally allows multiple resource records for any given domain, so you can easily create duplicates if your ISP isn't checking your requests. While a duplicate A record prolly isn't going to hurt anything, I wouldn't recommend it. The request for a PTR record is all wrong. :) <221.123.18.206.in-addr.arpa.> is the domain (left hand side); <mail.imcu.org.> is the RHS; and it has to go to a different service provider. -- Ben ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
