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

Treat as ignorable per RFC 6762 and skip the packet

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

Error message

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

What it means

mDNS messages must carry Rcode zero (NOERROR) on both queries and responses; non-zero response codes must be silently ignored per RFC 6762. handleQuery returns this error when a received query has a non-zero Rcode field.

Source

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

	// 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)
	}

	var unicastAnswer, multicastAnswer []dns.RR

	// Handle each question
	for _, q := range query.Question {
		mrecs, urecs := s.handleQuestion(q)
		multicastAnswer = append(multicastAnswer, mrecs...)

View on GitHub (pinned to 24529f1404)

Solutions

Treat as ignorable per RFC 6762 and skip the packet
Log and inspect the included packet dump to identify the sender
Segment the network or filter multicast traffic from non-mDNS sources

Defensive patterns

Strategy: try-catch

Try / catch

if err := srv.handleQuery(query, from); err != nil {
    if strings.Contains(err.Error(), "non-zero Rcode") {
        log.Debugf("ignoring query with Rcode!=0 from %v", from)
        return nil
    }
    return err
}

Prevention

Ignore per RFC 6762 rather than crashing the packet loop
Capture the packet dump included in the error to trace the source host
Filter multicast traffic from non-mDNS clients on shared networks

When it happens

Trigger: parsePacket delivering a query packet whose dns.Msg Rcode is non-zero (e.g. FormErr/NotImp encoded by a broken sender).

Common situations: Malformed or hostile packets on the local network; non-mDNS clients sending error-flagged DNS messages to the multicast address.

Related errors

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