[dns-operations] Intermittent failure on slave zone
kristian.vilmann at agillic.com
Tue Mar 1 14:00:07 UTC 2022
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.
> 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
>> 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...
>> 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 ...
More information about the dns-operations