What causes "cannot use IP address as DNS input" in projectdiscovery/nuclei?

Use a hostname as the target when the template queries non-PTR record types

cannot use IP address as DNS input

Error message

cannot use IP address as DNS input

What it means

Thrown by parseDNSInput in the DNS protocol when the target input is an IP literal but the DNS question type is not PTR. Nuclei only accepts IP inputs for PTR (reverse) queries, where it converts the address to an in-addr.arpa/ip6.arpa name via dns.ReverseAddr; every other question type (A, AAAA, CNAME, NS, MX, TXT, SOA) needs a hostname, since asking a resolver for an A record of '1.2.3.4' is meaningless.

Source

Thrown at pkg/protocols/dns/request.go:226

		dumpTraceData(event, request.options, traceToString(traceData, true), question)
	}

	callback(event)
	return err
}

func (request *Request) parseDNSInput(host string) (string, error) {
	isIP := iputil.IsIP(host)
	switch {
	case request.question == dns.TypePTR && isIP:
		var err error
		host, err = dns.ReverseAddr(host)
		if err != nil {
			return "", err
		}
	default:
		if isIP {
			return "", errors.New("cannot use IP address as DNS input")
		}
		host = dns.Fqdn(host)
	}
	return host, nil
}

func dumpResponse(event *output.InternalWrappedEvent, request *Request, _ *protocols.ExecutorOptions, response, domain string) {
	cliOptions := request.options.Options
	if cliOptions.Debug || cliOptions.DebugResponse || cliOptions.StoreResponse {
		hexDump := false
		if responsehighlighter.HasBinaryContent(response) {
			hexDump = true
			response = hex.Dump([]byte(response))
		}
		highlightedResponse := responsehighlighter.Highlight(event.OperatorsResult, response, cliOptions.NoColor, hexDump)
		msg := fmt.Sprintf("[%s] Dumped DNS response for %s\n\n%s", request.options.TemplateID, domain, highlightedResponse)
		if cliOptions.Debug || cliOptions.DebugResponse {
			gologger.Debug().Msg(msg)

View on GitHub (pinned to 265b3a3dec)

Solutions

Use a hostname as the target when the template queries non-PTR record types
Switch the template to `type: PTR` when you must feed IP inputs (nuclei then builds the reverse name automatically)
Pre-filter IP literals out of the target list: grep -vE '^[0-9.]+$|^[0-9a-fA-F:]+$' targets.txt
In workflows, split inputs so IPs go to a PTR template and hostnames go to forward-query templates

Example fix

# before
requests:
  - - type: A
# run: echo 192.168.1.1 | nuclei -t tpl.yaml  -> error

# after
requests:
  - - type: PTR
# run: echo 192.168.1.1 | nuclei -t tpl.yaml  -> reverse lookup

Defensive patterns

Strategy: validation

Validate before calling

import "github.com/projectdiscovery/utils/ip"

func usableForDNS(input string, isPTR bool) bool {
	if ip.IsIP(input) {
		return isPTR // only PTR questions accept IP inputs
	}
	return true
}

Prevention

Keep separate target lists for IP ranges vs hostnames and match them to the right DNS templates
Before scanning, filter IP literals out of inputs destined for forward-DNS templates
In workflows, branch on iputil.IsIP and route IPs to a `type: PTR` template

When it happens

Trigger: Running a DNS template whose requests block has `type: A` (or any non-PTR type) against an IP target, e.g. `echo 192.168.1.1 | nuclei -t dns-template.yaml`. Feeding a mixed list of hostnames and IPs to a DNS workflow without routing IPs to a PTR-only template.

Common situations: Scanning CIDR ranges or IP lists with DNS templates copied from hostname-oriented templates; forgetting that reverse lookups need `type: PTR`; input lists produced by subdomain-to-IP resolution pipelines.

Related errors

AI-assisted analysis of projectdiscovery/nuclei@265b3a3dec (2026-08-15). Data as JSON: /api/errors/d22774add00ccd2e. Report an issue: GitHub.