home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] Apache, Bind and virtual hosts again

Adrian Irving-Beer wrote:
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?").
That confirms what I suspected, I just didn't have the words to describe it. I am pleased you understood. :)
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.

Pretty much right, yes. registeryour.ca provides a service where their "park" servers will act as a basic primary and secondary DNS. Their web config form asks for an IP for www and mail, and thats it.

I have named the machine www.mydomain.net to accommodate that distinction, where I used to use cname to alias www as the host was actually called ns.mydomain.net. I would prefer it be that way again, but Mandrake really hates hostname changes.

If this wasn't so darned urgent (clients are not happy) I would scrap it for Ubuntu, but I just don't have the time to screw up Ubuntu as well, heheheh :)
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?

It is indeed.
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.

This is good to know and is new information for me. It seemed from the docs that cname was essential for vhosts, but further reading suggests thats for v-subdomains on vhosts. Gaaaaaaa.
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.

Thank you for that, I had no idea how to watch it, I was simply tailing messages which tells me a lot, but not enough.
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.

Gotcha.
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.


Thank you, thank you. I had lost my old zones (after keeping them on CD for damn near 10 years) recently and was having to work through the zone file like a complete newbie again. I see where I made some mistakes now.
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.

Thank you, I really did not want to risk the main site until I had this sorted out either.

I will make the recommended changes and let you know how it went.

Thanks again.
Scy