help with tinydns setup

[James-207]

All,

I'm trying to set up a DNS server here for a lab environment.

- hijacking a TLD (linux.com let's say, as an example)
- trying to point several Linux boxen in a sandbox with no internet connectivity

So, here's a copy of my tinydns data file:

.linux.com:172.18.109.125:a:259200
=server1.linux.com:14.17.108.241:86400
=server2.linux.com:14.17.108.242:86400

I've been following instructions on the following two pages in order
to get some guidance on where I'm going with this:

http://www.fredshack.com/docs/djbdns.html
http://wiki.vpslink.com/HOWTO:_Setup_a_DNS_server_with_tinydns

Inside of /etc/dnscache/root/servers/linux.com I have "127.0.0.1" so
that the server knows to query the tinydns daemon running.
Unfortunately, however, a "dig @<ipAddr> server1.linux.com" doesn't
seem to work.

Thoughts? Ideas?

Thanks!
-j

[Roy Wright-2]

On Nov 7, 2009, at 3:49 PM, James wrote:

> All,
>
> I'm trying to set up a DNS server here for a lab environment.
>
> Thoughts? Ideas?
>

I use dnsmasq as my home dns/dhcp server.  It was super easy to  
configure.  You might want to give it a look.

HTH,
Roy

[Florian Philipp-4]

James schrieb:

> All,
>
> I'm trying to set up a DNS server here for a lab environment.
>
> - hijacking a TLD (linux.com let's say, as an example)
> - trying to point several Linux boxen in a sandbox with no internet connectivity
>
> So, here's a copy of my tinydns data file:
>
> .linux.com:172.18.109.125:a:259200
> =server1.linux.com:14.17.108.241:86400
> =server2.linux.com:14.17.108.242:86400
>

[...]
>
> Inside of /etc/dnscache/root/servers/linux.com I have "127.0.0.1" so
> that the server knows to query the tinydns daemon running.
> Unfortunately, however, a "dig @<ipAddr> server1.linux.com" doesn't
> seem to work.
>
>

What do you mean with "doesn't seem to work"? Timeout? Wrong answer?

[James-207]

On Sun, Nov 8, 2009 at 5:14 AM, Florian Philipp
<lists@...> wrote:

> James schrieb:
>> All,
>>
>> I'm trying to set up a DNS server here for a lab environment.
>>
>> - hijacking a TLD (linux.com let's say, as an example)
>> - trying to point several Linux boxen in a sandbox with no internet connectivity
>>
>> So, here's a copy of my tinydns data file:
>>
>> .linux.com:172.18.109.125:a:259200
>> =server1.linux.com:14.17.108.241:86400
>> =server2.linux.com:14.17.108.242:86400
>>
> [...]
>>
>> Inside of /etc/dnscache/root/servers/linux.com I have "127.0.0.1" so
>> that the server knows to query the tinydns daemon running.
>> Unfortunately, however, a "dig @<ipAddr> server1.linux.com" doesn't
>> seem to work.
>>
>>
>
> What do you mean with "doesn't seem to work"? Timeout? Wrong answer?
>

Well, tinydns must be bound to a different address than dnscache.

If I do a dig @<tinydns ip address> server1.linux.com it responds with
the correct address.

However, if I put the dnscache IP address in my /etc/resolv.conf,
resolution to *any* IP address (including server1.linux.com and
server2.linux.com) fails.

Thoughts?
-j

[Keith Dart ♂]

=== On Sun, 11/08, James wrote: ===
> Thoughts?
> -
===

What I have done is bind named to a dummy interface, which serves a
psuedo TLD, and use dnsmasq for the local DNS.


2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
    inet 10.111.1.130/24 brd 10.111.1.255 scope global eth0
3: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state
    inet 172.17.211.1/24 brd 172.17.211.255 scope global dummy0

Then you have different interfaces to bind to, and different networks
to route to internally.



-- Keith Dart

--

-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   Keith Dart <keith@...>
   public key: ID: 19017044
   <http://www.dartworks.biz/>
   =====================================================================

[James-207]

On Mon, Nov 9, 2009 at 12:50 AM, Keith Dart <keith@...> wrote:

> === On Sun, 11/08, James wrote: ===
>> Thoughts?
>> -
> ===
>
> What I have done is bind named to a dummy interface, which serves a
> psuedo TLD, and use dnsmasq for the local DNS.
>
>
> 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
>    inet 10.111.1.130/24 brd 10.111.1.255 scope global eth0
> 3: dummy0: <BROADCAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc noqueue state
>    inet 172.17.211.1/24 brd 172.17.211.255 scope global dummy0
>
> Then you have different interfaces to bind to, and different networks
> to route to internally.

I'd rather not use named. tinydns seems simpler to set up (despite my
problems) and is theoretically far more secure.