"net.c:577: sendmsg() failed: Operation not permitted" in dig Output

Question

I am running Bind 9.10.2 version on CentOS 6.6 machine. While running the dig command, i am getting "net.c:577: sendmsg() failed: Operation not permitted" notification.

dig utility is giving me an answer but on the top, it shows this notification.

$dig nkn.in +short   
**net.c:577: sendmsg() failed: Operation not permitted**  
164.100.129.98

System Information :-  
cat /etc/*-release   
CentOS release 6.6 (Final)   
LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch    
CentOS release 6.6 (Final)   
CentOS release 6.6 (Final)

Can some one please help me out why i am getting this notification?

IPv6 firewall rules sets:-

*filter  
:INPUT DROP [0:0]  
:FORWARD DROP [0:0]  
:OUTPUT DROP [0:0]  
:LOGGING - [0:0]  
-A INPUT -i lo -j ACCEPT  
-A INPUT -p icmpv6 -j ACCEPT   
-A INPUT -p udp --dport 5353 -d ff02::fb -j ACCEPT  
-A INPUT -p udp -m udp --dport 631 -j ACCEPT  
-A INPUT -p tcp -m tcp --dport 631 -j ACCEPT  
-A INPUT -p udp -m udp --dport 53 -j ACCEPT  
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT  
-A OUTPUT -p icmpv6 --icmpv6-type echo-reply -j ACCEPT  
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT  
-A INPUT -m udp -p udp --sport 1812 -j ACCEPT  
-A INPUT -m udp -p udp --sport 1813 -j ACCEPT 
-A INPUT -s fe80::/64 -j ACCEPT  
-A INPUT -s ff02::/64 -j ACCEPT  
-A INPUT -j LOG --log-prefix "IP6Tables:INPUT " --log-level 7  
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT  
-A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT  
-A OUTPUT -p icmpv6 -j ACCEPT  
-A OUTPUT -p icmpv6 --icmpv6-type echo-request -j ACCEPT  
-A OUTPUT -m state --state RELATED,ESTABLISHED -j ACCEPT  
-A OUTPUT -d 2001:db8::/32 -j ACCEPT  
-A OUTPUT -d fe80::/64 -j ACCEPT  
-A OUTPUT -d ff02::/64 -j ACCEPT  
-A OUTPUT -j LOG --log-prefix "IP6Tables:OUTPUT " --log-level 7  
-A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IP6Tables-Dropped: "  
-A LOGGING -j DROP  
COMMIT  

Solution 1

In my arch linux it helped adding an ip6tables firewall rule to allow sending local udp packets from localhost to localhost:

ip6tables -I OUTPUT 1 -p udp -s 0000:0000:0000:0000:0000:0000:0000:0001 \ 
-d 0000:0000:0000:0000:0000:0000:0000:0001 -j ACCEPT

Solution 2

Have you tried to reach that destination with any other protocol? Like ICMP?

This error might indicate that you have no rights to do that action, or either blocked by a firewall rule.

Comments

[Gaurav Kansal]

@JennyD... Its a dns server.. And having entry like 'nameserver 127.0.0.1' and i am able to resolve the domains.

[Gaurav Kansal]

@kayess... My firewall rule set is updated in question section. Pl help me out what wrong in that.

[basos]

You can try running the same command as root. If that fails, you can try to temporarily disable the iptables firewall, if any and try again.

[Jenny D]

@basos Disabling the firewally is not a good troubleshooting practice. The right thing would be to look at the firewall logs to see whether anything does get caught in it.

[kasperd]

I believe this answer is onto something. I have seen that error message being produced when a process try to send a UDP packet, which is being blocked by an iptables rule in the OUTPUT chain.

[kayess]

It could also be the chains default policy.

[Gaurav Kansal]

@basos.... Ya i had tried from root also.. But same issue.... After disabling ipv6 firewall, i am not getting dis notification.

[Gaurav Kansal]

@JennyD I had enabled drop logs in ipv6 firewall.... But didn't get any usefull info.

[basos]

@JennyD of course it is safer to examine the logs, provided that you have configured them. In any case, when someone disables the firewall for any reason, the host is exposed to various threats. Having said that, for some environments, it might be an acceptable QnD troubleshooting choice, for some seconds.

[basos]

@kansal, can you explain what do you mean by "dis notification" ?

[Gaurav Kansal]

@basos .. Means i am nt getting notification msgs ( net.c:577 sendmsg() failed: )after disabling v6 firewall. My ipv6 firewall rule sets are also updated in my question section.

[kayess]

@kansal reviewing your updated question one thing popped out of my mind, that is, your firewall rules are built for IPv6 (assuming ip6tables here) and the i suppose your outgoing interface uses IPv6. Have you tried adding -6 argument to dig? Also in case the DNS server listens on IPv4, mind setting up IPv4 rules as well.

[basos]

@kayess, for the ipv4 firewall rules, I think that the protocol related rules (--dport 53) are sufficient for both ipv4 & ipv6.

[basos]

@kansal, despite that from your ruleset the UDP request to port 53 should be accepted, try to add explicit, stateless rules for the UDP replies. e.g. -A INPUT -p udp -m udp --sport 53 -j ACCEPT -A INPUT -p tcp -m tcp --sport 53 -j ACCEPT

[kayess]

@basos werent you want to write --dport? I think source port for incoming connection would be the remotes source port, the destination is you.

[basos]

@kayess, nope, this rule allows replies to queries sent from us (OUTPUT, dest port 53) from the remote ( INPUT source port 53) back to us, Also kansal please do not use the second rule (INPUT -p tcp ...) as tcp state is properly handled.

[Gaurav Kansal]

Any idea why IP6tables was generating an alert without the above rule ?

[Alexis Wilke]

@GauravKansal, when you retrieve an IP address with a function such as getaddrinfo(), you get a list of possibilities and when IPv6 is turned on, that's included in the response and they make it first now. That means tools like dig and host will first try with the IPv6 address, next it will try with IPv4.