Re: [Cerowrt-devel] [Dnsmasq-discuss] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014

[Phil Pennock <cerowrt-devel+phil@spodhuis.org>]

On 2014-04-28 at 20:32 +0100, Simon Kelley wrote:
> On 28/04/14 19:56, Dave Taht wrote:
> > I see A and AAAA requests for for "ds.test-ipv6.com" that fail.
> 
> The root of this failure is that DS ds.test-ipv6.com is broken.
> 
>  <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 ds ds.test-ipv6.com

> The latest fix I made (when the SERVFAIL reply comes, try the next
> possible secure-nonexistent DS record at test-ipv6.com) works sometimes,
> but the query above is taking long enough to fail that sometimes the
> original requestor has timed out before it gets the answer and tries again.

Er, DS records are authoritative in the parent domain and are equivalent
to glue; they are not expected to exist below the zone cut.

This is why you'll get results from:

    $ dig -t ds spodhuis.org @a2.org.afilias-nst.info

but a NOERROR from:

    $ dig -t ds spodhuis.org @nsauth.spodhuis.org

An NS query for "ds.test-ipv6.com" gives "test-ipv6.com", so that is the
zone cut, so it's in the COM. zone that you should expect to find any DS
records for "test-ipv6.com" and there's no need for a DS for anything
below that unless there's also a zone cut, in which case there's a DS at
the delegation point.

RFC 4033:
----------------------------8< cut here >8------------------------------
3.1.  Data Origin Authentication and Data Integrity
[...]
   The Delegation Signer (DS) RR type simplifies some of the
   administrative tasks involved in signing delegations across
   organizational boundaries.  The DS RRset resides at a delegation
   point in a parent zone and indicates the public key(s) corresponding
   to the private key(s) used to self-sign the DNSKEY RRset at the
   delegated child zone's apex.  The administrator of the child zone, in
   turn, uses the private key(s) corresponding to one or more of the
   public keys in this DNSKEY RRset to sign the child zone's data.  The
   typical authentication chain is therefore
   DNSKEY->[DS->DNSKEY]*->RRset, where "*" denotes zero or more
   DS->DNSKEY subchains.  DNSSEC permits more complex authentication
   chains, such as additional layers of DNSKEY RRs signing other DNSKEY
   RRs within a zone.
----------------------------8< cut here >8------------------------------