Re: ipv6 implementation in an ipv4 camp
In message <4c89fcd5.4050...@paz.bz>, Jim Pazarena writes: > I am curious if anyone can point out articles or deeper instructions > regarding an implementation and launch of ipv6 in a fully ipv4 camp? > > If the upstream ISP still provides the end user an ipv4 number > as a gateway, and the end user still has a /24 or /23 assigned by > the ISP, need they be concerned with ipv6? > > would the ipv4 /23 subnet be 'translatable' to a corresponding > ipv6 number? > > Any source documents would be greatly appreciated. > ___ > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users I would not bring up IPv6 internally without having external IPv6 connectivity. As others have mentioned HE provides a good tunnel service (I've been using them for ~7 years at home automatically reconfiguring the tunnel when my IPv4 address changes). Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC, views & trusted keys...
On Sep 12, 2010, at 10:45 AM, Tony Finch wrote:
> I could not get private stub nor forward zones to work if their public parent
> is signed and does not have a delegation to the private zone.
Does it work if the parent does have a DS record for the child covered by the
stub zone? I would expect it would not do so, since with a stub zone, the
resolver ought to start resolution right there, thus never seeing the parent's
DS record.
Instead, add a trusted key for the stub zone.
Conceptually, a stub zone is like a root hints zone. You need a trusted key for
the root in order to trust its DNSKEY. The same should be true of stub zones.
Disclaimer: I have not actually tested this. It's never come up as a problem
I've had to solve; stub zones have typically been for internal DNS
environments, where DNSSEC rollout has not been a priority.
Chris Buxton
BlueCat Networks
> On 12 Sep 2010, at 03:41, Chris Buxton wrote:
>
>>
>> On Sep 11, 2010, at 2:34 AM, Phil Mayers wrote:
>>>
>>> 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
>> };
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC, views & trusted keys...
I could not get private stub nor forward zones to work if their public parent
is signed and does not have a delegation to the private zone.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
On 12 Sep 2010, at 03:41, Chris Buxton wrote:
>
> On Sep 11, 2010, at 2:34 AM, Phil Mayers wrote:
>>
>> 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
> };
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: installing on SLES 10sp3
Chris Buxton wrote: > 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 SELinux! >> > > 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 Thanks, Chris. That is exactly what it was. AppArmor. Lyle Giese LCR Computer Services, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNSSEC, views & trusted keys...
On 09/12/2010 03:41 AM, Chris Buxton wrote: 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. Oops! Excellent point, sorry for the confusion ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
