I meant d.f.ip6.arpa rather than f.d.in-addr.arpa.
> On 24 Jul 2019, at 11:18 pm, Mark Andrews wrote:
>
> There is f.d.in-addr.arpa which is what this ticket is about and
> ipv4only.arpa which Stuart Cheshire is writing a update for and for which
> there is a seperate ticket. Both are DNSSEC
There is f.d.in-addr.arpa which is what this ticket is about and ipv4only.arpa
which Stuart Cheshire is writing a update for and for which there is a seperate
ticket. Both are DNSSEC related. Both cause operational problems. Both
involve having unsigned zones for the relevant names.
For
> On 14 Jul 2019, at 1:18 am, Jay Ford wrote:
>
> I'm still confused about why named looks further up the tree than
> c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which it holds authoritatively via
> master/slave zone type. That seems like incorrect behavior.
The cache doesn’t know about zones. The
I'm still confused about why named looks further up the tree than
c.0.d.7.5.7.c.2.a.9.d.f.ip6.arpa which it holds authoritatively via
master/slave zone type. That seems like incorrect behavior.
Is this something I can fix or work around?
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
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
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:
> 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-except {
Almost my point. It comes to my attention the hard way, that MDNS is
enabled by default or by accident in some Linux distros. Check
/etc/nsswitch.conf. Let us know what you find, and thanks a lot!
Longer answer: it depends on whether MDNS is in nsswitch, and what the
ordering is.
--
Fred
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 reported before it is FIXED! Yes, it has
been reported
before.
It should take a total of less than 10 minutes to fix. Create a empty zone
called
D.F.IP6.ARPA (SOA and
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-except { "f.ip6.arpa"; };
but alas, no.
Extra puzzling so far is that the behavior is time-variable: delegated zones
will resolve most
Because static-stub only overrides “where” to find the information about the
zone
not whether the zone content is valid.
With DNSSEC named will treat zone content as trusted (master/slave). Slave the
top
level internal zones. Note this doesn’t help any application that is also
performing
hi-
i have an environment which over time has managed to accumulate various
"internal" zones [in this specific case, "foo.local"]. eventually, these zones
will be phased out, but unfortunately in the interim, i'm stuck with this. i'm
attempting to configure them as static-stub zones:
zone
13 matches
Mail list logo
