Given the message says "ran out of space” it indicates that a fixed buffer was
too small. The lookup also works with current versions of BIND so I would
say the solution is to stop running EoL’d software and upgrade.
There is also a ridiculous number of DNSKEYs and signatures. I suspect that
the
Trying with +cd, +noedns and +tcp elicits a similar result; a SERVFAIL.
As these work fine if querying the authoritative servers directly (or using
+trace), it appears to be a quirk in the resolver code.
Stuart
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On Wed, 2019-06-26 at 13:16 +, Dennis via bind-users wrote:
> dig TXT cleanmail4.capgeminioutsourcing.nl @localhost
dig TXT cleanmail4.capgeminioutsourcing.nl +nodnssec
@ns1.capgeminioutsourcing.nl.
;; MSG SIZE rcvd: 124
dig TXT cleanmail4.c
There's a huge amount of DNSSEC verbiage in the response to that query
(4931-byte response from the authoritative nameservers), when querying
with +dnssec. I'm guessing the resolver function of BIND might be having
trouble with DNSSEC validation. At least, that's a hypothesis. I'm not
familiar enou
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 a dynamic update like A
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
>>> the zone file on disk?
>
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 a dynamic update like ACME in this case? Will the update go through?
I think that wo
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 under the impression that after s
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
> > the zone file on disk?
>
> Yes, exactly this. That is the reason I changed
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 under the impression that after start up,
> named would switch to the user co
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 surprised me there. I
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
Grant Taylor via bind-users wrote:
>
> The only way that I see that BIND, running as something other than root, could
> change them is if the user it's running as has write on the directory and
> deletes & recreates new zone files as itself. But that would surprise me too.
`named` requires write
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, exactly this. That is the reason I changed
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 surprised me there. I did not expect to change the file
ownership from root to bind!
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, exactly this. That is the reason I changed the actual zone disk
> file permissions to
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 6/25/19 9:25 PM, Lefteris Tsintjelis via bind-users wrote:
Is it possible to apply temporary only update policy and never save or
modify anything to a zone file?
What would this functionally do?
Or are you wanting to update the zone contents without actually updating
the zone file on disk?
Hi List,
When I try to resolve a TXT record cleanmail4.capgeminioutsourcing.nl I'll get
a SERVFAIL. Asking Google seems to work though:
rndc flush
dig TXT cleanmail4.capgeminioutsourcing.nl @localhost
; <<>> DiG 9.10.3-P4-Debian <<>> TXT cleanmail4.capgeminioutsourcing.nl
@localhost
;; global
19 matches
Mail list logo
