Subject: EDNS0 revisions

From: Paul Vixie <[email-masked]>
Date: Fri, 21 Dec 2007 14:42:24 +0000

i propose to revise RFC 2671 as follows:

1. remove extended label type.  (this "didn't work" inasmuch as it tries to
   provide an end-to-end feature using a hop-by-hop signalling method.  it
   should have been punted into EDNS1 along with RRD and the others.)

2. treatment of an unrecognized OPTION-CODE shall be the same as treatment
   of a non-zero "Z" field, which is, to ignore it.  (we ought not have to
   increment VERSION when allocating new OPTION-CODE values.)

3. change 5.3 as follows.  old:

   5.3. Responders who do not understand these protocol extensions are
        expected to send a response with RCODE NOTIMPL, FORMERR, or
        SERVFAIL.  ...

   new:

   5.3. Responders who do not understand these protocol extensions are
        expected to send a response with RCODE NOTIMPL, FORMERR, or
        SERVFAIL, or to appear to "time out" due to inappropriate action
        by a "middle box" such as a NAT.  ...

   old:

             ... Therefore use of extensions should be "probed" such that
        a responder who isn't known to support them be allowed a retry with
        no extensions if it responds with such an RCODE.  ...

   new:

             ... Therefore use of extensions should be "probed" such that
        a responder who isn't known to support them be allowed a retry with
        no extensions if it responds with such an RCODE, or does not respond.
        ...

4. a response should only contain an OPT RR if the request contained one.

while #3 above reflects implementation experience, it was foreseeable and
thus qualifies as an editorial error on my part in the original draft.  #1,
#2, and #4 are just editorial errors.

is there controversy around any of these, or, are there other things also
in need of clarification or correction from RFC 2671?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Florian Weimer <[email-masked]>
Date: Fri, 21 Dec 2007 17:37:09 +0100

> #2, and #4 are just editorial errors.

Is it likely that change #2 runs into the same problem as described
under #3?  In that case, probing might be infeasible due to
combinatorial explosion.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 21 Dec 2007 17:05:04 +0000

> Is it likely that change #2 runs into the same problem as described under
> #3?  In that case, probing might be infeasible due to combinatorial
> explosion.

i don't think we should word it that way.  if someone response SERVFAIL or
NOTIMP then we don't need to care whether it's because of an unrecognized
OPTION-CODE or because they don't understand EDNS at all.  either way we'd
fall back to non-EDNS.

---

From: Mark Andrews <[email-masked]>
Date: Sat, 22 Dec 2007 09:13:37 +1100

>         no extensions if it responds with such an RCODE, or does not respond.

	I think formalising the reaction to timeout for EDNS failues
	to fall back to plain DNS is wrong.  As dependany of EDNS
	increases (e.g. DNSSEC) it is much more important that
	packet loss is treated as packet loss and not broken servers
	/ middle boxes.

	Fallback to EDNS udpsize=512 maybe but not plain DNS on timeout.
	This will interoperate with firewalls that enforce a 512 byte
	packet size and not loose EDNS signaling which is required
	for DNSSEC.

	Yes there are some load balancers that do the wrong thing and
	drop queries but they are NOT RFC 103[45] compliant if they
	do that.  Codifing such non-compliance is wrong.

	Should we codify non response to non A queries as right? 
	Should we codify NXDOMAIN responses to unknow qtypes as right?
	Should we codify returning the wrong SOA record as right for
	negative responses?

	Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Fri, 21 Dec 2007 23:24:14 +0000

[marka]
> I think formalising the reaction to timeout for EDNS failues to fall back to
> plain DNS is wrong.  As dependany of EDNS increases (e.g. DNSSEC) it is much
> more important that packet loss is treated as packet loss and not broken
> servers / middle boxes.

since many members of the wider community feel that DNSSEC is a fool's errand,
i suggest that we concentrate on less controversial motivations for EDNS0, of
which there are plenty.

