My Leopard Server DNS had been working fine... hosting 7 domains with
numerous hosts each, in some cases. Haven't made any changes in at
least
over a week. The TTL's were set to 3 hours.
Now there are cases where a user can get to one site but can't resolve
another. Another user can't get to the first, but can get to the
second.
Can't make heads or tails out of it.
I used dnsstuff.com and it was able to successfully test the site.
The two major domains in question are dsop.com and pennsyrr.com, if
anyone
cars to troubleshoot.
This looks like a faux paux on your part, at least partially.
The designated DNS servers for the dsop.com zone are, "dns.dsop.com"
and "ns-1.epix.net". (Got this by running "dig @a.gtld-servers.net
dsop.com ns", directly querying one of the GTLD servers.)
Now, it appears that the "dns.dsop.com" server responds reasonably.
Running "dig @dns.dsop.com dsop.com any" returns:
; <<>> DiG 9.3.4 <<>> @dns.dsop.com dsop.com any
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 3416
;; flags: qr aa rd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 3
;; QUESTION SECTION:
;dsop.com. IN ANY
;; ANSWER SECTION:
dsop.com. 86400 IN MX 20 mail.dsop.com.
dsop.com. 86400 IN MX 10 dsop.com.
dsop.com. 86400 IN SOA dns.dsop.com.
admin.dsop.com.dsop.com. 2007113002 86400 3600 604800 345600
dsop.com. 86400 IN NS dns.dsop.com.
dsop.com. 86400 IN A 216.222.241.56
;; ADDITIONAL SECTION:
mail.dsop.com. 86400 IN A 216.222.241.56
dsop.com. 86400 IN A 216.222.241.56
dns.dsop.com. 86400 IN A 216.222.241.56
This server appears to NOT be configured to be a server for your
zone. What will happen is that if someone makes a query for
something in your zone it will recursively identify that either
"dns.dsop.com" or "ns-1.epix.net" will be able to provide the
information for this zone. If, your server is queried for the
request, the user will get the information that they desire. If they
query the other server it will simply tell them that there isn't any
information available, and they won't get the information they desire.
Talk to who ever manages the "ns-1.epix.net" server and have them
properly configure their server for your zone! I believe that many/
most of your problems will then go away.
Now, in YOUR data for this zone you have only identified that your
"dns.dsop.com" server is a server for this zone. Assuming that EPIX
gets their server configured, then even if someone does reach this
EPIX server for your DNS information, then once the "NS" record gets
cached then ONLY your server will ever be queried. You have broken
the redundancy built into DNS - bad mistake.
Now, you claim that you used DNSSTUFF to check out your DNS
operation. They should have reported this same problem to you. When
I ran the checks on DNSSTUFF for this zone it said that their were
both warnings and failures. I would strongly suggest that you heed
these messages and fix them. I don't consider the report on your
zone as "able to successfully test the site"!
Given this, I didn't spend any time looking at your other zone. Very
likely the same problem.
I've also noted, all along, that Leopard Server doesn't seem to
provide
SOA records. Can anyone comment on this?
Can't comment, but the zone on your server provides an SOA record.
In fact, if it didn't, I would be surprised if the "named" process
would even load the zone.
As David said, I would also check the zone files myself if I had such
a question.
Bill Larson
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/email@hidden
