Hi, I tried to upgrade from 9.18 to 9.20 and when I use
recursive-clients set to 0 then I get the following (9.18 was working
well with this):
Oct 13 14:11:04 ns4 named[10719]: quota.c:39:
REQUIRE(__c11_atomic_load(("a->max), memory_order_relaxed) > soft)
failed
Oct 13 14:11:04 ns4 named[1071
Everything looks good from here in a Debian with 9.18
# nslookup mofa.gov.bd
Server: 193.93.164.194
Address:193.93.164.194#53
Non-authoritative answer:
Name: mofa.gov.bd
Address: 103.163.210.121
Name: mofa.gov.bd
Address: 103.163.210.117
# dig ns mofa.gov.bd
; <<>> DiG 9.18
request when sending FORMERR.
FORMERR + OPT indicates the server understands EDNS.
You can workaround this by adding “server 1.1.2.2 { request-expire no; };” to
named.conf.
This worked really well! Thank you very much
On 24 May 2022, at 11:12, Lefteris Tsintjelis via bind-users
wrote:
I
usr/local/etc/namedb/secondary/db.domain.com"; };
On 24/5/2022 4:12, Lefteris Tsintjelis via bind-users wrote:
I turned on all logs channels and this is the error I get:
zone domain.com/IN: refresh: unexpected rcode (FORMERR) from primary
1.1.2.2#53 (source 0.0.0.0#0
tcpdump seems to al
4/5/2022 3:00, Grant Taylor via bind-users wrote:
On 5/23/22 5:55 PM, Lefteris Tsintjelis via bind-users wrote:
Nothing actually. Windows logs are clean. Unix logs also.
#trustTheBitsOnTheWire
#useTheSniffer
I'd start by capturing w/ tcpdump using the `-s 0` and `-w
/path/to/capture.pcapng`
On Mon, 23 May 2022, 21:52 Lefteris Tsintjelis via bind-users,
mailto:bind-users@lists.isc.org>> wrote:
I must be missing something. Any ideas why does it fail? Everything
seems normal. Works well with Windows 2016. Downgrading to 9.16
works again.
--
Visit https://lists.i
I must be missing something. Any ideas why does it fail? Everything
seems normal. Works well with Windows 2016. Downgrading to 9.16 works again.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support
On 12/7/2019 2:42, Mark Andrews wrote:
On 12 Jul 2019, at 8:54 am, Lefteris Tsintjelis via bind-users
wrote:
On 11/7/2019 22:56, @lbutlr wrote:
On 11 Jul 2019, at 10:52, Lefteris Tsintjelis via bind-users
wrote:
On 11/7/2019 15:35, Tony Finch wrote:
Lefteris Tsintjelis via bind-users
On 11/7/2019 22:56, @lbutlr wrote:
On 11 Jul 2019, at 10:52, Lefteris Tsintjelis via bind-users
wrote:
On 11/7/2019 15:35, Tony Finch wrote:
Lefteris Tsintjelis via bind-users wrote:
Why would you want something like that?
https://datatracker.ietf.org/wg/dprive/about/
If you are
On 11/7/2019 15:35, Tony Finch wrote:
Lefteris Tsintjelis via bind-users wrote:
Why would you want something like that?
https://datatracker.ietf.org/wg/dprive/about/
If you are willing to sacrifice speed. DNS responses have a pretty big
impact in browsing speed but I guess anyone
On 11/7/2019 13:39, Tony Finch wrote:
Encrypted DNS between resolvers and authoritative servers is still in the
process of being standardized.
It sounds like too much overhead already. Why would you want something
like that? Isn't DNSSEC enough to assure integrity?
Lefteris
_
On 30/6/2019 20:34, Grant Taylor via bind-users wrote:
> I think you're missing options that are outside of the box. ;-)
Very true! :-) I like to make my life easier
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from
On 30/6/2019 0:29, Grant Taylor via bind-users wrote:
> On 6/29/19 2:13 PM, Lefteris Tsintjelis via bind-users wrote:
>> Standard DNS mechanisms and poll would not work. Everything must be
>> done within 1 minute so notify MUST be used and therefor zone serial
>> must be in
On 29/6/2019 21:55, Grant Taylor via bind-users wrote:
> On 6/29/19 12:30 PM, Lefteris Tsintjelis via bind-users wrote:
>> Secondaries though are almost always slaves, so writing suppression
>> doesn't really matter for them. It is the primary that only matters so
>> i
On 26/6/2019 20:25, Tony Finch wrote:
> Lefteris Tsintjelis via bind-users wrote:
>> On 26/6/2019 17:39, Grant Taylor via bind-users wrote:
>>> Or are you wanting to update the zone contents without actually updating
>>> the zone file on disk?
>>
>> Yes, exa
On 26/6/2019 22:56, Grant Taylor via bind-users wrote:
> On 6/26/19 1:17 PM, Lefteris Tsintjelis via bind-users wrote:
>> If I set it though, and named no longer has access to modify and
>> rewrite other files but its own, will it break things? What will
>> happen in case of
On 26/6/2019 22:04, Anderson, Charles R wrote:
> On Wed, Jun 26, 2019 at 07:46:20PM +0300, Lefteris Tsintjelis via bind-users
> wrote:
>> On 26/6/2019 17:39, Grant Taylor via bind-users wrote:
>>> Or are you wanting to update the zone contents without actually updating
>
On 26/6/2019 21:57, Tony Finch wrote:
> Lefteris Tsintjelis via bind-users wrote:
>>
>> That makes perfect sense, but I was still shocked when I first saw it
>> specially to a file owned by root. This is the part that surprised me
>> and worried me the most! I was unde
On 26/6/2019 20:25, Grant Taylor via bind-users wrote:
> On 6/26/19 10:46 AM, Lefteris Tsintjelis via bind-users wrote:
>> Yes, exactly this. That is the reason I changed the actual zone disk
>> file permissions to root thinking that files would not be modifiable,
>> but bind
On 26/6/2019 21:13, Tony Finch wrote:
> It will rewrite the
> zone file from scratch when it merges in the journal, which is what would
> cause the change of ownership.
That makes perfect sense, but I was still shocked when I first saw it
specially to a file owned by root. This is the part that su
On 26/6/2019 20:25, Tony Finch wrote:
> Lefteris Tsintjelis via bind-users wrote:
>> On 26/6/2019 17:39, Grant Taylor via bind-users wrote:
>>> Or are you wanting to update the zone contents without actually updating
>>> the zone file on disk?
>>
>> Yes, exa
On 26/6/2019 17:39, Grant Taylor via bind-users wrote:
> Or are you wanting to update the zone contents without actually updating
> the zone file on disk?
Yes, exactly this. That is the reason I changed the actual zone disk
file permissions to root thinking that files would not be modifiable,
but
>> On 26 Jun 2019, at 1:25 pm, Lefteris Tsintjelis via bind-users
>> wrote:
>>
>> Hi,
>>
>> Is it possible to apply temporary only update policy and never save or
>> modify anything to a zone file?
>>
>> For example:
>>
>>
Hi,
Is it possible to apply temporary only update policy and never save or
modify anything to a zone file?
For example:
zone "example.com" {
type master;
auto-dnssec maintain;
inline-signing yes;
update-policy {
grant rndc-key temponly _acme-challenge.example.com. txt;
};
file "/etc/name
On 23/6/2019 20:28, Evan Hunt wrote:
On Sun, Jun 23, 2019 at 05:01:11PM +, Evan Hunt wrote:
It's a bug. I see the same result. Thanks for pointing it out, I'm
looking into it.
Ah, I see the problem. You overrode the default policy by using the name
"default", but you didn't set a "coverage
I am using FreeBSD with bind v9.11.8. v9.11.6P1 also had the same problem.
I am using ECDSAP256SHA256 for ZSK and KSK. I have made a very simple
policy that I am trying to automate by using dnssec-keymgr in crontab.
policy default {
directory "/usr/local/etc/namedb/keys";
algor
26 matches
Mail list logo
