RHEL, Centos, Fedora rpm 9.14.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://www.five-ten-sg.com/mapper/bind contains links to the source rpms, and build instructions. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAl3VnVMACgkQL6j7milTFsGv4ACfZBdGLuzuSS+5n1+yU4XGlH3u HzYAnRN+vZ/lMhKo8b0bCp9ghAmjOyR2 =pK5T -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.11.3 - resolving troubles running as a caching server
The cache shows you that the forwarder reported that there’s no such record
returned from the upstream resolvers.
The NXRRSET means - Non-eXistant Resource Record Set, e.g. your resolvers
cached the non-existence of the name returned from the upstream resolvers.
The other option would be running the affected query against the upstream
resolvers in a semi-tight loop and log the results.
while true; do echo "$(date -R): $(dig +short IN A @)“;
sleep 1; done
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 21 Nov 2019, at 01:09, Bind Mailinglist wrote:
>
> Hello Ondřej
> Many thanks for your answer. Hope debugging can help me without server
> overloading.
> They have around 1500 queries/s peakload during eveninghours. It will need
> some time to log exactly this effect.
> At the moment I have the following lines disabled:
> // forwarders {
> //213.160.41.2;
> //213.160.40.34;
> // };
> About the answer. Does it matter if I query A or if there is only a
> CNAME as an answer?
> My last test shows me following cache entry. This has happend around 20min
> after restarting bind with my forwarders enabled.
> ; answer
> tm.inregion.waas.oci.oraclecloud.net. 1697 \-A ;-$NXRRSET
> Could a server timeout ends up in such a cache entry? Or does it need a valid
> answer from the forwarders? What you think.
> I tried to force forwarding by adding "forwarding only" but the result was
> the same.
>
> Regards Florian
>
>
> Am 20.11.2019 um 11:58 schrieb Ondřej Surý:
>> Hi,
>>
>> you mentioned “forwarders” - what are these and how does answer look
>> like on the upstream forwarders?
>>
>> I would recommend enabling higher debug level (start with -d 1) and look
>> into logs what was the answer from the forwarders preceding the failure.
>>
>> Ondrej
>> --
>> Ondřej Surý — ISC
>>
>>
>>> On 20 Nov 2019, at 18:44, Bind Mailinglist
>>> wrote:
>>>
>>> Hello list
>>> I'm glad there is such an active list. Hope there is anybody out there
>>> who can help me with my little problem. :-)
>>> We are running six bind server ( all Ubuntu LTS 18.04 with bind 9.11.3
>>> ), so they are pretty up to date.
>>> Three of them have authoritative zones, one is for testing and two are
>>> just caching servers. And there starts my problem.
>>> 1. It only appears on my caching servers and only if I use my other
>>> servers as forwarders.
>>> 2. At the moment the problem appears on my chaching servers I'm still
>>> able to let it resolve through my forwarders.
>>> 3. Only one organisation with several newspapers are affected. There may
>>> be others but I don't know at the moment.
>>>
>>> Ok, all these newspapers are hosted on oraclecloud with short timers
>>> around 30s.
>>>
>>> # dig
>>> www.20min.ch
>>>
>>> ;; ANSWER SECTION:
>>>
>>> www.20min.ch
>>> . 39 IN CNAME
>>> tamedia.a.inregion.waas.oci.oraclecloud.net.
>>> tamedia.a.inregion.waas.oci.oraclecloud.net. 16 IN CNAME
>>> tm.inregion.waas.oci.oraclecloud.net.
>>> tm.inregion.waas.oci.oraclecloud.net. 16 IN CNAME
>>> eu-london.inregion.waas.oci.oraclecloud.net.
>>> eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 138.1.82.213
>>> eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.234.67
>>> eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.228.138
>>>
>>> # dig
>>> www.tagesanzeiger.ch
>>>
>>> ;; ANSWER SECTION:
>>>
>>> www.tagesanzeiger.ch
>>> . 113 IN CNAME cnp-a-cre-p.newsnetz.ch.
>>> cnp-a-cre-p.newsnetz.ch. 113IN CNAME
>>> tamedia.a.inregion.waas.oci.oraclecloud.net.
>>> tamedia.a.inregion.waas.oci.oraclecloud.net. 11 IN CNAME
>>> tm.inregion.waas.oci.oraclecloud.net.
>>> tm.inregion.waas.oci.oraclecloud.net. 12 IN CNAME
>>> eu-switzerland.inregion.waas.oci.oraclecloud.net.
>>> eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.59.121
>>> eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.46
>>> eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.42
>>>
>>>
>>> Now if I use my caching servers with forwarders enabled I run quite
>>> often into cases where resolving stops working for theses two domains at
>>> the same time.
>>> When I take a dump I see the following line:
>>> ; answer
>>> tm.inregion.waas.oci.oraclecloud.net. 893 \- ;-$NXRRSET
>>>
>>> I have to clear this host from cache to make it working again, for a few
>>> minutes.
>>> The stupid thing, this NXRRSET cache entry has a much higher lifetime.
>>> And so resolving stops working on my caching servers for more then 15min.
>>>
>>> Any idea how I could find out why this happens?
>>> There must be something between my DNS servers. They are in the same
>>> network, so there is no firewall between.
>>>
>>> Many thanks and regards
>>> Florian
>>>
>>> ___
>>> Please visit
>>> https://lists.isc.org/mailman/listinfo/bind-users
>>> to unsubscribe from this list
>>>
>>>
Re: bind 9.11.3 - resolving troubles running as a caching server
Hello Ondřej
Many thanks for your answer. Hope debugging can help me without server
overloading.
They have around 1500 queries/s peakload during eveninghours. It will
need some time to log exactly this effect.
At the moment I have the following lines disabled:
// forwarders {
// 213.160.41.2;
// 213.160.40.34;
// };
About the answer. Does it matter if I query A or if there is
only a CNAME as an answer?
My last test shows me following cache entry. This has happend around
20min after restarting bind with my forwarders enabled.
; answer
tm.inregion.waas.oci.oraclecloud.net. 1697 \-A ;-$NXRRSET
Could a server timeout ends up in such a cache entry? Or does it need a
valid answer from the forwarders? What you think.
I tried to force forwarding by adding "forwarding only" but the result
was the same.
Regards Florian
Am 20.11.2019 um 11:58 schrieb Ondřej Surý:
> Hi,
>
> you mentioned “forwarders” - what are these and how does answer look
> like on the upstream forwarders?
>
> I would recommend enabling higher debug level (start with -d 1) and look into
> logs what was the answer from the forwarders preceding the failure.
>
> Ondrej
> --
> Ondřej Surý — ISC
>
>> On 20 Nov 2019, at 18:44, Bind Mailinglist wrote:
>>
>> Hello list
>> I'm glad there is such an active list. Hope there is anybody out there
>> who can help me with my little problem. :-)
>> We are running six bind server ( all Ubuntu LTS 18.04 with bind 9.11.3
>> ), so they are pretty up to date.
>> Three of them have authoritative zones, one is for testing and two are
>> just caching servers. And there starts my problem.
>> 1. It only appears on my caching servers and only if I use my other
>> servers as forwarders.
>> 2. At the moment the problem appears on my chaching servers I'm still
>> able to let it resolve through my forwarders.
>> 3. Only one organisation with several newspapers are affected. There may
>> be others but I don't know at the moment.
>>
>> Ok, all these newspapers are hosted on oraclecloud with short timers
>> around 30s.
>>
>> # dig www.20min.ch
>> ;; ANSWER SECTION:
>> www.20min.ch. 39 IN CNAME
>> tamedia.a.inregion.waas.oci.oraclecloud.net.
>> tamedia.a.inregion.waas.oci.oraclecloud.net. 16 IN CNAME
>> tm.inregion.waas.oci.oraclecloud.net.
>> tm.inregion.waas.oci.oraclecloud.net. 16 IN CNAME
>> eu-london.inregion.waas.oci.oraclecloud.net.
>> eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 138.1.82.213
>> eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.234.67
>> eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.228.138
>>
>> # dig www.tagesanzeiger.ch
>> ;; ANSWER SECTION:
>> www.tagesanzeiger.ch. 113 IN CNAME cnp-a-cre-p.newsnetz.ch.
>> cnp-a-cre-p.newsnetz.ch. 113IN CNAME
>> tamedia.a.inregion.waas.oci.oraclecloud.net.
>> tamedia.a.inregion.waas.oci.oraclecloud.net. 11 IN CNAME
>> tm.inregion.waas.oci.oraclecloud.net.
>> tm.inregion.waas.oci.oraclecloud.net. 12 IN CNAME
>> eu-switzerland.inregion.waas.oci.oraclecloud.net.
>> eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.59.121
>> eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.46
>> eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.42
>>
>>
>> Now if I use my caching servers with forwarders enabled I run quite
>> often into cases where resolving stops working for theses two domains at
>> the same time.
>> When I take a dump I see the following line:
>> ; answer
>> tm.inregion.waas.oci.oraclecloud.net. 893 \- ;-$NXRRSET
>>
>> I have to clear this host from cache to make it working again, for a few
>> minutes.
>> The stupid thing, this NXRRSET cache entry has a much higher lifetime.
>> And so resolving stops working on my caching servers for more then 15min.
>>
>> Any idea how I could find out why this happens?
>> There must be something between my DNS servers. They are in the same
>> network, so there is no firewall between.
>>
>> Many thanks and regards
>> Florian
>>
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
>> unsubscribe from this list
>>
>> bind-users mailing list
>> bind-users@lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate with respone-policy zone
Thank you very much, this did the trick. Have a nice day! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nsupdate with respone-policy zone
mail-list-us...@materna.de wrote: > > server 127.0.0.1 > debug no > zone testoverride > update add zzz.google.de 604800 A 127.0.0.1 > send The problem is that nsupdate needs fully-qualified domain names - you can't omit the zone name like you can in zone files. So your script needs to be zone testoverride update add zzz.google.de.testoverride 604800 A 127.0.0.1 send Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking: South backing east, 4 to 6. Moderate, occasionally slight in east. Showers later. Good. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
nsupdate with respone-policy zone
Hello, I try to update my RPZ Zone 'testoverride' with nsupdate. Sadly I get only 127.0.0.1#56851: view public: updating zone 'testoverride/IN': update failed: update RR is outside zone (NOTZONE) as error message. How do I update a RPZ zone with nsupdate? Do I miss something? Do I understand something wrong? My nsupdate file is this: server 127.0.0.1 debug no zone testoverride update add zzz.google.de 604800 A 127.0.0.1 send Sincerely ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind 9.11.3 - resolving troubles running as a caching server
Hi, you mentioned “forwarders” - what are these and how does answer look like on the upstream forwarders? I would recommend enabling higher debug level (start with -d 1) and look into logs what was the answer from the forwarders preceding the failure. Ondrej -- Ondřej Surý — ISC > On 20 Nov 2019, at 18:44, Bind Mailinglist wrote: > > Hello list > I'm glad there is such an active list. Hope there is anybody out there > who can help me with my little problem. :-) > We are running six bind server ( all Ubuntu LTS 18.04 with bind 9.11.3 > ), so they are pretty up to date. > Three of them have authoritative zones, one is for testing and two are > just caching servers. And there starts my problem. > 1. It only appears on my caching servers and only if I use my other > servers as forwarders. > 2. At the moment the problem appears on my chaching servers I'm still > able to let it resolve through my forwarders. > 3. Only one organisation with several newspapers are affected. There may > be others but I don't know at the moment. > > Ok, all these newspapers are hosted on oraclecloud with short timers > around 30s. > > # dig www.20min.ch > ;; ANSWER SECTION: > www.20min.ch. 39 IN CNAME > tamedia.a.inregion.waas.oci.oraclecloud.net. > tamedia.a.inregion.waas.oci.oraclecloud.net. 16 IN CNAME > tm.inregion.waas.oci.oraclecloud.net. > tm.inregion.waas.oci.oraclecloud.net. 16 IN CNAME > eu-london.inregion.waas.oci.oraclecloud.net. > eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 138.1.82.213 > eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.234.67 > eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.228.138 > > # dig www.tagesanzeiger.ch > ;; ANSWER SECTION: > www.tagesanzeiger.ch. 113 IN CNAME cnp-a-cre-p.newsnetz.ch. > cnp-a-cre-p.newsnetz.ch. 113IN CNAME > tamedia.a.inregion.waas.oci.oraclecloud.net. > tamedia.a.inregion.waas.oci.oraclecloud.net. 11 IN CNAME > tm.inregion.waas.oci.oraclecloud.net. > tm.inregion.waas.oci.oraclecloud.net. 12 IN CNAME > eu-switzerland.inregion.waas.oci.oraclecloud.net. > eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.59.121 > eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.46 > eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.42 > > > Now if I use my caching servers with forwarders enabled I run quite > often into cases where resolving stops working for theses two domains at > the same time. > When I take a dump I see the following line: > ; answer > tm.inregion.waas.oci.oraclecloud.net. 893 \- ;-$NXRRSET > > I have to clear this host from cache to make it working again, for a few > minutes. > The stupid thing, this NXRRSET cache entry has a much higher lifetime. > And so resolving stops working on my caching servers for more then 15min. > > Any idea how I could find out why this happens? > There must be something between my DNS servers. They are in the same > network, so there is no firewall between. > > Many thanks and regards > Florian > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind 9.11.3 - resolving troubles running as a caching server
Hello list I'm glad there is such an active list. Hope there is anybody out there who can help me with my little problem. :-) We are running six bind server ( all Ubuntu LTS 18.04 with bind 9.11.3 ), so they are pretty up to date. Three of them have authoritative zones, one is for testing and two are just caching servers. And there starts my problem. 1. It only appears on my caching servers and only if I use my other servers as forwarders. 2. At the moment the problem appears on my chaching servers I'm still able to let it resolve through my forwarders. 3. Only one organisation with several newspapers are affected. There may be others but I don't know at the moment. Ok, all these newspapers are hosted on oraclecloud with short timers around 30s. # dig www.20min.ch ;; ANSWER SECTION: www.20min.ch. 39 IN CNAME tamedia.a.inregion.waas.oci.oraclecloud.net. tamedia.a.inregion.waas.oci.oraclecloud.net. 16 IN CNAME tm.inregion.waas.oci.oraclecloud.net. tm.inregion.waas.oci.oraclecloud.net. 16 IN CNAME eu-london.inregion.waas.oci.oraclecloud.net. eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 138.1.82.213 eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.234.67 eu-london.inregion.waas.oci.oraclecloud.net. 28 IN A 147.154.228.138 # dig www.tagesanzeiger.ch ;; ANSWER SECTION: www.tagesanzeiger.ch. 113 IN CNAME cnp-a-cre-p.newsnetz.ch. cnp-a-cre-p.newsnetz.ch. 113 IN CNAME tamedia.a.inregion.waas.oci.oraclecloud.net. tamedia.a.inregion.waas.oci.oraclecloud.net. 11 IN CNAME tm.inregion.waas.oci.oraclecloud.net. tm.inregion.waas.oci.oraclecloud.net. 12 IN CNAME eu-switzerland.inregion.waas.oci.oraclecloud.net. eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.59.121 eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.46 eu-switzerland.inregion.waas.oci.oraclecloud.net. 12 IN A 192.29.58.42 Now if I use my caching servers with forwarders enabled I run quite often into cases where resolving stops working for theses two domains at the same time. When I take a dump I see the following line: ; answer tm.inregion.waas.oci.oraclecloud.net. 893 \- ;-$NXRRSET I have to clear this host from cache to make it working again, for a few minutes. The stupid thing, this NXRRSET cache entry has a much higher lifetime. And so resolving stops working on my caching servers for more then 15min. Any idea how I could find out why this happens? There must be something between my DNS servers. They are in the same network, so there is no firewall between. Many thanks and regards Florian ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Log rolling stopped working in 9.11.12 ?
Am 19.11.19 um 18:23 schrieb John Thurston: A) Should I expect these file permissions be altered by a minor update? I know I started at 9.11.8 and have updated to 9.11.9 and 9.11.10 without seeing this behavior. On 11/19/2019 8:34 AM, Reindl Harald wrote: yes, every by a package owned directory or file has it's permissions in the rpm database and they are ensured everytime a package get updated I am certain I didn't need to reapply those file permissions with my earlier version updates. But if this is the expected behavior with each update, then that experience was an outlier. I will explore relocating my logs to a location not affected by package updates. I see bind 9.11.4 in centos7, where did you pull 9.11.10 from? which is why we don't need to reinstall our Linux boxes all the time when things become messy over the years On 19.11.19 12:16, John Thurston wrote: I find this somewhat humorous I have recently started using linux. I am amazed how often the operating system changes radically, and how short the support windows are . . . when compared to the Solaris environment we are turning off. yes, it depends on what you are replacing. commercial SW distributions have longer period than free. Redhat (commercial) and Centos (redhat-based) have 10-years security support. Debian and Ubuntu have 5-years LTS, Ubuntu provides commercial support for another 3 years (and company freexian tries to provide ELTS for debian for some time) However that does not apply for packages outside of centos. -- Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. Windows found: (R)emove, (E)rase, (D)elete ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
