On 8/28/15 9:19 AM, Bob McDonald wrote:
> It appears that receiving an NSID response depends on having server-id
> set in the options block. However, I'm seeing no way to restrict such
> queries.
You don't have to set the server-id information to anything that an
external entity would find interes
It appears that receiving an NSID response depends on having server-id set
in the options block. However, I'm seeing no way to restrict such queries.
regards,
Bob
On Fri, Aug 28, 2015 at 7:48 AM, Bob McDonald wrote:
> No, and there seems to be sparse documentation of the use of NSID in
> troub
No, and there seems to be sparse documentation of the use of NSID in
troubleshooting. I'm all ears. I would. however, like to restrict queries
to inside networks/users and negate access to that data from the outside
altogether.
TIA,
Bob
Alan Clegg wrote:
> Has anyone recommended doing debugging
Has anyone recommended doing debugging via NSID instead of the CH class
data?
On 8/27/15 12:55 PM, Bob McDonald wrote:
> If I set this up as follow, it works.
>
> view bind chaos {
> recursion no;
> allow-query { 127.0.0.1; none; };
> zone authors.bind ch { type master; database "_bu
If I set this up as follow, it works.
view bind chaos {
recursion no;
allow-query { 127.0.0.1; none; };
zone authors.bind ch { type master; database "_builtin authors"; };
zone hostname.bind ch { type master; database "_builtin hostname"; };
zone version.bind ch { type maste
The warning is issued either way (with or without recursion specified). But
I see the logic in not needing it if recursion is set to no.
Thanks again,
Bob
On Wed, Aug 26, 2015 at 5:45 AM, Tony Finch wrote:
> Bob McDonald wrote:
> >
> > I'd still include the hint zone (as I'm partial to not ha
Bob McDonald wrote:
>
> I'd still include the hint zone (as I'm partial to not having unnecessary
> warnings on startup).
The "recursion no" directive means you shouldn't have a hint zone in that
view. (I don't know if it will complain about the inconsistency.)
> Also a lot of folks use localhos
one problem is that you need to change your whole configuration if you
don't need views because dedicated servers for external and internal DNS
allow-chaos {localhost; localnets;} defaulting to 127.0.0.1 as global
option would be helpful
BTW: what i don't understand is why "status: NOERROR" i
That's brilliant! Thanks.
I'd still include the hint zone (as I'm partial to not having unnecessary
warnings on startup).
Also a lot of folks use localhost and/or localnets in DNS configuration.
Just from a security standpoint, I prefer to be more specific. localhost
and/or localnets can be much
Bob McDonald wrote:
> To further lock this information down I would suggest adding the
> following view statements to any internet facing DNS device configuration:
>
> view "outsiders" chaos {
> match-clients { !127.0.0.1; !your-inside--nets; any; };
> allow-query { none; };
> # w
, Bind 9 will produce some useful troubleshooting information.
(Currently running version information of Bind 9 and the hostname of the
host on which it is running) This can be queried via a dig request to class
chaos, type txt as below:
dig version.bind ch txt +norecurse
This is especially useful
11 matches
Mail list logo
