Subject: status opcode

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 25 Oct 2001 23:14:40 -0500

RFC 1034 specs opcode 2 as "status" but doesn't define it. I've been
thinking about some ways to use it for a couple of years, but recent
events have made me look at this more closely. On the one hand, I recently
did some DNS clean-up work for a large installation that was horribly
broken, and this would have really helped. Second, I'm thinking that
misconfigs from typos will become more frequent if a particular encoding
mechanisms ends up getting deployed.

So, I'd like to propose that this WG pick up as a work item some way of
standardizing "status" as a way to analyze zone data. EG, see what other
servers are being replicated with, the current version of the zone on the
queried server, the status of the NS entries for that zone, or just in
general, how misconfigured is that zone on that server.

To get this started, I've put together a draft of some POSSIBLE mechanisms
at http://www.ehsco.com/misc/draft-hall-status-opcode-00-1.txt  Many of
these mechanisms SHOULD NOT be included in any final version, and are only
presented to incite thought. Other mechanisms which SHOULD be there cannot
be installed without a new RR (replication servers, for example, which may
be configured by name OR address).

Anyway, is there any interest in this?

Thanks

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Ólafur Gudmundsson/DNSEXT co-chair <[email-masked]>
Date: Fri, 26 Oct 2001 10:20:03 -0400

>Anyway, is there any interest in this?

Procedure :
1 Write a draft,
2 Submit the draft as individual submission,
3 start a thread on namedroppers,
4 ask chair to admit document.

you have completed steps 1, 3 and 4.  you skipped step 2.

Temporary Answer to 4:
WG will decide after next IETF if this work is of interest to be
adopted.

On first read this my impression is that this is a interesting idea,
is one of few possible ways to monitor DNS servers and this should be
looked at in that context.
Security considerations section contains many MAY and MUST all these
should be in a separate section called "status message access control"

Old timers: Why was status never defined ?

         Olafur

---

From: Roy Arends <[email-masked]>
Date: Fri, 26 Oct 2001 16:29:15 +0200 (CEST)

> Anyway, is there any interest in this?

The config of a specific server for a specific zone is brand-dependant. To
specify optional configuration data in a status-response has some
inter-operable issues.

The server config should be of interest to the operator, who already has
some way of administering the server and zones.

Next to that, the status of specific zones on their respective servers can
currently be retrieved by analysing the aa, ra and ad bits together with
the RCODE and the sections data.

Also, how do the different server brands right now treat an incoming
status opcode.  I did a small survey recently, and it seems that some
server brands completely ignore the status OPCODE field (treating it as
though it was a QUERY opcode), others blackhole it, and some return a
FORMERR/SERVFAIL/NOTIMP RCODE. (I guess the proper way to respond to a
status opcode currently is with a NOTIMP rcode).

My .02 Euro

Roy Arends
Nominum

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 26 Oct 2001 09:53:01 -0500

Roy Arends wrote:

> The config of a specific server for a specific zone is brand-dependant.

Yes, very much so, which is why I used Text in the sketch.

>From the perspective of retrieving the status of a zone, there are lots of
important details which may be affecting operation. The most obvious ones
are the replication and/or forwarding servers for a zone, although there
isn't a good RR for that data at the moment (data can be FQDN, RDN, or IP
address). And really, there are a bunch of vendor-specific buttons and
knobs which can affect the processing of a query, such as permissions.

The only way to grab all of that data is to stuff it into TXT as a blob.

Personally, I don't think that all of the data is needed. TXT is used as a
way to grab it all, but I don't believe that is the way to go. I would
rather limit it to specific data using specific RRs, but which RRs those
should be is unclear at the moment. Nominations welcome.

> To specify optional configuration data in a status-response has some
> inter-operable issues.

Interoperability of TXT RR data wasn't an objective. It's just for human
consumption of ~all relevant config data for that zone.

> Next to that, the status of specific zones on their respective servers
> can currently be retrieved by analysing the aa, ra and ad bits together
> with the RCODE and the sections data.

Yeah, among other bits.

The problem is that isn't always easy. EG, the one server on the other
side of the empire that isn't picking up changes, and which you need to
find somebody at the remote office with a login in order to determine that
the list of replicating servers is misconfigured.

> I did a small survey recently, and it seems that some server brands
> completely ignore the status OPCODE field (treating it as though it
> was a QUERY opcode), others blackhole it, and some return a

I had also assumed that NOTIMP would be the proper response. Perhaps some
of the other responses indicate private extensions.