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

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?

On Sun, Nov 8, 2009 at 5:14 AM, Florian Philipp
<lists@f_philipp.fastmail.net> 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

=== 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@dartworks.biz>
public key: ID: 19017044
<http://www.dartworks.biz/>
================================================== ===================

On Mon, Nov 9, 2009 at 12:50 AM, Keith Dart <keith@dartworks.biz> 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.