From linus at nordberg.se  Fri Apr  1 14:53:14 2016
From: linus at nordberg.se (Linus Nordberg)
Date: Fri, 01 Apr 2016 16:53:14 +0200
Subject: [getdns-users] Example using the
	"dnssec_return_validation_chain" extension
In-Reply-To: <56D03416.9060200@nlnetlabs.nl> (Willem Toorop's message of "Fri, 
 26 Feb 2016 12:16:38 +0100")
References: <878u2sqrj7.fsf@localhost> <56BC5130.8050400@nlnetlabs.nl>
 <56BC5384.50502@nlnetlabs.nl> <877fibo32j.fsf@localhost>
 <56D03416.9060200@nlnetlabs.nl>
Message-ID: <87oa9te5yd.fsf@localhost>

Willem Toorop <willem at nlnetlabs.nl> wrote
Fri, 26 Feb 2016 12:16:38 +0100:

[...]
| you really want, but it doesn't seem too much of an effort to convert
| from wire format to a getdns_list.  I.e. for example with the well
| documented wire2rr_dict_scan ;) :
[...]
| We could expose this as
| 
| getdns_return_t
| getdns_wire_rrs2list(uint8_t *wire, size_t wire_len, getdns_list **list);
| 
| But I also like to keep the API as small as possible and don't want to
| expose a lot of helper functions that you could have easily recreated
| with the existing functions as well.

Makes sense. I ended up doing something very similar to what you outline
above. Works just fine. Thanks!

Next question is if I can somehow access the canonicalised data that the
validation is based on? From skimming the code, it seems to me that
canonicalisation is performed but I haven't figured out if it's safe to
assume that I could simply use the data in getdns_list's that I passed
to getdns_validate_dnssec2() once it returns.

By the way, I've been using commit 4e0073ae for my testing. This seems
to be close enough to 1.0.0b1 for me to give a thumbs up for at least
the DNSSEC validation parts of that (pre-)release. Great work!


From allison.mankin at gmail.com  Sat Apr  2 12:45:40 2016
From: allison.mankin at gmail.com (Allison Mankin)
Date: Sat, 2 Apr 2016 09:45:40 -0300
Subject: [getdns-users] Hackathon @ IETF95
Message-ID: <CAP8yD=tnrYNqshJQe1CBooNjXr2-4PRWYEE0RsmvyEPa-FgB3Q@mail.gmail.com>

For getdns folks who want to participate in the IETF hackathon remotely,
currently we're teleconferencing at:

https://appear.in/mellow-wolverine

There will also be a jabber room.  We'll update you as to that soon.

Welcome, and let us know if you need help!


>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.getdnsapi.net/pipermail/users/attachments/20160402/2e8fbb37/attachment.htm>

From allison.mankin at gmail.com  Sat Apr  2 13:01:58 2016
From: allison.mankin at gmail.com (Allison Mankin)
Date: Sat, 2 Apr 2016 10:01:58 -0300
Subject: [getdns-users] Hackathon @ IETF95
In-Reply-To: <CAP8yD=tnrYNqshJQe1CBooNjXr2-4PRWYEE0RsmvyEPa-FgB3Q@mail.gmail.com>
References: <CAP8yD=tnrYNqshJQe1CBooNjXr2-4PRWYEE0RsmvyEPa-FgB3Q@mail.gmail.com>
Message-ID: <CAP8yD=sZSa3f78xTNKVG-5mLqkj9Nnb7-yxBfyLdP4FCnkE5hw@mail.gmail.com>

Jabber room:

hackathon95 at jabber.ietf.org

On 2 April 2016 at 09:45, Allison Mankin <allison.mankin at gmail.com> wrote:

> For getdns folks who want to participate in the IETF hackathon remotely,
> currently we're teleconferencing at:
>
> https://appear.in/mellow-wolverine
>
> There will also be a jabber room.  We'll update you as to that soon.
>
> Welcome, and let us know if you need help!
>
>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.getdnsapi.net/pipermail/users/attachments/20160402/6e0c839b/attachment.htm>

From willem at nlnetlabs.nl  Sun Apr  3 11:45:45 2016
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Sun, 3 Apr 2016 08:45:45 -0300
Subject: [getdns-users] Example using the
 "dnssec_return_validation_chain" extension
In-Reply-To: <87oa9te5yd.fsf@localhost>
References: <878u2sqrj7.fsf@localhost> <56BC5130.8050400@nlnetlabs.nl>
 <56BC5384.50502@nlnetlabs.nl> <877fibo32j.fsf@localhost>
 <56D03416.9060200@nlnetlabs.nl> <87oa9te5yd.fsf@localhost>
Message-ID: <57010269.3080001@nlnetlabs.nl>

Op 01-04-16 om 11:53 schreef Linus Nordberg:
> Willem Toorop <willem at nlnetlabs.nl> wrote
> Fri, 26 Feb 2016 12:16:38 +0100:
> 
> [...]
> | you really want, but it doesn't seem too much of an effort to convert
> | from wire format to a getdns_list.  I.e. for example with the well
> | documented wire2rr_dict_scan ;) :
> [...]
> | We could expose this as
> | 
> | getdns_return_t
> | getdns_wire_rrs2list(uint8_t *wire, size_t wire_len, getdns_list **list);
> | 
> | But I also like to keep the API as small as possible and don't want to
> | expose a lot of helper functions that you could have easily recreated
> | with the existing functions as well.
> 
> Makes sense. I ended up doing something very similar to what you outline
> above. Works just fine. Thanks!
> 
> Next question is if I can somehow access the canonicalised data that the
> validation is based on? From skimming the code, it seems to me that
> canonicalisation is performed but I haven't figured out if it's safe to
> assume that I could simply use the data in getdns_list's that I passed
> to getdns_validate_dnssec2() once it returns.

No, the verification buffers are temporarily used for the verification
process only.  But why do you need the canonicalized form?


> 
> By the way, I've been using commit 4e0073ae for my testing. This seems
> to be close enough to 1.0.0b1 for me to give a thumbs up for at least
> the DNSSEC validation parts of that (pre-)release. Great work!
> 



From linus at nordberg.se  Sun Apr  3 12:10:42 2016
From: linus at nordberg.se (Linus Nordberg)
Date: Sun, 03 Apr 2016 14:10:42 +0200
Subject: [getdns-users] Example using the
	"dnssec_return_validation_chain" extension
In-Reply-To: <57010269.3080001@nlnetlabs.nl> (Willem Toorop's message of "Sun, 
 3 Apr 2016 08:45:45 -0300")
References: <878u2sqrj7.fsf@localhost> <56BC5130.8050400@nlnetlabs.nl>
 <56BC5384.50502@nlnetlabs.nl> <877fibo32j.fsf@localhost>
 <56D03416.9060200@nlnetlabs.nl> <87oa9te5yd.fsf@localhost>
 <57010269.3080001@nlnetlabs.nl>
Message-ID: <87vb3yvqnx.fsf@localhost>

Willem Toorop <willem at nlnetlabs.nl> wrote
Sun, 3 Apr 2016 08:45:45 -0300:

| > Next question is if I can somehow access the canonicalised data that the
| > validation is based on? From skimming the code, it seems to me that
| > canonicalisation is performed but I haven't figured out if it's safe to
| > assume that I could simply use the data in getdns_list's that I passed
| > to getdns_validate_dnssec2() once it returns.
| 
| No, the verification buffers are temporarily used for the verification
| process only.  But why do you need the canonicalized form?

(Cross posting to dnssec-transparency@ where this discussion is more on
topic.)

A DNSSEC Transparency log server should store RR's in canonicalised form
in order to be able to return an old SCT when a submitted record already
exists in the log. Without this it'd be even easier to spam a log to
death.

At least that's my understanding of why this is important. Another less
important reason would be to make it easier for auditors and monitors to
verify log behaviour and content.

Thinking some more about it, duplicate checks should probably be
performed on the submitted DS record (and possibly its accompanying
RRSIG) only. I'm still pretty sure it should be canonicalised.


From willem at nlnetlabs.nl  Sun Apr  3 15:46:24 2016
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Sun, 3 Apr 2016 12:46:24 -0300
Subject: [getdns-users] Example using the
 "dnssec_return_validation_chain" extension
In-Reply-To: <87vb3yvqnx.fsf@localhost>
References: <878u2sqrj7.fsf@localhost> <56BC5130.8050400@nlnetlabs.nl>
 <56BC5384.50502@nlnetlabs.nl> <877fibo32j.fsf@localhost>
 <56D03416.9060200@nlnetlabs.nl> <87oa9te5yd.fsf@localhost>
 <57010269.3080001@nlnetlabs.nl> <87vb3yvqnx.fsf@localhost>
Message-ID: <57013AD0.1070902@nlnetlabs.nl>

Op 03-04-16 om 09:10 schreef Linus Nordberg:
> Willem Toorop <willem at nlnetlabs.nl> wrote
> Sun, 3 Apr 2016 08:45:45 -0300:
> 
> | > Next question is if I can somehow access the canonicalised data that the
> | > validation is based on? From skimming the code, it seems to me that
> | > canonicalisation is performed but I haven't figured out if it's safe to
> | > assume that I could simply use the data in getdns_list's that I passed
> | > to getdns_validate_dnssec2() once it returns.
> | 
> | No, the verification buffers are temporarily used for the verification
> | process only.  But why do you need the canonicalized form?
> 
> (Cross posting to dnssec-transparency@ where this discussion is more on
> topic.)
> 
> A DNSSEC Transparency log server should store RR's in canonicalised form
> in order to be able to return an old SCT when a submitted record already
> exists in the log. Without this it'd be even easier to spam a log to
> death.
> 
> At least that's my understanding of why this is important. Another less
> important reason would be to make it easier for auditors and monitors to
> verify log behaviour and content.

Ok... well, then we need to do something about it :)
So, the conversion to wireformat functions already get rid of
compression if you remove the /rdata/rdata_raw fields from the rr_dicts.
 I suppose it could be an extra parameter in that conversion function to
