> On 12 Mar 2024, at 13:36, Mark Andrews wrote:
>
> Have you disabled EDNS to these servers in named.conf? DNSSEC responses are
> only returned
> if DO=1 is set in the request. Named can learn that a server doesn’t support
> EDNS if it doesn’t
> return EDNS responses consistently to EDNS re
ared to the
> other two: checkpoint.com <http://checkpoint.com/>.
>
> I get these errors:
>
> <142>1 2024-03-12T11:36:21.957013+00:00 dnsanycast named 86604 - - insecurity
> proof failed resolving 'checkpoint.com/A/IN': 198.51.44.65#53
> <142>1 2024-03-12T11
gt;1 2024-03-12T11:36:21.957013+00:00 dnsanycast named 86604 - - insecurity
proof failed resolving 'checkpoint.com/A/IN': 198.51.44.65#53
<142>1 2024-03-12T11:36:21.941389+00:00 dnsanycast named 86604 - - insecurity
proof failed resolving 'checkpoint.com/A/IN': 198.51.45.1#5
On 13.12.21 08:18, John Thurston wrote:
If you update your resolver to 9.16, I think you can do exactly what
you want with the "validate-execpt" option.
{rolls eyes} been there. done that. for exactly the same reason :/
On 14.12.21 16:58, Matus UHLAR - fantomas wrote:
thanks, this helped.
I
On 13.12.21 08:18, John Thurston wrote:
If you update your resolver to 9.16, I think you can do exactly what
you want with the "validate-execpt" option.
{rolls eyes} been there. done that. for exactly the same reason :/
thanks, this helped.
I assume I need to put "local" into validate-except
If you update your resolver to 9.16, I think you can do exactly what you
want with the "validate-execpt" option.
{rolls eyes} been there. done that. for exactly the same reason :/
--
--
Do things because you should, not just because you can.
John Thurston907-465-8591
john.thurs...@alask
amed[13112]: validating x.local/A: got insecure
response; parent indicates it should be secure
Dec 13 14:26:55 mail named[13112]: insecurity proof failed resolving
'x.local/ANY/IN': 100.1.2.3#53
Dec 13 14:26:55 mail named[13112]: validating x.local/NS: got insecure
response; parent
syslog:
Mar 23 08:11:15 linux named[19256]: error (insecurity proof failed) resolving
'./DS/IN': 192.33.4.12#53
Mar 23 08:11:15 linux named[19256]: error (insecurity proof failed) resolving
'./DS/IN': 192.203.230.10#53
Mar 23 08:11:15 linux named[19256]: error (insecu
On Mon, Jan 20, 2014 at 12:46 PM, Graham Clinch wrote:
> Thanks for the replies - and noticing the missing 'NS'!
>
> From my rather brain-busting afternoon reading, I believe this situation
> is covered by section 4.4 of RFC 6840, which requires a validator to ensure
> the NS type bit is set for a
NSKEY): unlink
> 20-Jan-2014 12:18:51.415 resolver: debug 3: fctx
> 0x80ac04000(postbank.de/DNSKEY): destroy
> 20-Jan-2014 12:18:51.415 dnssec: debug 3: validating @0x80bb74500:
> newsletter.postbank.de A: in dsfetched2: ncache nxrrset
> 20-Jan-2014 12:18:51.415 dnssec: de
Hi List (& Chris & Tony),
What *does* matter is that the NSEC3 "proves" that there are no NS
records as well (as no DS ones) for newsletter.postbank.de (despite
the fact that the NS records are included in the referral). Note the
absence of opt-out in the NSEC3.
Thanks for the replies - and no
On Jan 20 2014, Graham Clinch wrote:
I'm seeing a dnssec validation error that I can't pin down, for the
domain: newsletter.postbank.de.
Neither of http://dnsviz.net/ and
http://dnssec-debugger.verisignlabs.com/ report finding a problem, but
two (ubuntu packaged) versions of bind report a fa
415 dnssec: debug 3: validating @0x80bb74500:
newsletter.postbank.de A: insecurity proof failed
... what? ...
20-Jan-2014 12:18:51.416 resolver: debug 3: fetch 0x801859ff0 (fctx
0x80b044860(newsletter.postbank.de/DS)): destroyfetch
20-Jan-2014 12:18:51.416 resolver: debug 3: fctx
0x80b044860(new
nt_reference: delete from rbt:
0x7ff58b52c010 ns3.ecircle.com
20-Jan-2014 11:58:43.943 decrement_reference: delete from rbt:
0x7ff58b52c010 ns3.ecircle.com
20-Jan-2014 11:58:43.974 decrement_reference: delete from rbt:
0x7ff58b52c010 ns3.ecircle.com
20-Jan-2014 11:58:43.974 createfetch: de DS
20-Jan-
14 matches
Mail list logo
