rndc/controls block clarification needed?

[Jon A.]

Just spent a bit of time on missing a subtle rndc issue with Bind 9.9.1's
control block -- either I'm missing a better way to do this, or perhaps
bind should more appropriately issue a warning or fail to load instead of
silently accepted my bad control block.

I did RTFM, and until I'd spent a bunch of time playing with permutations,
I missed the subtle hints in the documentation.  Perhaps I still am, in
which case, I welcome a cleaner way to do this.

Ultimately I believe the issues to be that 1) you can't use the same
control port (993) for more than one inet statement and 2) using more than
one key isn't going to work.

I initially wanted the following, but had issues with getting rndc status
to work from both places:
controls {
   inet * port 953 allow { localhost;  authorized-controllers; } keys {
rndc-key;  masterkey;  };
};


Also tried:
controls {
   inet 127.0.0.1 allow { localhost; } keys { rndc-key; };
   inet * port 953 allow { authorized-controllers; } keys { masterkey;
};
 };

Ultimately it had to be set up as:

controls {
   inet 127.0.0.1 port 953 allow { localhost; } keys { rndc-key; };
   inet * port 9953 allow { authorized-controllers; } keys { masterkey;
};
};

Is there a cleaner way (that works!) to set this up?  If not, could it be
made to work, or documentation/warnings be created to pound such ideas out
of my head in the future?
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: using 127.0.0.1 in resolv.conf

[Jon A.]

I also use loopback regularly if running a localhost resolver; in fact I
use a script that goes as far as changing resolv.conf if it detects an
interface address instead of loopback.  [Our rules require listening on
loopback minimally here]

If you do use it, I recommend you make sure you don't have "options rotate"
set as that'll cause confusion as it's most likely not your intent if
you're running a nameserver locally.

On Mon, Jul 23, 2012 at 5:13 PM, John Miller  wrote:

> Hey there folks,
>
> I was just going back through the good ol' cricket book, and ran into the
> following:
>
> "If you use multiple nameserver directives, don't use the loopback
> address!  There's a bug in some Berkeley-derived TCP/IP implementations
> that can cause  problems with BIND if the local nameserver is down. The
> resolver's connected datagram socket won't rebind to a new local address if
> the local nameserver isn't running, and consequently the resolver sends
> query packets to the fallback remote nameservers with a source address of
> 127.0.0.1. When the remote nameservers try to reply, they end up sending
> the reply packets to themselves."
>
> Given that this same text is in the fourth edition of Cricket & Paul's
> book as well, I'm assuming this was an old bug (pre-BIND 9) and has long
> since been fixed.  Could someone point me to a bug report and/or changelog
> for this?  A quick Google search for 'bind resolver source address bug'
> didn't yield much.
>
> John
> --
> John Miller
> Systems Engineer
> Brandeis University
> 781-736-4619
> johnm...@brandeis.edu
>
> __**_
> Please visit 
> https://lists.isc.org/mailman/**listinfo/bind-usersto
>  unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/**listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users