Skip to main content

A Common Operational Problem in DNS Servers: Failure to Communicate
draft-ietf-dnsop-no-response-issue-23

Revision differences

Document history

Date Rev. By Action
2020-09-09
23 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-09-03
23 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-05-11
23 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-04-16
23 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-23.txt
2020-04-16
23 (System) New version approved
2020-04-16
23 (System) Request for posting confirmation emailed to previous authors: Mark Andrews , Ray Bellis
2020-04-16
23 Mark Andrews Uploaded new revision
2020-04-14
22 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-22.txt
2020-04-14
22 (System) New version approved
2020-04-14
22 (System) Request for posting confirmation emailed to previous authors: Mark Andrews , Ray Bellis
2020-04-14
22 Mark Andrews Uploaded new revision
2020-04-13
21 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-21.txt
2020-04-13
21 (System) New version approved
2020-04-13
21 (System) Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews
2020-04-13
21 Mark Andrews Uploaded new revision
2020-04-13
20 (System) RFC Editor state changed to EDIT
2020-04-13
20 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-04-13
20 (System) Announcement was received by RFC Editor
2020-04-13
20 (System) IANA Action state changed to No IANA Actions
2020-04-13
20 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2020-04-13
20 Amy Vezza IESG has approved the document
2020-04-13
20 Amy Vezza Closed "Approve" ballot
2020-04-13
20 Amy Vezza Ballot approval text was generated
2020-04-13
20 Amy Vezza Ballot writeup was changed
2020-04-09
20 Cindy Morgan IESG state changed to Approved-announcement to be sent from IESG Evaluation
2020-04-08
20 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-04-08
20 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-04-08
20 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2020-04-08
20 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2020-04-08
20 Amanda Baber IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-04-08
20 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. I also like the extensive test scenarios with 'dig' ;-)

To be honest, I …
[Ballot comment]
Thank you for the work put into this document. I also like the extensive test scenarios with 'dig' ;-)

To be honest, I was about to ballot a DISCUSS as I have some doubts whether the objective of removing non-compliant servers (end of section 2) is achievable... Too many non-compliant servers, probably managed by clueless people. But, hey, we can always try!

I also wonder why this document is a generic BCP while section 8 and other parts seem to indicate more like a testing of servers. Balloting NO OBJECTION but also long hesitation for a DISCUSS.

Please address the nits found by Carlos during the INTDIR review:
https://mailarchive.ietf.org/arch/msg/int-dir/wfKo4vDmFJwPa1HeDY9wxP2JdEA (at least one nit is already addressed, thank you)

Please find below some non-blocking COMMENTs and NITs. An answer will be appreciated.

I hope that this helps to improve the document,

Regards,

-éric

== COMMENTS ==
Generic: the objective of this document is a little unclear to me, is it to do compliance testing/certification specific DNS server software ? or to actual DNS servers on the Internet.

-- Section 1 --
Suggest to also add middle-box dropping EDNS in the sentence "Due to the inability to distinguish between packet loss and nameservers dropping EDNS" (see section 4).


