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 repor
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 appropriatel
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:
validate-
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
o
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. It
Hi!
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?
thanks
Klaus
PS: AFAIK the max jou
6 matches
Mail list logo
