On 03/11/2012 01:25 PM, Ralph Droms wrote:
> Suppose that view is on a per-device basis rather than per server?
>
> With something like environment variables in front of "classic" DNS
> resolution in the host resolver...
What's the use case for such complexity? Otherwise, my answer is KISS...
- Jim
>
> - Ralph
>
> On Mar 11, 2012, at 11:43 AM 3/11/12, Jim Gettys wrote:
>
>> On 03/11/2012 11:25 AM, Ted Lemon wrote:
>>> On Mar 11, 2012, at 11:03 AM, Jim Gettys <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>> I think there is an interesting question of whether interior *names*
>>>> should be automatically published into the global DNS by default or
>>>> not, which will depend on the security of the devices and systems and
>>>> the users' expertise, if only to make it a bit harder for attackers to
>>>> discover interior systems to attack (since with IPv6 finding them by
>>>> brute force address space search is relatively hard).
>>> Doesn't making the zone non-enumerable and disabling zone transfers
>>> address this problem? I guess you could still do a dictionary attack
>>> on the zone and decrease the cost of the search somewhat in the usual
>>> case, but it's a pretty sketchy way to try to start an attack.
>>> Having said that, I think it's probably fine to disable propagation of
>>> the zone by default, except that then we have to figure out what to
>>> name the non-propagated zone, and how to deal with the transition from
>>> non-propagated to propagated.
>>>
>> Had been thinking more along the line of the multiple "view" stuff in
>> bind; there would be/is already a public view, and then a private view
>> only visible internally.
>> - Jim
>>
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