-- Section 4 --
Why limiting the middle boxes to only firewalls and load balancers? There are many different types of middle-box (NAT, ...) also doing "packet massaging" on the fly... :-(

-- Section 10 --
The security considerations is rather weak...

If the intent is to probe Internet servers, then why not adding some text around 'do it only with prior agreement of the DNS servers operator' ?

Also, if the firewall is "protecting" the DNS server (cough cough), then as a security officer I would prefer to block all unknown opcodes/types at the firewall (possibly with a reply).

== NITS ==

-- section 2 --
Please add an expansion or a reference to "AD flag bit". (and in my non-native English speaker, it is a pleonasm).
2020-04-08
20 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-04-07
20 Barry Leiba
[Ballot comment]
Thanks for a BCP on this.

I agree with Ben about the commas.

For what it’s worth, I disagree with Martin’s comment about …
[Ballot comment]
Thanks for a BCP on this.

I agree with Ben about the commas.

For what it’s worth, I disagree with Martin’s comment about “should” and such: the document does not cite BCP 14, and I think that’s fine.

Some editorial stuff:

— Section 1 —

  While
  there is still a pool of servers that don't respond to EDNS requests,
  clients have no way to know if the lack of response is due to packet
  loss, or EDNS packets not being supported,

I tripped on the meaning of “while” here, and I suggest changing it to “As long as there are still servers...”, so as to avoid the ambiguity.

— Section 2 —

  Some are caused directly from the non-compliant
  behaviour and others as a result of work-arounds

Make it “directly by”, not “from”.  And then “and others are as a result”.

  o  Widespread non-response to EDNS queries has lead to recursive

Make it “has led”.

      servers to have to decide whether to probe to see if it is the
      EDNS option or just EDNS that is causing the non response.

I would say, “the specific EDNS option or the use of EDNS in general”.
2020-04-07
20 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-04-07
20 Roman Danyliw
[Ballot comment]
Thanks for this document – it is allows for a very approachable way to verify conformance.

** Section 2. Per “Working around issues …
[Ballot comment]
Thanks for this document – it is allows for a very approachable way to verify conformance.

** Section 2. Per “Working around issues due to non-compliance with RFCs is not sustainable”, this seems like a bold statement.  What is the basis for it?

** Section 4.  This section repeats several times that firewall should not drop DNS traffic with unknown parameters and such traffic should not be construed as an attack.  In the general case with “normal clients”, this is good advice.  However, for certain highly controlled enclaves where a white-list-style approach to traffic is taken, this is not realistic.  The presence of unexpected classes of new DNS traffic would be a bad sign (e.g., of compromise, a new software load whose features were not understood, or a configuration which was not validated)

** Section 8.  For completeness, per “The test below use dig from BIND 9.11.0”, please provide a reference.

** Section 8 dig examples.  It would be worth explaining $zone and $server.

** Section 10.  Per “Testing protocol compliance can potentially result in false reports of attempts to break services from Intrusion Detection Services and firewalls.”, thanks for calling this out.  I would recommend tuning this language:

-- s/break services/attack services/

-- to acknowledge that uncommon DNS protocol fields or traffic (from this test regime) might trigger anomaly-detection/profile-based IDS alerts too

** Editorial Nits:

-- Section 8. s/is know/is known/
2020-04-07
20 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2020-04-07
20 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-20.txt
2020-04-07
20 (System) New version approved
2020-04-07
20 (System) Request for posting confirmation emailed to previous authors: Mark Andrews , Ray Bellis
2020-04-07
20 Mark Andrews Uploaded new revision
2020-04-07
19 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-04-07
19 Benjamin Kaduk
[Ballot comment]
Someone (maybe the RFC Editor) will end up tweaking a lot of commas.
I didn't try to list them all.

I didn't see …
[Ballot comment]
Someone (maybe the RFC Editor) will end up tweaking a lot of commas.
I didn't try to list them all.

I didn't see a response to the secdir reviewer's question (though I'm
also not sure that there's an easy answer to it).

Section 1

  The existence of servers which fail to respond to queries results in
  developers being hesitant to deploy new standards.  Such servers need

nit: it feels a little like a juxtaposition to have "developers" that
"deploy" new standards (vs. "developers that implement" or "operators
that deploy").

  indication that the server is under attack.  Parent zone operators
  are advised to regularly check that the delegating NS records are
  consistent with those of the delegated zone and to correct them when
  they are not [RFC1034].  Doing this regularly should reduce the
  instances of broken delegations.

I can't tell if this 1034 reference is for the recommendation to
regularly check or the definition of "consistent" or something else; if
the recommendation is new, then would BCP 14 keywords be appropriate?

Section 2

  o  The AD flag bit in a response cannot be trusted to mean anything
      as some servers incorrectly copy the flag bit from the request to
      the response [RFC1035], [RFC4035].

Would it be worth a 6840 ref here as well (to catch setting AD in a
request, even though that's not exactly what's being mentioned)?

Section 3.1.2

(Do we want to remind the reader on the NOERROR vs. NXDOMAIN rules? "No"
is probably acceptable.  I see we do so later, in Section 7, so even a
forward reference might suffice.)

Where's the first reference/mention of Meta-RRs?  I see RFC 2929
(obsoleted, transitively, by 6895) that we cite for the "range reserved
for private use" but not for terminology.  Even RFC 8499 (which we don't
cite) only has "meta-RR" in a parenthetical in the description of OPT.

Section 3.1.5

micro-nit: I guess firewalls don't exactly count as "nameservers", which
seems to be the claimed scope for this document.

Section 3.2.1

This section threw me a bit, at first, as the 3.1.x had led me to expect
"nameservers should behave in this way", but this section is "here is
how to tell if a nameserver is misbehaving".  That's not necessarily a
problem, just a ... comment :)

Section 3.2.6

  Some nameservers fail to copy the DO bit to the response despite
  clearly supporting DNSSEC by returning an RRSIG records to EDNS
  queries with DO=1.

I'm not sure if we also want an explicit "nameservers should copy to the
DO bit to the response when they support DNSSEC".

Section 3.2.7

[similarly an affirmative statement of what nameservers should do might
be appropriate here.]

Section 4

  Firewalls and load balancers can affect the externally visible
  behaviour of a nameserver.  Tests for conformance should to be done
  from outside of any firewall so that the system is tested as a whole.

(These are conformance tests run by the nameserver's own operator, or
externally-driven tests, too?)

  However, there may be times when a nameserver mishandles messages
  with a particular flag, EDNS option, EDNS version field, opcode, type
  or class field or combination thereof to the point where the
  integrity of the nameserver is compromised.  Firewalls should offer
  the ability to selectively reject messages using an appropriately
  constructed response based on all these fields while awaiting a fix
  from the nameserver vendor.

I would suggest reiterating that this is "with a response" vs. "drop the
packet silently".

Section 5

  Ideally, Operators should run these tests against a packet scrubbing
  service to ensure that these tests are not seen as attack vectors.

It feels like maybe the most we can say here is "not seen as attack
vectors during normal operation".  We can't exclude the possibility that
some actor decides to generate a flood of messages that happens to match
the test behavior (whether by accident or design), which seems fairly
likely to lead to blocking of the test-behavior traffic as collateral
damage.

Section 7

  If the server does not support EDNS at all, FORMERR is the expected
  error code.  That said a minimal EDNS server implementation requires
  parsing the OPT records and responding with an empty OPT record in
  the additional section in most cases.  There is no need to interpret
  any EDNS options present in the request as unsupported EDNS options
  are expected to be ignored [RFC6891].  Additionally EDNS flags can be
  ignored.  The only part of the OPT record that needs to be examined
  is the version field to determine if BADVERS needs to be sent or not.

It seems like there's an implied "so providing minimal EDNS support is
pretty trivial and you ought to do so already" in here; do we want to
make such sentiment explicit?

Section 8

  Testing is divided into two sections.  "Basic DNS", which all servers
  should meet, and "Extended DNS", which should be met by all servers
  that support EDNS (a server is deemed to support EDNS if it gives a
  valid EDNS response to any EDNS query).  If a server does not support
  EDNS it should still respond to all the tests.

Is this "respond to all the tests, albeit with [error responses]"?

  The tests below use dig from BIND 9.11.0.

I guess this version could become important if some future version
starts setting a new flag by default (that would need to be suppressed
if that version of dig was used for many of these tests).

Section 8.1.2

  Ask for the TYPE1000 RRset at the configured zone's name.  This query
  is made with no DNS flag bits set and without EDNS.  TYPE1000 has
  been chosen for this purpose as IANA is unlikely to allocate this
  type in the near future and it is not in a range reserved for private
  use [RFC6895].  Any unallocated type code could be chosen for this
  test.

Is there a risk that since we document TYPE1000 like this some server
will implement "respond to TYPE1000" without implementing the actual
desired behavior?

Section 8.1.3.2

  AD use in queries is defined in [RFC6840].

(Knowing this would have been helpful up in the toplevel section 8 where
we talk about one or both AD=1 and DO=1 being a signal to expect AD=1.)

Section 8.2.3, 8.2.6

[Same comment about option code 100 as for TYPE1000 above; the same
response is assumed.]

Section 9

  When notification is not effective at correcting problems with a
  misbehaving name server, parent operators can choose to remove NS
  record sets (and glue records below) that refer to the faulty server
  until the servers are fixed.  This should only be done as a last
  resort and with due consideration, as removal of a delegation can
  have unanticipated side effects.  [...]

I have mixed feelings about recommending "cut you off until you fix your
bugs" as an option, but not strongly enough to override WG consensus.
2020-04-07
19 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-04-07
19 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-04-05
19 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-19.txt
2020-04-05
19 (System) New version approved
2020-04-05
19 (System) Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews
2020-04-05
19 Mark Andrews Uploaded new revision
2020-04-04
18 Erik Kline
[Ballot comment]
{Yes}

[nits]

S3.2.2

* s/answers responses/responses/  (or answers)

S5

* Is there a reference for a definition of "scrubbing service"?

S10

* s/None …
[Ballot comment]
{Yes}

[nits]

S3.2.2

* s/answers responses/responses/  (or answers)

S5

* Is there a reference for a definition of "scrubbing service"?

S10

* s/None the tests/None of the tests/
2020-04-04
18 Erik Kline [Ballot Position Update] New position, Yes, has been recorded for Erik Kline
2020-03-30
18 Murray Kucherawy
[Ballot comment]
General:
Nits:
* I tripped almost every time on saying "set FOO bit to 1" and similar because I'm used to "set" implying …
[Ballot comment]
General:
Nits:
* I tripped almost every time on saying "set FOO bit to 1" and similar because I'm used to "set" implying one and "not set" or "clear" implying zero.  In other places the prose does go with simply saying "FOO bit is set".  Maybe that's just me though; we'll see how my colleagues feel.

Section 1:
* Suggest including a reference to RFC4732 in the discussion of amplification attacks.

Section 2:
* In the discussion of abandoned transition to the SPF type, suggest a reference to RFC6686.

Nits:
* "Widespread non-response to EDNS queries has lead to  ..." -- s/lead/led/
* "Widespread non-response to EDNS options, requires ..." -- remove comma
* "... requires recursive servers to have to decide ..." -- s/to have//
* "... being present, leads to ..." -- remove comma

Section 3.1.2:
A nit:
* "The exception to this are ..." -- either s/exception/exceptions/ or s/are/is/.

Section 3.1.5:
A nit:
* "While firewalls should not block TCP connection attempts if they do they should ..." -- suggest: "While firewalls should not block TCP connection attempts, those that do should ..."

Section 3.2.2:
More nits:
* "... version 0 queries but ... version numbers that are higher than zero." -- why the digit in one place but prose in the other?

Section 4:
* Paragraphs 3, 4, and 5 could be common factored very easily since most of the text is identical.

Section 5:
* I've never heard of a "scrubbing service".  Is there a reference RFC, or could we include a short definition?
* "One needs to take care when choosing a scrubbing service." -- This is vague.  What, apart from the prior sentence (whose implications I don't understand), should an operator be looking for?

Section 8:
Nit:
* "Testing is divided into two sections." -- a list follows, so s/./:/

Section 9:
* The final paragraph suggests disconnection of broken nameservers.  This can have serious non-technical implications as well.  That might be worth mentioning.

Nit:
* "Name server operators ..." -- s/Name server/Nameserver/, to be consistent with the rest of the document
2020-03-30
18 Murray Kucherawy [Ballot Position Update] Position for Murray Kucherawy has been changed to No Objection from No Record
2020-03-28
18 Murray Kucherawy
[Ballot comment]
[ballot position under construction]

General:
Nits:
* I tripped almost every time on saying "set FOO bit to 1" and similar because I'm …
[Ballot comment]
[ballot position under construction]

General:
Nits:
* I tripped almost every time on saying "set FOO bit to 1" and similar because I'm used to "set" implying one and "not set" or "clear" implying zero.  In other places the prose does go with simply saying "FOO bit is set".  Maybe that's just me though; we'll see how my colleagues feel.

Section 1:
* Suggest including a reference to RFC4732 in the discussion of amplification attacks.

Section 2:
* In the discussion of abandoned transition to the SPF type, suggest a reference to RFC6686.

Nits:
* "Widespread non-response to EDNS queries has lead to  ..." -- s/lead/led/
* "Widespread non-response to EDNS options, requires ..." -- remove comma
* "... requires recursive servers to have to decide ..." -- s/to have//
* "... being present, leads to ..." -- remove comma

Section 3.1.2:
A nit:
* "The exception to this are ..." -- either s/exception/exceptions/ or s/are/is/.

Section 3.1.5:
A nit:
* "While firewalls should not block TCP connection attempts if they do they should ..." -- suggest: "While firewalls should not block TCP connection attempts, those that do should ..."

Section 3.2.2:
More nits:
* "... version 0 queries but ... version numbers that are higher than zero." -- why the digit in one place but prose in the other?

Section 4:
* Paragraphs 3, 4, and 5 could be common factored very easily since most of the text is identical.

Section 5:
* I've never heard of a "scrubbing service".  Is there a reference RFC, or could we include a short definition?
* "One needs to take care when choosing a scrubbing service." -- This is vague.  What, apart from the prior sentence (whose implications I don't understand), should an operator be looking for?

Section 8:
Nit:
* "Testing is divided into two sections." -- a list follows, so s/./:/

Section 9:
* The final paragraph suggests disconnection of broken nameservers.  This can have serious non-technical implications as well.  That might be worth mentioning.

Nit:
* "Name server operators ..." -- s/Name server/Nameserver/, to be consistent with the rest of the document
2020-03-28
18 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2020-03-26
18 Martin Duke
[Ballot comment]
Thanks for the draft. It's always good for congestion controls if congestion-based packet losses are disambiguated from other types.

A few nits:
- …
[Ballot comment]
Thanks for the draft. It's always good for congestion controls if congestion-based packet losses are disambiguated from other types.

A few nits:
- Section 1 has a number of acronyms without clear references (DANE, SPF, TLSA). Please define them on first use.

- Sec. 3.1.5. Please add a comma after "attempts"

- Sec 3.2.4 uses lower case versions of the normative keywords. Selecting a synonym would improve it.
2020-03-26
18 Martin Duke Ballot comment text updated for Martin Duke
2020-03-26
18 Martin Duke
[Ballot comment]
Thanks for the draft. It's always good for congestion controls if congestion-based packet losses are disambiguated from other types.

A few nits:
- …
[Ballot comment]
Thanks for the draft. It's always good for congestion controls if congestion-based packet losses are disambiguated from other types.

A few nits:
- Section 1 has a number of acronyms without clear references (DANE, SPF, TLSA). Please define them on first use.
- Sec. 3.1.5. Please add a comma after "attempts"
- Sec 3.2.4 uses lower case versions of the normative keywords. Selecting a synonym would improve it.
2020-03-26
18 Martin Duke [Ballot Position Update] New position, No Objection, has been recorded for Martin Duke
2020-03-22
18 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-03-22
18 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-18.txt
2020-03-22
18 (System) New version approved
2020-03-22
18 (System) Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews
2020-03-22
18 Mark Andrews Uploaded new revision
2020-03-22
17 Carlos Pignataro Request for Telechat review by INTDIR Completed: Ready with Nits. Reviewer: Carlos Pignataro. Sent review to list.
2020-03-17
17 Warren Kumari IESG state changed to IESG Evaluation from IESG Evaluation::AD Followup
2020-03-16
17 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Carlos Pignataro
2020-03-16
17 Carlos Jesús Bernardos Request for Telechat review by INTDIR is assigned to Carlos Pignataro
2020-03-16
17 Éric Vyncke Requested Telechat review by INTDIR
2020-03-15
17 Warren Kumari IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2020-03-15
17 Warren Kumari IESG state changed to IESG Evaluation::AD Followup from Waiting for Writeup::AD Followup
2020-03-11
17 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2020-03-11
17 Cindy Morgan Placed on agenda for telechat - 2020-04-09
2020-03-11
17 Warren Kumari Ballot has been issued
2020-03-11
17 Warren Kumari [Ballot Position Update] New position, Yes, has been recorded for Warren Kumari
2020-03-11
17 Warren Kumari Created "Approve" ballot
2020-03-11
17 Warren Kumari Ballot writeup was changed
2020-03-11
17 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-03-11
17 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-17.txt
2020-03-11
17 (System) New version approved
2020-03-11
17 (System) Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews
2020-03-11
17 Mark Andrews Uploaded new revision
2020-03-10
16 Warren Kumari IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup::AD Followup
2020-03-08
16 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-16.txt
2020-03-08
16 (System) New version approved
2020-03-08
16 (System) Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews
2020-03-08
16 Mark Andrews Uploaded new revision
2020-03-08
15 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-03-08
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2020-03-08
15 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-15.txt
2020-03-08
15 (System) New version approved
2020-03-08
15 (System) Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews
2020-03-08
15 Mark Andrews Uploaded new revision
2020-02-06
14 Warren Kumari 2020-02-06 - Reminded authors to post new version / asked for status - https://mailarchive.ietf.org/arch/msg/dnsop/fY3vSZO-oBOfUGbl29cLWU7ty8E
2020-01-27
14 Warren Kumari IESG state changed to Waiting for Writeup::Revised I-D Needed from Waiting for Writeup
2020-01-17
14 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Wassim Haddad. Submission of review completed at an earlier date.
2020-01-16
14 Dan Romascanu Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Dan Romascanu. Sent review to list.
2020-01-03
14 Jean Mahoney Request for Last Call review by GENART Completed: Ready. Reviewer: Wassim Haddad.
2019-12-23
14 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-12-23
14 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-no-response-issue-14, which is currently in Last Call, and has the following comments:

We …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-no-response-issue-14, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2019-12-19
14 Catherine Meadows Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Catherine Meadows. Sent review to list.
2019-12-19
14 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-12-17
14 David Black Request for Last Call review by TSVART Completed: Ready. Reviewer: David Black. Sent review to list.
2019-12-17
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Dan Romascanu
2019-12-17
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Dan Romascanu
2019-12-12
14 Jean Mahoney Request for Last Call review by GENART is assigned to Wassim Haddad
2019-12-12
14 Jean Mahoney Request for Last Call review by GENART is assigned to Wassim Haddad
2019-12-12
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Catherine Meadows
2019-12-12
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Catherine Meadows
2019-12-08
14 Wesley Eddy Request for Last Call review by TSVART is assigned to David Black
2019-12-08
14 Wesley Eddy Request for Last Call review by TSVART is assigned to David Black
2019-12-05
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-12-05
14 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-12-19):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski , …
The following Last Call announcement was sent out (ends 2019-12-19):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, dnsop@ietf.org, Tim Wicinski , draft-ietf-dnsop-no-response-issue@ietf.org, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A Common Operational Problem in DNS Servers - Failure To Communicate.) to Best Current Practice


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'A Common Operational Problem
in DNS Servers - Failure To Communicate.'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2019-12-19. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The DNS is a query / response protocol.  Failing to respond to
  queries, or responding incorrectly, causes both immediate operational
  problems and long term problems with protocol development.

  This document identifies a number of common kinds of queries to which
  some servers either fail to respond or else respond incorrectly.
  This document also suggests procedures for zone operators to apply to
  identify and remediate the problem.

  The document does not look at the DNS data itself, just the structure
  of the responses.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc6840: Clarifications and Implementation Notes for DNS Security (DNSSEC) (Proposed Standard - IETF stream)
    rfc3225: Indicating Resolver Support of DNSSEC (Proposed Standard - IETF stream)
    rfc7766: DNS Transport over TCP - Implementation Requirements (Proposed Standard - IETF stream)
    rfc4035: Protocol Modifications for the DNS Security Extensions (Proposed Standard - IETF stream)



2019-12-05
14 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-12-05
14 Warren Kumari Last call was requested
2019-12-05
14 Warren Kumari Last call announcement was generated
2019-12-05
14 Warren Kumari Ballot approval text was generated
2019-12-05
14 Warren Kumari Ballot writeup was generated
2019-12-05
14 Warren Kumari IESG state changed to Last Call Requested from Publication Requested
2019-12-05
14 Warren Kumari Changed consensus to Yes from Unknown
2019-11-17
14 Tim Wicinski
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) The RFC is being requested as BCP

