On 09/12/2013 12:46 AM, Mark Andrews wrote:
In message 523080dd.6010...@restena.lu, Gilles Massen writes:
I'm seeing weird things (multiple RRSIGs when enabling NSEC3) so I'd
like to know if these are likely to be bugs or if I'm in unchartered
territory...
Fixed in the next maintainence
Hi,
Do you know if Bind with auto-dnssec maintain + inline-signing is
supposed to work with a single key (i.e. not a KSK + ZSK)?
I'm seeing weird things (multiple RRSIGs when enabling NSEC3) so I'd
like to know if these are likely to be bugs or if I'm in unchartered
territory...
Gilles
--
Hello,
I have a weird issue with a zone configured with auto-dnssec maintain
and inline-signing yes. The zone is maintaned with dynamic updates. If I
add, say, a TXT record, it appears in the signed zone just fine. A
records are ignored. They do appear in the unsigned zone just fine, but
the
Hello,
I'd like to change the DNS operator for a signed domain, where the
parent does not allow a DS that is not pointing to an active DNSKEY
(thus the double-DS procedure won't work).
As a result I'd need to insert the old DNSKEYs in the new zone. However,
bind tries to do something with them,
On 11/30/2012 01:30 PM, Matus UHLAR - fantomas wrote:
On 28.11.12 18:38, Tony Finch wrote:
Yes it does. For example, have a look at responses to queries for
dotat.at
in mx for various buffer sizes and observe that RRsets are dropped but
the
TC bit is not set.
Nice to see. I'm seeing
On 30/4/12 13:56 , Chris Thompson wrote:
http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01
Being actively discussed on DNSOP list
It *was* being actively discussed there, up until about 10 days ago. Since
then the participants seem to have stopped, maybe from sheer
On 9/2/12 21:38 , Casey Deccio wrote:
Is it because the resolver, even if sticky, re-queries the parent when
the negative TTL of the (missing) DS records ends? And chokes when it
receives back a NXDOMAIN?
Actually, what I have observed in my limited testing is that the
Evan,
Thanks for outlining this - it's much clearer now.
BIND will try to maintain the signatures in a zone if the zone is
configured to be dynamic--i.e, if it has an update-policy or allow-update
option. It won't create signatures where there were none, but it will try
to keep existing
Hello,
I have a very peculiar behavior: a zone, signed by OpenDNSSEC and pushed
to Bind 9.7.2-P3 by scp was working fine. But now, completely out of the
blue, Bind decides to claim some authority over the zone: the SOA RRSIG
(only that one) is scrapped, and this is logged:
06-Feb-2011
Chris,
thanks for the hint, but:
On 6/2/11 19:20 , Chris Thompson wrote:
On Feb 6 2011, Gilles Massen wrote:
I have a very peculiar behavior: a zone, signed by OpenDNSSEC and
pushed to Bind 9.7.2-P3 by scp was working fine. But now, completely
out of the blue, Bind decides to claim some
Mark,
On 02/06/2011 10:41 PM, Mark Andrews wrote:
Mark Andrews writes:
Does your configuration also have an allow-update setting
(other than none) for it, maybe only for the instance that
is giving you trouble? In that case BIND will take it that you
want it to do resigning as the RRSIGs
Finally I caught one query/server that produces the . SOA: got insecure
response; parent indicates it should be secure log each time:
dig @ns ladeco.com. MX does this every time, where ns runs bind
9.7.1-P2, with only the root TA configured.
The server serving that domain returns not exactly
Mark,
Named has to deal with multually incompatible senarios. DNSSEC
which requires EDNS and nameservers and firewalls which drop EDNS
requests so named has to turn off EDNS to get answers back.
Occasionally a set of answers will take too long to get back to
named or are lost due to network
Hello,
Since enabling the root TA in my resolver, I keep seeing from time to time:
21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: .
SOA: attempting insecurity proof
21-Jul-2010 08:52:27.929 dnssec: debug 3: validating @0x134fe7e8: .
SOA: insecurity proof failed
21-Jul-2010
Evan,
Evan Hunt wrote:
How do you manage managed-keys?
BIND 9.7.2 will introduce a command rndc secroots that dumps
a list of the current trust anchors for each view to a file.
Thanks, good to know.
To remove a key from managed-keys.bind, just remove the initial key
for that name from
Hello,
How do you manage managed-keys? I there a way to ask bind which key
(for a given zone) is actually in use? Or is there a possibility to get
rid of a trust anchor that found it's way into managed-keys.bind (short
of stopping bind and editing managed-keys.bind)?
Best,
Gilles
--
Fondation
Hello,
I have a signed zone (dnssec.lu) with NSEC3 / no optout, signed through
OpenDNSSEC. The zone contains a wildcard with a TXT and A record.
Each time the server is queried for something where the QNAME is matched
by the wildcard, but the QTYPE is not, named logs a warning: expected
covering
Kalman Feher wrote:
It looks like normal NSEC to me, unless you are referring to an isolated
copy of the domain not accessible to the public:
Yes, indeed, sorry about that. I should keep my playgrounds tidier. The
actual zone is located on nssec.restena.lu, and is publicly queriable
(even with
Kalman Feher wrote:
Ok now I see it.
The response appears ok, but the log entry is odd. I see the same on my test
box (9.7.1 not patched to P1 yet).
I saw this on earlier 9.7 as well.
A brief thread on this occurred earlier
in the year (archived here):
Hi Nico,
Could it be that the signature of the AXFR message is created at request
time on the master (actually when the answer is build), but the
validation on the client side is obviously only made at the end of the
transfer?
The RFC2845 suggests that this is possible, but I'm not fluent enough
Mark Andrews wrote:
Obviously there are parallels to NXDOMAIN rewriting. However, the major
difference I see is that NXDOMAIN is a clear message, known by the OSs
and applications, that has basically one meaning. SERVFAIL is more like
'didn't work. go figure.' And the good thing is that
Kevin Darcy wrote:
The fundamental requirement is that the requestor needs to know that
their query FAILED. When you send back a helpful, answerful response
for a failure, either under NXDOMAIN redirection or your proposal, then
you essentially deceive the client and confuse any
Hello all,
If a the validation of a signed RR fails, the answer from the validating
resolver to the requestor is SERVFAIL, if I understood correctly. To the
average end user who isn't aware that DNS exists this translates to
it's broken. Possibly even my ISP is broken if the neighbor's ISP
does
Is there a way to prevent Bind (9.6) from using ipv6 transport for
making queries, by an entry in the config file rather than by
'named -4'?
Well, i think that is OS-specific issue than bind issue. At once,
that was discussed in here, i remember. Ask to Mark.
I don't think it's OS
JINMEI Tatuya / 神明達哉 wrote:
Is there a way to prevent Bind (9.6) from using ipv6 transport for
making queries, by an entry in the config file rather than by 'named -4'?
No.
Ok, thanks.
In that case I would humbly suggest to enhance the syntax of
query-source[-6v] and transfer-source[-v6]
JINMEI Tatuya / 神明達哉 wrote:
Is there a way to prevent Bind (9.6) from using ipv6 transport for
making queries, by an entry in the config file rather than by 'named -4'?
No.
Ok, thanks.
In that case I would humbly suggest to enhance the syntax of
query-source[-6v] and transfer-source[-v6]
Mark Andrews wrote:
-4 shuts down any v6 service. We would like BIND to be able to *reply*
to v6 queries without *generating* them. (For the record, I have the
same issue than Gilles.)
::/0 - NULL
ULA::/48 - default router
Would allow ula local traffic but catch the
27 matches
Mail list logo
