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

[Simon Kelley <simon@thekelleys.org.uk>]

On 29/04/14 00:24, Phil Pennock wrote:
> 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

A NOERROR answer from the authoritative server for test-ipv6.com would
be fine. What actually happens is no answer at all and a timeout (or a
closed TCP connection if TCP is used.)


It's maybe worth expanding on what we're trying to do here. The original
query is "A ds.test-ipv6.com". The answer to that comes back fine, but
there are no RRSIGs proving that that answer is good. Now we have to
distinguish between no signatures because the domain isn't signed, and
no signatures because the answer has come from the Bad Guys.

To do that, we need to find proof (NSEC or NSEC3 records) that a DS
doesn't exist somewhere between ds.test-ipv6.com and the root. Bear in
mind that dnsmasq is a DNS forwarder, not a recursive DNS server, so it
doesn't know where the zone cuts are.

The current strategy it to start at ds.test-ipv6.com and do DS queries.
There are three possible results.

unsigned NOERROR -> chop one label off the RHS and repeat
DS record        -> definite Bad Guy activity, return BOGUS
signed no DS record -> we expect unsigned original answer, return
INSECURE result.ds.test-ipv6.com


The other alternative approach is to start from the root and add labels,
but that has a problem.

Consider

department.campus.university.edu

where there are zone cuts between university and edu and between
department and campus.

All the zones are signed, so if we look up something under .department,
we expect a signature, if we don't get it, we check

DS .edu gives an answer
DS university.edu gives secure NODATA

secure no DS means that the original unsigned answer should be accepted,
except that it shouldn't. There's no way to distinguish between secure
lack of DS because we've reached an unsigned branch of the tree, and
secure lack of DS because we're not at a zone cut, except if we know
where the zone cuts are, and we don't.


That's why dnsmasq works up from the bottom. The first secure no-DS
answer we find marks the boundary between signed and unsigned tree.

Dnsmasq is acting as a validating stub resolver here. That's a supported
role for DNSSEC, so this must be possible. If it's not then we have a
standards problem.


> 
> 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.
ds.test-ipv6.com
Doing NS queries to find zone cuts is a possible solution, but I know of
ISP nameservers that elide the Authority section for "performance".


Simon.

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