(2)

Technical Summary

  Failing to respond to DNS queries, or responding incorrectly,
  causes both immediate operational problems and long term
  problems with protocol development.
  This document identifies a number of common kinds of DNS queries which
  some servers either fail to respond or else respond incorrectly.
  This document also suggests procedures for zone operators to apply to
  identify and remediate the problem.

Working Group Summary

  The document initially perscribed remediation for failing to
  respond correctly.  After much working group debate, this
  wording was removed and the document focused on documenting
  the failure scenarios.

Document Quality

  Document quality is good and has been through several reviews.

Personnel

Document Shepherd: Tim Wicinski
Responsible Area Director: Warren Kumari

(3) The Document went through an exhaustive review by the Document
Shepherd.  We went through several editorial iterations during the
working group process before WGLC.  We feel the document is ready
for publication.

(4) The Document Shepherd has no concerns on the depth or
breadth of the reviews.

(5) There is no need for broader review

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) WG Consensus is solid.  There has been many iterations and comments from a
broad spectrum of working group participants.

(10) There has been no appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) No formal reviews needed.

(13) All references have been identified as either normative or informative

(14) There are no normative references waiting to advance.

(15) There are no downward normative references

(16) This RFC will not change any existing RFCs.


(17) No IANA Considerations.

(18)  No new IANA Registries

