On Tue, Apr 11, 2006 at 11:30:07AM -0400, sberaud wrote:
> The vhost site I am using for testing showed up for some people,
> such as at Carleton U., but outside of that, nobody else could see
> it. Worse yet, dig and ns lookup did not return anything. This
> suggests a DNS problem to me, and further suggests that Carleton is
> on the same er.. "dns area"(?) zone (?) as my ISP and secondary DNS
> provider, Teksavvy.
There's really no such thing as DNS "zones" in the sense you suggest.
The entire Internet is one "zone", since they all use the same root
DNS servers. Other root DNS servers exist, but these are not widely
used at all, and they break the concept of the Internet as a single
namespace.
The only other way to create "zones" -- where people in one part of
the Internet habitually get different info than another part, even
with fresh, uncached answers -- would be if a name server was set up
to be "authoritative" for a domain it didn't actually have authority
over. That is, it hands out answers for that domain from its own
records, even though it's not an official nameserver of that domain.
This could happen by accident if e.g. you once hosted your domain with
Carleton University, then moved it to someone else, but Carleton
mistakenly never removed your records from their DNS server. This
would mean that people at Carleton would see one set of records, while
the rest of the world would see another.
Another possible (but exceedingly unlikely) way to create "zones" is
malicious overriding of domains by major nameservers. For example, I
could run ISP-A, and set up my nameservers to give false answers for
my competitor's ISP-B.com, thus preventing my customers from accessing
ISP-B's website. But that wouldn't stop the Internet at large, only
my customers.
It's far more likely that different people are seeing earlier or later
version of your DNS info, cached, that either work or don't work.
If I request a record from your domain (like "www.your-domain.com")
and I use the Carleton nameserver to do that, it caches the result.
And now, so long as that cached answer remains, everyone at Carleton
will see the same result I did. If you then change it, other people
who access it for the first time will get your new records, while
Carleton users continue to get the old one.
Be warned that even failures are cached, albeit for a shorter time
than successful results. Hence, you can't make edits to your config
and expect immediate results (e.g. "can you see me now?").
> My main site is using my registrars domain forwarding service to
> provide dns to my main site IP for a basic www and mail host. No
> bind required.
"Domain forwarding" is fairly vague, so I'm not really sure what
you're talking about here. My guess is that they handle the DNS, but
"www.your-domain.com" resolves to your static IP.
> The registrar now says that their forwarding service is broken - old
> sites work, new sites not - and I need to provide real name servers
> for my new domains. OK.
Okay, so like a standard DNS domain.
> Because I want to use my static-ip as my primary DNS server, but the
> main site (which is my machine host name) is being handled my their
> basic forwarders.
Is this the "domain forwarding" you mentioned above?
> Does it cause BIND/Apache to not handle virtual sites very well?
As long as Apache receives proper HTTP/1.1 requests, it can handle
name-based virtual sites fine. The key is making sure that people are
actually hitting your web server, and that you've configured it
properly. Once requests are making it to your system, Apache and DNS
are pretty much unrelated.
> The reason I ask is while dig, and whois show my main domain working
> right with the forwarding service, the same can not be said for the
> virtual domains. They know of the site, but they seem to not be able
> to see my name server.
Sounds like people just aren't reaching your nameserver. This could
be a configuration mistake (e.g. wrong IP for your nameserver, or a
bind config problem) or a firewalling issue (either your ISP's
firewalling or your own).
Try watching port 53 with
tcpdump -i any port 53 -n
and have someone on the outside query your domains, specifically using
your IP address as their DNS server:
host <www.your-domain.com> <your-static-ip>
Via tcpdump, you should see incoming DNS requests (and perhaps
outgoing DNS replies). If you don't, then they won't get an answer,
and that's the root of your problem.
If the above works fine (you see incoming and outgoing, and the other
person gets a proper response), then the problem lies elsewhere.
> Firewalls would not seem to be an issue as I can transfer domains
> and accept queries from my remote secondary.
Domain transfers are typically done via TCP rather than UDP. Using
the above should tell you what other people see. Be sure to use
someone other than your remote secondary as your test subject for the
above, in case special rules apply to your remote secondary.
> So what do I do to start this process from scratch? What are the
> minimum record types needed in BIND to get my primary domain to act
> as an authoritative DNS host, and get my sites to all play nice with
> each other?
In your bind config:
zone "your-domain.com" {
type master;
file "/path/to/zone/files/your-domain.com";
};
In /path/to/zone/files/your-domain.com, this is a generic example:
; Default TTL (1d).
$TTL 86400
; Start Of Authority:
@ SOA your-hostname hostmaster.your-hostname (
2006041101 ; serial (yyyymmdd##)
1800 ; refresh (30m)
900 ; retry (15m)
604800 ; expire (7d)
1200 ; minimum (20m)
)
NS your-hostname
NS secondary.other-domain.com.
MX 0 your-hostname
; Records in domain:
your-hostname A your-static-ip
@ A your-static-ip
www CNAME your-hostname
; End.
> So to confirm one thing: I do _not_ use the local subnet IPs in bind in
> any manner for these sites. I use the static IP. Even though the machine
> is a different IP, my router will forward to it as if it was?
This is all correct, bearing in mind that the forwarding is not magic.
You need to set your router to either a) forward certain ports to your
internal IP (e.g. UDP 53 and TCP 53+80), or b) forward everything to
your internal IP, often called the "DMZ" setting.
> Do I take the risk and "un-forward" the service and run my primary
> domain from my own primary DNS (this is the old way I had it configured
> years ago, but I it was way easier to use their service as my server was
> only for light duty use when I first started this up again).
Absolutely not, at least until you've got other domains working
using your server as a primary DNS. There is no way that your
"forward" style service (whatever it really is) would be confusing
Apache. If you switched, you'd just be condemning your primary
domain to the same issues, which sounds like a bad thing considering
you need it for work.
Good luck.
Attachment:
signature.asc
Description: Digital signature