write out canonicalized form.  Or a different function names...  for
example:

getdns_return_t
getdns_rr_dict2canonical_wire(
    const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);

getdns_return_t
getdns_rr_dict2canonical_wire_buf(
	const getdns_dict *rr_dict, uint8_t *wire, size_t *wire_sz);

getdns_return_t
getdns_rr_dict2canonical_wire_scan(
	const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);

What do you think?

Are you only converting individual rr_dict's or complete replies as
well?  For complete replies it could also be interesting (for other use
cases) to explicitly ask for name compression.

> Thinking some more about it, duplicate checks should probably be
> performed on the submitted DS record (and possibly its accompanying
> RRSIG) only. I'm still pretty sure it should be canonicalised.
> 



From linus at nordberg.se  Sun Apr  3 16:59:52 2016
From: linus at nordberg.se (Linus Nordberg)
Date: Sun, 03 Apr 2016 18:59:52 +0200
Subject: [getdns-users] Example using the
	"dnssec_return_validation_chain" extension
In-Reply-To: <57013AD0.1070902@nlnetlabs.nl> (Willem Toorop's message of "Sun, 
 3 Apr 2016 12:46:24 -0300")
References: <878u2sqrj7.fsf@localhost> <56BC5130.8050400@nlnetlabs.nl>
 <56BC5384.50502@nlnetlabs.nl> <877fibo32j.fsf@localhost>
 <56D03416.9060200@nlnetlabs.nl> <87oa9te5yd.fsf@localhost>
 <57010269.3080001@nlnetlabs.nl> <87vb3yvqnx.fsf@localhost>
 <57013AD0.1070902@nlnetlabs.nl>
Message-ID: <87h9fitypj.fsf@nordberg.se>

Willem Toorop <willem at nlnetlabs.nl> wrote
Sun, 3 Apr 2016 12:46:24 -0300:

| Op 03-04-16 om 09:10 schreef Linus Nordberg:
| > Willem Toorop <willem at nlnetlabs.nl> wrote
| > Sun, 3 Apr 2016 08:45:45 -0300:
| > 
| > | > Next question is if I can somehow access the canonicalised data that the
| > | > validation is based on? From skimming the code, it seems to me that
| > | > canonicalisation is performed but I haven't figured out if it's safe to
| > | > assume that I could simply use the data in getdns_list's that I passed
| > | > to getdns_validate_dnssec2() once it returns.
| > | 
| > | No, the verification buffers are temporarily used for the verification
| > | process only.  But why do you need the canonicalized form?
| > 
| > (Cross posting to dnssec-transparency@ where this discussion is more on
| > topic.)
| > 
| > A DNSSEC Transparency log server should store RR's in canonicalised form
| > in order to be able to return an old SCT when a submitted record already
| > exists in the log. Without this it'd be even easier to spam a log to
| > death.
| > 
| > At least that's my understanding of why this is important. Another less
| > important reason would be to make it easier for auditors and monitors to
| > verify log behaviour and content.
| 
| Ok... well, then we need to do something about it :)
| So, the conversion to wireformat functions already get rid of
| compression if you remove the /rdata/rdata_raw fields from the rr_dicts.
|  I suppose it could be an extra parameter in that conversion function to
| write out canonicalized form.  Or a different function names...  for
| example:
| 
| getdns_return_t
| getdns_rr_dict2canonical_wire(
|     const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);
| 
| getdns_return_t
| getdns_rr_dict2canonical_wire_buf(
| 	const getdns_dict *rr_dict, uint8_t *wire, size_t *wire_sz);
| 
| getdns_return_t
| getdns_rr_dict2canonical_wire_scan(
| 	const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);
| 
| What do you think?

That'd be very useful for my purposes.


| Are you only converting individual rr_dict's or complete replies as
| well?  For complete replies it could also be interesting (for other use
| cases) to explicitly ask for name compression.

My validation program reads a set of RR's in wire format where the first
RR is a DS RR, the next one is an RRSIG RR covering the previous DS RR
and the rest are "support records", including RRSIG's.



From paul at nohats.ca  Sun Apr  3 17:49:26 2016
From: paul at nohats.ca (Paul Wouters)
Date: Sun, 3 Apr 2016 14:49:26 -0300
Subject: [getdns-users] [DNSSEC-Transparency] Example using the
	"dnssec_return_validation_chain" extension