> Fallback to EDNS udpsize=512 maybe but not plain DNS on timeout.  This will
> interoperate with firewalls that enforce a 512 byte packet size and not
> loose EDNS signaling which is required for DNSSEC.

first, those firewalls are broken.  just as broken as NAT boxes which rewrite
DNS packets in flight.  second, i cannot see any benefit to an additional
fallback state (full EDNS, old DNS).  we don't need one for "bufsize=512" and
we don't need one for "only use OPTION-CODEs that existed as of RFC2671".  if
full EDNS doesn't work, then fall back all the way to old DNS.  no new states.

> Yes there are some load balancers that do the wrong thing and drop queries
> but they are NOT RFC 103[45] compliant if they do that.  Codifing such
> non-compliance is wrong.
> 

all of those things remain wrong.  but RFC2671bis' job is not to right any
wrongs, nor codify some wrongs.  all we want is greater interoperability, of
the form, "if you do things a little differently, it'll work a little better."

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 Dec 2007 00:05:33 +0000

ok, here's where it sits.  olafur asked that i modernize the document
according to RFC 2119, which i have done.  i then did battle with a cgi
python script at "datatracker.ietf.org" for a while, and ultimately
found out which part of my old postel-era nroff template needed to be
tweaked, and did that.  i was able to deduce that "creation date" needs
a day of month now, not just a month and year.  finally the tool said:

    An email with a submmiter verification key and URL has been sent to the
    submitter. However, verification has not yet been received. Upon receipt
    of verification (clicking the link in the email), this status page will be
    shown with updated status information.

my maillog, however, is filled with evidence for a contrary outcome:

Dec 27 21:19:01 sa postfix/smtpd[32246]: NOQUEUE: reject: RCPT from
    unknown[2001:698:9:31:214:22ff:fe21:bb]: 550 5.7.1 Client host rejected:
    cannot find your hostname, [2001:698:9:31:214:22ff:fe21:bb]; from=<>
    to=<[email-masked]> proto=SMTP helo=<merlot.tools.ietf.org>

so, i guess there is no PTR RR, in the absence of which the verification
e-mail won't be arriving here.  (if i allow PTR-free sources to reach my
SMTP server i get even more spam than already, so, that's not happening.)

