[dnsext] some words

[Mark Andrews <[e-mail]>]

CD bit handling is in a couple of places in 4035.  The alternative
to this is defining a way to pass trust anchors and time from the
stub to the recursive server to be used to find answers which will
pass validation on the stub resolver.

I'll see if I can come up with similar words for the recursive
server that is talking to another recursive server.

Section 4.9.2 of RFC 4035 is hereby replaced with the following:

Old:
4.9.2.  Handling of the CD Bit

   A non-validating security-aware stub resolver SHOULD NOT set the CD
   bit when sending queries unless it is requested by the application
   layer, as by definition, a non-validating stub resolver depends on
   the security-aware recursive name server to perform validation on its
   behalf.

   A validating security-aware stub resolver SHOULD set the CD bit,
   because otherwise the security-aware recursive name server will
   answer the query using the name server's local policy, which may
   prevent the stub resolver from receiving data that would be
   acceptable to the stub resolver's local policy.

New:
4.9.2.  Handling of the CD Bit

   A non-validating security-aware stub resolver SHOULD NOT set the CD
   bit when sending queries unless it is requested by the application
   layer, as by definition, a non-validating stub resolver depends on
   the security-aware recursive name server to perform validation on its
   behalf.

   A validating security-aware stub resolver SHOULD first try queries
   with the CD bit clear, then if SERVFAIL is returned, retry the
   query with the CD bit set.  The CD=0 query allow the recursive
   server to reject answers from misconfigured / stale authorititative
   servers.  The CD=1 query allows the stub resolver to talk though
   a recursive server with stale trust anchors or a misconfigured
   clock.  In either case it validates the answer it receives from
   the recursive server prior to passing it to the application.

   It is RECOMMENDED that the recursive server be configured with
   a super-set of the trust anchors used by its clients.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	[phone]		         INTERNET: [e-mail]
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext