Is this the right way?

[Kevin Darcy]

jymmm at yahoo.com wrote:

> I've never setup a dns server from scratch, so comments
> and suggestions would be appreciated.
> Nothing has been setup yet, just doing my homework.
>
> I have a 1.5Mb/128kb dsl with a single static IP behind a NAT box.
> I want to start developing some anti-uce tools and need the reverse
> to match up to the domain (and ip-less virtual domains).
>
> I've been able to convince my ISP to deligate authority for the reverse
> as per RFC2317, section 5.2 as I understand it from reading this from
> another ISP: http://www.dnai.com/services/policies/dns_policies.html
>
> 1) Would this be the correct configuration?
> ===============================================================
>
> In my ISP's reverse file:
> ---------------------------------------------------------------
> 130.0.0.300.in-addr.arpa.  IN  CNAME  300-0-0-130.mydomain.com.
> ---------------------------------------------------------------
>
> In my mydomain.com.hosts file:
> ---------------------------------------------------------------
> 300-0-0-130.mydomain.com.  IN PTR   host.mydomain.com.
> host.mydomain.com.         IN A     300.0.0.130
> mydomain.com.              IN A     300.0.0.130
> mydomain.com.              IN MX 10 mydomain.com.
> mydomain.com.              IN NS    300.0.0.130
> mydomain.com.              IN NS    300.1.1.111 (My ISP's Pri DNS server)
> mydomain.com.              IN NS    300.2.2.222 (My ISP's Sec DNS server)
> www.mydomain.com.          IN CNAME mydomain.com.
> mail.mydomain.com          IN CNAME mydomain.com.
> ---------------------------------------------------------------
>
> I'm not too clear about RFC2317 section 5.3 and if this could
> break what I'm trying to accomplish here.

Your zone needs an SOA record, of course. Once you add that, seems like it
should work. Assuming, of course, that you actually register mydomain.com...

Note that it is recommended practice when implementing RFC 2317, to arrange
to make oneself a slave for the /24 reverse domain (0.0.300.in-addr.arpa in
your case) from your ISP. That way, your nameserver should be able to
reverse-resolve your address even if your ISP's nameservers are temporarily
unavailable.

> 2) Would this cause alot of traffic (only have 128kbps avail)
> ===============================================================
> I really don't want to suck up ALL of the bandwidth I have.

Hard to know. How often will 130.0.0.300.in-addr.arpa or mydomain.com names
be queried? What do you plan for the REFRESH and RETRY settings for the zone
(in the SOA record)? What is REFRESH/RETRY for the /24 reverse zone? How big
are the zones, and how often do they change? All of these things drive the
traffic profile.

> I heard, but can't recall where, that I can setup a 'blind' dns
> server so my ISP's dns servers appear to be authoritive for the domain,
> but still allow me to make changes on my local dns server, and have them
> updated on my ISP's server.

I think you mean "hidden master" rather than "blind". As a matter of
terminology, if a nameserver is a slave for a zone (as your ISP's
nameservers would be, presumably), then it is "authoritative" for that zone.
The only thing different about a "hidden master" configuration is that the
master is, well, hidden, i.e. there is no NS record for it and so it never
gets any normal queries, only serial-number checks and the occasional zone
transfer, from the slaves. This should reduce the traffic on your link,
depending again on what the REFRESH/RETRY settings are, the size of the
zone, the frequency of change, etc.

> 4) Virtual domains
> ===============================================================
> I also would like to be able to do virtual hosting (ip-less).
> Is there any reason I couldn't do this using the above configuration?
> No heavy traffic, just mostly for fun and testing.

Sure. From a DNS perspective, named-based virtual hosting consists of
nothing more than a bunch of aliases and/or A records all resolving,
ultimately, to the same address. Not exactly rocket science.

Nothing you've specified in #1, #2 or #4 seems terribly problematic.
However, I'm less optimistic about something you mentioned earlier:

> [I] need the reverse to match up to the domain (and ip-less virtual domains).
>

A reverse record is practically speaking a one-to-one mapping. (Technically
it's not, but nothing actually looks beyond the first PTR record, so
practically speaking it is). So you can have a bajillion names all resolving
to 1 IP address, but the reverse record for that IP address only maps back
to one of those names. Sounds like this might be a showstopper for you...


- Kevin