(19) N/A
2019-11-15
14 Tim Wicinski
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) The RFC is being requested as BCP

(2)

Technical Summary

  Failing to respond to DNS queries, or responding incorrectly,
  causes both immediate operational problems and long term
  problems with protocol development.
  This document identifies a number of common kinds of DNS queries which
  some servers either fail to respond or else respond incorrectly.
  This document also suggests procedures for zone operators to apply to
  identify and remediate the problem.

Working Group Summary

  The document initially perscribed remediation for failing to
  respond correctly.  After much working group debate, this
  wording was removed and the document focused on documenting
  the failure scenarios.

Document Quality

  Document quality is good and has been through several reviews.

Personnel

Document Shepherd: Tim Wicinski
Responsible Area Director: Warren Kumari

(3) The Document went through an exhaustive review by the Document
Shepherd.  We went through several editorial iterations during the
working group process before WGLC.  We feel the document is ready
for publication.

(4) The Document Shepherd has no concerns on the depth or
breadth of the reviews.

(5) There is no need for broader review

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) WG Consensus is solid.  There has been many iterations and comments from a
broad spectrum of working group participants.

(10) There has been no appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) No formal reviews needed.

(13) All references have been identified as either normative or informative

(14) There are no normative references waiting to advance.

(15) There are no downward normative references

