On 11/6/22 6:39 AM, Matus UHLAR - fantomas wrote:
3. allow your servers to to fetch 66.136.193.in-addr.arpa.
Is this 3rd step documented somewhere?
I searched for it in RFC 2317 but didn't find it. Maybe I over looked it.
alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or
0-1
On 11/6/22 11:12 AM, Carl Byington via bind-users wrote:
or use $clientname.66.136.193.in-addr.arpa. as the intermediate zone
which has a slight advantage when the same client has multiple disjoint
parts of the same /24.
I find that $CLIENTNAME or some other stand in for the client is a
poten
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Sun, 2022-11-06 at 14:39 +0100, Matus UHLAR - fantomas wrote:
> alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or
> 0-15.66.136.193.in-addr.arpa.
> instead of 0-28.66.136.193.in-addr.arpa.
or use $clientname.66.136.193.in-addr.arp
> Is this as intended?
Nope, that’s local to your system. Hard to tell what’s wrong from just a single
message, but either there’s cruft somewhere in the path with more priority or
your dynamic linker configuration is wrong. Inspecting the binary that’s
failing with `libtool --mode=execute ldd`
Building BIND 9.18.8 from source seems to need
./configure; LD_RUN_PATH=/usr/local/lib make; sudo make install
instead of the traditional
./configure; make; sudo make install
Using the traditional recipe, I obtained the run-time error message
named: error while loading shared libraries: libis
On 05.11.22 09:58, David Alexandre M. de Carvalho via bind-users wrote:
Thank you all for the replies.
For what I understand after reading your replies (I might be wrong :) ),
reverse lookups fail when I have no outgoing
connection because some caching or or transfer is needed from
66.136.193.
6 matches
Mail list logo
