Am 03.04.20 um 15:20 schrieb David Alexandre M. de Carvalho:
> Where can I find about alternatives to point 2?
in the part you quoted from me
> I have a windows subdomain configured in that way, never realized there was a
> better way.
> Thanks and regards.
which way?
a) zone-delegation, 192.168.196.1 is the nameserver responsible for
whatever below subzone.example.com
subzone IN A 192.168.196.1
subzone IN NS subzone
b) records in the same main zone file
subzone IN A 192.168.1.1
www.subzone IN A 192.168.196.10
mail.subzone IN A 192.168.196.11
>>>> why so much complexity to begin with?
>>>>
>>>> t1 A 127.0.0.3
>>>> sub.t30 A 127.0.0.2
>>
>> On 03.04.20 11:53, [email protected] wrote:
>>> -----------------------
>>> Well, in first place to make it human readable, if needed to look into the
>>> zone.
>>
>> well
>> 1. the above is more readablt than whay you proposed.
>>
>> 2. delegating subdomain (sub) to other servers via NS records and setting
>> any other records in the zone is a bad idea.
>>
>> 3. putting localhost into any domain is useless and I discourage you from
>> doing that
>>
>>> For some subdomains we would have entries for the subdomain itself, like
>>> couple NS,TXT,A,CNAME,SRV etc.
>>> So with these thoughts, the documentation gives this as a valid option and
>>> it
>>> worked in small scale on the testsystem, so we decieded to go this way.
>>> If this needs to be changed, I need a reason besides of 'that is this way
>>> more easy',
>>> because these zones get generated from an automated system and I need an
>>> argument to get a permission for a change request.
_______________________________________________
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
[email protected]
https://lists.isc.org/mailman/listinfo/bind-users
