LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices

Reply
 
Search this Thread
Old 07-05-2004, 02:58 PM   #1
remi
LQ Newbie
 
Registered: May 2003
Distribution: Red Hat Linux 9.0
Posts: 16

Rep: Reputation: 0
BIND: local TLD work, but not outside TLDs


Hello all,

I'm trying to setup my Fedora Core 1 Linux computer has a nameserver. The nameserver will be used by the other computers on my LAN, which is connected to the Internet with a router, so they'll be able to access the normal TLD's (e.g.: .com, .net, etc.) and the internal one, .kawamura, which I use for testing. I already know everything is stored in /var/named/chroot . (Took me sometime to figure that out!)

I have setup everything, but now, I can only access the internal .kawamura domain, and not the external ones. I can ping and I can get records from dig for *.kawamura, *.root-servers.net, and *.gtld-servers.net, but everything else don't work.

Here are my files:

/var/named/chroot/etc/named.conf {
Code:
// generated by named-bootconf.pl

options {
        directory "/var/named";
        //forward first;
        /*
         * If there is a firewall between you and nameservers you want
         * to talk to, you might need to uncomment the query-source
         * directive below.  Previous versions of BIND always asked
         * questions using port 53, but BIND 8.1 uses an unprivileged
         * port by default.
         */
        query-source address * port 53;
};

//
// a caching only nameserver config
//
controls {
        inet 127.0.0.1 allow { localhost; } keys { rndckey; };
};

zone "." IN {
        type hint;
        file "named.cache";
};

//zone "." IN {
//      type slave;
//      file "tld-root.txt";
//      masters { 208.185.249.250; 208.185.249.251; 199.175.137.211; };
//}

zone "localhost" IN {
        type master;
        file "localhost.zone";
        allow-update { none; };
};

zone "0.0.127.in-addr.arpa" IN {
        type master;
        file "named.local";
        allow-update { none; };
};

zone "kawamura" {
        type master;
        file "kawamura.zone";
        allow-update { none; };
        allow-query { any; };
};

include "/etc/rndc.key";
}

/var/named/chroot/var/named/kawamura.zone {
Code:
$ORIGIN kawamura
$TTL 86400
kawamura.       IN      SOA     ns.kawamura. hostmaster.kawamura. (
                        2004070101      ; serial, todays date + todays serial #
                        8H              ; refresh, seconds
                        2H              ; retry, seconds
                        1W              ; expire, seconds
                        1D )            ; minimum, seconds

kawamura.       IN      NS      ns.kawamura.    ; Inet Address of name server
kawamura.       IN      MX      10 mail         ; Primary Mail Exchanger

kawamura.               IN      A       192.168.0.100
localhost.kawamura.     IN      A       127.0.0.1
sadako.kawamura.        IN      A       192.168.0.100
ns.kawamura.            IN      A       192.168.0.100
linuxhost.kawamura.     IN      A       192.168.0.100
mail.kawamura.          IN      A       192.168.0.100
www.kawamura.           IN      A       192.168.0.100
keiko.kawamura.         IN      A       192.168.0.105
maiko.kawamura.         IN      A       192.168.0.103
latouffe.com.kawamura.  IN      A       192.168.0.100
}

The "named.cache" file is the last version I got from ftp.internic.net .

Any ideas? Thanks in advance!

Last edited by remi; 07-05-2004 at 02:59 PM.
 
Old 07-05-2004, 03:08 PM   #2
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Rep: Reputation: 69
Have you tried using ndc to increase your log level and read the log output? Also, why did you setup your test zone as a TLD? That's generally a bad idea as resolvers have special ideas about TLDs. You should setup your zone as a second-level domain.
 
Old 07-05-2004, 04:40 PM   #3
remi
LQ Newbie
 
Registered: May 2003
Distribution: Red Hat Linux 9.0
Posts: 16

Original Poster
Rep: Reputation: 0
As a second-level domain? ... I thought that would have been worst? I'll change that later.