(16) This RFC will not change any existing RFCs.


(17) No IANA Considerations.

(18)  No new IANA Registries

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
2019-11-15
14 Tim Wicinski Responsible AD changed to Warren Kumari
2019-11-15
14 Tim Wicinski IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2019-11-15
14 Tim Wicinski IESG state changed to Publication Requested from I-D Exists
2019-11-15
14 Tim Wicinski IESG process started in state Publication Requested
2019-11-15
14 Tim Wicinski
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) The RFC is being requested as BCP

(2)

Technical Summary

  Failing to respond to DNS queries, or responding incorrectly,
  causes both immediate operational problems and long term
  problems with protocol development.
  This document identifies a number of common kinds of DNS queries which
  some servers either fail to respond or else respond incorrectly.
  This document also suggests procedures for zone operators to apply to
  identify and remediate the problem.

Working Group Summary

  The document initially perscribed remediation for failing to
  respond correctly.  After much working group debate, this
  wording was removed and the document focused on documenting
  the failure scenarios.

Document Quality

  Document quality is good and has been through several reviews.

Personnel

Document Shepherd: Tim Wicinski
Responsible Area Director: Warren Kumari

(3) The Document went through an exhaustive review by the Document
Shepherd.  We went through several editorial iterations during the
working group process before WGLC.  We feel the document is ready
for publication.