to keep the ball rolling, here's the text that i put into the system, which
has apparently passed the syntax checking rules, and was approved by olafur,
but which i cannot submit because of lack of "author verification", because
of a lack of a PTR RR for the IETF's outbound IPv6 SMTP transport agent.

   DNSEXT Working Group                                Paul Vixie, ISC
   INTERNET-DRAFT <draft-ietf-dnsext-rfc2671bis-edns0-00.txt>
   December 27, 2007

                Revised extension mechanisms for DNS (EDNS0)

   Status of this Memo
      By submitting this Internet-Draft, each author represents that any
      applicable patent or other IPR claims of which he or she is aware
      have been or will be disclosed, and any of which he or she becomes
      aware will be disclosed, in accordance with Section 6 of BCP 79.

      Internet-Drafts are working documents of the Internet Engineering
      Task Force (IETF), its areas, and its working groups.  Note that
      other groups may also distribute working documents as Internet-
      Drafts.

      Internet-Drafts are draft documents valid for a maximum of six
      months and may be updated, replaced, or obsoleted by other
      documents at any time.  It is inappropriate to use Internet-Drafts
      as reference material or to cite them other than as "work in
      progress."

      The list of current Internet-Drafts can be accessed at
      http://www.ietf.org/ietf/1id-abstracts.txt

      The list of Internet-Draft Shadow Directories can be accessed at
      http://www.ietf.org/shadow.html.

   Copyright Notice
      Copyright (C) The IETF Trust (2007).

   Abstract
      The Domain Name System's wire protocol includes a number of fixed
      fields whose range has been or soon will be exhausted and does not
      allow clients to advertise their capabilities to servers.  This
      document describes backward compatible mechanisms for allowing the
      protocol to grow.

   Expires May 27, 2008                                          [Page 1]

   INTERNET-DRAFT                   EDNS0               December 27, 2007

   1 - Introduction

   1.1. DNS (see [RFC1035]) specifies a Message Format and within such
   messages there are standard formats for encoding options, errors, and
   name compression.  The maximum allowable size of a DNS Message is
   fixed.  Many of DNS's protocol limits are too small for uses which are
   or which are desired to become common.  There is no way for
   implementations to advertise their capabilities.

   1.2. Unextended agents will not know how to interpret the protocol
   extensions detailed here.  In practice, these clients will be upgraded
   when they have need of a new feature, and only new features will make
   use of the extensions.  Extended agents must be prepared for behaviour
   of unextended clients in the face of new protocol elements, and fall
   back gracefully to unextended DNS.

   1.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC 2119
   [RFC2119].

   2 - Affected Protocol Elements

   2.1. The DNS Message Header's (see [RFC1035 4.1.1]) second full 16-bit
   word is divided into a 4-bit OPCODE, a 4-bit RCODE, and a number of
   1-bit flags.  The original reserved Z bits have been allocated to
   various purposes, and most of the RCODE values are now in use.  More
   flags and more possible RCODEs are needed.

   2.2. The first two bits of a wire format domain label are used to
   denote the type of the label.  [RFC1035 4.1.4] allocates two of the
   four possible types and reserves the other two.  Proposals for use of
   the remaining types far outnumber those available.  More label types
   were needed, and an extension mechanism was proposed in RFC 2671
   [RFC2671 Section 3].

   2.3. DNS Messages are limited to 512 octets in size when sent over
   UDP.  While the minimum maximum reassembly buffer size still allows a
   limit of 512 octets of UDP payload, most of the hosts now connected to
   the Internet are able to reassemble larger datagrams.  Some mechanism
   must be created to allow requestors to advertise larger buffer sizes
   to responders.

   Expires May 27, 2008                                          [Page 2]

   INTERNET-DRAFT                   EDNS0               December 27, 2007

   3 - Extended Label Types

   [RFC2671 Section 3] reserved label type "0 1" to indicate that an
   extended label type followed in the next octet, but gave inadequate
   guidance as to how EDNS, as a hop-by-hop signalling method, could be
   used to carry a new kind of DNS label.  Extended label types might be
   addressed in a future specification, perhaps requiring that the EDNS
   VERSION be incremented.

   4 - OPT pseudo-RR

   4.1. One OPT pseudo-RR (RR type 41) MAY be added to the additional
   data section of a request, and to responses to such requests.  An OPT
   is called a pseudo-RR because it pertains to a particular transport
   level message and not to any actual DNS data.  OPT RRs MUST NOT be
   cached, forwarded, or stored in or loaded from master files.  The
   quantity of OPT pseudo-RRs per message MUST be either zero or one, but
   not greater.

   4.2. An OPT RR has a fixed part and a variable set of options
   expressed as {attribute, value} pairs.  The fixed part holds some DNS
   meta data and also a small collection of new protocol elements which
   we expect to be so popular that it would be a waste of wire space to
   encode them as {attribute, value} pairs.

   4.3. The fixed part of an OPT RR is structured as follows:

   Field Name   Field Type     Description
   ------------------------------------------------------
   NAME         domain name    empty (root domain)
   TYPE         u_int16_t      OPT
   CLASS        u_int16_t      sender's UDP payload size
   TTL          u_int32_t      extended RCODE and flags
   RDLEN        u_int16_t      describes RDATA
   RDATA        octet stream   {attribute,value} pairs

   Expires May 27, 2008                                          [Page 3]

   INTERNET-DRAFT                   EDNS0               December 27, 2007

   4.4. The variable part of an OPT RR is encoded in its RDATA and is
   structured as zero or more of the following:

                    +0 (MSB)                            +1 (LSB)
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0: |                          OPTION-CODE                          |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      2: |                         OPTION-LENGTH                         |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      4: |                                                               |
         /                          OPTION-DATA                          /
         /                                                               /
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   OPTION-CODE    (Assigned by IANA.)

   OPTION-LENGTH  Size (in octets) of OPTION-DATA.

   OPTION-DATA    Varies per OPTION-CODE.

   4.4.1. Order of appearance of option tuples is never relevant.  Any
   option whose meaning is affected by other options is so affected no
   matter which one comes first in the OPT RDATA.

   4.4.2. Any OPTION-CODE values not understood by a responder or
   requestor MUST be ignored.  So, specifications of such options might
   wish to include some kind of signalled acknowledgement.  For example,
   an option specification might say that if a responder sees option XYZ,
   it SHOULD include option XYZ in its response.

   4.5. The sender's UDP payload size (which OPT stores in the RR CLASS
   field) is the number of octets of the largest UDP payload that can be
   reassembled and delivered in the sender's network stack.  Note that
   path MTU, with or without fragmentation, may be smaller than this.

   4.5.1. Note that a 512-octet UDP payload requires a 576-octet IP
   reassembly buffer.  Choosing 1280 on an Ethernet connected requestor
   would be reasonable.  The consequence of choosing too large a value
   may be an ICMP message from an intermediate gateway, or even a silent
   drop of the response message.

   4.5.2. Both requestors and responders are advised to take account of
   the path's discovered MTU (if already known) when considering message
   sizes.

   Expires May 27, 2008                                          [Page 4]

   INTERNET-DRAFT                   EDNS0               December 27, 2007

   4.5.3. The requestor's maximum payload size can change over time, and
   therefore MUST NOT be cached for use beyond the transaction in which
   it is advertised.

   4.5.4. The responder's maximum payload size can change over time, but
   can be reasonably expected to remain constant between two sequential
   transactions; for example, a meaningless QUERY to discover a
   responder's maximum UDP payload size, followed immediately by an
   UPDATE which takes advantage of this size.  (This is considered
   preferrable to the outright use of TCP for oversized requests, if
   there is any reason to suspect that the responder implements EDNS, and
   if a request will not fit in the default 512 payload size limit.)

   4.5.5. Due to transaction overhead, it is unwise to advertise an
   architectural limit as a maximum UDP payload size.  Just because your
   stack can reassemble 64KB datagrams, don't assume that you want to
   spend more than about 4KB of state memory per ongoing transaction.

   4.6. The extended RCODE and flags (which OPT stores in the RR TTL
   field) are structured as follows:

                    +0 (MSB)                            +1 (LSB)
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      0: |         EXTENDED-RCODE        |            VERSION            |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
      2: | DO|                           Z                               |
         +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

   EXTENDED-RCODE  Forms upper 8 bits of extended 12-bit RCODE.  Note
                   that EXTENDED-RCODE value "0" indicates that an
                   unextended RCODE is in use (values "0" through "15").

   VERSION         Indicates the implementation level of whoever sets it.
                   Full conformance with this specification is indicated
                   by version ``0.''  Requestors are encouraged to set
                   this to the lowest implemented level capable of
                   expressing a transaction, to minimize the responder
                   and network load of discovering the greatest common
                   implementation level between requestor and responder.
                   A requestor's version numbering strategy should
                   ideally be a run time configuration option.

                   If a responder does not implement the VERSION level of
                   the request, then it answers with RCODE=BADVERS.  All

   Expires May 27, 2008                                          [Page 5]

   INTERNET-DRAFT                   EDNS0               December 27, 2007

                   responses MUST be limited in format to the VERSION
                   level of the request, but the VERSION of each response
                   MUST be the highest implementation level of the
                   responder.  In this way a requestor will learn the
                   implementation level of a responder as a side effect
                   of every response, including error responses,
                   including RCODE=BADVERS.

   DO              DNSSEC OK bit [RFC3225].

   Z               Set to zero by senders and ignored by receivers,
                   unless modified in a subsequent specification
                   [IANAFLAGS].

   5 - Transport Considerations

   5.1. The presence of an OPT pseudo-RR in a request is an indication
   that the requestor fully implements the given version of EDNS, and can
   correctly understand any response that conforms to that feature's
   specification.

   5.2. Lack of use of these features in a request is an indication that
   the requestor does not implement any part of this specification and
   that the responder SHOULD NOT use any protocol extension described
   here in its response.

   5.3. Responders who do not understand these protocol extensions are
   expected to send a response with RCODE NOTIMPL, FORMERR, or SERVFAIL,
   or to appear to "time out" due to inappropriate action by a "middle
   box" such as a NAT.  Therefore use of extensions SHOULD be ``probed''
   such that a responder who isn't known to support them be allowed a
   retry with no extensions if it responds with such an RCODE, or does
   not respond.  If a responder's capability level is cached by a
   requestor, a new probe SHOULD be sent periodically to test for changes
   to responder capability.

   6 - Security Considerations

   Requestor-side specification of the maximum buffer size may open a new
   DNS denial of service attack if responders can be made to send
   messages which are too large for intermediate gateways to forward,
   thus leading to potential ICMP storms between gateways and responders.

   Expires May 27, 2008                                          [Page 6]

   INTERNET-DRAFT                   EDNS0               December 27, 2007

   7 - IANA Considerations

   IANA has allocated RR type code 41 for OPT.

   This document controls the following IANA sub-registries in registry
   "DOMAIN NAME SYSTEM PARAMETERS":

      "EDNS Extended Label Type"
      "EDNS Option Codes"
      "EDNS Version Numbers"
      "Domain System Response Code"

   This document assigns label type 0b01xxxxxx as "EDNS Extended Label
   Type."  We request that IANA record this assignment.

   This document assigns option code 65535 to "Reserved for future
   expansion."

   This document assigns EDNS Extended RCODE "16" to "BADVERS".

   IESG approval is required to create new entries in the EDNS Extended
   Label Type or EDNS Version Number registries, while any published RFC
   (including Informational, Experimental, or BCP) is grounds for
   allocation of an EDNS Option Code.

   8 - Acknowledgements

   Paul Mockapetris, Mark Andrews, Robert Elz, Don Lewis, Bob Halley,
   Donald Eastlake, Rob Austein, Matt Crawford, Randy Bush, and Thomas
   Narten were each instrumental in creating and refining this
   specification.

   Expires May 27, 2008                                          [Page 7]

   INTERNET-DRAFT                   EDNS0               December 27, 2007

   9 - References

   [RFC1035]    P. Mockapetris, ``Domain Names - Implementation and
                Specification,'' RFC 1035, USC/Information Sciences
                Institute, November 1987.

   [RFC2119]    S. Bradner, ``Key words for use in RFCs to Indicate
                Requirement Levels,'' RFC 2119, Harvard University, March
                1997.

   [RFC2671]    P. Vixie, ``Extension mechanisms for DNS (EDNS0),'' RFC
                2671, Internet Software Consortium, August 1999.

   [RFC3225]    D. Conrad, ``Indicating Resolver Support of DNSSEC,'' RFC
                3225, Nominum Inc., December 2001.

   [IANAFLAGS]  IANA, ``DNS Header Flags and EDNS Header Flags,'' web
                site http://www.iana.org/assignments/dns-header-flags, as
                of June 2005 or later.

   10 - Author's Address

   Paul Vixie
      Internet Systems Consortium
      950 Charter Street
      Redwood City, CA 94063
      +1 650 423 1301
      <[email-masked]>

   Full Copyright Statement

   Copyright (C) IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

   Expires May 27, 2008                                          [Page 8]

   INTERNET-DRAFT                   EDNS0               December 27, 2007

   Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be found
   in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this specification
   can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [email-masked].

   Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

   Expires May 27, 2008                                          [Page 9]

