LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   Creating a bogus DNS domain inside private address range network (https://www.linuxquestions.org/questions/linux-networking-3/creating-a-bogus-dns-domain-inside-private-address-range-network-713420/)

zogness 03-21-2009 02:32 PM

Creating a bogus DNS domain inside private address range network
 
Like most people with high speed internet I have only one real, routable IP address. I have a gateway/firewall/masquerade machine "in front of" all the rest of the computers in my LAN. This firewall/gateway also does caching DNS and dhcpd for the internal machines.

The idea is to create a bogus DNS domain like, "hey.you" for my LAN so I can experiment with stuff like LDAP, which requires fully qualified domain names and working DNS.

I know this setup is possible. Had such a fake/internal DNS domain set up years ago with Bind 8. I can't find any trace of it in my backups.

Do any of you have such a setup running now or know of a good How-To?

Thanks.

bathory 03-22-2009 05:04 PM

There is nothing special to do to add a domain in bind, either it is real or bogus.
Just add the appropriate entry in /etc/named.conf, create the zone file of the new domain and use your dns ip address in /etc/resolv.conf of the clients.

archtoad6 04-06-2009 12:27 PM

Although I think it's too long (11 characters), & would prefer ".lan"; I believe ".localdomain" is reserved for this purpose. Or did I miss your point?

SaintDanBert 10-15-2009 06:19 PM

Quote:

Originally Posted by archtoad6 (Post 3500287)
Although I think it's too long (11 characters), & would prefer ".lan";

I, too, like to use dot-lan. Given that there is RFC convention for private networks, I'm surprised that there is no RFC convention for "private network domain names". If my organization want 100 top-level private names, some guidelines might be useful. (I'd love to discover that I'm wrong about this and what that convention is.)

Quote:

Originally Posted by archtoad6 (Post 3500287)
I believe ".localdomain" is reserved for this purpose.

Yes, "localhost.localdomain" is universal name for "THIS computer on THIS network". However, I think it applies to the 127.0.0.xxx series of network addresses. (I'd love to know the facts about that.)

While every computer on the same LAN could be a member of "this network" [aka, localdomain], one workstation would not know a name assigned to another workstation on the same LAN. The other option is to have each host have its own /etc/hosts file and use static IP addresses.

There is some way that DHCP and dynamic IP addresses interact with DNS to create unique names on-the-fly that is known to the local name servers. Would love to learn how to make that work so I've never used the feature.

Cheers,
~~~ 0;-Dan

zogness 10-16-2009 10:40 AM

Thanks for the reply.

I have named almost the way I want it now. From my workstation I can do "host skullery.oplz.lan" and reliably receive the right IP address as well as any CNAME I have applied.
What I can't get is the one thing I most want. I can't do "ssh skullery".
I can go "ssh skullery.oplz.lan" and login but I can't login using the unqualified host name.

My resolv.conf has this in it:

domain oplz.yo
search oplz.yo
nameserver 192.168.10.42

Perhaps I should take the machines with A records in DNS out of my dhcpd.conf file. However the IP and hostnames in the dhscpd.conf -do- match what I have in DNS, so I'm not sure how dhcpd would get in the way. I do have option domain-name "oplz.yo"; and option domain-name-servers 192.168.10.42; in my dhcpd.conf file.

SaintDanBert 10-16-2009 10:55 AM

Quote:

Originally Posted by zogness (Post 3721791)
...
I can go "ssh skullery.oplz.lan" and login but I can't login using the unqualified host name.

My resolv.conf has this in it:

domain oplz.yo
search oplz.yo
nameserver 192.168.10.42

...

Am I missing something obvious our should your default domain read
Code:

domain oplz.lan
search oplz.lan

instead of the oplz.yo that you report?

QUESTION: If you have it mostly working, how did you deal with personal, family and visitor DHCP hosts and your DNS lists? Are you using MAC-matching {my term} to assign specific IP to specific MAC addresses?

QUESTION: Is there any chance that you might share what you did in ways that (a)protect your security, and (b) enable others to try something similar

~~~ 0;-Dan

zogness 10-16-2009 10:56 AM

In fact I can resolve hosts using only their hostnames uisng /usr/bin/host and dig but from ssh I need to use the fqdn. How does this make sense?

zogness 10-16-2009 10:58 AM

oh. I changed it.
 
I used .yo instead of .lan across the entire network.

Yes, I do use MAC addresses in dhcpd.conf.

zogness 10-16-2009 11:11 AM

Here is my zone file. One thing none of the docs talk about is the significance of "hostmaster" in this config. Is that a required thing? Seems to always be present. Is there something magical about it? Could I change hostmaster to some other string?
----------------------------------------------------------------------------------------------------
$ORIGIN nplz.yo.
$TTL 1D
@ IN SOA ns.oplz.yo. hostmaster.oplz.yo. (
2009101511 ; serial, todays date + todays serial #
8H ; refresh, seconds
2H ; retry, seconds
4W ; expire, seconds
1D ) ; minimum, seconds
NS ns
zucchini CNAME ns
1 PTR localhost.
localhost A 127.0.0.1
ns A 192.169.10.42
sparc A 192.168.10.1
jdn A 192.168.10.53

Here is my named.conf:
-----------------------------------------------------------------------------------------------------
include "/etc/bind/rndc.key";
zone "0.0.127.in-addr.arpa" {
type master;
file "pz/127.0.0";
};
zone "oplz.yo" IN {
type master;
file "/etc/bind/pz/oplz.yo.db";
#allow-transfer { none; };
#allow-update { none; };
};
zone "10.168.192.in-addr.arpa" {
type master;
file "/etc/bind/pz/rev.10.168.192.in-addr.arpa";
};

SaintDanBert 10-16-2009 11:14 AM

Quote:

Originally Posted by zogness (Post 3721814)
In fact I can resolve hosts using only their hostnames uisng /usr/bin/host and dig but from ssh I need to use the fqdn. How does this make sense?

Sadly, man ssh said almost nothing about host name resolution.
Take a look into man ssh_config. My quick scan revealed that there are all sorts of pattern matching and other processing that can happen. {grin}I'll leave that exercise to the student.{/grin}

zogness 10-16-2009 11:16 AM

$ORIGIN nplz.yo.

Should and does read, "$ORIGIN oplz.yo."

I'm not using my real (fake) domain in this post.

Just assume my files are consistantly set up for oplz.yo.

SaintDanBert 10-16-2009 11:18 AM

Quote:

Originally Posted by zogness (Post 3721818)

Yes, I do use MAC addresses in dhcpd.conf.

Which box on your lan does DHCP -- a server or a network-specific box (linksys, &c)?

When you have visitors, I suspect that they play standard DHCP and get the address of your in-house name server. If they wish to play with your resources {blush} they use something.oplz.yo and all is well. Do I understand what you are doing?

Also, do you play with win-dose workstations at all? Do they play well with others using your scheme? It seems to me that redmond-DNS is not quite the same as for the rest of us.

Cheers,
~~~ 0;-Dan

zogness 10-16-2009 11:27 AM

A linux server (not the DNS server) does dhcpd for my lan. I don't trust a "black box."

I have a range of reserved IP addresses in dhcpd.conf and a block of freely assignable ones.

There is no Windows machine on my LAN. None.

You said, "they use something.oplz.yo and all is well."
No. Visitors only get an IP address.

zogness 10-16-2009 01:34 PM

I just realized I had a typo in the IP address for the machine I was trying to ssh into. Typo in the CNAME in the zone file. Now I can ssh in, since I fixed the typo. Was not an SSH issue.

When I did the host command (and thought my DNS config was fine) my eye did not catch the bad IP address returned. I was getting 192.169.10.42 and could not notice the 169 for the longest time. We tend to correct stuff (like spelling errors) without even knowing it.


All times are GMT -5. The time now is 07:20 AM.