What causes "mdns: received query with non-zero Opcode %v: %v" in micro/go-micro?

Ignore/drop the packet — this is expected behavior for non-standard opcodes per RFC 6762

mdns: received query with non-zero Opcode %v: %v

Error message

mdns: received query with non-zero Opcode %v: %v

What it means

Per RFC 6762, mDNS query messages must have Opcode zero (standard queries only). handleQuery rejects any received query whose Opcode differs from dns.OpcodeQuery. Although framed as an error, the RFC says such packets should be silently ignored, so callers typically treat this as a drop condition.

Source

Thrown at internal/util/mdns/server.go:226

	if err := msg.Unpack(packet); err != nil {
		log.Errorf("[ERR] mdns: Failed to unpack packet: %v", err)
		return err
	}
	// TODO: This is a bit of a hack
	// We decided to ignore some mDNS answers for the time being
	// See: https://tools.ietf.org/html/rfc6762#section-7.2
	msg.Truncated = false
	return s.handleQuery(&msg, from)
}

// handleQuery is used to handle an incoming query.
func (s *Server) handleQuery(query *dns.Msg, from net.Addr) error {
	if query.Opcode != dns.OpcodeQuery {
		// "In both multicast query and multicast response messages, the OPCODE MUST
		// be zero on transmission (only standard queries are currently supported
		// over multicast).  Multicast DNS messages received with an OPCODE other
		// than zero MUST be silently ignored."  Note: OpcodeQuery == 0
		return fmt.Errorf("mdns: received query with non-zero Opcode %v: %v", query.Opcode, *query)
	}
	if query.Rcode != 0 {
		// "In both multicast query and multicast response messages, the Response
		// Code MUST be zero on transmission.  Multicast DNS messages received with
		// non-zero Response Codes MUST be silently ignored."
		return fmt.Errorf("mdns: received query with non-zero Rcode %v: %v", query.Rcode, *query)
	}

	// TODO(reddaly): Handle "TC (Truncated) Bit":
	//    In query messages, if the TC bit is set, it means that additional
	//    Known-Answer records may be following shortly.  A responder SHOULD
	//    record this fact, and wait for those additional Known-Answer records,
	//    before deciding whether to respond.  If the TC bit is clear, it means
	//    that the querying host has no additional Known Answers.
	if query.Truncated {
		return fmt.Errorf("[ERR] mdns: support for DNS requests with high truncated bit not implemented: %v", *query)
	}

View on GitHub (pinned to 24529f1404)

Solutions

Ignore/drop the packet — this is expected behavior for non-standard opcodes per RFC 6762
Identify the offending sender from the log (packet content is included) and reconfigure it
Ensure your network segment isn't mixing unicast DNS traffic into the mDNS multicast group

Defensive patterns

Strategy: try-catch

Try / catch

if err := srv.handleQuery(query, from); err != nil {
    if strings.Contains(err.Error(), "non-zero Opcode") {
        // RFC 6762: silently ignore — log at debug and continue serving
        log.Debugf("ignoring non-mDNS opcode from %v", from)
        return nil
    }
    return err
}

Prevention

Treat this error as a packet-drop signal, not a fatal condition
Keep mDNS traffic isolated from legacy unicast DNS traffic
Log the sender address so misbehaving devices can be identified

When it happens

Trigger: parsePacket receiving a DNS query packet over multicast with Opcode != 0 (e.g. reverse-lookup/iquery opcodes from non-mDNS DNS traffic).

Common situations: Non-mDNS DNS traffic leaking onto the multicast group; misconfigured devices sending legacy DNS queries to 224.0.0.251:5353.

Related errors

AI-assisted analysis of micro/go-micro@24529f1404 (2026-09-01). Data as JSON: /api/errors/f7edff067f47f0a6. Report an issue: GitHub.