Help with errors from Dlint?

[Jim Reid]

>>>>> "Aaron" == Aaron Bush <abush at columbus.rr.com> writes:

    Aaron> Recently my ISP has been upgrading their name servers also
    Aaron> and I am no longer able to resolve my domain names from
    Aaron> other PC's that are on dhcp assigned IP's from this ISP.

That's because you've configured your name server to tell lies about
the reverse zone containing your IP address. Read on.

    Aaron> I'm not sure if changes need to be made to by DNS configs
    Aaron> for each domain or if the problem is with my ISP.  I am
    Aaron> able to resolve my domains using DNS servers outside of my
    Aaron> ISP though.

    Aaron> An example of the problem is this: IP that I have leased
    Aaron> is: 204.210.233.254 crvs.com domain registered with
    Aaron> network-solutions and the primary (listed first) name
    Aaron> server there is: NS1.BEERGEEKS.COM 204.210.233.254 The
    Aaron> beergeeks.com is also registered by me and is at the same
    Aaron> 204.210.233.254 IP address. 

Well it's not clear from the above (and the meaningless output from
Dlint - whatever that is - that I've snipped) what the actual problem
is but at least you supplied some of the named.conf file and the zone
files.

    Aaron> Are my db files incorrect or is there a problem with my ISP
    Aaron> still being authoritatve for my IP?  

Your zone files are a bit of a mess. The first thing is that your zone
files only contain one NS record. That's a single point of failure:
what if that one and only name server for these zones dies or becomes
unreachable? The second error is delegation. The .com zone says that
panda.cam-hx.com and ns1.beergeeks.com are name servers for crvs.com
and beergeeks.com. panda.cam-hx.com appears to be dead. And it isn't
listed as an NS record in the zone files you showed. Your next error
is that you have illegal MX records for these two zones. The target of
an MX record is a hostname: a name that exists as an A record
somewhere. You've supplied dotted-decimal strings that are presumably
IP addresses. This is wrong. Oh and an MX preference value of 0 is
probably not a good idea either: what if you need to install another
MX record with a lower preference value? The next error is your
(bogus) 233.210.204.in-addr.arpa zone. This isn't delegated to you, so
you shouldn't be claiming ownership of it. The zone file you presented
for that contains only one NS record again.  [This is legal, but
unwise.]  Then you have two PTR records which mean that if someone
does a reverse lookup on your server for 204.210.233.254, they will
get two names returned. This is also legal but unwise. Which name is
correct?  Not that it matters because the rest of the world won't use
your name server to lookup that PTR record. They'll get the answer
from your ISP: dhcp233254.columbus.rr.com. So either they change their
PTR record to have your chosen hostname or else they do RFC2317
delegation of 254.233.210.204.in-addr.arpa to your name server(s).
And since your bogus zone file has no PTR records for 0, 1, 2, ...
253.233.210.204.in-addr.arpa, it's hardly surprising that reverse
lookups to your server for the other IP addresses in 204.210.233/24
fail.

BTW name servers are authoritative for zones, not "my IP" whatever
that means.