So, I got some logs. I tried to get records with dig for edojin.info and slashdot.org . For some reason, now, sometimes it works for some domains, sometimes it doesn't. When it doesn't work for one, it stops working.

named.run (dunno why rndc picked that name...):

For edojin.info (failed)
Code:
Jul 05 17:32:43.653 received control channel command 'trace'
Jul 05 17:32:44.072 received control channel command 'trace'
Jul 05 17:32:44.458 received control channel command 'trace'
Jul 05 17:32:45.919 received control channel command 'trace'
Jul 05 17:32:46.385 received control channel command 'trace'
Jul 05 17:33:07.812 client 127.0.0.1#32795: UDP request
Jul 05 17:33:07.812 client 127.0.0.1#32795: using view '_default'
Jul 05 17:33:07.812 client 127.0.0.1#32795: request is not signed
Jul 05 17:33:07.812 client 127.0.0.1#32795: recursion available: approved
Jul 05 17:33:07.812 client 127.0.0.1#32795: query
Jul 05 17:33:07.812 client 127.0.0.1#32795: query (cache) approved
Jul 05 17:33:07.812 client 127.0.0.1#32795: replace
Jul 05 17:33:07.812 clientmgr @0x8738840: createclients
Jul 05 17:33:07.812 clientmgr @0x8738840: create new
Jul 05 17:33:07.812 client @0x8781558: create
Jul 05 17:33:07.812 createfetch: edojin.info A
Jul 05 17:33:07.812 fctx 0x8783848: join
Jul 05 17:33:07.812 fetch 0x87819c8 (fctx 0x8783848): created
Jul 05 17:33:07.812 client @0x8781558: udprecv
Jul 05 17:33:09.416 client 127.0.0.1#32795: timeout
Jul 05 17:33:12.815 client 127.0.0.1#32795: UDP request
Jul 05 17:33:12.815 client 127.0.0.1#32795: using view '_default'
Jul 05 17:33:12.815 client 127.0.0.1#32795: request is not signed
Jul 05 17:33:12.815 client 127.0.0.1#32795: recursion available: approved
Jul 05 17:33:12.815 client 127.0.0.1#32795: query
Jul 05 17:33:12.815 client 127.0.0.1#32795: query (cache) approved
Jul 05 17:33:12.815 client 127.0.0.1#32795: replace
Jul 05 17:33:12.815 clientmgr @0x8738840: createclients
Jul 05 17:33:12.816 clientmgr @0x8738840: create new
Jul 05 17:33:12.816 client @0x878aaf8: create
Jul 05 17:33:12.816 createfetch: edojin.info A
Jul 05 17:33:12.816 fctx 0x8783848: join
Jul 05 17:33:12.816 fetch 0x873e528 (fctx 0x8783848): created
Jul 05 17:33:12.816 client @0x878aaf8: udprecv
Jul 05 17:33:14.425 client 127.0.0.1#32795: timeout
For slashdot.org (worked)
Code:
Jul 05 17:38:29.944 client 127.0.0.1#32795: UDP request
Jul 05 17:38:29.944 client 127.0.0.1#32795: using view '_default'
Jul 05 17:38:29.944 client 127.0.0.1#32795: request is not signed
Jul 05 17:38:29.944 client 127.0.0.1#32795: recursion available: approved
Jul 05 17:38:29.944 client 127.0.0.1#32795: query
Jul 05 17:38:29.944 client 127.0.0.1#32795: query (cache) approved
Jul 05 17:38:29.944 client 127.0.0.1#32795: replace
Jul 05 17:38:29.944 clientmgr @0x8738840: createclients
Jul 05 17:38:29.944 clientmgr @0x8738840: recycle
Jul 05 17:38:29.944 createfetch: slashdot.org A
Jul 05 17:38:29.944 fctx 0x8766bd0: create
Jul 05 17:38:29.944 fctx 0x8766bd0: join
Jul 05 17:38:29.944 fetch 0x8784838 (fctx 0x8766bd0): created
Jul 05 17:38:29.944 client @0x8753a50: udprecv
Jul 05 17:38:29.944 fctx 0x8766bd0: start
Jul 05 17:38:29.944 fctx 0x8766bd0: try
Jul 05 17:38:29.944 fctx 0x8766bd0: cancelqueries
Jul 05 17:38:29.944 fctx 0x8766bd0: getaddresses
Jul 05 17:38:29.944 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.944 res 0x8767368: priming
Jul 05 17:38:29.944 createfetch: . NS
Jul 05 17:38:29.944 fctx 0x8789ec8: create
Jul 05 17:38:29.945 fctx 0x8789ec8: join
Jul 05 17:38:29.945 fetch 0x876bbb8 (fctx 0x8789ec8): created
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x8782390 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x8782da0 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x878be58 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x8782448 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x8782670 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x87825b8 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x878bda0 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x8782500 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x8782950 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x8782898 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x8782ce8 in db
Jul 05 17:38:29.945 res 0x8767368: dns_resolver_prime
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x8782c30 in db
Jul 05 17:38:29.945 dns_adb_createfind: found A for name 0x87822d8 in db
Jul 05 17:38:29.945 fctx 0x8766bd0: query
Jul 05 17:38:29.945 resquery 0x8790d28 (fctx 0x8766bd0): send
Jul 05 17:38:29.945 resquery 0x8790d28 (fctx 0x8766bd0): sent
Jul 05 17:38:29.945 resquery 0x8790d28 (fctx 0x8766bd0): senddone
Jul 05 17:38:29.945 fctx 0x8789ec8: start
Jul 05 17:38:29.945 fctx 0x8789ec8: try
Jul 05 17:38:29.945 fctx 0x8789ec8: cancelqueries
Jul 05 17:38:29.945 fctx 0x8789ec8: getaddresses
Jul 05 17:38:29.945 fctx 0x8789ec8: query
Jul 05 17:38:29.945 resquery 0x8790fa0 (fctx 0x8789ec8): send
Jul 05 17:38:29.945 resquery 0x8790fa0 (fctx 0x8789ec8): sent
Jul 05 17:38:29.945 resquery 0x8790fa0 (fctx 0x8789ec8): senddone
Jul 05 17:38:30.771 client 202.12.27.33#53: UDP request
Jul 05 17:38:30.771 client 202.12.27.33#53: next
Jul 05 17:38:30.771 client 202.12.27.33#53: endrequest
Jul 05 17:38:30.771 client @0x8757818: udprecv
Jul 05 17:38:30.771 resquery 0x8790fa0 (fctx 0x8789ec8): response
Jul 05 17:38:30.771 fctx 0x8789ec8: answer_response
Jul 05 17:38:30.771 fctx 0x8789ec8: cache_message
Jul 05 17:38:30.771 fctx 0x8789ec8: cancelquery
Jul 05 17:38:30.771 fctx 0x8789ec8: done
Jul 05 17:38:30.771 fctx 0x8789ec8: stopeverything
Jul 05 17:38:30.771 fctx 0x8789ec8: cancelqueries
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8785ff8
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8785ed8
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8781dc8
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x87861a8
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8781af8
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8785e48
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8785db8
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8781ca8
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8781f78
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8781a68
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x87862c8
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8782098
Jul 05 17:38:30.771 dns_adb_destroyfind on find 0x8786118
Jul 05 17:38:30.771 fctx 0x8789ec8: sendevents
Jul 05 17:38:30.771 fetch 0x876bbb8 (fctx 0x8789ec8): destroyfetch
Jul 05 17:38:30.771 fctx 0x8789ec8: shutdown
Jul 05 17:38:30.771 fctx 0x8789ec8: doshutdown
Jul 05 17:38:30.771 fctx 0x8789ec8: stopeverything
Jul 05 17:38:30.771 fctx 0x8789ec8: cancelqueries
Jul 05 17:38:30.771 fctx 0x8789ec8: destroy
Jul 05 17:38:30.773 client 202.12.27.33#53: UDP request
Jul 05 17:38:30.773 client 202.12.27.33#53: next
Jul 05 17:38:30.773 client 202.12.27.33#53: endrequest
Jul 05 17:38:30.773 client @0x8757818: udprecv
Jul 05 17:38:30.773 resquery 0x8790d28 (fctx 0x8766bd0): response
Jul 05 17:38:30.773 fctx 0x8766bd0: answer_response
Jul 05 17:38:30.773 fctx 0x8766bd0: cache_message
Jul 05 17:38:30.773 fctx 0x8766bd0: cancelquery
Jul 05 17:38:30.773 fctx 0x8766bd0: done
Jul 05 17:38:30.773 fctx 0x8766bd0: stopeverything
Jul 05 17:38:30.773 fctx 0x8766bd0: cancelqueries
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8781ee8
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8781e58
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8781d38
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x87821b8
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8786088
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8782128
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8781b88
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8785c08
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8785c98
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8782248
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x87819d8
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8781c18
Jul 05 17:38:30.773 dns_adb_destroyfind on find 0x8782008
Jul 05 17:38:30.773 fctx 0x8766bd0: sendevents
Jul 05 17:38:30.773 fetch 0x8784838 (fctx 0x8766bd0): destroyfetch
Jul 05 17:38:30.773 fctx 0x8766bd0: shutdown
Jul 05 17:38:30.773 client 127.0.0.1#32795: send
Jul 05 17:38:30.773 client 127.0.0.1#32795: sendto
Jul 05 17:38:30.774 client 127.0.0.1#32795: senddone
Jul 05 17:38:30.774 client 127.0.0.1#32795: next
Jul 05 17:38:30.774 client 127.0.0.1#32795: endrequest
Jul 05 17:38:30.774 fctx 0x8766bd0: doshutdown
Jul 05 17:38:30.774 fctx 0x8766bd0: stopeverything
Jul 05 17:38:30.774 fctx 0x8766bd0: cancelqueries
Jul 05 17:38:30.774 fctx 0x8766bd0: destroy
I must say... I'm clueless right now. :-|
 
