big problem - possibly dns?

Dana Holland

unread,

Dec 12, 2006, 5:52:00 PM12/12/06

to

We've got a problem here that seems to be DNS related, but I'm not sure.
We have a website http://blackboard.navarrocollege.edu. Yesterday
some people started reporting that they couldn't access the website.
Others can access it just fine.

The problems started when we moved to a gigaman circuit, with a new
firewall. At the same time we began looking at upgrading our DNS
server. Our primary server has been running Bind 4 (yes, I know!).
Yesterday I tested a Bind 8 configuration (in preparation for moving up
to Bind 9!). It appeared to be working, except that I had forgotten the
CNAME for the server I'm having problems with. I switched back to my
Bind 4 configuration thinking that we would function as before until I
could complete the move to the new Bind.

I'm not sure what I should post to help diagnose this. Below is the
primary zone file, and the in-addr.arpa. Note that we don't normally
have TTL set to 900 - we just did that while we were trying to figure
out this problem.

@ IN SOA dns.navarrocollege.edu.
root.dns.navarrocollege.edu. (

2006121204 ; Serial Number YYMMDDxxx
900 ; Refresh 2dary
900 ; 2dary retries after ..
604800 ; 2dary says primary is dead after ..
900 ) ; TTL in cache (12 hours) - 30 min (1800)
IN NS dns
IN NS dns2
navarrocollege.edu. IN MX 10 mailfoundry
navarrocollege.edu. IN A 205.165.189.178
mollybrown IN A 205.165.189.135
ftp IN CNAME mollybrown
astp IN A 205.165.189.139
webadvisor IN CNAME astp
testwa IN CNAME astp
calendar IN CNAME astp
ipac IN A 205.165.189.138
dns IN A 205.165.189.130
columbia IN CNAME dns
localhost IN A 127.0.0.1
sts IN A 205.165.189.178
www IN CNAME sts
layout IN CNAME sts
foundation IN CNAME sts
admin IN CNAME sts
sbdc IN CNAME sts
news IN CNAME sts
search IN CNAME sts
tour IN CNAME sts
collegeday IN CNAME sts
dns2 IN A 205.165.189.183
apollo16 IN A 205.165.189.176
blackboard IN CNAME apollo16
gemini IN A 205.165.189.182
mail IN CNAME gemini
pop IN CNAME gemini
gemini2 IN CNAME gemini
ldap IN A 205.165.189.180
mysql IN CNAME ldap
test IN A 205.165.189.179
navnet IN A 205.165.189.185
catalog IN A 205.165.189.174
mailfoundry IN A 205.165.189.184
navarrocollege.edu. IN TXT "v=spf1 mx mx:johnwyoung.org
mx:dana-holland.com mx:r
oxanndawson.info mx:roddymcdowall.info ~all"
gemini.navarrocollege.edu. IN TXT "v=spf1 a -all"

Scott, Casey

unread,

Dec 12, 2006, 7:13:42 PM12/12/06

to

What probably happened is those users who looked up the record while the
CNAME was missing are now stuck with a negative cache record. The
others, who were able to access the site were getting the proper result
from their name server's cached record of the zone. For what its worth,
I just looked up blackboard.navarrocollege.edu now, and got

blackboard.navarrocollege.edu is an alias for
apollo16.navarrocollege.edu.
apollo16.navarrocollege.edu has address 205.165.189.176

Once the negative cache expires, the users' problems will disappear.

Regards,
Casey Scott

Mark Andrews

unread,

Dec 12, 2006, 7:27:48 PM12/12/06

to

> We've got a problem here that seems to be DNS related, but I'm not sure.
> We have a website http://blackboard.navarrocollege.edu. Yesterday
> some people started reporting that they couldn't access the website.
> Others can access it just fine.
>
> The problems started when we moved to a gigaman circuit, with a new
> firewall.

BIND 9 and BIND 8 support EDNS. Make sure your firewall
is configured to support EDNS. This usually requires
allowing through larger DNS/UDP packets (up to 4096 bytes
of payload). It also means allowing through IP fragments.

Check your firewall documentation.

> At the same time we began looking at upgrading our DNS
> server. Our primary server has been running Bind 4 (yes, I know!).
> Yesterday I tested a Bind 8 configuration (in preparation for moving up
> to Bind 9!). It appeared to be working, except that I had forgotten the
> CNAME for the server I'm having problems with.