In-Reply-To: <87h9fitypj.fsf@nordberg.se>
References: <878u2sqrj7.fsf@localhost> <56BC5130.8050400@nlnetlabs.nl>
 <56BC5384.50502@nlnetlabs.nl> <877fibo32j.fsf@localhost>
 <56D03416.9060200@nlnetlabs.nl> <87oa9te5yd.fsf@localhost>
 <57010269.3080001@nlnetlabs.nl> <87vb3yvqnx.fsf@localhost>
 <57013AD0.1070902@nlnetlabs.nl> <87h9fitypj.fsf@nordberg.se>
Message-ID: <ED381A79-86B2-4AAD-8483-A7754C76936B@nohats.ca>



> 
> My validation program reads a set of RR's in wire format where the first
> RR is a DS RR, the next one is an RRSIG RR covering the previous DS RR
> and the rest are "support records", including RRSIG's.

Note you need to be able to accept any order of RRdata if you get the order that came in on the wire (because at least powerdns randomized the rrset)

> 
> _______________________________________________
> DNSSEC-Transparency mailing list
> DNSSEC-Transparency at lists.sunet.se
> https://lists.sunet.se/listinfo/dnssec-transparency




From willem at nlnetlabs.nl  Wed Apr  6 14:35:13 2016
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 6 Apr 2016 11:35:13 -0300
Subject: [getdns-users] Example using the
 "dnssec_return_validation_chain" extension
In-Reply-To: <87h9fitypj.fsf@nordberg.se>
References: <878u2sqrj7.fsf@localhost> <56BC5130.8050400@nlnetlabs.nl>
 <56BC5384.50502@nlnetlabs.nl> <877fibo32j.fsf@localhost>
 <56D03416.9060200@nlnetlabs.nl> <87oa9te5yd.fsf@localhost>
 <57010269.3080001@nlnetlabs.nl> <87vb3yvqnx.fsf@localhost>
 <57013AD0.1070902@nlnetlabs.nl> <87h9fitypj.fsf@nordberg.se>
Message-ID: <57051EA1.8060800@nlnetlabs.nl>

Op 03-04-16 om 13:59 schreef Linus Nordberg:
> Willem Toorop <willem at nlnetlabs.nl> wrote
> Sun, 3 Apr 2016 12:46:24 -0300:
> 
> | Op 03-04-16 om 09:10 schreef Linus Nordberg:
> | > Willem Toorop <willem at nlnetlabs.nl> wrote
> | > Sun, 3 Apr 2016 08:45:45 -0300:
> | > 
> | > | > Next question is if I can somehow access the canonicalised data that the
> | > | > validation is based on? From skimming the code, it seems to me that
> | > | > canonicalisation is performed but I haven't figured out if it's safe to
> | > | > assume that I could simply use the data in getdns_list's that I passed
> | > | > to getdns_validate_dnssec2() once it returns.
> | > | 
> | > | No, the verification buffers are temporarily used for the verification
> | > | process only.  But why do you need the canonicalized form?
> | > 
> | > (Cross posting to dnssec-transparency@ where this discussion is more on
> | > topic.)
> | > 
> | > A DNSSEC Transparency log server should store RR's in canonicalised form
> | > in order to be able to return an old SCT when a submitted record already
> | > exists in the log. Without this it'd be even easier to spam a log to
> | > death.
> | > 
> | > At least that's my understanding of why this is important. Another less
> | > important reason would be to make it easier for auditors and monitors to
> | > verify log behaviour and content.
> | 
> | Ok... well, then we need to do something about it :)
> | So, the conversion to wireformat functions already get rid of
> | compression if you remove the /rdata/rdata_raw fields from the rr_dicts.
> |  I suppose it could be an extra parameter in that conversion function to
> | write out canonicalized form.  Or a different function names...  for
> | example:
> | 
> | getdns_return_t
> | getdns_rr_dict2canonical_wire(
> |     const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);
> | 
> | getdns_return_t
> | getdns_rr_dict2canonical_wire_buf(
> | 	const getdns_dict *rr_dict, uint8_t *wire, size_t *wire_sz);
> | 
> | getdns_return_t
> | getdns_rr_dict2canonical_wire_scan(
> | 	const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);
> | 
> | What do you think?
> 
> That'd be very useful for my purposes.

Yes, I've been chewing on this a little bit, and considering that
canonical order also seems important, perhaps we can come up with some
more generic functions.

For example one to canonicalize a single rr_dict:

getdns_return_t
getdns_rr_dict_canonicalize(
    const getdns_list *rr_dict, getdns_list **canonicalized_rr_dict);

and one to sort:

getdns_return_t
getdns_rr_dicts_sort(const getdns_list *unsorted, getdns_list **sorted);

where the sorting function makes sure the signature rr_dicts are right
behind the rrsets they sign.

