DaemonForums  

Go Back   DaemonForums > FreeBSD > FreeBSD General

FreeBSD General Other questions regarding FreeBSD which do not fit in any of the categories below.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 21st February 2010
riotnrrd's Avatar
riotnrrd riotnrrd is offline
New User
 
Join Date: Feb 2010
Posts: 8
Default DDNS problem (unable to add forward / reverse map)

Hi all,

I got tired of updating hosts files and decided to set up dynamic DNS for hosts on my local LAN. The server is running FreeBSD 8.0-RELEASE-p2. Hosts are Windows and Linux. However things have not gone as smoothly as I hoped.

The messages in the logs look like this:

Code:
Feb 21 18:15:21 moose dhcpd: Unable to add forward map from dashaus-nas.dashaus to 192.168.1.10: timed out
Feb 21 18:18:05 moose dhcpd: unable to add reverse map from 12.1.168.192.in-addr-arpa to beast.dashaus: timed out
Feb 21 18:20:22 moose dhcpd: Unable to add forward map from dashaus-nas.dashaus to 192.168.1.10: timed out
Feb 21 18:23:06 moose dhcpd: unable to add reverse map from 12.1.168.192.in-addr-arpa to beast.dashaus: timed out
Feb 21 18:25:23 moose dhcpd: Unable to add forward map from dashaus-nas.dashaus to 192.168.1.10: timed out
named.conf file:

Code:
options {
        // Relative to the chroot directory, if any
        directory       "/etc/namedb";
        pid-file        "/var/run/named/pid";
        dump-file       "/var/dump/named_dump.db";
        statistics-file "/var/stats/named.stats";

// If you've got a DNS server around at your upstream provider, enter
// its IP address here, and enable the line below.  This will make you
// benefit from its cache, thus reduce overall DNS traffic in the Internet.
        forwarders {
                62.101.93.101;
        };
};

acl dashaus{
        192.168.1.0/24;
        127.0.0.1;
};

zone "." {
        type slave;
        file "slave/root.slave";
        masters {
                192.5.5.241;    // F.ROOT-SERVERS.NET.
        };
        notify no;
};
zone "arpa" {
        type slave;
        file "slave/arpa.slave";
        masters {
                192.5.5.241;    // F.ROOT-SERVERS.NET.
        };
        notify no;
};
zone "in-addr.arpa" {
        type slave;
        file "slave/in-addr.arpa.slave";
        masters {
                192.5.5.241;    // F.ROOT-SERVERS.NET.
        };
        notify no;
};

// RFC 1912
zone "localhost"        { type master; file "master/localhost-forward.db"; };
zone "127.in-addr.arpa" { type master; file "master/localhost-reverse.db"; };
zone "255.in-addr.arpa" { type master; file "master/empty.db"; };

zone "dashaus" {
    type master;
    file "dashaus";
    allow-update {
        dashaus;
    };
};

zone "1.168.192.in-addr.arpa" {
    type master;
    file "dashaus.rev";
    allow-update {
        dashaus;
    };
};
dhcpd.conf:

Code:
option domain-name "dashaus";
option domain-name-servers 192.169.1.1, 208.67.222.222, 208.67.220.220;
option subnet-mask 255.255.255.0;

default-lease-time 600;
max-lease-time 7200;

#authoritative;
ddns-update-style interim;
ddns-domainname "dashaus";
ddns-rev-domainname "in-addr-arpa";
log-facility local7;
update-static-leases on;
do-forward-updates true;

subnet 192.168.1.0 netmask 255.255.255.0 {
  range 192.168.1.10 192.168.1.30;
  option routers 192.168.1.1;
  option domain-name-servers 192.168.1.1;
}

subnet 192.168.3.0 netmask 255.255.255.0 {
  range 192.168.3.10 192.168.3.20;
  option routers 192.168.1.1;
  option domain-name-servers 192.168.1.1;
}
And finally the zone files. Forward:

Code:
;BIND DUMP V8
$ORIGIN .
dashaus.        3600    IN      NS      moose.dashaus.
                3600    IN      SOA     moose.dashaus. root.moose.dashaus. (
                                        20011195        ; serial number
                                        3600            ; refresh
                                        900             ; retry
                                        3600000         ; expiry
                                        3600            ; minimum
                                        )
$ORIGIN dashaus.
moose   3600            A       192.168.1.1
And reverse:

Code:
;BIND DUMP V8
$ORIGIN 1.168.192.in-addr.arpa.
@       3600    IN      NS      moose.dashaus.
@       3600    IN      SOA     moose.dashaus. root.moose.dashaus. (
                                20011195        ; serial number
                                3600            ; refresh
                                900             ; retry
                                3600000         ; expiry
                                3600            ; minimum
                                )
I have been reading manuals, cook-books and forum posts all over the place, and the one thing I can think of that could be significant is that the FreeBSD box is itself a DHCP client. It acts as the firewall and gateway, so it has one NIC which acts as a DHCP client to my ISP, and another NIC which is where the DHCP server runs.

The reason I wonder whether this might be significant is that the FreeBSD box itself reports itself as being in the ISP's domain. The resolv.conf file also gets rewritted by dhclient, so "nslookup <servername>" fails, though "nslookup <servername> <servername>" works.

Can anybody tell me what (obvious, foolish) mistake I have made above?
Reply With Quote
  #2   (View Single Post)  
Old 21st February 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

How about following the Domain name conventions and use a Top Level Domain name like everybody else. For example "rrd" the last three characters from your UserId here

That would give you dashaus.rrd as domain name and nas.dashaus.rrd and beastie.dashaus.rrd as host names.

The situation now is that "dashaus" is interpreted like a TLD like "com" or "org", so "beastie.dashaus" and "dashaus-nas.dashaus" are different domains just like "beastie.com" and "dashaus-nas.com" would be totally different domains. Do you see the problem with this setup?
__________________
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 21st February 2010
riotnrrd's Avatar
riotnrrd riotnrrd is offline
New User
 
Join Date: Feb 2010
Posts: 8
Default Clarification

Sorry, the above may be misleading due to overloading. dashaus-nas is the name of a Linux box on the net (surprisingly, it's the NAS). I expect it to end up as dashaus-nas.dashaus. There are other hosts with the same naming convention, e.g. dashaus-ap; I may go around changing them once I have the DNS workign properly.

In any case, dashaus-nas.dashaus to 192.168.1.10 is exactly the forward map I was expecting.

I am slightly confused as to why beast, my Windows workstation, gets an error for a reverse map, while dashaus-nas has the error for a forward map. Is this significant, or is it just due to differences in DHCP client configs on the two machines / OS?
Reply With Quote
  #4   (View Single Post)  
Old 21st February 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

What do you mean with overloading?

The point I tried to make is that a proper hostname consists of at least three parts. separated with dots. Yours only have two parts. and are interpreted like different domain names. It is just like you are trying to get google.com register itself as DDDNS client at yahoo.com. That is the problem

For a example zone file for a local domain see
http://www.daemonforums.org/showthread.php?t=4073. There I use a local domain called "de.filo" and the hosts have names like kant.de.filo and hegel.de.filo
__________________
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
  #5   (View Single Post)  
Old 21st February 2010
riotnrrd's Avatar
riotnrrd riotnrrd is offline
New User
 
Join Date: Feb 2010
Posts: 8
Default TLDs

Ah, OK, I did not realize that was significant. I will go and brainstorm how to name things, because I like .haus as the TLD and want something nice for the next level down. Maybe brick.haus, for the obvious joke.
Reply With Quote
  #6   (View Single Post)  
Old 21st February 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

After you have found names, please add NS records to your zone file. that will help too

And if your hosts don't change, you might as well give them static IPs and hostnames. Then you don't have to mess with DDNS at all.
__________________
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
  #7   (View Single Post)  
Old 22nd February 2010
riotnrrd's Avatar
riotnrrd riotnrrd is offline
New User
 
Join Date: Feb 2010
Posts: 8
Default

I moved everything to dashaus.lan, with the only result that now the errors are of the form "Unable to add forward map from <hostname>.dashaus.lan to <IP address>: timed out".

What do you mean by adding NS records? I thought this line did that:

Code:
dashaus.lan.    3600    IN      NS      moose.dashaus.lan.
Reply With Quote
  #8   (View Single Post)  
Old 22nd February 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

I did not notice them, because the SOA (Start of Authority) record is supposed to be the first one.
Never in my life have I seen a zonefile with the NS record first.

Please move the NS record below the SOA record. I gave you a link to an working zone file. How about copying that verbatim, and just adjust the names and IP addresses.
__________________
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
  #9   (View Single Post)  
Old 23rd February 2010
riotnrrd's Avatar
riotnrrd riotnrrd is offline
New User
 
Join Date: Feb 2010
Posts: 8
Default Configs reversed

Sorry, I did not realise that the order of the directives was important here. I copied the structure of your files, as you recommended, right down to your timeout values.

Forward:
Code:
; zone file for dashaus.lan

$TTL 86400
@       IN      SOA     moose.dashaus.lan. root.moose.dashaus.lan. (
                                20011195        ; serial number
                                3600            ; refresh
                                900             ; retry
                                3600000         ; expiry
                                3600            ; minimum
                                )
        IN      NS      moose.dashaus.lan.
moose   IN      A       192.168.1.1
Reverse:
Code:
; zone "1.168.192.in-addr.arpa"
$TTL 86400
@       IN      SOA     moose.dashaus.lan. root.moose.dashaus.lan. (
                        20011195        ; serial number
                        3600            ; refresh
                        900             ; retry
                        3600000         ; expiry
                        3600            ; minimum
                        )
        IN      NS      moose.dashaus.lan.
I also took the time to add a listen-on directive to my named.conf, as I noticed that it was listening on the public NIC as well as on the inside one - not desirable at all.

However I still have exactly the same messages ("Unable to add forward map from hostname.dashaus.lan to 1.2.3.4: timed out"). Any further suggestions?

Oh, and thanks for your help so far!
Reply With Quote
Old 23rd February 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

Are you aware that you need to increase the serial version, when you change something in your zone files? If named is already running, has loaded a zone file, it will only reload the zone file if the serial number has been increased.

Before we go any further. Do basic things work now?

A request for the SOA record
Code:
$ dig +norecurse -t soa dashaus.lan @192.168.1.1
or asking the the nameserver records
Code:
$ dig +norecurse -t ns dashaus.lan @192.168.1.1
or a reverse lookup
Code:
$ dig +norecurse -x 192.168.1.1 @192.168.1.1
or a plain A record question
Code:
$ dig +norecurse -t A moose.dashaus.lan
__________________
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 25th February 2010
riotnrrd's Avatar
riotnrrd riotnrrd is offline
New User
 
Join Date: Feb 2010
Posts: 8
Default

Oops - I was not aware of that. A quick ":r !date \%Y\%m\%d" and that is all better. However it still hasn't fixed the issue.

FYI, while doing these checks I realized that a "pkill -HUP named" does NOT reload the config file - the timestamps weren't changing. I had to kill -15 named and restart it before the output changed.

I had been doing various checks with dig already, based on your other thread. This looks healthy to me:

Code:
moose# dig +norecurse -t soa dashaus.lan @192.168.1.1

; <<>> DiG 9.6.1-P1 <<>> +norecurse -t soa dashaus.lan @192.168.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57097
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; QUESTION SECTION:
;dashaus.lan.                   IN      SOA

;; ANSWER SECTION:
dashaus.lan.            86400   IN      SOA     moose.dashaus.lan. root.moose.dashaus.lan. 20100225 3600 900 3600000 3600

;; AUTHORITY SECTION:
dashaus.lan.            86400   IN      NS      moose.dashaus.lan.

;; ADDITIONAL SECTION:
moose.dashaus.lan.      86400   IN      A       192.168.1.1

;; Query time: 2 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Thu Feb 25 09:30:35 2010
;; MSG SIZE  rcvd: 106
Reply With Quote
Old 25th February 2010
J65nko J65nko is offline
Administrator
 
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 4,125
Default

You can use this named.conf as a template:
Code:
// $OpenBSD: named-dual.conf,v 1.11 2009/11/02 21:12:56 jakob Exp $
//
// Example file for a named configuration with dual views,
// one processing recursive queries only and one processing
// authoritative-only queries.


// Update this list to include only the networks for which you want
// to execute recursive queries. The default setting allows all hosts
// on any IPv4 networks for which the system has an interface, and
// the IPv6 localhost address.
//
acl clients {
        localnets;
        ::1;
};

options {
        version "";     // remove this to allow version queries

        listen-on    { any; };
        listen-on-v6 { any; };

        empty-zones-enable yes;
};

logging {
        category lame-servers { null; };
};

view "recursive" {
        match-clients { clients; };
        match-recursive-only yes;
        allow-recursion { clients; };

        zone "." {
                type hint;
                file "etc/root.hint";
        };

        zone "localhost" {
                type master;
                file "standard/localhost";
                allow-transfer { localhost; };
        };

        zone "127.in-addr.arpa" {
                type master;
                file "standard/loopback";
                allow-transfer { localhost; };
        };

        zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" {
                type master;
                file "standard/loopback6.arpa";
                allow-transfer { localhost; };
        };
};

view "authoritative" {
        recursion no;
                                                                                                             (p2 of 2)
        additional-from-auth no;
        additional-from-cache no;

        // Master zones
        //
        //zone "myzone.net" {
        //      type master;
        //      file "master/myzone.net";
        //};

        // Slave zones
        //
        //zone "otherzone.net" {
        //      type slave;
        //      file "slave/otherzone.net";
        //      masters { 192.168.1.10; [...;] };
        //};
};
__________________
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 28th February 2010
riotnrrd's Avatar
riotnrrd riotnrrd is offline
New User
 
Join Date: Feb 2010
Posts: 8
Default

Thanks for that. The final piece of the puzzle turned out to be in the dhcpd.conf, not the named.conf. Of all the stupid things, I had in-addr-arpa where I meant in-addr.arpa... Everything works beautifully now, and this has been a learning experience for next time. Thanks!

Now to get the BSD box to do wi-fi bridging...
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
Forward SSH from some port to some other machine starbuck Other BSD and UNIX/UNIX-like 10 18th September 2008 04:40 AM
unable to log in delboy FreeBSD Installation and Upgrading 5 31st August 2008 11:39 AM
DDNS Client revzalot OpenBSD Installation and Upgrading 3 12th August 2008 02:21 AM
Linux Machine Can access share on Mac bot the reverse dosen't work. FloridaBSD Other BSD and UNIX/UNIX-like 2 6th August 2008 03:16 AM
Unable to hear any sound ebzzry FreeBSD General 26 29th July 2008 06:39 PM


All times are GMT. The time now is 09:51 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