AC_CHECK_PROG([DOXYGEN], [doxygen]) should be AC_PATH_PROG([DOXYGEN], [doxygen])

Following error trying to use libev on FreeBSD. This was in a call to getdns_general_sync!

Assertion failed: (("libev: ev_signal_start called with illegal signal number", w->signum > 0 && w->signum < EV_NSIG)), function ev_signal_start, file ev.c, line 3748.

libuv works fine.

I have been checking some stuff with wireshark and everything appears to go over UDP regardless of the the transport set in getdns_context_set_dns_transport();

This appears to be due to missing :'s in the six calls to set_ub_string_opt() in set_ub_dns_transport.
The current code reads:
set_ub_string_opt(context, "do-tcp", "yes");
it should read
set_ub_string_opt(context, "do-tcp:", "yes");

See http://unbound.net/documentation/libunbound.html

I will do a PR once I figure out a nice way to test the actual transport used. Please shout if this is me doing something stupid!

Since homebrew apparently doesn’t install the libgetdns_ext_event libs required to try the examples (cf. Homebrew/legacy-homebrew#28027), I tried the binary installer and it appears that it just dumps everything into /usr/local :

drwxr-xr-x    5 root   wheel   170B 26 Feb 00:08 getdns
-rwxr-xr-x    1 root   wheel   110K 26 Feb 00:08 libgetdns-0.1.0.0.dylib
-rw-r--r--    1 root   wheel   499K 26 Feb 00:08 libgetdns.a
lrwxr-xr-x    1 58540  wheel    23B  1 Apr 08:21 libgetdns.dylib -> libgetdns-0.1.0.0.dylib
-rw-r--r--    1 root   wheel   1,1K 26 Feb 00:08 libgetdns.la
-rwxr-xr-x    1 root   wheel    10K 26 Feb 00:08 libgetdns_ext_event-0.1.0.0.dylib
-rw-r--r--    1 root   wheel    12K 26 Feb 00:08 libgetdns_ext_event.a
lrwxr-xr-x    1 58540  wheel    33B  1 Apr 08:21 libgetdns_ext_event.dylib -> libgetdns_ext_event-0.1.0.0.dylib
-rw-r--r--    1 root   wheel   1,3K 26 Feb 00:08 libgetdns_ext_event.la
drwxr-xr-x    3 root   wheel   102B 26 Feb 00:08 doc

Please, either install to /opt/getdns if you want a whole hierarchy or (even better) use the appropriate sub-directories like /usr/local/lib, /usr/local/include, etc.

FWIW, the installers are also outdated (0.1.0 vs 0.1.1).

May be related to fix for #18

Create a context, issue an async query, cancel the query. In the callback, destroy the context. I am guessing this occurs in a timeout also. If this occurs in timeout, we would want to make sure the event loop extensions still work with minimal/no change.

cedespeaux:

So based on the information in the spec, I'm not sure if this is the expected result or not. I am querying dell,com, which is an unsigned domain, with qtype ANY and the dnssec_return_secure_only extension. None of the ANSWER section records are returned since the domain is insecure, however, the header still reports "ancount": 12 representiing the number of records that would be returned without the extension. This may be the correct behaviour but it's hard to say based on the information in the spec alone.

For that matter, should the ADDITIONAL records be returned? They aren't secure either.

wtoorop:
Hi Craig & the rest, I am wrestling a bit with what to do here, though I do think that the procedure you observed (of not including answer resource records based on DNSSEC policy) is confusing. I would rather handle the inclusion/exclusion policy on a packet/reply-level. I have changed the behaviour and it is now the following: - All DNSSEC extension add the "dnssec_status" to the reply dicts. - With "dnssec_return_status" and "dnssec_return_only_secure", the "status" in the response dict is GETDNS_RESPSTATUS_NO_NAME when all replies are NXDOMAIN and/or BOGUS. - With "dnssec_return_only_secure", the "status" in the response dict is GETDNS_RESPSTATUS_NO_SECURE_ANSWERS when non of the replies are SECURE, even when all were NXDOMAIN. - When "dnssec_return_validation_chain" is set, besides the validation chain, all replies are returned, even when other DNSSEC extensions are set that would otherwise exclude these replies. This is the only modus were one can observe the "dnssec_status" to be GETDNS_DNSSEC_BOGUS. - When the "dnssec_return_status" extension is set (and "dnssec_return_validation_chain" is not), only non-bogus replies are returned. - When the "dnssec_return_only_secure" extension is set (and "dnssec_return_validation_chain" is not), only secure replies are returned. Speak-up when you believe this should be handled differently, or that the specification should be modified to be clearer on this.

(#111 from private repo)

Raised in discussion between Neel and John Dickinson - 140805 - target 0.1.5?

Per semantic versioning we have lattitude to change things without incrementing the patch number since we are on release 0, however it might be good to increment it anyway (so that we have tag/branch 0.1.1) to pick up some of the recent changes.

I would like to include a few more fixes to the configure script for the next patch release, what do folks think about marking that release this Friday?

Our generated documentation via doxygen is weak, we need to spend some time properly documenting the code and adding sufficient details to support doxygen more effectively.

Related to the ldns refactoring and needs for TCP

Willem will create function prototypes to discuss, because design is needed

Blocked waiting for more ldns functionality in GetDNS.

on cdespeaux's behalf: While working on the Perl bindings for getdns, I have stumbled across a bug. I added a call to getdns_dict_remove_name to my "make test" file after defining the XSUB to verify I could remove a name from a dict. Although, the item was successfully removed, getdns_dict_remove_name returned GETDNS_RETURN_GENERIC_ERROR rather than GETDNS_RETURN_GOOD. Looking at the code, the last line in the subroutine is "return GETDNS_RETURN_GENERIC_ERROR;".

The first DNSSEC example in https://getdnsapi.net/spec.html#a6 seems wrong: it says

this_ret = getdns_dict_get_int(this_rdata, "dnssec_status", &this_dnssec_status);

but it should be:

this_ret = getdns_dict_get_int(this_rdata, "dnssec_status", this_dnssec_status);

per the definition of getdns_dict_get_int:

getdns_dict_get_int (getdns_dict *this_dict,
          char *name,
          uint32_t *answer)

12 August 2014

getdns weekly meeting Agenda:

• github issues for the 0.1.4 release milestone (reminder: add yours today)
• Transferred from last week: Python update (Melinda) and Python questions/comments (Shumon)
• Coordination of getdns-related talks for DNS-OARC and DNSSEC Workshop at ICANN51 (due date for ICANN workshop is 8/13)
• Coordination on RIPE workshop/hands-on tutorial proposal - interested in proposing and serving as instructors: Glen / Shumon / Willem(?) / ?
• Expected timing of multi-file descriptor revision (Neel)

Meeting ends after 45 mins

————————————————

Follow-on TCP-related meeting (same Hangout) Agenda:

• Required participants from Duane, Allison, John, Sara and Willem
• Discussion of TCP, T-DNS, ldns plans
• Meeting ends after 45 mins

Tested on FreeBSD 10-RELEASE-p1

I am guessing there are fixed paths in a Makefile.in????

There is some concern that developers using the API might find it unpleasant to wade through the response data specified in the description so there might be room to offer the results in a more easily digestible format.

One approach would be to offer an entry point that returns the data as a struct, another approach would be to offer a helper function that extracts a specific piece of data from the response (such as the IPv4/6 address from an A record).

(#23 from private repo)

• commits done by COB Wed, 5/22, branch created from master
• testing release branch Thu/Fri 5/23-5/24, bug fixes only
• release announced COB Fri 5/24

On FreeBSD 10.0-RELEASE-p1 running configure with the following arguments

--with-libevent
make example ok (as expected from the README)
make test failed

--with-libuv
make example failed (as expected from the README)
make test ok

--with-libev
make example failed (as expected from the README)
make test failed

No args.
make example failed (as expected from the README)
make test ok

After I finally managed to compile an example on OS X (you seriously should document that) using

clang  -I/usr/local/getdns -L/usr/local -I/usr/local -levent -lgetdns_ext_event -lgetdns t.c

the binary crashes with the following error:

dyld: Library not loaded: /Users/gwiley/getdnsosx/export/lib/libgetdns_ext_event-0.1.0.0.dylib
  Referenced from: /Users/hynek/gda/./a.out
  Reason: image not found
fish: Job 1, './a.out' terminated by signal SIGTRAP (Trace or breakpoint trap)

In other words: nobody except Glen has ever used the OS X binary package successfully.

I’m not really intimate with OS X’s linking/loading/packaging, but it appears that https://github.com/getdnsapi/getdns/blob/master/getdns.pmdoc/02lib-contents.xml is the problem.

Need further modifications to libunbound

all, I download the tarball ,and install with no error, when I compile the example, an error occurred.
/usr/bin/ld: cannot find -lgetdns_ext_event.

could someone help to resolve the problem??

We need to build for MS-Windows - this is a significant enough body of work to merit its own separate issue.

It would be good to support an optional system wide and per user configuration file that affects the run-time performance of the getdns library. If the files do not exist then the library runs the way it is currently designed to.

The system wide configuration would be in /etc/getdns.conf and the per user file would be ~/.getdns.conf

Some of the elements addressed in the configuration files include:

• special behavior for particular zones, forwarding, etc.
• whether to accept dhcp provided resolvers or override with manually specified resolvers
• default settings in the context such as stub vs. recursive mode for the library
• cache behavior - whether to share with the system or per user, another issue addresses this in more detail

getdns_general uses namespaces and getdns_address does not, so one can choose to use namespaces on a per query basis. However, currently namespaces are set in the prepare_for_resolution function, which initializes the "context" for those namespaces.

Solution that comes to mind:

1. having two unbound contexts, one that does local names and one that does dns only.
2. Or lift local name lookup out of unbound and put it in getdns.

I prefer the second. (Willem & Neel)

(#106 from private repo)

I see the following statements put out on the console when destroying the context within a callback.

[1393946950] libunbound[32477:0] error: libunbound/libunbound.c at 501 could not pthread_mutex_lock(&ctx->rrpipe_lock): Invalid argument
[1393946950] libunbound[32477:0] error: tube msg read failed: Bad file descriptor
[1393946950] libunbound[32477:0] error: libunbound/libunbound.c at 503 could not pthread_mutex_unlock(&ctx->rrpipe_lock): Invalid argument

The process exits fine, but ideally we shouldn't see prints like this. I believe these occur because we are firing the callback before our call to ub_process_async returns. One solution is to have the context queue up the callbacks to fire, and then fire them off once ub_process_async exits.

Provide a means for users to register their own parsers for RR types that allow them to append to the generic dictionary that contains what getdns has parsed out. For unknown types, this dictionary should initially contain the raw rdata along with type, etc.

After Glen and I agreed that query tests should be done in both recursive and stub mode I began changing my getdns_general() test suite to issue a query in recursive mode, then switch to stub mode, and issue another query. For the recursive query, I query something like "google.com" A and generically verify that I get address records in the ANSWER section, etc. For the stub mode query, I am querying a local named server I setup with a canned zone file. In this case, I actually verify that I get the exact response recorded in a character constant defined in a header file that was produced by my "golden master" test program. What I've found is that if I do the "google.com" query in recursive mode that the next query for "kitchensink.net" is also done in recursive mode even though I've switched the context to stub mode. I know this because the real "kitchensink.net" returns different records (A, SOA, etc.) than my test zone file does. If I comment out the getdns_general() call to query "google.com" then the stub mode test passes (i.e., I get the expected response).

For now to keep my test progress flowing, I am going to destroy and recreate the context between these two queries.

Neel:

We will need to re-create the unbound context. I think this is a valid bug for sure. The specification doesn't call out details on what happens to outbound requests when the resolution mode changes. I think we should document our approach in our implementation specific documentation. I propose the following for our initial release:

setting the resolution mode to something different sets a flag (just like it does today).
the context update callback is fired if one is set
when a query is issued and the resolution mode has changed, then all outbound requests are canceled prior to the new query being sent. The callback type will be GETDNS_CALLBACK_CANCEL. Alternatively, we can not fire the callback, or propose a new type that is a bit more descriptive than cancel.

(#113 from private repo)

timeframe: by August 31

features/fixes:

• fix TCP so it works when called (issue #54) - done - Python release needs
• some TCP unit tests (John)
• Bortzmayer documentation bug - fixed
• openpgp RR decoding (Shumon)

Blocked waiting for pipelining
Will need server side modifications to allow testing

Cannot install getdns with install this afternoon - no problem with other installs.

brew install getdns
Error: No available formula for getdns

Features/bug fixes targeted for 0.1.3

• libtool fix only

from Duane W during the hackathon:

I used src/example/example-hostname.c as my guide and was confused by this line for a short while:

struct getdns_bindata this_type = { 5, (void *)"IPv4" };

It took me a while to realize 5 was the length of "IPv4". Maybe there could be a helper function to populate a bindata. For example:

struct getdns_bindata this_type;
getdns_bindata_set(&this_type, "IPv4", sizeof("IPv4"));

or

getdns_bindata_set_from_str(&this_type, "IPv4");

(#57 from private repo)

I'd like to include the set/modify bindata functions that Bob Steagall's suggested

getdns_return_t getdns_list_set_bindata_2(struct getdns_list *the_list, size_t index, size_t bindata_size, uint8_t *bindata_content);
getdns_dict_set_bindata_2(struct getdns_dict *the_dict, const char *name, size_t bindata_size, uint8_t *bindata_content);
(#64 from private repo)

Timeout settings are ignored when doing synchronous lookups.
(#110 from private repo)

For package maintainers, it is challenging if there isn't an easy way to disable optional extensions. Ideally, this would also include a means to specify the path to search for the library/headers.

Today, we will automatically add support for libev/libevent/libuv/doxygen in the event they are found.

There's just been a new release of the idnkit (C with some other language APIs as well), developed and maintained by JPRS, with a non GPL open source license and full support of IDN 2008. It was recommended by a colleague who works in the area of DNS support for native American languages.

(#83 from private repo)

On 2/11 we discussed where to apply unbound_anchor (Make install? what about local install options)
and how not to send out just a hard-coded root trust anchor.

Decision for 2/25 - Willem removes the hard-coded trust anchor. Make install will run unbound_anchor.

In later releases, we will enhance this.
(#104 from private repo)

Agenda items

• 0.1.3 release - who could execute/get this out this week?
• 0.1.4 and 0.1.5 release planning/roadmapping - review updated issues #46, #47
• tdns update
• python update
• Plan next bindings: perl, java, ruby, go, php, c++
• Packaging - which other OS, how, and when?
• Quick revisit of meeting time

Items for future meetings

• Sunday after-dinner gathering in Toronto
• Windows port update (once work starts)

The sync versions of commands do not follow the API design in an important way that has a very negative effect on the Python bindings. The spec says:

The async getdns functions return GETDNS_RETURN_GOOD if the call was properly formatted.
. . .
The value returned [by an sync call] is exactly the same as the response returned in the callback if you had used the async version of the function.

However, when a sync function goes to a stub that does not respond, it returns GETDNS_RETURN_GENERIC_ERROR even if the call is properly formatted. See the attached code, the output of which is:

% ./syncstub 8.8.8.8 www.imc.org
Recursive 8.8.8.8; Domain www.imc.org; RRtype 1
The address is 207.182.41.81

% ./syncstub 8.8.8.9 www.imc.org
Recursive 8.8.8.9; Domain www.imc.org; RRtype 1
The request returned GETDNS_RETURN_GENERIC_ERROR. Exiting.

This is a significant violation of the design in that the return of a function should not be used to indicate when an upstream resolver has an error. In the case of a stub getting no answer from its upstream, the return must be GETDNS_RETURN_GOOD, and the returned dict contains a replies_tree of [], meaning "there were no replies".

/* Make the call */
getdns_return_t dns_request_return = getdns_general_sync(ThisContext, DomainToLookUp, RRtypeToLookUp,
    Extensions, &ThisResponse);
if (dns_request_return == GETDNS_RETURN_BAD_DOMAIN_NAME)
{
    fprintf(stderr, "A bad domain name was used: %s. Exiting.\n", DomainToLookUp);
    /* ... */
}
else if (dns_request_return == GETDNS_RETURN_GENERIC_ERROR)
{
    fprintf(stderr, "The request returned GETDNS_RETURN_GENERIC_ERROR. Exiting.\n");
    /* ... */
}
else ...

op 16-02-14 12:26, amankin schreef:
Does the iterative code just swing into play even though in stub mode? Heh I talked with Paul Hoffman on this on Wednesday - when in stub mode, those extensions should mean 'forward the DNSSEC request' and we should either get responses suitable to the extension from our first hop or give an error if that does not happen.

What does that mean? The AD bit sets the "dnssec_status" to GETDNS_DNSSEC_SECURE and SERVFAIL sets "dnssec_status" to GETDNS_DNSSEC_BOGUS, the rest is GETDNS_DNSSEC_INSECURE?
DNSSEC iterative querying is not to happen

Not even with dnssec_return_validation_chain? Why not?

but a DNSSEC query in any three extensions should provide a result. Paul agreed the spec needs to express this differently.

Ok, this is our current behavior in stub mode: Currently our implementation does do iterative querying of DNSSEC records with all three extensions. This works perfectly with an DNSSEC aware resolver (even when it doesn't do the DNSSEC itself), but will render all answers BOGUS when talking to an incapable DNSSEC resolver. (because the DNSKEY of the root doesn't have RRSIGs)
…
-- Willem
(#112 from private repo)

It would be interesting to port getdns to capsicum - a bare bones port that deals with the changed system calls would be a sufficient first step. Further improvements to make the library more security aware might be worth discussing.

We should probably return a negative response dictionary for errors. It would be nice if the callback received at least the name being queried.
(#108 from private repo)

Need to detect and use changes to system files such as /etc/resolv.conf and /etc/hosts for contexts that are using them. (#9 from private repo)

(#72 from private repo)

The setter is getdns_context_set_resolution_type() but the in the information returned from getdns_context_get_api_information() the dictionary key is "resolver_type". These should probably be brought into alignment; as Neel pointed out it would have less impact on existing code to change the dictionary key to "resolution_type".

examples on FreeBSD built with libevent do not work (fail with a broken pipe at run time). This should be fixed in the next release.

libunbound appears to be returning servfail when it can not recurse. There is no indication that a timeout occurred.

Today, we will ignore this and always install to $(prefix)/share/doc/getdns-$(version)

Support for shared cache. A user configurable (see issue #51 ) option to share the cache across processes on the same system and or for process running as the same user. This implies a separate process that can handle a persistent cache.

It would be useful to add an API where a trust anchor file can be added on a per context basis after it has been created. This may follow the context finalization rules. Mobile platforms can certainly benefit from this.

The API can be added to getdns_extra.h and then brought into the official header when we agree on a signature. I suggest something like:
getdns_return_t getdns_context_add_trust_anchor(getdns_context* context, const char* path); which is a mirror of the unbound API.

Should we take in a user specified format (unbound, bind, etc.) as well?

This is a very tentative and future-looking list and we will be revising it frequently

timeframe:

features/fixes:

• edns option support (client setting of MTU, support of registered codepoints)
• per system and per user config files (issue #51 )
• additional namespace support
• integration with t-dns
• sync with dnssd work
• mdns support

bindings:

• 2-3 additional language bindings - candidates Java, Perl, ruby, go, php, c++?