How to create a fake root server?
Lawrence K. Chen, P.Eng.
lkchen at ksu.edu
Thu Mar 13 21:44:18 UTC 2014
Had to think for a moment on how we got our own TLD to work....
The answer is that all our resolvers, including the localhost resolvers
for machines in 10.x.x.x space.
Don't recall if it was related to this or not...but these localhost
resolvers also use "forward first;"
I had at one time tried to make the recursive caching resolvers be only
this...stop being authoritative slaves....which didn't work. And, I had
heard complaints of people who refuse to use central DNS not being able
to resolve names our own TLD, or only visible through the our ksu
(internal) view. The latter, being that our published
authoritative-only nameservers only know about the external view (or use
our central DNS servers...since they are currently all also being
authoritative for our TLD (and for ksu.edu & k-state.edu.)
On 03/13/14 15:28, Peter wrote:
> I finally managed to configure a TLD DNS server which will answer, in
> its own CLI, with proper IP:s for added domains. The problem is that it
> doesn't reply to the other querying Domain DNS servers when they are
> asking for domain lookups to it. I can only do lookups inside the TLD
> DNS server.
>
> The TLD server settings:
>
> named.conf
> -----------------------------------------------
> options {
> directory "/var/cache/bind";
>
> // forwarders {
> // 0.0.0.0;
> // };
>
> dnssec-validation auto;
>
> auth-nxdomain no; # conform to RFC1035
> listen-on-v6 { any; };
> allow-query { any; };
> recursion yes;
> };
> zone "loc" {
> type master;
> file "/etc/bind/pri.loc";
> };
> -----------------------------------------------
>
> pri.loc
> -----------------------------------------------
> $ORIGIN .
> $TTL 7200 ; 2 hours
> loc IN SOA ns1.intranet admin.intranet.loc (
> 2 ; serial
> 7200 ; refresh (2 hours)
> 1800 ; retry (30 minutes)
> 7200 ; expire (2 hours)
> 7200 ; minimum (2 hours)
> )
> NS ns1.intranet
> $ORIGIN loc.
> domain1 A 172.16.0.121
> domain2 A 172.16.0.122
> -----------------------------------------------
>
> TLD Server# ping domain1.loc
> PING domain1.loc (172.16.0.121) 56(84) bytes of data.
> 64 bytes from 172.16.0.121: icmp_req=1 ttl=64 time=0.196 ms
> 64 bytes from 172.16.0.121: icmp_req=2 ttl=64 time=0.160 ms
> 64 bytes from 172.16.0.121: icmp_req=3 ttl=64 time=0.177 ms
> ----
> TLD Server# ping domain2.loc
> PING domain2.loc (172.16.0.121) 56(84) bytes of data.
> 64 bytes from 172.16.0.121: icmp_req=1 ttl=64 time=0.193 ms
> 64 bytes from 172.16.0.121: icmp_req=2 ttl=64 time=0.168 ms
> 64 bytes from 172.16.0.121: icmp_req=3 ttl=64 time=0.172 ms
> ----
> Domain Server1# ping domain2.loc
> ping: unknown host domain2.loc
> ----
> Domain Server2# ping domain1.loc
> ping: unknown host domain2.loc
> ----
>
> On both Domain DNS servers, I have made forwards with the IP of the TLD
> server. But they simply will not receive any lookup answers. They have
> also been configured with 127.0.0.1 in the resolv.conf file, which means
> they will use their own internal DNS server for lookups. All servers are
> on the same 172.16.0.x network.
>
> What am I doing wrong here?
>
> Sincerely, Peter
>
>
> On 13/03/14 11:10, Mark Andrews wrote:
>> In message <53216B43.8040200 at gmail.com>, Peter writes:
>>> Hi Kevin,
>>>
>>> Thanks for your reply. It's just for a closed internal network with no
>>> access to the rest of the internet. Making labs such as testing ISP
>>> functions and services, mail servers etc. Everything is running inside
>>> an VMware host with an internal closed network.
>>>
>>> I have created a closed "Internet" on 172.16.x.x where I would like to
>>> put up a root server for .loc, where several other ISP-DNS servers, with
>>> domains, are referred to. I've managed to create those "ISP-DNS" servers
>>> which works fine. But I'm having trouble to create the root DNS server
>>> with Bind. I haven't found any useful examples at the web yet.
>> Perhaps because a root zone is like any other zone. It has a SOA
>> record and NS records at the apex and other records.
>>
>> . 3600 SOA server.example.net. hostmaster.example.net. 1 3600 1200
>> 2419200 3600
>> . 3600 NS server.example.net.
>> . 3600 NS another.example.net.
>> server.example.net. 3600 A 1.2.3.4
>> another.example.net. 3600 A 1.2.3.5
>>
>>> It's for a school project.
>>>
>>> Regards, Peter
>>>
>>>
>>> On 12/03/14 19:56, Kevin Darcy wrote:
>>>> First of all, don't use .loc as an internal TLD. There are *many*
>>>> proposals in process with ICANN for establishing new TLDs, and for all
>>>> you know, .loc might be one of them. If .loc gets established on the
>>>> Internet, and you're using it internally, that presents abundant
>>>> opportunities for confusion and failure.
>>>>
>>>> Use a publically-registered domain, a descendant of a
>>>> publically-registered domain, or potentially, one of the reserved TLDs
>>>> in RFC 6761.
>>>>
>>>> I'm not sure what your question is, exactly. Set up the root zone,
>>>> slave it, publish 2 or more of the master/slaves in the NS records,
>>>> delegate whatever TLD you're going to use, set up *that* zone, lather,
>>>> rinse, repeat, for the entire hierarchy. Anyone who reads
>>>> _DNS_and_BIND_ should be able to set up an internal-root
>>>> infrastructure, IMO (although, sadly, the later editions don't seem as
>>>> aligned to internal-root as they used to be).
>>>>
>>>> - Kevin
>>>>
>>>>
>>>> On 3/12/2014 11:07 AM, Peter wrote:
>>>>> Hi guys,
>>>>>
>>>>> I'm doing a virtual internet (internal net) for several VPS's. My
>>>>> goal is to simulate the Internet root servers and the ISP:s domain
>>>>> servers, which are hosting the actual domains. I want to the create
>>>>> several DNS nameservers that will contain the specific domain under
>>>>> the "xxx.loc, yyy.loc, zzz.loc".
>>>>>
>>>>> 1 server for the .loc root
>>>>> 3 servers for xxx.loc (server1), yyy.loc (server2), zzz.loc (server3)
>>>>>
>>>>> Running BIND 9 at every server.
>>>>>
>>>>> Any suggestions or good links are highly appreciated.
>>>>>
>>>>> Best regards,
>>>>> Peter
>>>>> _______________________________________________
>>>>>
>
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
For: Enterprise Server Technologies (EST) -- & SafeZone Ally
More information about the bind-users
mailing list