bind 9.11.3 - resolving troubles running as a caching server

[Bind Mailinglist]

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 AAAA answer. Does it matter if I query A or AAAA 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 AAAA 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 <bindbandbund at ggaweb.ch> 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. 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 \-AAAA ;-$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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20191120/fb42105a/attachment.htm>