RCODE: Not Implemented

[Kevin Darcy]

The currently-defined opcodes are: QUERY (0), IQUERY (1), STATUS (2), NOTIFY
(4) and UPDATE (5). Opcode 3 is apparently reserved. See include/arpa/nameser.h
(search in lowercase).

IQUERY and STATUS opcodes are deprecated/obsolete; why do you care?

NOTIFY is (currently) something only sent between masters and slaves; there's
no perceived need to generate them from clients.

Any program that implements Dynamic Update, e.g. the "nsupdate" utility, is
capable of generating a query with an UPDATE opcode.


- Kevin
Mark wrote:

> Thank you.  I was confusing QTYPE( A, NS, MX)  with OPCODE( Standard Query,
> Inverse Query ).
>
> Can you tell me how to change the OPCODE to something other than "Standard
> Query"? I would like to send some inverse queries to my name servers to test
> them. Actually I'm not even sure what OPCODES there are. RFC 1035 ,which is
> ancient by now ,shows OPCODES 3-15 reserved for future use.
>
> Anyway   I don't see anything in the dig man pages about forming different
> "kinds" of queries only different types of RR's inside of standard queries
> which is not what I am looking for.
>
> Regards,
>
> Mark
>
> Jim Reid <jim at rfc1035.com> wrote in message
> news:29363.965839666 at gromit.rfc1035.com...
> > >>>>> "Mark" == Mark  <msanp at earthlink.net> writes:
> >
> >     Mark> When querying my name servers for a resource record type
> >     Mark> that I am sure they don't implement ( SRV, SIG ) named
> >     Mark> ummmm........ works.  That is it tells me that there aren't
> >     Mark> any such records.
> >
> > Er, the output from dig showed that. The answer section of the reply
> > was empty.
> >
> >     Mark> I thought that named would respond with
> >     Mark> the RCODE in the response packet set to "NOT IMPLEMENTED" at
> >     Mark> least for the older name servers.  I get this behavior from
> >     Mark> BIND 4.9.7, 8.1.2 & 8.2.2 name servers.
> >
> > Are you sure about that? Are these servers returning NOTIMP if you ask
> > them for a SIG record? I would expect them to either return NXDOMAIN
> > or NOERROR with an empty answer section. NOTIMP should be returned
> > when the name server doesn't implement the opcode on the lookup. The
> > opcode would denote things like QUERTY, UPDATE, NOTIFY, IQUERY and
> > stuff like that, not the record type for the name that's been looked
> > up. The record type is specified in the query's QTYPE field.
> >
> >     Mark> I notice that nslookup won't even let you
> >     Mark> send such a query if it doesn't recognize the RR type.
> >
> > All the more reason to put a bullet in nslookup...
> >
> >     Mark> when does named reply with "NOT IMPLEMENTED"??
> >
> > See above. Or lines 279-312 of ns_req.c in BIND8.
> >
> >     Mark> $ dig SIG cookie.com
> >
> >     Mark> ; <<>> DiG 8.1 <<>> SIG cookie.com
> >     MarK> ; (1 server found)
> >     Mark> ;; res options: init recurs defnam dnsrch
> >     Mark> ;; got answer:
> >     Mark> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
> >   ^ dig set the opcode to QUERY
> >     (surprise, surprise!)
> >     Mark> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL:
> 2
> >      ^ Look ma! No answers!
> >
> >     Mark> ;; QUERY SECTION:
> >     Mark  ;; cookie.com, type = SIG, class = IN
> >
> > Notice there's no ANSWER SECTION.....
> >
> >     Mark> ;; AUTHORITY SECTION:
> >     Mark> cookie.com.  2D IN NS INTERPAGE.NET.
> >     Mark> cookie.com.  2D IN NS ADMIRAL.INTERPAGE.NET.
> >
> >     Mark> ;; ADDITIONAL SECTION:
> >     Mark> ADMIRAL.INTERPAGE.NET.  2D IN A 204.75.164.2
> >     Mark> INTERPAGE.NET.          2D IN A 204.75.164.1
> >
> >
> >