---

From: Danny Mayer <[email-masked]>
Date: Thu, 27 Dec 2007 22:14:32 -0500

> of a lack of a PTR RR for the IETF's outbound IPv6 SMTP transport agent.

I don't know why but the draft that you posted in your message is
properly formatted while the one that got sent out from ietf.org is
misformatted. I can't quite tell but it looks as if there are extra
newlines in the text. You may have to battle the python yet again.

Danny

---

From: Paul Vixie <[email-masked]>
Date: Fri, 28 Dec 2007 04:53:06 +0000

> newlines in the text. You may have to battle the python yet again.

that script, and RFC 2119, have already cost me more than half a day.
i don't plan to concern myself with it again.  please read the draft
i posted.  i promise to keep submitting through the python script, and
to keep sending unmutiliated copies to the working group, and some day
some rfc editor who wants to turn the draft into an rfc will have to
deal with the wonkiness of the python script.  it's just not our burden.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 31 Dec 2007 12:40:48 -0500

>i posted.  i promise to keep submitting through the python script, and

When you say "posted" - do you mean the one on the web site or the 
one in email?
(I know you don't mean the one that came through botched.)

At first glance, the one posted to:
  http://www.ietf.org/internet-drafts/draft-ietf-dnsext-rfc2671bis-edns0-00.txt
looks well formatted.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Think glocally.  Act confused.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 31 Dec 2007 12:53:41 -0500

>	packet loss is treated as packet loss and not broken servers

I side with Paul's opinion - it's better to let non responses cause 
state changes.  In 2004 or so I ran some tests for lame servers and 
observed these two things:

1) I would reissue a query up to 10 times before giving up to see 
what was the tipping point - at what point were retries generally not 
worth the effort.  From my now lost records and dusty memory, 
counting 100% as the pool of queries ever answered, over 99% were 
answered on the first try.  The number answering to the 2nd, 3rd, 
..., 10th try, never went to 0 but were all pretty negligible.

Caveat - YMMV...as is always the case with any experiment.  I was on 
an office-grade T-1 and self-rate-limited the UDP's out so they 
didn't trip on themselves at the first hop.

2) There are name server implementations that will silently discard a 
query by policy.  One implementation refused to respond to any query 
it felt it wasn't supposed to see.  I would have expected (as BIND 
does in this case) to see a referral to the root.

After some discussion I was convinced that there was merit to this 
approach, although the puritanical client-server protocol guy I am 
bristles with the notion that silence means error.  But that's the 
network we have now.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

---

From: Noah Treuhaft <[email-masked]>
Date: Mon, 31 Dec 2007 15:19:31 -0800

>    requestor, a new probe SHOULD be sent periodically to test for changes

I think it's reasonable for a responder who does not understand the OPT 
pseudo-RR to ignore it and respond as though the OPT were absent from 
the request.  As the above paragraph stands, that's unexpected behavior. 
  Is there any reason it should be?

---

From: Edward Lewis <[email-masked]>
Date: Mon, 31 Dec 2007 19:16:45 -0500

>Is there any reason it should be?

Maybe my recollection is hazy, but I think the theory is that any 
responder that does not understand the OPT pseudo-RR would barf when 
seeing a record in the additional section in a query.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 01 Jan 2008 04:37:16 +0000

> Maybe my recollection is hazy, but I think the theory is that any responder
> that does not understand the OPT pseudo-RR would barf when seeing a record
> in the additional section in a query.

still, it's possible that an older implementation wouldn't notice the OPT RR
at all.  the language should be cleaned up to include the possibility, such
that an OPT requestor that receives an OPTless response has just learned that
the responder does not speak EDNS.