(4) The Document Shepherd has no concerns on the depth or
breadth of the reviews.

(5) There is no need for broader review

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) WG Consensus is solid.  There has been many iterations and comments from a
broad spectrum of working group participants.

(10) There has been no appeals.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

(12) No formal reviews needed.

(13) All references have been identified as either normative or informative

(14) There are no normative references waiting to advance.

(15) There are no downward normative references

(16) This RFC will not change any existing RFCs.


(17) No IANA Considerations.

(18)  No new IANA Registries

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
2019-11-04
14 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-14.txt
2019-11-04
14 (System) New version approved
2019-11-04
14 (System) Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews
2019-11-04
14 Mark Andrews Uploaded new revision
2019-08-29
13 (System) Document has expired
2019-08-01
13 Tim Wicinski IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2019-07-17
13 Tim Wicinski IETF WG state changed to In WG Last Call from WG Document
2019-02-25
13 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-13.txt
2019-02-25
13 (System) New version approved
2019-02-25
13 (System) Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews
2019-02-25
13 Mark Andrews Uploaded new revision
2018-11-04
12 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-12.txt
2018-11-04
12 (System) New version approved
2018-11-04
12 (System) Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews
2018-11-04
12 Mark Andrews Uploaded new revision
2018-07-27
11 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-11.txt
2018-07-27
11 (System) New version approved
2018-07-27
11 (System) Request for posting confirmation emailed to previous authors: Ray Bellis , Mark Andrews
2018-07-27
11 Mark Andrews Uploaded new revision
2018-07-20
10 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-10.txt
2018-07-20
10 (System) New version approved
2018-07-20
10 (System) Request for posting confirmation emailed to previous authors: Mark Andrews , dnsop-chairs@ietf.org
2018-07-20
10 Mark Andrews Uploaded new revision
2018-07-18
09 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-09.txt
2018-07-18
09 (System) New version approved
2018-07-18
09 (System) Request for posting confirmation emailed to previous authors: Mark Andrews
2018-07-18
09 Mark Andrews Uploaded new revision
2017-09-04
08 (System) Document has expired
2017-03-03
08 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-08.txt
2017-03-03
08 (System) New version approved
2017-03-03
08 (System) Request for posting confirmation emailed to previous authors: Mark Andrews , dnsop-chairs@ietf.org
2017-03-03
08 Mark Andrews Uploaded new revision
2017-03-02
07 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-07.txt
2017-03-02
07 (System) New version approved
2017-03-02
07 (System) Request for posting confirmation emailed to previous authors: Mark Andrews , dnsop-chairs@ietf.org
2017-03-02
07 Mark Andrews Uploaded new revision
2016-10-27
06 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-06.txt
2016-10-27
06 (System) New version approved
2016-10-27
06 (System) Request for posting confirmation emailed to previous authors: "Mark Andrews" , dnsop-chairs@ietf.org
2016-10-27
06 Mark Andrews Uploaded new revision
2016-09-18
05 Mark Andrews New version approved
2016-09-18
05 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-05.txt
2016-09-18
05 Mark Andrews New version approved
2016-09-18
05 Mark Andrews Request for posting confirmation emailed to previous authors: "Mark Andrews" , dnsop-chairs@ietf.org
2016-09-18
05 (System) Uploaded new revision
2016-08-26
04 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-04.txt
2016-04-06
03 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-03.txt
2016-02-21
02 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-02.txt
2015-11-30
01 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-01.txt
2015-11-28
00 Tim Wicinski Notification list changed to "Tim Wicinski" <tjw.ietf@gmail.com>
2015-11-28
00 Tim Wicinski Document shepherd changed to Tim Wicinski
2015-11-28
00 Tim Wicinski Intended Status changed to Best Current Practice from None
2015-11-28
00 Tim Wicinski This document now replaces draft-andrews-dns-no-response-issue instead of None
2015-11-28
00 Mark Andrews New version available: draft-ietf-dnsop-no-response-issue-00.txt