DaemonForums  

Go Back   DaemonForums > Miscellaneous > General software and network

General software and network General OS-independent software and network questions, X11, MTA, routing, etc.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 8th June 2008
tanked tanked is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 56
Default DNS problem- name server record

System: FreeBSD 7.0-RELEASE

I'm using BIND from the base system and I'm having a problem, first here is the relevant entry from named.conf:

Code:
zone "wes.internal" {
     type master;
     file "master/wes.internal";
};

zone "1.168.192.in-addr.arpa" {
     type master;
     file "master/1.168.192.in-addr.arpa";
Here is the contents of my forward zone:

Code:
$TTL 1h
@ IN SOA starburst.wes.internal. hostmaster.wes.internal. (
                       20080707 ; Serial
                       1d       ; Refresh
                       2h       ; Retry
                       1000h    ; Expire
                       2d       ; Minimum
                     )

IN  NS  starburst.wes.internal.

localhost IN   A   127.0.0.1
starburst IN   A   192.168.1.1
Here are the contents of my reverse zone:

Code:
$TTL 1h
@ IN SOA starburst.wes.internal. hostmaster.wes.internal. (
                       20080707 ; Serial
                       1d       ; Refresh
                       2h       ; Retry
                       1000h    ; Expire
                       2d       ; Minimum
                     )

IN   NS  starburst.wes.internal.

1    IN   PTR   starburst.wes.internal.
The problem I have is that when named starts it prints the following error message to the console:

Code:
starburst named[752]: zone 1.168.192.in-addr.arpa/IN: has no NS records
starburst named[752]: zone wes.internal/IN: has no NS records
I don't understand why this is as I've defined the NS records in the zone files, can anyone help?
Reply With Quote
  #2   (View Single Post)  
Old 8th June 2008
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

You haven't defined the A record for the nameserver
Code:
IN   NS  starburst.wes.internal.
Or in other words, you forgot to provide the glue record

EDIT: See http://daemonforums.org/showpost.php?p=3927&postcount=9 for an example.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #3   (View Single Post)  
Old 9th June 2008
tanked tanked is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 56
Default

I thought I defined the A record with the following:

Code:
starburst IN   A   192.168.1.1
Reply With Quote
  #4   (View Single Post)  
Old 9th June 2008
tanked tanked is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 56
Default

Anyone?

I've looked at the handbook and the DNS chapter in 'Absolute FreeBSD' 2nd Ed. and I can't see what I've done wrong.
Reply With Quote
  #5   (View Single Post)  
Old 9th June 2008
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

You defined an A record for the wes.internal zone, but you haven't defined the A record for your reverse zone.
That is what named is complaining about
Code:
tarburst named[752]: zone 1.168.192.in-addr.arpa/IN: has no NS records
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #6   (View Single Post)  
Old 9th June 2008
tanked tanked is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 56
Default

Thanks for getting back to me, I still don't quite understand though; I thought A records were for forward zones only and the equivalent PTR records for reverse zones. Also, if you look at the named error message it isn't just complaining about the reverse zone, it does about the forward one too.

However, I seem to have fixed the problem by adding the zone name to the NS entries in both my forward and reverse zone files:

Forward zone file

Code:
wes.internal. IN  NS  starburst.wes.internal.
Reverse zone file:

Code:
1.168.192.in-addr.arpa. IN   NS  starburst.wes.internal.
My name server now replies to forward and reverse lookup queries but if this is incorrect can you tell me what I should add to my zone files?
Reply With Quote
  #7   (View Single Post)  
Old 10th June 2008
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

Yes, you are right. There shouldn't be A records in the reverse zone. I have been using tinydns from Daniel Bernstein for years and there you only have a singe file for all zones. I probably should stop answering BIND questions

On OpenBSD with BIND 9.3.4 the following named.conf works
Code:
zone    "wes.internal" {
        type master;
        file "master/wes.internal" ;
};

zone "1.168.192.in-addr.arpa" {
     type master;
     file "master/1.168.192.in-addr.arpa";
};
The file "master/wes.internal":
Code:
$TTL 1h
@       IN SOA ns.starburst.wes.internal. hostmaster.wes.internal. (
                       20080707 ; Serial
                       1d       ; Refresh
                       2h       ; Retry
                       1000h    ; Expire
                       2d       ; Minimum
                     )

                IN  NS  ns.wes.internal.

ns              IN  A   192.168.1.1
starburst       IN  A   192.168.1.1
supernova       IN  A   192.168.1.2
Notice that I use "1.168.192" instead of "1.1.168.192." for the "in-addr.arpa" zone. I wonder if that is the cause of your problems

The file "master/1.168.192.in-addr.arpa":
Code:
$TTL 1h
@ IN SOA  ns.wes.internal. shostmaster.wes.internal. (
                       20080707 ; Serial
                       1d       ; Refresh
                       2h       ; Retry
                       1000h    ; Expire
                       2d       ; Minimum
                     )

                        IN   NS  ns.wes.internal.

1    IN   PTR   starburst.wes.internal.
2    IN   PTR   supernova.wes.internal.
A query for the nameserver of the "wes.internal" domain:
Code:
$ dig +norecurse -t ns wes.internal @127.0.0.1

; <<>> DiG 9.3.4 <<>> +norecurse -t ns wes.internal @127.0.0.1
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47311
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;wes.internal.                  IN      NS

;; ANSWER SECTION:
wes.internal.           3600    IN      NS      ns.wes.internal.

;; ADDITIONAL SECTION:
ns.wes.internal.        3600    IN      A       192.168.1.1

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 10 02:48:54 2008
;; MSG SIZE  rcvd: 63
Same but now for "1.168.192.in-addr.arpa" domain
Code:
dig -t ns 1.168.192.in-addr.arpa @127.0.0.1

; <<>> DiG 9.3.4 <<>> -t ns 1.168.192.in-addr.arpa @127.0.0.1
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41557
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; QUESTION SECTION:
;1.168.192.in-addr.arpa.                IN      NS

;; ANSWER SECTION:
1.168.192.in-addr.arpa. 3600    IN      NS      ns.wes.internal.

;; ADDITIONAL SECTION:
ns.wes.internal.        3600    IN      A       192.168.1.1

;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 10 02:55:42 2008
;; MSG SIZE  rcvd: 85
The complete zone
Code:
$ dig -t axfr wes.internal @127.0.0.1 

; <<>> DiG 9.3.4 <<>> -t axfr wes.internal @127.0.0.1
; (1 server found)
;; global options:  printcmd
wes.internal.           3600    IN      SOA     ns.starburst.wes.internal. hostmaster.wes.internal. 20080707 86400 7200 3600000 172800
wes.internal.           3600    IN      NS      ns.wes.internal.
ns.wes.internal.        3600    IN      A       192.168.1.1
starburst.wes.internal. 3600    IN      A       192.168.1.1
supernova.wes.internal. 3600    IN      A       192.168.1.2
wes.internal.           3600    IN      SOA     ns.starburst.wes.internal. hostmaster.wes.internal. 20080707 86400 7200 3600000 172800
;; Query time: 1 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jun 10 03:02:06 2008
;; XFR size: 6 records (messages 1)
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
  #8   (View Single Post)  
Old 10th June 2008
tanked tanked is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 56
Default

Hello again, this is very odd...

I copied your zone file examples into mine and they worked fine. I then edited my zone files back to how they were when I was having the problem- and it now works!!

Here are the current contents of my zone files:

Forward zone:

Code:
$TTL 1h
@       IN SOA starburst.wes.internal. hostmaster.wes.internal. (
                       20080707 ; Serial
                       1d       ; Refresh
                       2h       ; Retry
                       1000h    ; Expire
                       2d       ; Minimum
                     )

                IN  NS  starburst.wes.internal.

starburst       IN  A   192.168.1.1
Reverse zone:

Code:
$TTL 1h
@ IN SOA  starburst.wes.internal. shostmaster.wes.internal. (
                       20080707 ; Serial
                       1d       ; Refresh
                       2h       ; Retry
                       1000h    ; Expire
                       2d       ; Minimum
                     )

                        IN   NS  starburst.wes.internal.

1    IN   PTR   starburst.wes.internal.
Take a look at them and compare them to the zone files I posted in my first post- I don't see a difference, do you? The only thing I can think of is that it is a spacing issue (I had spaces where I should -or shouldn't have). Either that or there was something named did not like about my original zone files themselves, as I created new zone files when I pasted your examples.
Reply With Quote
  #9   (View Single Post)  
Old 13th June 2008
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

Quote:
Originally Posted by tanked View Post
....... there was something named did not like about my original zone files themselves, as I created new zone files when I pasted your examples.
Many programs use a lexical analyzer to parse a comifiguration file. In those cases spaces or blanks are usually not a problem, because these are not part of the syntax.

You could have entered some control character by accident. Next time you have a similar issue you can use cat -e to check for for the human eye invisible weird characters.
__________________
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump
Reply With Quote
Old 16th June 2008
tanked tanked is offline
Fdisk Soldier
 
Join Date: May 2008
Posts: 56
Default

Thanks, thats useful to know, in fact I still have the old problem zone files so I'll run that command on them to see if it comes up with anything.
Reply With Quote
Reply

Thread Tools
Display Modes

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 On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Boot problem. Geometry problem? gulanito FreeBSD Installation and Upgrading 0 3rd July 2009 03:03 AM
Lost FreeBSD boot record (when installing Ubuntu) TomAmundsen FreeBSD General 6 19th January 2009 09:41 PM
Sun Java System Web Server - Active Server Pages (yes ASP) hopla FreeBSD General 0 26th September 2008 08:22 AM


All times are GMT. The time now is 05:33 AM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick