|
FreeBSD General Other questions regarding FreeBSD which do not fit in any of the categories below. |
|
Thread Tools | Display Modes |
|
|||
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 |
|
||||
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? |
|
|||
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 |
|
|||
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 |
|
||||
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. |
|
|||
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 |
|
||||
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 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. 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! |
|
|||
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 Code:
$ dig +norecurse -t ns dashaus.lan @192.168.1.1 Code:
$ dig +norecurse -x 192.168.1.1 @192.168.1.1 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 |
|
||||
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 |
|
|||
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 |
|
||||
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... |
|
|
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 |