WillyXJ / facileManager

A modular suite of web apps built with the sysadmin in mind.
www.facilemanager.com
GNU General Public License v2.0
85 stars 37 forks source link

[ISSUE] error transferring to the slave server when a zone is in a view (same zone name two views) #562

Closed oiLvAcciNe closed 1 year ago

oiLvAcciNe commented 1 year ago

Hi,

can we take a look at this?

I am trying to accomplish a view setup in bind. The answer is ok. Based on the "match-clients" acl that i defined.

But i am having a problem while transferring this to the slave server. The master refuses the transfer ... to the best of my knowledge this is because there is no key setup for masters on the slave.

image

if i put a key in the master server i can only download the zone from that view where the key is in/matches the allow-transfer

image

image

But rndc retransfer nos.nos in external or rndc retransfer nos.nos in external

it will always use internal tsig key specified in the master

. .

image

. . . if i manualy edit te file to the view/zones ... to include the key in master it all works fine

zones/zones.conf.internal masters { 10.156.45.72 key internal; };

zones/zones.conf.external masters { 10.156.45.72 key external; };

. image . . . .

My fM version on this lab server is v4.3.0 And fmDNS is v5.2.1

. . this img below is also a mannualy edit of the named.conf file to provide a lab . . image .

I have already tried to to some setup/configuration in fmDNS ... and also this steps provided above ...

But i'm missing something or this is not possible yet in gui. Can you confirm?

A possible solution : ... Could we have a entry in the edit view to insert a key value for zone transfer (that would be added to the master ip / key slave zone configurating / inside "zones/zones.conf.external" ? ... per example ... )

image

Regards

Originally posted by @oiLvAcciNe in https://github.com/WillyXJ/facileManager/issues/512#issuecomment-1183167766

oiLvAcciNe commented 1 year ago

related to #512

WillyXJ commented 1 year ago

Duplicate of #512. Further discussion is in original issue.