Specifying port in 'forwarders' directive?

Bob Vance bobvance at alumni.caltech.edu
Mon Sep 25 15:49:22 UTC 2000


Thanks, Jim.

>. Forwarding is already ugly enough

Maybe so; but it's very useful.>)

I think that the original question was posed as "for completeness and
full understanding" intentions.  I'm not necessarily advocating that
change, either.

Although, as I think about it, it appears that the listen-on "port"
option is *only* useful only in this test scenario that you proffer.
However, this really wouldn't be a *full* test, not to mention being
inconvenient when trying to test interactions between servers.
If we're really talking test scenarios, then it seems that it might be
nice to have a port option on the "forwarders" to be able to test
server interaction from a second test server.

-------------------------------------------------
Tks        | <mailto:Bob_Vance at sbm.com>
BV         | <mailto:bobvance at alumni.caltech.edu>
Sr. Technical Consultant,  SBM, A Gates/Arrow Co.
Vox 770-623-3430           11455 Lakefield Dr.
Fax 770-623-3429           Duluth, GA 30097-1511
=================================================





-----Original Message-----
From: Jim Reid [mailto:jim at rfc1035.com]
Sent: Monday, September 25, 2000 11:25 AM
To: bobvance at alumni.caltech.edu
Cc: bind-users at isc.org
Subject: Re: Specifying port in 'forwarders' directive?


>>>>> "Bob" == Bob Vance <bobvance at alumni.caltech.edu> writes:

    Bob>    "Why can you specify a "port" on the "listen-on" option?
    Bob> What commands make a server *query* that specific port?  "

ISTR there was a suggestion that the forwarders syntax could be
extended to make the name servers send queries to a non-standard port
number. Hopefully this will remain unimplemented forever. Forwarding
is already ugly enough IMHO without making it worse. BTW the -p option
to dig(1) allows queries to be sent to a non-standard port
number. This can be useful when testing new name server configurations
without disrupting the currently running server.




More information about the bind-users mailing list