BIND and Webmin with Google Apps

Is that the entire zone file? Where are the A records for your name servers (ns1 and ns2)?

I get server-fail when I try to query your domain, and although there's nothing wrong with your MX records, something is wrong with your name servers.

Chris

This is my named.conf file if it helps:
options {
      directory "/etc";
      pid-file "/var/run/named/named.pid";
      };

zone "." {
      type hint;
      file "/etc/db.cache";
      };

zone "pcelements.com" {
      type master;
      file "/var/named/pcelements.com.hosts";
      };

I'd like to see this file if possible? /var/named/pcelements.com.hosts

And are you willing to share your server IP? The address I have from the registrar is not responding to DNS requests (173.243.84.34).

Chris

The content of the pcelements.com.hosts file is the one I already posted with the question. The IP address is 173.243.84.34

Somebody Help Please!!!

Sorry, dinner time. Family takes precedence over internet stuff.

Anyway. You need NS records, initially I suggest you make these changes:

$ttl 38400
pcelements.com.      IN      SOA      ns1.pcelements.com. xyz.pcelements.com. (
                  1298125782
                  10800
                  3600
                  604800
                  38400 )

pcelements.com.      IN      NS      ns1.pcelements.com.
pcelements.com.      IN      NS      ns2.pcelements.com.

pcelements.com.      IN      A      173.243.84.34

ns1.pcelements.com.  IN A  173.243.84.34
ns2.pcelements.com.  IN A  173.243.84.34

www.pcelements.com.      IN      A      173.243.84.34

mail.pcelements.com.      IN      CNAME      ghs.google.com.
pcelements.com.      IN      MX      1 ASPMX.L.GOOGLE.COM.
pcelements.com.      IN      MX      5 ALT1.ASPMX.L.GOOGLE.COM.
pcelements.com.      IN      MX      5 ALT2.ASPMX.L.GOOGLE.COM.
pcelements.com.      IN      MX      10 ASPMX2.GOOGLEMAIL.COM.
pcelements.com.      IN      MX      10 ASPMX3.GOOGLEMAIL.COM.

Select all Open in new window

We *must* address the last problem. Your server is not responding to DNS requests, it's possible the service is failing to start with the zone file you've defined, but this has to be checked after you modify the zone.

Chris

I replaced the content of the file with yours. I restarted BIND. I'm still unable to receive emails and access my domain without the IP address.

Your server still does not respond to DNS requests. Firewall? IPTables?

Can you verify the service is actually up?

Chris

I turned off the Firewall and restarted named service.

If you're not sure, try running:

iptables --list

You'd be looking for a rule set like this:

ACCEPT    udp  --   anywhere     anywhere     udp dpt:domain
ACCEPT    tcp  --   anywhere     anywhere     tcp dpt:domain

The first is the most important, the majority of traffic to your DNS service will use that.

Chris

Still nothing, I can get to your web service, but no response to DNS.

Is there another firewall in front of this server? What kind of host are you running this on?

Chris

[root@apollo ~]# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination        

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        
[root@apollo ~]#

There is a router in front of the server, but http port is open. The IP address used for the server is the same for ns1.pcelements.com and ns2.pcelements.com.

Yeah, I saw :)

You'll need to open more than HTTP for this to work. Can you open UDP 53 (DNS / Domain) there as well?

Chris

I'll need to go to my office for that. Give me 30 min more or less.

Were getting somewhere!
Ok, I opened the DNS port at my router, turned on Centos firewall and now I am able to access my domain using pcelements.com!!!

I am also able to receive and send emails!!!

But, when I access http://www.intodns.com/pcelements.com to check the DNS records, I still receive errors. Also, when I access http://www.google.com/support/a/bin/answer.py?hl=en&answer=33313
to check my MX records, I still get errors.

Is there something else I need to do?

I still can't contact your DNS server, I get the same error if I pop that into "intodns.com":

ERROR: One or more of your nameservers did not respond:
The ones that did not responded are:
173.243.84.34

That is the right IP isn't it?

The firewall on CentOS, now it's back on can you post "iptables --list"?

Chris

That is the only IP. It is used for the domains and both nameservers.

Chain INPUT (policy ACCEPT)
target     prot opt source               destination        
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination        
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            icmp any
ACCEPT     esp  --  anywhere             anywhere            
ACCEPT     ah   --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             224.0.0.251         udp dpt:mdns
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipp
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ipp
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ndmp
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ftp
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:https
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited

Thanks.

Lets see if I remember this stuff well enough. Please run:

iptables -A RH-Firewall-1-INPUT -p udp --dport 53 -j ACCEPT

Then run this to make sure it's present:

iptables -L -v

If it is, we can test it, and if that works, running this should save the rule set:

service iptables save

Chris

Actually, we might run it this way instead:

iptables -I RH-Firewall-1-INPUT 10 -p udp --dport 53 -j ACCEPT

That should insert it half way down, and should avoid the REJECT rule at the bottom which is a bit troubling.

Chris

I ran the commands and this is the  iptables --list result: I still receive the errors when checking DNS

Chain INPUT (policy ACCEPT)
target     prot opt source               destination        
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        
RH-Firewall-1-INPUT  all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination        

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination        
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            icmp any
ACCEPT     esp  --  anywhere             anywhere            
ACCEPT     ah   --  anywhere             anywhere            
ACCEPT     udp  --  anywhere             224.0.0.251         udp dpt:mdns
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ipp
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ipp
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ndmp
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:ftp
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:https
REJECT     all  --  anywhere             anywhere            reject-with icmp-host-prohibited
ACCEPT     udp  --  anywhere             anywhere            udp dpt:domain

Bingo, I just got a reply from your name server :-D

Chris

I think it is Perfect Now!!!
Please check in http://www.intodns.com/pcelements.com to see the warnings shown, to see if it is something that I can improve.
Thank You Very Much for your time and expertise!!!!!!!!!!!!!!!!!!!!!!!!!!

Right, you're still getting a few errors flagged on IntoDNS, so I figure I'll pop up my thoughts about those in case you want to follow up on any of them.

> Recursive Queries

Generally speaking this is bad practice for public DNS servers as it opens you up to denial of service attacks. You can disable these in named.conf as follows (options section already exists, only here to indicate that's where it should go):

options {
  allow-recursion { none; };
};

Select all Open in new window

If you use this as an internal resolver (if internal clients on the network use the DNS service) you should treat that a little more carefully.

If you only expect this to answer requests for pcelements.com, and not resolve www.google.com for someone else (for example) you should do this.

> WARNING: Not all of your nameservers are in different subnets
> WARNING: Single point of failure

The second message says it, both basically amount to the same thing, you have no fault tolerance. A hard one to resolve unless you get another site.

> Your SOA serial number is: 1298125783. This can be ok if you know what you are doing.

Convention / tradition has us build serial numbers in this format:

<Year><Month><Day><RevisionNumber>

e.g.

2011021901

This indicates the first change today, the second change today would be 02 instead of 01, etc. Then tomorrows changes would start back at 2011022001.

It's not critical, if you wish to continue with the serial you have you can.

Chris

I'm off to bed now, so if I don't reply it's because I'm snoring :) Hopefully this is enough to keep you going for now anyway.

All the best,

Chris

Thank You Again :) !!!

Port 53 is definitely needed for your DNS. Also, have you updated your domain record to point to your NS servers and you have to register each NS with ICANN. This last step is the least obvious, but is one reason your NS can be seen/queried even if your DNS isn't bug-free.