8

I'm wondering about why would that be. It's even stranger if you simply "dig +short" the record - you get the response, but clients can't make use of that. I've had a quick look at the RFC, but I was unable to find the reason for this behaviour.

Example:

... opcode: QUERY, status: REFUSED ...

;; QUESTION SECTION:
blah.blah IN A

;; ANSWER SECTION:
blah.blah 19343 IN A 1.1.1.1

dig +short blah.blah just plainly returns 1.1.1.1
Celada
  • 44,132
iangelov
  • 81
  • 1
    I believe that's definately odd. It could be a broken DNS server or a DNS firewall rewriting status codes? Please provide more information about DNS server software and the network path between the DNS client and DNS server. If possible, perform this query directly on the DNS server itself with dig @127.0.0.1 (or whatever IP address it is listening on). – Celada Aug 14 '15 at 19:56
  • glue records, maybe?? – Jeff Schaller Aug 14 '15 at 19:57
  • Yes, these records are not from an authoritative server - they come from a local dns proxy which I've configured locally to not resolve certain domain names (although I expected these queries to be refused without actually resolving the record). I'm wondering how does client-side DNS lib deal with this oddity, though. – iangelov Aug 14 '15 at 20:36

1 Answers1

4

The meaning of the REFUSED status is, according to RFC 1035:

The name server refuses to perform the specified operation for policy reasons.

So using that status code and returning an answer to the query does not make sense. How a particular client software will react to this nonsensical answer is not defined in the RFCs, and will quite likely vary from implementation to implementation.

Calle Dybedahl
  • 534