[getdns-users] STUB mode, does it validate DNSSEC security?

[Willem Toorop]

Op 26-02-16 om 10:46 schreef Rick van Rein:
> Hi Willem,
> 
>> A subscription service for DNS information (or on a DNS cache even),
>> taking into account DNS redirects (by SRV, CNAME, MX, NS, or whatever).
>>  I like that idea a lot!  This would work perfectly well with the whole
>> eventloop approach that getdns embraces too.
>>
>> It would also be in line with the "small cache for the sub resolver (for
>> DS/DNSKEY (or their denial of existence) only in first instance)"
>> feature that we have on our wishlist.
> 
> Whoa, enthousiasm ;-)
> 
> 
> Then let me add a few other things I've been missing in the DNS landscape...
> 
> First, I think SCTP as a transport for DNS is a no-brainer, at least
> between authoritatives (but possibly also for local/befriended clients):
> 
>  * reliable delivery: slaves never miss a NOTIFY from their master
>  * out-of-order delivery: data up to 64k can overtake (as with UDP)
>  * optional ordering: mimic TCP style when data exceeds 64k (AXFR, IXFR)
>  * SCTP is relatively expensive to setup, but fine for known relations
>  * potentially use added streams for extra info (I/AXFR, zones serviced)
> 
> For the work I've been doing at SURFnet I've really wished my client
> software could subscribe to NOTIFYs over SCTP, as though they were a
> slave DNS server themselves.  This is not stub functionality I suppose,
> although it gets really close.  It can speed up closed loops
> OpenDNSSEC -> DNS -> monitoring -> OpenDNSESC and take out the guesses.
> Note how the entire DNS system becomes instant-upgrade among friends;
> this can really facilitate DNS as a secure backbone, even if it is just
> used internally.  (SCTP for all DNS is probably going to be too hefty.)
> 
> Finally, much of our work in assuring DNSSEC to be correctly implemented
> came down to TTL computations (you may have seen https://dnssec.surfnet.nl/?p=771
> which was truly painful to compose) and IMHO additional management data
> from DNS could be useful: I call it "minDNS,maxDNS" to indicate separate
> DNS supply streams with the data common to all DNS caches in the World, and
> the union of all information that might be in a DNS cache anywhere in the
> World.  All the TTL administration that we've been doing to make DNSSEC
> rock solid crystalises to this sort of information base: minDNS,maxDNS.
> This would be the work of an authoritative server, unless clients could
> follow the published state and receieve reliable NOTIFYs as though they
> were authoritatives themselves.  (Using SCTP, that would be possible, and
> separate streams may be used for minDNS and maxDNS.)

Interesting stuff!  I'm afraid I have to chew on this a bit more to
properly appreciate it tough, sorry ;)

> 
>> This would be a great hackathon project for the IETF95 too.
> 
> I will probably be there...

Good!  Make sure to sign up for the hackathon and join the DNSSEC team
if you do!

> 
>> Too many fun & interesting things to do, too little time... :(
> 
> I'm afraid I can have a very bad impact on that :-D
> 
>> Maybe we could discuss API prototypes for such an API if your in the
>> neighbourhood sometime?
> 
> Gladly!  I liked the word "enumerator" but didn't find it yet.  And I have
> some strong ideas about static structures in APIs too (just made an ASN.1
> DER parser fulfilling that same ideal, while staying generic, and we could
> maybe look for something like that to make GetDNS taste more like a C library,
> https://github.com/vanrein/quick-der#quick-and-easy-der-a-library-for-parsing-asn1
> )

Aha... iterators and such things.  We have those sort of structures
under the hood too.  Have a look at
https://github.com/getdnsapi/getdns/blob/develop/src/rr-iter.h for
example  (documentation is lagging behind a bit, sorry...).

Cheers,
-- Willem

> 
> Cheers,
>  -Rick
> _______________________________________________
> Users mailing list
> Users at getdnsapi.net
> http://getdnsapi.net/mailman/listinfo/users
>