What do you think?

-- Willem
> 
> 
> | Are you only converting individual rr_dict's or complete replies as
> | well?  For complete replies it could also be interesting (for other use
> | cases) to explicitly ask for name compression.
> 
> My validation program reads a set of RR's in wire format where the first
> RR is a DS RR, the next one is an RRSIG RR covering the previous DS RR
> and the rest are "support records", including RRSIG's.
> 



From willem at nlnetlabs.nl  Wed Apr  6 18:21:25 2016
From: willem at nlnetlabs.nl (Willem Toorop)
Date: Wed, 6 Apr 2016 15:21:25 -0300
Subject: [getdns-users] [DNSSEC-Transparency] Example using the
 "dnssec_return_validation_chain" extension
In-Reply-To: <87fuuy3fdb.fsf@nordberg.se>
References: <878u2sqrj7.fsf@localhost> <56BC5130.8050400@nlnetlabs.nl>
 <56BC5384.50502@nlnetlabs.nl> <877fibo32j.fsf@localhost>
 <56D03416.9060200@nlnetlabs.nl> <87oa9te5yd.fsf@localhost>
 <57010269.3080001@nlnetlabs.nl> <87vb3yvqnx.fsf@localhost>
 <57013AD0.1070902@nlnetlabs.nl> <87h9fitypj.fsf@nordberg.se>
 <57051EA1.8060800@nlnetlabs.nl> <87fuuy3fdb.fsf@nordberg.se>
Message-ID: <570553A5.2020407@nlnetlabs.nl>

Op 06-04-16 om 12:51 schreef Linus Nordberg:
> Willem Toorop <willem at nlnetlabs.nl> wrote
> Wed, 6 Apr 2016 11:35:13 -0300:
> 
> | Op 03-04-16 om 13:59 schreef Linus Nordberg:
> | > Willem Toorop <willem at nlnetlabs.nl> wrote
> | > Sun, 3 Apr 2016 12:46:24 -0300:
> | > 
> | > | Op 03-04-16 om 09:10 schreef Linus Nordberg:
> | > | > Willem Toorop <willem at nlnetlabs.nl> wrote
> | > | > Sun, 3 Apr 2016 08:45:45 -0300:
> | > | > 
> | > | > | > Next question is if I can somehow access the canonicalised data that the
> | > | > | > validation is based on? From skimming the code, it seems to me that
> | > | > | > canonicalisation is performed but I haven't figured out if it's safe to
> | > | > | > assume that I could simply use the data in getdns_list's that I passed
> | > | > | > to getdns_validate_dnssec2() once it returns.
> | > | > | 
> | > | > | No, the verification buffers are temporarily used for the verification
> | > | > | process only.  But why do you need the canonicalized form?
> | > | > 
> | > | > (Cross posting to dnssec-transparency@ where this discussion is more on
> | > | > topic.)
> | > | > 
> | > | > A DNSSEC Transparency log server should store RR's in canonicalised form
> | > | > in order to be able to return an old SCT when a submitted record already
> | > | > exists in the log. Without this it'd be even easier to spam a log to
> | > | > death.
> | > | > 
> | > | > At least that's my understanding of why this is important. Another less
> | > | > important reason would be to make it easier for auditors and monitors to
> | > | > verify log behaviour and content.
> | > | 
> | > | Ok... well, then we need to do something about it :)
> | > | So, the conversion to wireformat functions already get rid of
> | > | compression if you remove the /rdata/rdata_raw fields from the rr_dicts.
> | > |  I suppose it could be an extra parameter in that conversion function to
> | > | write out canonicalized form.  Or a different function names...  for
> | > | example:
> | > | 
> | > | getdns_return_t
> | > | getdns_rr_dict2canonical_wire(
> | > |     const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);
> | > | 
> | > | getdns_return_t
> | > | getdns_rr_dict2canonical_wire_buf(
> | > | 	const getdns_dict *rr_dict, uint8_t *wire, size_t *wire_sz);
> | > | 
> | > | getdns_return_t
> | > | getdns_rr_dict2canonical_wire_scan(
> | > | 	const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);
> | > | 
> | > | What do you think?
> | > 
> | > That'd be very useful for my purposes.
> | 
> | Yes, I've been chewing on this a little bit, and considering that
> | canonical order also seems important, perhaps we can come up with some
> | more generic functions.
> 
> I've been looking a bit closer at draft-zhang-trans-ct-dnssec-03 and
> think that I only need the submitted DS record to be canonicalised. So
> no ordering is necessary and only section 6.2 of RFC4034 needs to be
> considered in my case.
> 
> If you don't think there's a good reason for adding the feature of
> returning canonicalised records in getdns, I could probably handle this
> myself.

Linus,

After a meeting a few minutes ago about
draft-shore-tls-dnssec-chain-extension-02, I realize I need to have
those functions for our draft anyway.  So they will be added.