Why were you re-entering data? BIND 8 and BIND 9 both read
the same master files as BIND 4 does. They are just stricter
than BIND 4 w.r.t. error in the master files.

> I switched back to my
> Bind 4 configuration thinking that we would function as before until I
> could complete the move to the new Bind.

Just go straight to BIND 9.

> I'm not sure what I should post to help diagnose this. Below is the
> primary zone file, and the in-addr.arpa. Note that we don't normally
> have TTL set to 900 - we just did that while we were trying to figure
> out this problem.

Use $TTL <value> or specify a TTL on the SOA line for the
default TTL. MINIMUM is use to specify a negative TTL.
See RFC 2308

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: Mark_A...@isc.org

dhott...@harrisonburg.k12.va.us

unread,

Dec 12, 2006, 7:20:10 PM12/12/06

to

Im not sure, but I think you can use your old zone files on the new
versions of bind. Can you connect to the server via IP? Is your new
firewall allowing dns requests to your dns server? When you switch
back to the old server does the connection work? That is a lot of
switching to new things at one time.

ddh

Quoting Dana Holland <dana.h...@navarrocollege.edu>:

> We've got a problem here that seems to be DNS related, but I'm not sure.
> We have a website http://blackboard.navarrocollege.edu. Yesterday
> some people started reporting that they couldn't access the website.
> Others can access it just fine.
>
> The problems started when we moved to a gigaman circuit, with a new

> firewall. At the same time we began looking at upgrading our DNS

> server. Our primary server has been running Bind 4 (yes, I know!).
> Yesterday I tested a Bind 8 configuration (in preparation for moving up
> to Bind 9!). It appeared to be working, except that I had forgotten the

> CNAME for the server I'm having problems with. I switched back to my

> Bind 4 configuration thinking that we would function as before until I
> could complete the move to the new Bind.
>

> I'm not sure what I should post to help diagnose this. Below is the
> primary zone file, and the in-addr.arpa. Note that we don't normally
> have TTL set to 900 - we just did that while we were trying to figure
> out this problem.
>

--
Dwayne Hottinger
Network Administrator
Harrisonburg City Public Schools

Kevin Darcy

unread,

Dec 12, 2006, 7:41:42 PM12/12/06

to

OK, this is pretty confusing:
1) you upgraded your network hardware/topology, and some people (but not
others) were having problems accessing your website,
2) You took a stab at upgrading from BIND 4 to BIND 8 in preparation for
BIND 9 (why not just save some time by going directly to BIND 9?), but
you forgot to add a CNAME so you went back to BIND 4 (????). Why didn't
you just add the CNAME record that was missing?

In the interim, I'll just throw out some observations:

1) Syntactically, the only thing I (and the named-checkzone utility) see
wrong with your forward zone file is the absence of the $TTL directive,
but I think even that should be acceptable to most/all versions of BIND 8.
2) In your reverse zone, you have one name
(178.189.162.205.in-addr.arpa) that owns multiple PTR records. While
legal, this is highly DISrecommended. No known application looks beyond
the first record, so why supply more than that? It just bloats the size
of the response packet, in extreme cases to the point where the response
size overflows the allowable size of a DNS UDP packet, and the query
therefore has to be retried using TCP.

- Kevin

P.S. If and when it comes time to upgrade to BIND 9, check out the
"migration" files under doc/misc in the BIND 9 distribution.

Dana Holland

unread,

Dec 14, 2006, 9:46:23 AM12/14/06

to

Mark Andrews wrote:
> Why were you re-entering data? BIND 8 and BIND 9 both read
> the same master files as BIND 4 does. They are just stricter
> than BIND 4 w.r.t. error in the master files.

Thanks everyone. It started working about 5 minutes after I posted to
the group. I guess it was the caching problem mentioned.

I was re-entering data because I was trying to get some clean
configuration files. Such as using the $TTL. And I didn't want to
risk my original files in case something didn't work.

> Just go straight to BIND 9.

Was planning that originally - but the system we're on already had a
Bind 8 binary. My first attempt and compiling and testing Bind 9 didn't
work, so I thought using the Bind 8 as an intermediate step would at
least get me off of Bind 4.