Re: bind9 issue?
notify-source :) I must have been blind. Sorry, Chris. - Original Message - From: Chris Knipe [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 30, 2005 12:09 PM Subject: bind9 issue? Hi, I'm not on the bind9 mailing lists, hopefully someone can help me out here, or as I suspect, perhaps just fill in a bug report My server has a primary IP, with various aliases: x.x.x.136 (Primary) x.x.x.131 (Alias) named.conf: options { listen-on port 53 { x.x.x.131; }; query-source address x.x.x.131 port 53; transfer-source x.x.x.131; }; Yes, notifies at my slave, comes from x.x.x.136 The slave thus, complains notify from non master (because 136 is not a name server), and as such, no updates happens on my slaves. How can I force bind9 to send notifies from the query-source address? IMHO, if bind uses the query-source address do to lookups, it *should* also use this address to send notifies - hence, my initial claim above re bug... Can anyone perhaps confirm this?? Alternatively, give some pointers to a working way for the above scenario? Thanks, Chris. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED] ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
bind9 issue?
Hi, I'm not on the bind9 mailing lists, hopefully someone can help me out here, or as I suspect, perhaps just fill in a bug report My server has a primary IP, with various aliases: x.x.x.136 (Primary) x.x.x.131 (Alias) named.conf: options { listen-on port 53 { x.x.x.131; }; query-source address x.x.x.131 port 53; transfer-source x.x.x.131; }; Yes, notifies at my slave, comes from x.x.x.136 The slave thus, complains notify from non master (because 136 is not a name server), and as such, no updates happens on my slaves. How can I force bind9 to send notifies from the query-source address? IMHO, if bind uses the query-source address do to lookups, it *should* also use this address to send notifies - hence, my initial claim above re bug... Can anyone perhaps confirm this?? Alternatively, give some pointers to a working way for the above scenario? Thanks, Chris. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Bind9 Issue
I bought a domain for my gaming clan and installed bind9 specifically for the views feature. The DNS machine is my home router and our gaming machine is on another network and physically 60 miles away and is nat'ed on a lan. The lan the game server is on has it's own DNS machine, but is located behind the same public ip. I have DNS setup up so that any requests for www.gameserver.org (name different to protect the ignorant) that come from that lan get the ip 192.168.1.20, the machines internal ip. When logged into the game server, I can do a dig www.gameserver.org my DNS ip and the correct ip comes back. The problem is that When I dig www.gameserver.org @the lan's DNS machine, it responds with the public ip, not the internal and therefore won't work for the lan. Talking with workers at that site, their DNS forwards to just the root servers, not their local ISP DNS. Any ideas on how I can track this down and get the internal ip listed for just the users of the lan? -Derrick ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bind9 Issue
On Thu, Jul 24, 2003 at 03:02:15PM -0700, Derrick Ryalls wrote: I bought a domain for my gaming clan and installed bind9 specifically for the views feature. The DNS machine is my home router and our gaming machine is on another network and physically 60 miles away and is nat'ed on a lan. The lan the game server is on has it's own DNS machine, but is located behind the same public ip. I have DNS setup up so that any requests for www.gameserver.org (name different to protect the ignorant) that come from that lan get the ip 192.168.1.20, the machines internal ip. When logged into the game server, I can do a dig www.gameserver.org my DNS ip and the correct ip comes back. The problem is that When I dig www.gameserver.org @the lan's DNS machine, it responds with the public ip, not the internal and therefore won't work for the lan. You're going to have to show us the named.conf, before anyone will answer. -- Jonathan Chen [EMAIL PROTECTED] -- Beer. Now there's a temporary solution. - Homer Simpson ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Bind9 Issue
On Thu, Jul 24, 2003 at 03:02:15PM -0700, Derrick Ryalls wrote: I bought a domain for my gaming clan and installed bind9 specifically for the views feature. The DNS machine is my home router and our gaming machine is on another network and physically 60 miles away and is nat'ed on a lan. The lan the game server is on has it's own DNS machine, but is located behind the same public ip. I have DNS setup up so that any requests for www.gameserver.org (name different to protect the ignorant) that come from that lan get the ip 192.168.1.20, the machines internal ip. When logged into the game server, I can do a dig www.gameserver.org my DNS ip and the correct ip comes back. The problem is that When I dig www.gameserver.org @the lan's DNS machine, it responds with the public ip, not the internal and therefore won't work for the lan. You're going to have to show us the named.conf, before anyone will answer. -- Jonathan Chen [EMAIL PROTECTED] -- Beer. Now there's a temporary solution. - Homer Simpson named.conf // $FreeBSD: src/etc/namedb/named.conf,v 1.6.2.5 2002/02/04 18:24:21 ume Exp $ // // Refer to the named.conf(5) and named(8) man pages for details. If // you are ever going to setup a primary server, make sure you've // understood the hairy details of how DNS is working. Even with // simple mistakes, you can break connectivity for affected parties, // or cause huge amount of useless Internet traffic. acl internals { 192.168.0.0/24; 127.0.0.1; }; acl mis { 216.57.216.55; }; acl dhcp-server { 127.0.0.1; 192.168.0.1; }; options { directory /etc/namedb; forwarders { 4.2.2.4; 4.2.2.5; 4.2.2.6; }; }; view internal { match-clients { internals; }; recursion yes; zone javaweenie.org { type master; file db.javaweenie.org.internal; allow-transfer { none; }; allow-update { dhcp-server; }; }; zone clanbuckbuck.org { type master; file db.clanbuckbuck.org.external; allow-transfer { 12.224.183.109; }; }; }; view mis { match-clients { mis; }; recursion no; zone clanbuckbuck.org { type master; file db.clanbuckbuck.org.mis; allow-transfer { 12.224.183.109; }; }; }; view external { match-clients { any; }; recursion no; zone clanbuckbuck.org { type master; file db.clanbuckbuck.org.external; allow-transfer { 12.224.183.109; }; }; }; db.clanbuckbuck.org.mis ** $TTL 86400 @ IN SOA clanbuckbuck.org. root.clanbuckbuck.org. ( 961230 ; Serial 3600; Refresh 300 ; Retry 360 ; Expire 3600 ) ; Minimum IN NS ns.clanbuckbuck.org. IN MX 10 clanbuckbuck.org. IN A 4.47.114.1 ns IN A 4.47.114.1 www IN A 192.168.1.20 db.clanbuckbuck.org.external *** $TTL 86400 @ IN SOA clanbuckbuck.org. root.clanbuckbuck.org. ( 961230 ; Serial 3600; Refresh 300 ; Retry 360 ; Expire 3600 ) ; Minimum IN NS ns.clanbuckbuck.org. IN NS2 ns2.clanbuckbuck.org. IN MX 10 clanbuckbuck.org. IN A 4.47.114.1 ns IN A 4.47.114.1 ns2 IN A 12.224.183.109 www IN A 216.57.216.55 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]