Re: static stub zone not working as expected

See ticket [IANA #992665] from December 2017 for at least one previous request to get this fixed. Mark > On 12 Jul 2019, at 12:13 pm, Mark Andrews wrote: > > IANA, why is there NOT a insecure delegation for D.F.IP6.ARPA as REQUIRED by > RFC 6303? > > How many times does this need to be

Re: static stub zone not working as expected

I suspect this will be negative response synthesis. The cache has learnt that d.f.ip6.arpa doesn’t exist in ip6.arpa and when the name in question is looked up the covering NSEC is returned which covers all of ULA space. If I’m right querying for DS d.f.ip6.arpa will load the cache

Re: static stub zone not working as expected

On Fri, 12 Jul 2019, Mark Andrews wrote: On 12 Jul 2019, at 1:00 pm, Mark Andrews wrote: On 12 Jul 2019, at 11:12 am, Jay Ford wrote: I have a similar problem with zones for IPv6 ULA space. I'm running BIND 9.14.3. I had hoped that validate-except would do the trick, such as:

Re: IXFR fallback to AXFR if diff is bigger than zone

Hi Tony! Am 12.07.2019 um 13:00 schrieb Tony Finch: > Yes, that is curious. Are you sure it isn't actually doing an > IXFR-flavoured AXFR of the whole zone, rather than a delta? We have a setup with severals Bind in a row: hidden master customer (software unknown) | | V

Re: IXFR fallback to AXFR if diff is bigger than zone

Klaus Darilion wrote: > > I wonder how Bind as master handles IXFR when the requested IXFR would > be much than the AXFR. (For example: if you change the NSEC3 salt). > > Are there some mechanisms to detect such a situation and trigger a > fallback to AXFR or will Bind always perform IXFR? No.