Old 07-05-2004, 07:09 PM   #4
chort
Senior Member
 
Registered: Jul 2003
Location: Silicon Valley, USA
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660

Rep: Reputation: 69
It doesn't look like there's a huge difference, beside the fact that your original query timed-out and the second one did not. I'm not sure why a time-out would cause the resolver to completely stop working, that's quite odd.

Generally speaking, you shouldn't invent second-level domains off a gTLD/ccTLD/etc, because they might already be in use somewhere; however, if you're not answering requests from the Internet and you're not advertising zone changes, it should be safe. Of course you'll want to make sure to pick a domain that doesn't actually exist (just to be sure). The reason why a TLD might be a problem is because recent versions of BIND have incorporated weird hacks to work around foul-play like VeriSlimes "SiteFinder". Thus TLDs have slightly different treatment than lower level domains.

Another choice might be example.edu. Although it's registered, it's held by IANA and it only has SOA and NS records, nothing else. It's the domain generally used in RFC examples.
 
Old 07-06-2004, 07:25 AM   #5
remi
LQ Newbie
 
Registered: May 2003
Distribution: Red Hat Linux 9.0
Posts: 16

Original Poster
Rep: Reputation: 0
Yeah, the VeriSlimes marketing scam was very stupid. I hated that SiteFinder thing.

Anyways, now I've changed kawamura. to kawamura.eremi.net., though it's only used internally on my LAN, not for people from the Internet.

Though, I've spent all night trying to figure out what it was and why it's timing out after a few domains. No luck. I can only make my own domain work.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
amavisd-new blacklisting TLDs packetz Linux - Software 0 04-11-2005 01:07 PM
BIND 9: Slow response from root servers. Local is ok. Apollo77 Linux - Networking 3 01-14-2005 10:22 AM
cant get bind/named to work! please help! gsgleason Slackware 2 10-23-2004 01:56 PM
bind & resolve local hosts jingo_man Linux - Networking 7 07-08-2004 02:56 PM
bind named and samba to local interfaces kif Linux - Networking 4 02-07-2003 06:34 AM


All times are GMT -5. The time now is 06:35 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration