Re: BIND9 TSIG from Windows Server 2016 DNS Server Zone

As far as I know, GSS-TSIG is only used for DNS updates, not zone transfers. https://bind9.readthedocs.io/en/v9_16_5/advanced.html#dynamic-update Sorry, don't know what capabilities AD has for securing zone transfers beyond IP ACLs, which of course is not much security at all. I've never had luck

Re: bugs for cname can not be working properly with bind 9.11.4

Hello Bob, thank you for the support. please find the answer below 1.yes , I have already update the serial number from master server ,it is not a stealth master, it can provide the dns resolution publicly 2. [image: image.png] 3. they can communicate without any block by using internal ip address

BIND9 TSIG from Windows Server 2016 DNS Server Zone

Dear all, I have a zone local.grf.hr administered by AD, DHCP and DDNS ran by Windows Server 2016 (not by my architectural choice). However, since Windows Server 2016 had round-robin strategy of inquiring the forwarders, it performed worse than BIND9 on old Debian server. So, I had the BIND9

BIND9 TSIG from Windows Server 2016 DNS Server Zone

Dear all, I have a zone local.grf.hr administered by AD, DHCP and DDNS ran by Windows Server 2016 (not by my architectural choice). However, since Windows Server 2016 had round-robin strategy of inquiring the forwarders, it performed worse than BIND9 on old Debian server. So, I had the BIND9

BIND9 TSIG from Windows Server 2016 DNS Server Zone

Dear all, I have a zone local.grf.hr administered by AD, DHCP and DDNS ran by Windows Server 2016 (not by my architectural choice). However, since Windows Server 2016 had round-robin strategy of inquiring the forwarders, it performed worse than BIND9 on old Debian server. So, I had the BIND9

Re: bugs for cname can not be working properly with bind 9.11.4

I just modified the serial number this is not currently a problem, but please note that you've changed the first four digits which are likely to 2023. Also if the zone is reloaded there's no need to restart named. Actually nothing changed , Indeed. Are you doing these changes on the

Re: bugs for cname can not be working properly with bind 9.11.4

I also get the same value for the serial number from a dig soa . A couple of questions. 1) I assume you are updating the serial number on the master (primary) zone file. Correct? Is this a stealth (hidden) master? 2) On that same server, what are your values for NOTIFY and if specified, EXPLICIT-

Re: There are some prombles in the query log

All queries are from the same client whose ip is 192.168.100.126, but why the port which each query from is so different? The source port is random and it should be different. I disabled the recursion of bind 9 ,but all the Recursion Desired flag was set '+', this confused me. > If you add

Re: bugs for cname can not be working properly with bind 9.11.4

the domain name is kaixinduole.com Querying the SOA record for kaixinduole.com shows the SOA serial number is less than what you showed in the screenshot: ;; ANSWER SECTION: kaixinduole.com.21600 IN SOA ns1.kaixinduole.com. shawn.kaixinduole.com. ( 20220