I will also consider returning the validation chain already
canonicalized and sorted as a future improvement.  Currently this is not
the optimal path; the chain is extracted from the actual replies and not
the verification buffers.  Plus, you need the separate functions to
canonicalize the answer anyway.  But it might be a good future optimization.

> 
> If so, can this list explain if point 5 in RFC4034 section 6.2 is
> applicable to this case, a DS record? I don't really understand it.
> 
>    5.  the RR's TTL is set to its original value as it appears in the
>        originating authoritative zone or the Original TTL field of the
>        covering RRSIG RR.

When you lookup the DS at a recursive resolver, the TTL will be the time
it has left in the recursive's cache and not the TTL that the DS had at
the authoritative server.  That TTL is in the "Original TTL" rdata field
of the RRSIG associated with the DS.  It would make sense for DNSSEC
transparency log to store the "Original TTL" with the DS yes.

-- Willem

> 
> 
> 
> | For example one to canonicalize a single rr_dict:
> | 
> | getdns_return_t
> | getdns_rr_dict_canonicalize(
> |     const getdns_list *rr_dict, getdns_list **canonicalized_rr_dict);
> 
> Should getdns_list be getdns_dict here? Or will the function perform
> canonicalisation of all dicts in the list?
> 
> 
> | and one to sort:
> | 
> | getdns_return_t
> | getdns_rr_dicts_sort(const getdns_list *unsorted, getdns_list **sorted);
> | 
> | where the sorting function makes sure the signature rr_dicts are right
> | behind the rrsets they sign.
> | 
> | What do you think?
> 
> I think this would be useful, not the least for analytic and test
> tools. If it's not too much work, I think it'd be a good idea!
> 



From rick at openfortress.nl  Wed Apr  6 19:25:25 2016
From: rick at openfortress.nl (Rick van Rein)
Date: Wed, 06 Apr 2016 21:25:25 +0200
Subject: [getdns-users] GetDNS 1.0 / port to Go?
Message-ID: <570562A5.5040603@openfortress.nl>

Hey Willem,

> I am very pleased to announce that we have a beta release for version
> 1.0.0 of getdns

A good reason to be proud of yourself, and your hard work!

I'm very curious if our discussion on the API will lead to something;
and am open to further interaction on it of course.

There are boundless languages calling for GetDNS of course ;-) but I
wonder if Go has crossed your mind.  There are so many new languages
that walk up some frivolous aisle but Go seems to crack a lot of hard
nuts that we are now dealing with manually in everyday practice using
C.  I don't mean Garbage Collection, but types like maps, array slices
and coroutines with automatic scheduling and CSP communication channels
hit quite a few sweet spots with me.  You might want to take this one
language seriously, and port GetDNS to it... or use it as your native
platform?

(And yes, I understand I'd be welcome to donate.  It's not my place
though; my strengt lies elsewhere.  Which, I understand, may disempower
this suggestion and reduce it to a mere +1 vote.)


Cheers,
 -Rick


From melinda.shore at nomountain.net  Wed Apr  6 19:36:37 2016
From: melinda.shore at nomountain.net (Melinda Shore)
Date: Wed, 6 Apr 2016 11:36:37 -0800
Subject: [getdns-users] GetDNS 1.0 / port to Go?
In-Reply-To: <570562A5.5040603@openfortress.nl>
References: <570562A5.5040603@openfortress.nl>
Message-ID: <57056545.10501@nomountain.net>

Go has been on the list for awhile now, although it's not
clear whether or not there's much demand for it given the
existing Go DNS libraries.  It should be fairly straightforward
to use with CGo, although a native port would likely be more
effort.

Melinda


From rick at openfortress.nl  Wed Apr  6 21:12:23 2016
From: rick at openfortress.nl (Rick van Rein)
Date: Wed, 06 Apr 2016 23:12:23 +0200
Subject: [getdns-users] GetDNS 1.0 / port to Go?
In-Reply-To: <57056545.10501@nomountain.net>
References: <570562A5.5040603@openfortress.nl> <57056545.10501@nomountain.net>
Message-ID: <57057BB7.6020501@openfortress.nl>

Hi Melinda,

Thanks;

> Go has been on the list for awhile now, although it's not
> clear whether or not there's much demand for it given the
> existing Go DNS libraries.  It should be fairly straightforward
> to use with CGo, although a native port would likely be more
> effort.

I suppose a native port is also more valuable; it's a bit mad to mimic dictionaries in C and port them into Go when Go has those types natively.  But I understand this to be a desire-versus-time issue.  No surprise there :)

Please discount my suggestion as "yet another vote for support in Go" then!

-Rick


From linus at nordu.net  Wed Apr  6 15:51:12 2016
From: linus at nordu.net (Linus Nordberg)
Date: Wed, 06 Apr 2016 17:51:12 +0200
Subject: [getdns-users] [DNSSEC-Transparency] Example using the
	"dnssec_return_validation_chain" extension
