Re: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-no-response-issue-19: (with COMMENT)

[Mark Andrews <[e-mail]>]

> On 8 Apr 2020, at 02:04, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-dnsop-no-response-issue-19: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-no-response-issue/
> 
> 
> 
> ----------------------------------------------------------------------
> 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”).

It can be a bit of both.  Developers both implement and deploy (enable by
default) new standards.  Often the only way to reach critical mass is to
do both.

>   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?

RFC 1034, 4.4.2 Paragraph 3

"As the last installation step, the delegation NS RRs and glue RRs
necessary to make the delegation effective should be added to the parent
zone.  The administrators of both zones should insure that the NS and
glue RRs which mark both sides of the cut are consistent and remain so.”

-        them when they are not <xref target="RFC1034"/>.  Doing
-        this regularly should reduce the instances of broken
-        delegations.
+        them when they are not <xref target="RFC1034"/>, Section 4.4.2,
+	 Paragraph 3.  Doing this regularly should reduce the instances
+	 of broken delegations.


> 
> 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)?

Added.

> 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.)

I don’t think so.

> 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.

The clients can’t tell whether it is a firewall or the server itself.  If you
add a NS record you are responsible for what the client sees at the addresses
referred to by that NS record.

> 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”.

Added.


> 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?)

https://ednscomp.isc.org is one site where a operator can trigger tests against
their own servers for a subset of the issues listed here.  There are also
links to source code to perform the rest of tests.

Everyone from nameserver developers and DNS server operators (from the root down)
should be testing the implementations, servers for their zones and delegated zones.

>   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.

They might but there have definitely been cases where single packets got
dropped just because they where slightly different but not part of attack
streams.

> 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?

I think this is the wrong document to do that in.

> 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]”?

Added.

>   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).

Yes.

> 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?

Yes, there is some risk.

> 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.
> 
> 
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]              INTERNET: [e-mail]