Re: DNSSEC, views trusted keys...
On 09/10/2010 11:12 PM, Timothe Litt wrote:
So it looks like the new (r-internal) view is starting at the root when it
resolves -- ignoring what it has data for locally. It sorta works for
You'll need a:
zone name {
type forward;
forward only;
forwarders {
ips;
};
};
It won't automatically detect that another view contains the zone and
redirect it; you have to tell it.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: installing on SLES 10sp3
On Sep 9, 2010, at 5:02 PM, Lyle Giese wrote: wllarso wrote: I'm not any sort of Linux expert but this started my mind thinking. Take a look at the BIND FAQ, it comes with the sources. There are some Linux specific comments about file and directory permissions. Bind running under Linux drops special 'root' permissions when it starts up. I am not using the -u option nor am I running in a CHROOT environment. ps shows root owning the named process. Also, there are specific issues when running the Security Enhanced Linux. This may be your situation, or not. We can't tell. I have never on purpose enabled SELinuxGRIN! On SLES, look for AppArmor. You may find that an AppArmor profile is stifling what named can do. Try disabling it. IMO, SELinux and AppArmor have their place, but you generally have to create or customize your own security profile to allow services to work the way you want them to. Both SUSE and RHEL/Fedora/CentOS make the assumption that you will use the provided management tools, or none at all, rather than using any 3rd party management system. Chris Buxton BlueCat Networks ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC, views trusted keys...
On Sep 11, 2010, at 2:34 AM, Phil Mayers wrote:
On 09/10/2010 11:12 PM, Timothe Litt wrote:
So it looks like the new (r-internal) view is starting at the root when it
resolves -- ignoring what it has data for locally. It sorta works for
You'll need a:
zone name {
type forward;
forward only;
forwarders {
ips;
};
};
It won't automatically detect that another view contains the zone and
redirect it; you have to tell it.
Use a stub zone instead of a forward zone, so that the query will actually
reach the authoritative view. With a forward zone, the query is recursive, so
will be picked up by the recursive view - the view will query itself and not
receive an answer.
zone zone.name {
type stub;
file /path/to/recursive-view-data/zone.name;
masters { 127.0.0.1; }; // or whatever the correct IP is to reach the
internal view
};
Chris Buxton
BlueCat Networks
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
