[dns-operations] Intermittent failure on slave zone

[Kristian Vilmann]

On 3/1/22 14:43, Phil Regnauld wrote:
> Hi Kristian,
>
> Comments inline. This may be a better topic for the bind-users, but
> let's see.
True ...
>
> Kristian Vilmann (kristian.vilmann) writes:
>> The setup:
>>
>> Master server (Hidden,internal zones) 10.100.10.7
>>       |
>>       |
>> Secondary (recursor, cache, Internal zones) 10.100.10.32
>>       |
>>       |
>> Cache 10.100.10.34
>>       |
>>       |
>> Internet
>>
>> Only the secondary is known by the servers.
>      Ok - personnaly I would have left the "secondary" as pure resolver,
>      and have some forward/stub zones pointing to the hidden SOA (which
>      allows you to substitude BIND with somethinge else for the recursive).

Actually I just configured that. It seems to work, but let's see as what 
happens over time.

>      Ok, so you probably haven't had the time to strace...
No :)
>> Often I see subsequent queries for influx.int.myzone.eu.myzone.eu. That
>> makes sense, but I cannot figure out why it fails in the first place. I see
>> nothing in the logs. It happens also when the secondary server is almost
>> idle, so I doubt it has anything to do with load.
>      Are you seeing actual queries in the log for "myzone.eu.myzone.eu" ?

Yes. And this morning I just did a tcpdump also. The picture is the 
same. A client ask for a host name and then immediately after it asks 
for the same hostname with one of the search domains appended.

2022-03-01 10:32:28.122803 10.100.30.31    10.100.10.32    DNS     
Standard query 0xc6b1 A influx.int.myzone.eu    81
2022-03-01 10:32:28.122873      10.100.10.32    10.100.30.31 DNS     
Standard query response 0xc6b1 A influx.int.myzone.eu A 10.2.98.1       97
2022-03-01 10:32:29.209988      10.100.30.31    10.100.10.32 DNS     
Standard query 0xe765 A influx.int.myzone.eu.myzone.org 93
2022-03-01 10:32:29.210065      10.100.10.32    10.100.30.31 DNS     
Standard query response 0xe765 No such name A 
influx.int.myzone.eu.myzone.org SOA ns.myzone.org 165

10.100.10.31 is the client. 10.100.10.32 is the secondary nameserver.

I'm getting to a point where I think it might be an issue with bind.

>> As far as I can see, requests to the internal zones are not cached. It makes
>> sense since the secondary server has the zone in memory already.
>      Correct, the resolver module won't be active for authoritative zones.
>      It's not recommended to mix auth and recursive service on the same system
>      (although for an internal setup it makes sense, even id I'd put those zones
>      behind a stub/forwarded statement instead).
That makes sense. I'll let it run as a resolver with forwarding until 
tomorrow. Hoping for some magic to happen :)
>      -- I'm assuming 'myzone.eu' isn't the real zone name ?

You're right. But compliance people seems to like that internal network 
names are not exposed ...

/kristian