In message 
<CAPt1N1mkOheWcQAispL7zpK=Whcjm=7ibjjcv9-dunjkfyb...@mail.gmail.com>, Ted Lemon 
writes:
> 
> What does forwarding DS lookups for home.arpa out of the homenet do?   That
> is, suppose I implement a cache that doesn't do this: what bad thing
> happens?   It's going to return NXDOMAIN, right?   Isn't it the NSEC
> lookups that have to succeed, and the NS record lookup?   And doesn't the
> NS record have to be forged?

It will return a signed NOERROR nodata responses saying that there
isn't a DS record for home.arpa but there is a delegation assuming
DO=1 is set in the query and IANA has competed setting up the
insecure delegation.  If DO=0, or there isn't a OPT record, you
still get a NOERROR nodata response but that isn't useful for
downstream validating clients.

Note for DNSSEC to work reliably all resolvers that are forwarding
queries need to be DNSSEC aware (set DO=1) and validate responses.
If they don't validate responses they will cache bad answers which
will prevent down stream validators getting good answers.  Validating
allow the forwarding resolver to reject bad answers and to try
alternate sources.

It they don't validate DNSSEC will work most of the time because
most answers you get back are actually correct and complete.

Writing a recursive server these days that doesn't support DNSSEC
should be a hanging offence. :-)

> I think this actually means that it does have to be an unsigned delegation.
>   Argh.
> 
> Hm, thinking farther, no, it doesn't, because it's okay to return the right
> answer for the delegation as long as the stub resolver is willing to rely
> on the cache, which we've already specified it must do.   So what's the
> failure mode that this new text prevents?  Oh, you have to look up the DS
> record to get the NSEC that validates it?

Yes (proves its non existence).
 
> (I'm leaving in all of the stuff I typed while I was thinking this through
> because I'm not sure I got it right, and you can point out what I got
> wrong.)
> 
> On Tue, Aug 8, 2017 at 11:17 PM, Mark Andrews <ma...@isc.org> wrote:
> 
> >
> > In message <79597e4d-dec0-4622-a410-003b45eb5...@fugue.com>, Ted Lemon
> > writes:
> > > I updated homenet-dot with the change that Mark requested regarding
> > > signed, unsigned and insecure delegations.   I believe the text is
> > > correct now, but would appreciate a sanity check.   Otherwise, I think
> > > it's up to the chairs to make the next move.
> >
> > I would explictly list DS home.arpa as a exception.  (I had to file
> > a bug report against recursive server that failed to have this
> > exception this week for AS112 zones.  The bug has been fixed.)  Also
> > I wouldn't be using '.home.arpa.' as we also want to stop queries
> > for 'home.arpa' leaving the home.  There are a couple of references
> > to '.home.arpa'.
> >
> > e.g.
> >
> > Old:
> >    DNS queries for names ending with '.home.arpa.' are resolved using
> >    local resolvers on the homenet.  Such queries MUST NOT be recursively
> >    forwarded to servers outside the logical boundaries of the homenet.
> >
> > New:
> >    DNS queries for names ending with 'home.arpa.' are resolved using
> >    local resolvers on the homenet.  Such queries MUST NOT be recursively
> >    forwarded to servers outside the logical boundaries of the homenet with
> >    the exception of DS lookups for 'home.arpa.'.
> >
> > Mark
> >
> > --
> > Mark Andrews, ISC
> > 1 Seymour St., Dundas Valley, NSW 2117, Australia
> > PHONE: +61 2 9871 4742                 INTERNET: ma...@isc.org
> >
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: ma...@isc.org

_______________________________________________
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to