In-Reply-To: <57051EA1.8060800@nlnetlabs.nl> (Willem Toorop's message of "Wed, 
 6 Apr 2016 11:35:13 -0300")
References: <878u2sqrj7.fsf@localhost> <56BC5130.8050400@nlnetlabs.nl>
 <56BC5384.50502@nlnetlabs.nl> <877fibo32j.fsf@localhost>
 <56D03416.9060200@nlnetlabs.nl> <87oa9te5yd.fsf@localhost>
 <57010269.3080001@nlnetlabs.nl> <87vb3yvqnx.fsf@localhost>
 <57013AD0.1070902@nlnetlabs.nl> <87h9fitypj.fsf@nordberg.se>
 <57051EA1.8060800@nlnetlabs.nl>
Message-ID: <87fuuy3fdb.fsf@nordberg.se>

Willem Toorop <willem at nlnetlabs.nl> wrote
Wed, 6 Apr 2016 11:35:13 -0300:

| Op 03-04-16 om 13:59 schreef Linus Nordberg:
| > Willem Toorop <willem at nlnetlabs.nl> wrote
| > Sun, 3 Apr 2016 12:46:24 -0300:
| > 
| > | Op 03-04-16 om 09:10 schreef Linus Nordberg:
| > | > Willem Toorop <willem at nlnetlabs.nl> wrote
| > | > Sun, 3 Apr 2016 08:45:45 -0300:
| > | > 
| > | > | > Next question is if I can somehow access the canonicalised data that the
| > | > | > validation is based on? From skimming the code, it seems to me that
| > | > | > canonicalisation is performed but I haven't figured out if it's safe to
| > | > | > assume that I could simply use the data in getdns_list's that I passed
| > | > | > to getdns_validate_dnssec2() once it returns.
| > | > | 
| > | > | No, the verification buffers are temporarily used for the verification
| > | > | process only.  But why do you need the canonicalized form?
| > | > 
| > | > (Cross posting to dnssec-transparency@ where this discussion is more on
| > | > topic.)
| > | > 
| > | > A DNSSEC Transparency log server should store RR's in canonicalised form
| > | > in order to be able to return an old SCT when a submitted record already
| > | > exists in the log. Without this it'd be even easier to spam a log to
| > | > death.
| > | > 
| > | > At least that's my understanding of why this is important. Another less
| > | > important reason would be to make it easier for auditors and monitors to
| > | > verify log behaviour and content.
| > | 
| > | Ok... well, then we need to do something about it :)
| > | So, the conversion to wireformat functions already get rid of
| > | compression if you remove the /rdata/rdata_raw fields from the rr_dicts.
| > |  I suppose it could be an extra parameter in that conversion function to
| > | write out canonicalized form.  Or a different function names...  for
| > | example:
| > | 
| > | getdns_return_t
| > | getdns_rr_dict2canonical_wire(
| > |     const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);
| > | 
| > | getdns_return_t
| > | getdns_rr_dict2canonical_wire_buf(
| > | 	const getdns_dict *rr_dict, uint8_t *wire, size_t *wire_sz);
| > | 
| > | getdns_return_t
| > | getdns_rr_dict2canonical_wire_scan(
| > | 	const getdns_dict *rr_dict, uint8_t **wire, size_t *wire_sz);
| > | 
| > | What do you think?
| > 
| > That'd be very useful for my purposes.
| 
| Yes, I've been chewing on this a little bit, and considering that
| canonical order also seems important, perhaps we can come up with some
| more generic functions.

I've been looking a bit closer at draft-zhang-trans-ct-dnssec-03 and
think that I only need the submitted DS record to be canonicalised. So
no ordering is necessary and only section 6.2 of RFC4034 needs to be
considered in my case.

If you don't think there's a good reason for adding the feature of
returning canonicalised records in getdns, I could probably handle this
myself.

If so, can this list explain if point 5 in RFC4034 section 6.2 is
applicable to this case, a DS record? I don't really understand it.

   5.  the RR's TTL is set to its original value as it appears in the
       originating authoritative zone or the Original TTL field of the
       covering RRSIG RR.



| For example one to canonicalize a single rr_dict:
| 
| getdns_return_t
| getdns_rr_dict_canonicalize(
|     const getdns_list *rr_dict, getdns_list **canonicalized_rr_dict);

Should getdns_list be getdns_dict here? Or will the function perform
canonicalisation of all dicts in the list?


| and one to sort:
| 
| getdns_return_t
| getdns_rr_dicts_sort(const getdns_list *unsorted, getdns_list **sorted);
| 
| where the sorting function makes sure the signature rr_dicts are right
| behind the rrsets they sign.
| 
| What do you think?

I think this would be useful, not the least for analytic and test
tools. If it's not too much work, I think it'd be a good idea!



From linus at nordu.net  Wed Apr  6 19:15:00 2016
From: linus at nordu.net (Linus Nordberg)
Date: Wed, 06 Apr 2016 21:15:00 +0200
Subject: [getdns-users] [DNSSEC-Transparency] Example using the
	"dnssec_return_validation_chain" extension
In-Reply-To: <570553A5.2020407@nlnetlabs.nl> (Willem Toorop's message of "Wed, 
 6 Apr 2016 15:21:25 -0300")
References: <878u2sqrj7.fsf@localhost> <56BC5130.8050400@nlnetlabs.nl>
 <56BC5384.50502@nlnetlabs.nl> <877fibo32j.fsf@localhost>
 <56D03416.9060200@nlnetlabs.nl> <87oa9te5yd.fsf@localhost>
 <57010269.3080001@nlnetlabs.nl> <87vb3yvqnx.fsf@localhost>
 <57013AD0.1070902@nlnetlabs.nl> <87h9fitypj.fsf@nordberg.se>
 <57051EA1.8060800@nlnetlabs.nl> <87fuuy3fdb.fsf@nordberg.se>
 <570553A5.2020407@nlnetlabs.nl>
Message-ID: <87shyy1rd7.fsf@nordberg.se>

Willem Toorop <willem at nlnetlabs.nl> wrote
Wed, 6 Apr 2016 15:21:25 -0300:

| > | Yes, I've been chewing on this a little bit, and considering that
| > | canonical order also seems important, perhaps we can come up with some
| > | more generic functions.
| > 
| > I've been looking a bit closer at draft-zhang-trans-ct-dnssec-03 and
| > think that I only need the submitted DS record to be canonicalised. So
| > no ordering is necessary and only section 6.2 of RFC4034 needs to be
| > considered in my case.
| > 
| > If you don't think there's a good reason for adding the feature of
| > returning canonicalised records in getdns, I could probably handle this
| > myself.
| 
| Linus,
| 
| After a meeting a few minutes ago about
| draft-shore-tls-dnssec-chain-extension-02, I realize I need to have
| those functions for our draft anyway.  So they will be added.

Interesting. Glad to see a followup on agl's thing that you mentioned in
Yokohama. Seems useful.


| I will also consider returning the validation chain already
| canonicalized and sorted as a future improvement.  Currently this is not
| the optimal path; the chain is extracted from the actual replies and not
| the verification buffers.  Plus, you need the separate functions to
| canonicalize the answer anyway.  But it might be a good future optimization.

OK.


| > If so, can this list explain if point 5 in RFC4034 section 6.2 is
| > applicable to this case, a DS record? I don't really understand it.
| > 
| >    5.  the RR's TTL is set to its original value as it appears in the
| >        originating authoritative zone or the Original TTL field of the
| >        covering RRSIG RR.
| 
| When you lookup the DS at a recursive resolver, the TTL will be the time
| it has left in the recursive's cache and not the TTL that the DS had at
| the authoritative server.  That TTL is in the "Original TTL" rdata field
| of the RRSIG associated with the DS.  It would make sense for DNSSEC
| transparency log to store the "Original TTL" with the DS yes.

I see. Good info.

Since I require, even if the dnssec trans draft does not, that the
client includes the RRSIG for the DS in the submission (avoiding the log
to add pieces of information from its own view of the DNS tree) I guess
it doesn't seem crazy to "rewrite" the DS like this before checking for
a duplicate. (If there's already an entry in the log matching the
submitted record, we don't want to store the record again.)

Any thoughts on pros and cons?



From gmadkat1 at gmail.com  Sat Apr  2 01:05:42 2016
From: gmadkat1 at gmail.com (Gowri V)
Date: Fri, 1 Apr 2016 21:05:42 -0400
Subject: [getdns-api] getdns 1.0.0b1 release
In-Reply-To: <56FD1553.2070400@nlnetlabs.nl>
References: <56FD1553.2070400@nlnetlabs.nl>
Message-ID: <CADXFHE8PhmrgoPiGkk92SvuVCSG-w3Qqi5dHdx7tHkT7BzhNSQ@mail.gmail.com>

Dear All,

I am happy to announce that we have a beta release for version
1.0.0 of the Node.js bindings for the getdnsapi
<http://getdnsapi.net/> implementation
of getdns <http://vpnc.org/getdns-api/>.

This release is now published to the npm repository and can be installed
using the command:
npm install getdns

I kindly ask you to review and try out this beta release
thoroughly. The 1.0.0 release will follow as soon as we are confident
we haven't missed anything and it is ready for production.
Please let me know if you find any problems in this version.

Regards,

Gowri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.getdnsapi.net/pipermail/users/attachments/20160401/05e9b47e/attachment.htm>