since the BugZilla seems to be down currently (I get a "DBD::mysql::db
selectrow_array failed: called with 4 bind variables when 3 are needed"
when adding a new bug or searching for one while being logged in,
forwarded to webmaster@) I'll post it to the ML and open discussion
Almost the last feature I would need to replace some more of my BINDs
with NSD is the support of BINDs $GENERATE statement. IMHO it should be
pretty straight forward to implement something like that, since the
syntax is pretty easy (but I'm no programmer, so don't count on me).
It is described on page 97 of the (today) current BIND9 ARM at
Almost the last feature I would need to replace some more of my BINDs
with NSD is the support of BINDs $GENERATE statement. IMHO it should be
pretty straight forward to implement something like that, since the
syntax is pretty easy (but I'm no programmer, so don't count on me).
I also wish NSD to have $GENERATE feature and guess zonec
must be the right position to implement.
Because it helps
- ISPs supporting RFC 2317 style inverse query setup.
- ISPs, Companies, Campus who have pool address blocks for
IPCP, DHCP, etc.
[On 09 Apr, @ 01:41, Bernhard wrote in "Feature Request: $GENERATE sta ..."]
Hi,
since the BugZilla seems to be down currently (I get a "DBD::mysql::db
selectrow_array failed: called with 4 bind variables when 3 are needed"
when adding a new bug or searching for one while being logged in,
to put this in the archives.
Try flushing your cookies in your browser, there seems to be a problem
with older cookies and our newer bugzilla,
[On 09 Apr, @ 01:41, Bernhard wrote in "Feature Request: $GENERATE sta ..."]
Almost the last feature I would need to replace some more of my BINDs
with NSD is the support of BINDs $GENERATE statement. IMHO it should be
pretty straight forward to implement something like that, since the
syntax is pretty easy (but I'm no programmer, so don't count on me).
what's wrong with a little perl magic _before_ you compile the zone?
I wonder if what Bernhard made is a complain or suggestion,
applying perl magic sounds good, and the script should go
under contrib directory not reside on somebody's home
directory.
Making nsdc to hook the script is more efficient. Not
require special operation for it is desired.
[On 11 Apr, @ 11:35, Koh-ichi wrote in "Re: Feature Request: $GENERATE ..."]
>
> what's wrong with a little perl magic _before_ you compile the zone?
I wonder if what Bernhard made is a complain or suggestion,
applying perl magic sounds good, and the script should go
under contrib directory not reside on somebody's home
directory.
I don't think we have a problem with adding a script that
does this to contrib/
Making nsdc to hook the script is more efficient. Not
require special operation for it is desired.
that, or make a Makefile that can handle other preprocessing
tasks as well (dnssec zone signing comes to mind).
I've been using NSD for 2 years now, since 1.2. I've recently set-up a new name server using the latest NSD. I couldn't find any documentation or message in the mailing list archive regarding multi-homing system.
Basicly, I have a system which is use as a router and a name server. One is the IP address of the box as a gateway, the other will be use as the IP address of the name server. The reason I'm not using the same IP for both is that when I move the name server function to a different box, I can simply move the IP to a different box and I won't have to do any modification in my zone.
With that said, is there a way to tell NSD to listen and reply on one interface and not the other? Currently, if I dig @server mydomain.com, the reply comes back through the first ip address, and not the secondary.
man nsd
....
-a ip-address
Listen to the specified ip-address. The ip-address must be
specified in numeric format (using the standard IPv4 or IPv6 notation).
This flag can be specified multiple times to listen to multiple IP
addresses. If this flag is not specified NSD listens to all IP addresses.
......
This is how I achieve exactly what you're talking about.
Add it to flags in nsdc.conf as a permanent change.
I had the same problem before. If you want that your server answer the question using the same interface that came from, you should specify the flag "-a"
:With that said, is there a way to tell NSD to listen and reply on one
:interface and not the other? Currently, if I dig @server mydomain.com,
:the reply comes back through the first ip address, and not the
:secondary.
That seems like a bug to me.
Like others mentioned, you can use -a to listen on specific addresses.
:With that said, is there a way to tell NSD to listen and reply on one
:interface and not the other? Currently, if I dig @server mydomain.com,
:the reply comes back through the first ip address, and not the
:secondary.
That seems like a bug to me.
Someone explained to me that it is the typical behaviour for UDP socket.
They use as the source address the address of the interface used to send the packet (which depends on the route table in the host). The way to overcome that problem is create a socket binded to a specific address.
:On Fri, 15 Apr 2005 14:22:16 -0700, Peter Hessler <phessler@theapt.org>
:wrote:
:
:>On Fri, Apr 15, 2005 at 04:52:02PM -0400, Dany V. wrote:
:>:With that said, is there a way to tell NSD to listen and reply on one
:>:interface and not the other? Currently, if I dig @server mydomain.com,
:>:the reply comes back through the first ip address, and not the
:>:secondary.
:>
:>That seems like a bug to me.
:>
:
:Someone explained to me that it is the typical behaviour for UDP socket.
:They use as the source address the address of the interface used to send
:the packet (which depends on the route table in the host). The way to
:overcome that problem is create a socket binded to a specific address.
:
:If I'm wrong, let me know please.
:
It may be the default behaivour, but its certainly possible to fix. If
a patch doesn't show up in a a few days, I'll see if I can write
something decent.
