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
&g
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
--
Fond
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 event
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, a
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
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
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
The easier way to mitigation is to enable dnssec validation on the
resolver (which is a good thing anyway). From my tests this changes the
behaviour of bind in so far that it respects the TTL of the NS set
rather strictly, and returns to the parent on expiry.
Looks like the most efficient long-te
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 RRSIGs
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
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
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 15:10:
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 net
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
Thanks, Marc.
Mark Andrews wrote:
> It's cosmetic. The final NSEC3 record proves the non-existance
> of the data or wildcard. With a nodata response we should be
> expecting the record. The following has been compiled but otherwise
> has not been tested.
It works here, and seems to have the ex
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 nam
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
--
Fondatio
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):
> http://newsgroups.derkeiler.com
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 wit
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
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
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 troubles
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 tha
Alan,
Alan Clegg wrote:
>
> The problem is that to correctly protect non-DNSSEC aware applications,
> a return code had to be chosen that even the lowliest of clients would
> understand as "STOP! YOU MUST NOT USE THIS INFORMATION" to which
> SERVFAIL is the only correct response.
Any other retu
Mark, Mat,
Mat wrote:
> End users will get confused by this, but then there are plenty of
> other possibilities with and without DNS they may get confused about.
> I think providing help to them should be dealt with by the OS instead
> of bloating DNS. Upon return of any error by DNS (or any other
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
doe
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 tra
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 tran
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[-
>> 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
Hello,
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'?
I wasn't able to find anything in the ARM, but maybe I missed something...
Best,
Gilles
--
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-
32 matches
Mail list logo
