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 <domain> @<forwarder>)“;
sleep 1; done
Ondrej
--
Ondřej Surý
ond...@isc.org
> On 21 Nov 2019, at 01:09, Bind Mailinglist <bindbandb...@ggaweb.ch> 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 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 <bindbandb...@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@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
_______________________________________________
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
