Hi Gaurav
On Fri, Mar 27, 2015 at 11:18:33AM +0530, Gaurav Kansal wrote:
> While querying through dig utility, I am getting ADDITIONAL :3 in the
> Header section while I am only getting 2 additional records.
The 3rd one is the OPT RR which is printed separately under
"OPT PSEUDOSECTION".
Dear Team,
While querying through dig utility, I am getting ADDITIONAL :3 in the Header
section while I am only getting 2 additional records.
C:\Users\Kansal>dig ns3.nkn.in @ns1.nkn.in
; <<>> DiG 9.10.1 <<>> ns3.nkn.in @ns1.nkn.in
;; global options: +cmd
;; Got answer:
;; -
On Thu, Mar 26, 2015 at 1:00 PM, Matus UHLAR - fantomas
wrote:
>> On Thu, Mar 26, 2015 at 12:17 PM, Matus UHLAR - fantomas
>> wrote:
>>>
>>> What's the SOA? It's possible that the zones were not expired, so they
>>> were
>>> provided as saved on disk. Since BIND wasn't able to transfer newer
>>>
On Thu, Mar 26, 2015 at 12:17 PM, Matus UHLAR - fantomas
wrote:
What's the SOA? It's possible that the zones were not expired, so they were
provided as saved on disk. Since BIND wasn't able to transfer newer
versions, it continued providing old versions.
On 26.03.15 12:48, Frank Even wrote:
Y
On Thu, Mar 26, 2015 at 12:17 PM, Matus UHLAR - fantomas
wrote:
> On 26.03.15 11:34, Frank Even wrote:
>>
>> Zone files were in place for the necessary domains, but were outdated
>> (assuming one of our updates broke something somewhere, they were all
>> on average 3 months old).
>
>
>> Here is wh
On 26.03.15 11:34, Frank Even wrote:
Zone files were in place for the necessary domains, but were outdated
(assuming one of our updates broke something somewhere, they were all
on average 3 months old).
Here is where the issue is. I've generally found if BIND fails to
write the zone, it gener
Am 26.03.2015 um 19:34 schrieb Frank Even:
Zone files were in place for the necessary domains, but were outdated
(assuming one of our updates broke something somewhere, they were all
on average 3 months old)
I guess the question really is, is this expected behavior or a bug?
after 3 months th
The subject is about the only way I can think to describe a situation
we've run into recently. First here is the system:
[root@dns]# cat /etc/redhat-release
CentOS release 6.6 (Final)
[root@dns]# rpm -q bind
bind-9.8.2-0.30.rc1.el6_6.2.x86_64
So, we got bit by a chroot permissions issue (unsure
Hello
I have several RPZ zones configured on our caching resolver. e.g.
response-policy {
zone "whitelist.rpz.switch.ch." policy passthru;
zone "malware.rpz.switch.ch." policy GIVEN;
};
I currently log RPZ hits via syslog to a remote log server. I don't want
the whitelist rpz zone hits to
9 matches
Mail list logo
