[ERR] mdns: support for DNS requests with high truncated bit

Error message

[ERR] mdns: support for DNS requests with high truncated bit not implemented: %v

What it means

When a query has the TC (truncation) bit set, the sender indicates more Known-Answer records will follow and the responder should wait before answering. This implementation does not support that; it returns an error instead of partially handling the truncated message.

Source

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

		// 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...)
		unicastAnswer = append(unicastAnswer, urecs...)
	}

	// See section 18 of RFC 6762 for rules about DNS headers.
	resp := func(unicast bool) *dns.Msg {
		// 18.1: ID (Query Identifier)
		// 0 for multicast response, query.Id for unicast response
		id := uint16(0)
		if unicast {
			id = query.Id

View on GitHub (pinned to 24529f1404)

Solutions

Reduce the number of questions/known-answers per query on the client side
Await follow-up packets — but note this server won't aggregate them; send separate smaller queries instead
Upgrade or patch the mDNS implementation to buffer truncated queries

Defensive patterns

Strategy: fallback

Try / catch

if err := srv.handleQuery(query, from); err != nil {
    if strings.Contains(err.Error(), "truncated bit not implemented") {
        // wait briefly for follow-up packets, or drop; do not fail the server
        log.Debugf("dropped truncated query from %v", from)
        return nil
    }
    return err
}

Prevention

Keep mDNS queries small (few questions/known-answers per packet)
Avoid clients that emit oversized multi-packet queries on this network
Track upstream support for TC-bit aggregation before relying on large queries

When it happens

Trigger: parsePacket receiving a query larger than one packet with query.Truncated == true, typically when a client packs many questions/known-answers exceeding the UDP payload.

Common situations: Clients with very large service lists issuing oversized mDNS queries; networks with small MTU forcing truncation; other mDNS implementations with large known-answer lists.

Related errors

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