Bug 1571059

Summary: named[<pid>]: socket.c:2135: unexpected error
Product: [Fedora] Fedora Reporter: Bojan Smojver <bojan>
Component: bindAssignee: Petr Menšík <pemensik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 28CC: mruprich, msehnout, pemensik, pzhukov, thozza, vonsch, zdohnal
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-05-01 21:45:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Bojan Smojver 2018-04-24 03:26:22 UTC
Description of problem:

Getting stuff like this in logs since the upgrade to 9.11.3:
------------------
Apr 23 02:38:04 <host> named[<pid>]: socket.c:2135: unexpected error:
Apr 23 02:38:04 <host> named[<pid>]: internal_send: <client_ip>#60374: Invalid argument
Apr 23 02:38:04 <host> named[<pid>]: client @0x7fec0804f070 <client_ip>#60374 (time-ios.apple.com): view internal: error sending response: invalid file
------------------

There are occasional DNS resolution problems, which go away when the question is attempted again. The client doesn't seem to matter: Linux, OS X, Windows etc.

Version-Release number of selected component (if applicable):
bind-chroot-9.11.3-4.fc27.x86_64

How reproducible:
It comes up from time to time.

Steps to Reproduce:
1. Attempt DNS resolution.
2. Fails, with error in the log.

Actual results:
Unusual errors in DNS logs, resolution fails.

Expected results:
Worked fine with 9.11.2 (no such messages in the log prior to upgrade).

Additional info:
IPv6 is not used on this network, if it matters.

Comment 1 Petr Menšík 2018-04-25 11:19:32 UTC
Thanks for your report. I checked sources a bit and could not find any reason for such messages after 9.11.2. Are names of failed queries random? Could you tell if that errors happen short after or before restarts from logs?

Comment 2 Bojan Smojver 2018-04-25 11:23:37 UTC
The names appear random. I could not see a particular pattern.

It happens at any time, it seems.

Comment 3 Bojan Smojver 2018-04-25 11:31:36 UTC
Maybe some other compounent changed around that time, which caused this. Who knows. Haven't seen similar bug reports with this version of bind, so maybe it's something specific to my setup. First time I'm seeing it though...

Comment 4 Petr Menšík 2018-04-26 10:36:12 UTC
Can you share more about your configuration? named-checkconf -p output would help.

Comment 5 Bojan Smojver 2018-04-26 11:46:25 UTC
Sent privately.

Comment 7 Petr Menšík 2018-04-27 12:07:46 UTC
# Version with domains replaced
controls {
	inet 127.0.0.1 allow {
		127.0.0.1/32;
	} keys {
		"rndckey";
	};
};
logging {
	channel "default_syslog" {
		syslog "daemon";
		severity warning;
	};
	category "default" {
		"default_syslog";
	};
};
options {
	avoid-v4-udp-ports {
		range 0 32767;
		range 61000 65535;
	};
	avoid-v6-udp-ports {
		range 0 32767;
		range 61000 65535;
	};
	directory "/var/named";
	dump-file "/var/named/data/cache_dump.db";
	listen-on {
		127.0.0.1/32;
		10.1.1.1/32;
		10.1.1.2/32;
	};
	managed-keys-directory "/var/named/dynamic";
	memstatistics-file "/var/named/data/named_mem_stats.txt";
	pid-file "/run/named/named.pid";
	statistics-file "/var/named/data/named_stats.txt";
	version none;
	dnssec-enable yes;
	dnssec-validation auto;
	allow-transfer {
		"none";
	};
	allow-update {
		"none";
	};
	key-directory "/etc/pki/dnssec-keys";
};
view "internal" {
	match-clients {
		127.0.0.1/32;
		10.1.1.0/24;
		192.168.8.0/24;
	};
	zone "." IN {
		type hint;
		file "named.ca";
	};
	zone "localhost.localdomain" IN {
		type master;
		file "named.localhost";
		allow-update {
			"none";
		};
	};
	zone "localhost" IN {
		type master;
		file "named.localhost";
		allow-update {
			"none";
		};
	};
	zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa" IN {
		type master;
		file "named.loopback";
		allow-update {
			"none";
		};
	};
	zone "1.0.0.127.in-addr.arpa" IN {
		type master;
		file "named.loopback";
		allow-update {
			"none";
		};
	};
	zone "0.in-addr.arpa" IN {
		type master;
		file "named.empty";
		allow-update {
			"none";
		};
	};
	zone "xy.com" {
		type master;
		file "data/internal/xy.com";
		update-policy {
			grant "dhcpkey" subdomain "xy.com." "A" "TXT";
		};
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "xy.net" {
		type master;
		file "data/internal/xy.net";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "xy.org" {
		type master;
		file "data/internal/xy.org";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "xy.com.au" {
		type master;
		file "data/internal/xy.com.au";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "yz.com" {
		type master;
		file "data/internal/yz.com";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "yz.net" {
		type master;
		file "data/internal/yz.net";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "yz.org" {
		type master;
		file "data/internal/yz.org";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "1.1.10.in-addr.arpa" {
		type master;
		file "data/internal/1.1.10.in-addr.arpa";
		update-policy {
			grant "dhcpkey" subdomain "1.1.10.in-addr.arpa." "PTR";
		};
	};
	zone "8.168.192.in-addr.arpa" {
		type master;
		file "data/internal/8.168.192.in-addr.arpa";
	};
	recursion yes;
};
view "external" {
	match-clients {
		"any";
	};
	zone "xy.com" {
		type master;
		file "data/external/xy.com";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "xy.net" {
		type master;
		file "data/external/xy.net";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "xy.org" {
		type master;
		file "data/external/xy.org";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "xy.com.au" {
		type master;
		file "data/external/xy.com.au";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "yz.com" {
		type master;
		file "data/external/yz.com";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "yz.net" {
		type master;
		file "data/external/yz.net";
		auto-dnssec maintain;
		inline-signing yes;
	};
	zone "yz.org" {
		type master;
		file "data/external/yz.org";
		auto-dnssec maintain;
		inline-signing yes;
	};
	recursion no;
};

Comment 8 Bojan Smojver 2018-05-01 21:45:55 UTC
I have seen this just once in the last week or so, after I gave --transparent option to -m socket for the squid that's running in TPROXY mode on the same machine. No idea whether it's somehow related or maybe something else changed that made it better.

So, I'm going to close this for now. If it reappears, I'll reopen.