In message <[email protected]>, Andrew Sullivan w
rites:
> Hi there,
>
> I have read the -09 draft. I think I am confused (but maybe I am
> confused about that).
>
> It says
>
> 5. No special processing of '.home.arpa' is required for
> authoritative DNS server implementations. However, it is
> possible that an authoritative DNS server might attempt to
> validate the delegation for a zone before answering
> authoritatively for that zone. In this situation, it would find
> an invalid delegation, and would not answer authoritatively. A
> server that implements this sort of check MUST be configurable so
> that either it does not do this check for the 'home.arpa' domain,
> or it ignores the results of the check.
I suspect someone is confusing authoritative (AA=1) with authenticated
data (AD=1). A authoritative nameserver can set both or just AA=1.
Note you can set AD=1 without checking the DS record in the parent.
All that is required is that *local policy* for setting AD is met.
5. No special processing of '.home.arpa' is required for
authoritative DNS server implementations. However, it is
possible that an authoritative DNS server might attempt
to validate the delegation for a zone before answering
authoritatively for that zone. In this situation, it would
find an insecure delegation (no DS record), and would not
answer with AD=1. AA should be set as required by STD13.
Note this is a *insecure* delegation, not a *invalid* delegation.
> I think the problem here might be "attempt to validate". Since the
> point of section 7 is precisely to permit DNSSEC validation not to
> "fail" (i.e. not to validate "bogus"), this seems to be an
> equivocation on "validate". I think what is probably meant is
Section 7 is wrong, re-write below.
7. Delegation of 'home.arpa'
In order to be fully functional, there must be a delegation of
'home.arpa' in the '.arpa' zone [RFC3172]. This delegation MUST
be signed, MUST NOT include a DS record, and MUST point to one
or more black hole servers, for example BLACKHOLE-1.IANA.ORG and
BLACKHOLE-2.IANA.ORG. The delegation is signed to prove the
existance of the delegation at 'home.arpa' and the non-existance
of the DS record at 'home.arpa'. This breaks the DNSSEC chain
of trust at 'home.arpa', which prevents a validating stub resolver
from rejecting names published under 'home.arpa' on a homenet
name server.
The delegation of home.arpa is signed (NSEC record for home.arpa,
or a covering NSEC3 record.), it just isn't a SECURE delegation (no
DS record present).
> It is possible that an authoritative DNS server might have local
> policy that requires positive DNSSEC validation of a delegation
> for a zone before answering authoritatively for that zone. In
> that situation, it would not find a signed delegation, and would
> therefore not answer authoritiatively. A server
>
> If that's not what's meant, then I don't know what is meant. The
> delegation is certainly not invalid in the DNSSEC sense. It's not
> possible to find it in the global DNS servers authoritative for the
> parent name space, however. If _that's_ the worry, then the term
> "valid" is not what is needed here. In that case, maybe this is
> what's wanted:
>
> It is possible that an authoritative DNS server might attempt to
> check the authoritative servers for home.arpa. for a delegation
> beneath that name before answering authoritatively for such a
> delegated name. In such a case, because the name always has only
> local significance there will be no such delegation in the
> home.arpa. zone, and so the server would refuse to answer
> authoritatively for such a zone. A server
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> [email protected]
>
> _______________________________________________
> homenet mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/homenet
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
