PTR records shoud have no impact on browsing. PTR are reverse lookups used most often for email verification.
The issue has to be in DNS, I agree about that. What is the name of the domain to which your webserver responds, flagstaff.k12.az.us? If you don't feel confortable giving it out, do you use the same domain internally as externally?
I see that flagstaff.k12.az.us resolves to: 184.108.40.206.
The authroitative server for it shows as: NS1.INFOMAGIC.NET
It also shows itself as its own authoritative answer.
Now, your clients are probably also using the same webserver, so they are trying to go to 220.127.116.11. I assume that this server sits in a DMZ somewhere and you have certain ports on the public address forwarded to this server instead of giving the acutal server a true public address.
If that is true, when you say you can put the IP address of the server in the client's address line it works fine... are you putting in the public address or the private address?
If you are using the private address, does it work if you use the public address (18.104.22.168).
If it works with the local address but not the public, it's that your firewall is having issues with an internal client requesting an address/port that is internal to the firewall.
If the domain is correct, then I see it is for a public school district. Do you use a proxy server to filter your client's connections? If so, the issue could be with your proxy server? The clients are often setup to bypass the proxy for local addresses. So, it would work just fine if you put in a local IP address of the server, but would not work if you use the domain since it resolves to an external address.
I guess that is enough speculation for now...
**Update** I see that your "Technical Services" link goes to http://10.3.97.27/Help_desk/techweb.html
I guess I answered one of my questions... ;o)