getdnsapi / getdns-node Goto Github PK

When running build tests on commit/push, some of the tests fail due to unexpected (non-)timeouts thus "failing" the entire build suite. Due to the nature of the tests, testing against "real world" domain names etcetera, it would be good if these intermittently failing tests can be identified and made more stable.

Instead of annoying developers with failing tests, perhaps timeouts can be increased -- and perhaps even automatic retries for certain tests?

It might seem contrived, but it's showing that Zalgo is indeed unleashed.

• Create a context.
• Start a lookup, for example using ctx.address(), with a callback (expected to be called asynchronously).
• Store the transaction id (which is a synchronous operation): const transId = ctx.address(name, callback)
• Synchronously call const cancelSuccess = context.cancel(transactionId) (which also is a synchronous operation).
• Now the lookup callback will also be called synchronously.

During testing, and possibly in the wild, the callback being called means the lookup completed, the test is over, and the context can be destroyed. This unfortunately also prevents further synchronous and asynchronous expectations from being checked (or at least from being reported). This means it's hard to tell if/how/where the code will continue to execute.

The following test is written to show that a transaction should not be able to be cancelled twice. The first call to cancel() should return true, second call should false. The second cancel() call is never invoked, within the scope of the test. Outside of the scope of collecting test results it might be called though -- with or without side-effect. (The callback might also inadvertently be called twice, which is a big node.js no-no.) The test passes, despite the synchronous call to expect().fail().

// Take from the tests, executed using mocha.
it("Should not be able to synchronously cancel the query twice", function(done) {
    const ctx = getdns.createContext({
        resolution_type: getdns.RESOLUTION_STUB,
    });

    let callCount = 0;

    const transId = ctx.address("nlnetlabs.nl", (err, result) => {
        // TODO BUG: this callback is being called synchronously due to cancel() being synchronous.
        // TODO BUG: the callback might be called twice. This might not be detectable after the test has ended.
        callCount++;
        expect(callCount).to.be(1);

        expect(err).to.be.an("object");
        expect(result).to.be(null);
        expect(err).to.have.property("msg");
        expect(err).to.have.property("code");
        expect(err.code).to.equal(getdns.CALLBACK_CANCEL);
        shared.destroyContext(ctx, done);
    });

    expect(transId).to.be.ok();

    const cancelResult = ctx.cancel(transId);

    // TODO BUG: this code is never reached, at least not within the scope of the test.
    expect().fail("Something is wrong, because this is never called (or at least not reported).");

    expect(cancelResult).to.be.ok();

    // NOTE: should not be able to cancel the same transaction twice.
    const cancelResult2 = ctx.cancel(transId);
    expect(cancelResult2).to.not.be.ok();
});

Unleasing Zalgo means that work might perform work synchronously, or it might performed asynchronously. With connected functions, such as those on the context object, all public functions should be either synchronous or asynchronous. As the lookups rely on callbacks, all functions need to be asynchronous.

• Returning a synchronous value from a function call accepting a callback is out of the ordinary for a node.js API, and a bad sign.
  • const transId = ctx.address(name, callback).
• Having a function which returns a synchronous value also synchronously invoke a callback is bad.
  • const cancelSuccess = context.cancel(transactionId).
• There might be similar sync/async issues when creating destroying the context. Sync/async destruction issues seems to have been handled in getdns.js as a workaround.
• The quick fix is to make at least context.cancel(transactionId) somehow invoke the callback asynchronously.
• The better solution is to make the entire API asynchronous.
  • Promises are the current preferred way to handle a mix of synchronous and asynchronous work, and also allow a natural way forward towards async/await.
  • In the case of canceling lookups, Bluebird promises with cancellation support might be a good alternative.

It will most likely require a bunch of work to redesign the getdns-node api to be consistent and more node.js-like. The question is if the current style should be accessible (to be similar to the getdns API for the same of being similar) or if this should be a node.js API built on top of the C API getdns. Any comments?

• Current issues (possibly) include:
  • Creating the context, if some internal initialization is done asynchronously.
  • Returning the transaction id from a lookup.
  • Canceling a transaction using the transaction id.
  • Destroying the context, if any internal work is done asynchronously.

Hi there!

I installed the latest getdns with Homebew and compilation fails because a constant cannot be found:

  CXX(target) Release/obj.target/getdns/src/GNConstants.o
../src/GNConstants.cpp:87:53: error: use of undeclared identifier 'GETDNS_APPEND_NAME_TO_SINGLE_LABEL_FIRST'
    SetConstant("APPEND_NAME_TO_SINGLE_LABEL_FIRST",GETDNS_APPEND_NAME_TO_SINGLE_LABEL_FIRST,exports);
                                                    ^

While writing tests, a few "magic numbers" popped up. Turns out no all @getdnsapi/getdns API constants have been implemented in getdns-node/src/GNConstants.cpp.

• Might more be missing?
• How can changes in the @getdnsapi/getdns API -- past or future -- be detected on the code level, so that the "diff" can be implemented in getdns-node?

The closest thing that comes to mind is to diff getdns/src/getdns/getdns.h.in between releases. What the changes actually mean would then be lookup up in the API documentation. Is that enough?

We seem to be having an issue getting RRSIG records when using stub resolver.
Command line utilities getdns_query and dig return the expected RRSIG records. When doing the same through getdns-node we are receiving:
(I have edited out the DNS IP and domain names due to our corporate policy)

  "answer_type": 800,
  "canonical_name": "XXXXX",
  "just_address_answers": [],
  "replies_full": [],
  "replies_tree": [],
  "status": 901
}

Executing the following two utilities returns proper results:
./getdns_query +dnssec_return_status @xxx.xxx.xxx.xxx XXXXX A

dig @xxx.xxx.xxx.xxx XXXXX +dnssec A

Nodejs code:

var getdns = require("getdns");

var options = {
   resolution_type: getdns.RESOLUTION_STUB,
    upstream_recursive_servers: [
        ["XXX.XXX.XXX.XXX", 53],
    ],
    timeout: 7000,
    return_dnssec_status: true,
    follow_redirects: getdns.REDIRECTS_FOLLOW,
};

var context = getdns.createContext(options);

var callback = function(err, result) {
    if (err) {
        console.error(err);
    } else {
        console.log(JSON.stringify(result, null, 2));
    }
    context.destroy();
};

var extensions = {};

var transactionId = context.general("XXXX", getdns.RRTYPE_A, extensions, callback)

Are we missing something in the configuration or is DNSSEC+stub resolver just not supported in getdns-node

As specified in semantic versioning v2.0.0, pre-release version numbers must have a hyphen to separate the patch version and the pre-release name: v1.0.0-b2.

9. A pre-release version MAY be denoted by appending a hyphen and a series of dot separated identifiers immediately following the patch version. Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. Pre-release versions have a lower precedence than the associated normal version. A pre-release version indicates that the version is unstable and might not satisfy the intended compatibility requirements as denoted by its associated normal version. Examples: 1.0.0-alpha, 1.0.0-alpha.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.

The current getdns pre-release naming is in the style v1.0.0b2 and v1.1.0a1. The current getdns-node package.json has copied this format. The format is already good and useful, but in the spirit of following the semver standard, I propose that future pre-releases of getdns-node, independently of the upstream getdns, introduce this hyphen, as the default package manager for node.js, npm heavily relies on semver for version matching. The version number formatting impact is higher for node-based applications and will most likely be updated to be on the safe side when it comes to release management.

I would love to employ this library, but am unable to due to the Node.js engine constraints. The most recent version of Node.js currently supported is 10 which reaches end of life next month.

Are there any plans to update getdns-node to support newer engines?

Found this out as npm install getdns breaks due to getdns v0.1.4 being installed by brew install getdns. See #getdns/83.

getdns-node: An installation of getdns 0.1.5 or later is required.

Building and testing on Travis hasn't worked properly since June 2015.

• The current issues seems to stem from This version of node/NAN/v8 requires a C++11 compiler during compilation for iojs v3 and most likely major node versions higher than v0.12 (untested). It's just a configuration issue.
• For node v0.10 and v0.12 one test seems to be failing (see below). Could it be a timeout?

  1) getdns test TLSHostname TLS hostname validation should return successfully:
     Error: expected { msg: 'Error issuing query', code: 1 } to be falsy
      at Assertion.assert (node_modules/expect.js/index.js:96:13)
      at Assertion.ok (node_modules/expect.js/index.js:115:10)
      at Function.ok (node_modules/expect.js/index.js:499:17)
      at test/test.js:321:39
      at Context.ctx.general (getdns.js:50:27)
      at Context.<anonymous> (test/test.js:320:13)

Deprecation warnings (since Node.js v10):

• Nan::MakeCallback(...)
• Call(...) on Nan::Callback

Should either use/pass in Nan::AsyncResource, or switch to Nan::AsyncWorker (which builds upon Nan::AsyncResource).

The effect on asynchronous DNS requests should be assessed, and possibly improved. This change may help with cleanup of both finished and unfinished requests.

See

• https://travis-ci.org/github/getdnsapi/getdns-node/jobs/769298461#L309-L393
• https://github.com/nodejs/nan
• https://github.com/nodejs/nan/blob/master/doc/node_misc.md#nanmakecallback
• https://github.com/nodejs/nan/blob/master/doc/node_misc.md#api_nan_asyncresource
• https://github.com/nodejs/nan/blob/master/doc/asyncworker.md#api_nan_async_worker

../src/GNContext.cpp: In static member function ‘static void GNContext::Callback(getdns_context*, getdns_callback_type_t, getdns_dict*, void*, getdns_transaction_t)’:
../src/GNContext.cpp:832:69: warning: ‘v8::Local<v8::Value> Nan::Callback::Call(v8::Local<v8::Object>, int, v8::Local<v8::Value>*) const’ is deprecated [-Wdeprecated-declarations]
  832 |     data->callback->Call(Nan::GetCurrentContext()->Global(), 3, argv);
      |                                                                     ^
In file included from ../src/GNContext.h:32,
                 from ../src/GNContext.cpp:28:
../node_modules/nan/nan.h:1720:3: note: declared here
 1720 |   Call(v8::Local<v8::Object> target
      |   ^~~~
../src/GNContext.cpp: In static member function ‘static Nan::NAN_METHOD_RETURN_TYPE GNContext::Lookup(Nan::NAN_METHOD_ARGS_TYPE)’:
../src/GNContext.cpp:877:81: warning: ‘v8::Local<v8::Value> Nan::MakeCallback(v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*)’ is deprecated [-Wdeprecated-declarations]
  877 |         Nan::MakeCallback(Nan::GetCurrentContext()->Global(), localCb, 1, cbArgs);
      |                                                                                 ^
In file included from ../src/GNContext.h:32,
                 from ../src/GNContext.cpp:28:
../node_modules/nan/nan.h:1026:46: note: declared here
 1026 |   NAN_DEPRECATED inline v8::Local<v8::Value> MakeCallback(
      |                                              ^~~~~~~~~~~~
../src/GNContext.cpp:886:81: warning: ‘v8::Local<v8::Value> Nan::MakeCallback(v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*)’ is deprecated [-Wdeprecated-declarations]
  886 |         Nan::MakeCallback(Nan::GetCurrentContext()->Global(), localCb, 1, cbArgs);
      |                                                                                 ^
In file included from ../src/GNContext.h:32,
                 from ../src/GNContext.cpp:28:
../node_modules/nan/nan.h:1026:46: note: declared here
 1026 |   NAN_DEPRECATED inline v8::Local<v8::Value> MakeCallback(
      |                                              ^~~~~~~~~~~~
../src/GNContext.cpp:916:81: warning: ‘v8::Local<v8::Value> Nan::MakeCallback(v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*)’ is deprecated [-Wdeprecated-declarations]
  916 |         Nan::MakeCallback(Nan::GetCurrentContext()->Global(), localCb, 1, cbArgs);
      |                                                                                 ^
In file included from ../src/GNContext.h:32,
                 from ../src/GNContext.cpp:28:
../node_modules/nan/nan.h:1026:46: note: declared here
 1026 |   NAN_DEPRECATED inline v8::Local<v8::Value> MakeCallback(
      |                                              ^~~~~~~~~~~~
../src/GNContext.cpp: In static member function ‘static Nan::NAN_METHOD_RETURN_TYPE GNContext::HelperLookup(Nan::NAN_METHOD_ARGS_TYPE)’:
../src/GNContext.cpp:992:81: warning: ‘v8::Local<v8::Value> Nan::MakeCallback(v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*)’ is deprecated [-Wdeprecated-declarations]
  992 |         Nan::MakeCallback(Nan::GetCurrentContext()->Global(), localCb, 1, cbArgs);
      |                                                                                 ^
In file included from ../src/GNContext.h:32,
                 from ../src/GNContext.cpp:28:
../node_modules/nan/nan.h:1026:46: note: declared here
 1026 |   NAN_DEPRECATED inline v8::Local<v8::Value> MakeCallback(
      |                                              ^~~~~~~~~~~~
In file included from ../src/GNContext.h:31,
                 from ../src/GNContext.cpp:28:
../src/GNContext.cpp: At global scope:

Had two issues where a few "too modern" pieces of javascript code got pushed to getdns-node. Apart from setting up full a transpilation system, a simpler build/commit time test would be good.

• For browsers there is browserslist. There's talk about supporting node.js, but not sure it's functional yet.
• eslint might have suitable rules.

I've tested it multiple times with multiple versions of the getdns library and the getdns-node module and node (v6, v8 and v9) and it seems as if I send a request with enabled DNSSEC validation for specific domains I get the following segmentation fault and the whole node process dies.

My local resolver is unbound 1.6.7

const getdns = require('getdns');
var ctx = getdns.createContext({
        // Upstream recursive servers.
        upstreams : [ '127.0.0.1', ],
        // Request timeout time in milliseconds.
        timeout : 5000,
        // Always return DNSSEC status.
        return_dnssec_status : true
    });

var extensions = {
    // NOTE: enforce DNSSEC security validation and return only secure replies.
    dnssec_return_only_secure: true,
};

var domains = [ 'nic.menu', 'nic.uno', 'nic.onl', 'nic.buzz', 'nic.pink', 'nic.build', 'nic.rich', 'nic.red', 'nic.luxury', 'nic.shiksha', 'nic.kim' ],
    i = 0;
ctx.general(domains[i], getdns.RRTYPE_SOA, extensions);

node: ../deps/uv/src/unix/poll.c:120: uv_poll_start: Assertion `!(((handle)->flags & (UV_CLOSING | UV_CLOSED)) != 0)' failed.

with enabled segfault-handler:

PID 3770 received SIGSEGV for address: 0x7f2342e3ed88
/home/daemons/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x1aaa)[0x7f213c651aaa]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf890)[0x7f2140538890]
node[0x1340739]
node(uv_poll_start+0x6f)[0x13379ff]
/home/daemons/getdns/build/Release/getdns.node(+0xadea)[0x7f213df72dea]
/usr/lib/x86_64-linux-gnu/libgetdns.so.6(+0x2e4d9)[0x7f213dd234d9]
/usr/lib/x86_64-linux-gnu/libgetdns.so.6(+0x3918c)[0x7f213dd2e18c]
/usr/lib/x86_64-linux-gnu/libgetdns.so.6(+0x212ec)[0x7f213dd162ec]
/usr/lib/x86_64-linux-gnu/libgetdns.so.6(+0x21aa1)[0x7f213dd16aa1]
/usr/lib/x86_64-linux-gnu/libgetdns.so.6(+0x20b89)[0x7f213dd15b89]
/usr/lib/x86_64-linux-gnu/libgetdns.so.6(+0x20d60)[0x7f213dd15d60]
/usr/lib/x86_64-linux-gnu/libgetdns.so.6(+0x2205a)[0x7f213dd1705a]
/usr/lib/x86_64-linux-gnu/libgetdns.so.6(+0x2ff45)[0x7f213dd24f45]
/home/daemons/getdns/build/Release/getdns.node(+0xaf50)[0x7f213df72f50]
node[0x1340c08]
node(uv_run+0x156)[0x132f6d6]
node(_ZN4node5StartEiPPc+0x580)[0x10abcf0]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f214019fb45]
node[0x7ba78d]

Any idea?

If a value of the wrong type, or the wrong range/format, is passed to getdns.createContext(options) nothing happens.

The bad value is either:

• Ignored, if the type is wrong.
• Not set by getdns, as the return value from the call to getdns_context_set_* is never checked.

This means users may not know that they misconfigured their getdns context. The worst output would be if a security settings would be wrong, such as dnssec_return_only_secure: 1 instead of dnssec_return_only_secure: true. This would silently fail and leave the value as the default dnssec_return_only_secure: false. The user would probably not check to see if all values had a good DNSSEC return value, but trust getdns-node to have done so before returning the replies, completely negating the security measure.

In a closely related issue, an unknown or misspelled property would also not render any feedback to the user. This means that dnsec_return_only_secure: true would be silently ignored, again leaving the user thinking that the replies would be secure when they might not be.

When running the test suite for v2.0.0-alpha.1, it might happen that a SIGSEGV is thrown. The cause is unclear, and it only happens every few hundred test cases or few thousand DNS lookups.

• It might be related to outstanding queries.
• There might be a race condition.
• It might be because of ctx.destroy() being called from a callback.

This needs more investigation.

See for example

• https://github.com/getdnsapi/getdns-node/blob/develop/getdns.js#L50-L59
• https://github.com/getdnsapi/getdns-node/blob/develop/src/GNContext.cpp#L665-L681

Sample console output:

PID 83504 received SIGSEGV for address: 0x10
0   segfault-handler.node               0x00000001022e9d2b _ZL16segfault_handleriP9__siginfoPv + 283
1   libsystem_platform.dylib            0x00007fff9264ef1a _sigtramp + 26
2   ???                                 0x0000000300000000 0x0 + 12884901888
3   libunbound.2.dylib                  0x000000010473cb3f comm_point_close + 32
4   libunbound.2.dylib                  0x00000001047408a1 portcomm_loweruse + 58
5   libunbound.2.dylib                  0x000000010474354e serviced_delete + 68
6   libunbound.2.dylib                  0x000000010470ecab outbound_list_clear + 30
7   libunbound.2.dylib                  0x00000001046ff986 iter_clear + 46
8   libunbound.2.dylib                  0x000000010470d04a mesh_state_cleanup + 279
9   libunbound.2.dylib                  0x000000010470bc3f mesh_state_delete + 352
10  libunbound.2.dylib                  0x000000010470b7f6 mesh_delete + 38
11  libunbound.2.dylib                  0x00000001046ee65d libworker_delete_env + 42
12  libunbound.2.dylib                  0x00000001046ee615 libworker_delete_event + 22
13  libunbound.2.dylib                  0x00000001046eb7a9 ub_ctx_delete + 829
14  libgetdns.1.dylib                   0x00000001046a7bfe getdns_context_destroy + 126
15  getdns.node                         0x00000001043c8ef0 _ZN9GNContext7DestroyERKN3Nan20FunctionCallbackInfoIN2v85ValueEEE + 92
16  getdns.node                         0x00000001043caedd _ZN3Nan3impL23FunctionCallbackWrapperERKN2v820FunctionCallbackInfoINS1_5ValueEEE + 141
17  node                                0x00000001001795d1 _ZN2v88internal25FunctionCallbackArguments4CallEPFvRKNS_20FunctionCallbackInfoINS_5ValueEEEE + 369
18  node                                0x00000001001e73ac _ZN2v88internal12_GLOBAL__N_119HandleApiCallHelperILb0EEENS0_11MaybeHandleINS0_6ObjectEEEPNS0_7IsolateENS0_6HandleINS0_10HeapObjectEEESA_NS8_INS0_20FunctionTemplateInfoEEENS8_IS4_EENS0_16BuiltinArgumentsE + 924
19  node                                0x00000001001e6809 _ZN2v88internalL26Builtin_Impl_HandleApiCallENS0_16BuiltinArgumentsEPNS0_7IsolateE + 281
20  ???                                 0x00003e3fad2843a7 0x0 + 68443208958887
21  ???                                 0x00003e3fad5d8719 0x0 + 68443212449561

This notice is shown for the the most recent Travis getdns-node cron build (or at least the specific build jobs).

This job ran on our Precise, sudo: required environment which will be updated on May 3rd. You can check more details about this in our blog.

The blog states that it's because of Ubuntu Precise 12.04 LTS End of Life being 2017-04-28. It's not great to test on a dist which has reached EOL; the Travis configuration should be updated.

If other dists/operating systems are also available, it'd be nice to run Travis on them as well.

Having difficulty installing this. Any ideas?

mike@blob:~/meteor/dns2$ npm install getdns

> [email protected] install /home/mike/meteor/dns2/node_modules/getdns
> node-gyp rebuild

make: Entering directory '/home/mike/meteor/dns2/node_modules/getdns/build'
  CXX(target) Release/obj.target/getdns/src/GNContext.o
In file included from ../src/GNContext.h:32:0,
                 from ../src/GNContext.cpp:28:
../../nan/nan.h:324:27: error: redefinition of ‘template<class T> v8::Local<T> Nan::imp::NanEnsureHandleOrPersistent(const v8::Local<T>&)’
   NAN_INLINE v8::Local<T> NanEnsureHandleOrPersistent(const v8::Local<T> &val) {
                           ^
../../nan/nan.h:319:17: note: ‘template<class T> v8::Handle<T> Nan::imp::NanEnsureHandleOrPersistent(v8::Handle<T>&)’ previously declared here
   v8::Handle<T> NanEnsureHandleOrPersistent(const v8::Handle<T> &val) {
                 ^
../../nan/nan.h:344:27: error: redefinition of ‘template<class T> v8::Local<T> Nan::imp::NanEnsureLocal(v8::Handle<T>&)’
   NAN_INLINE v8::Local<T> NanEnsureLocal(const v8::Handle<T> &val) {
                           ^
../../nan/nan.h:334:27: note: ‘template<class T> v8::Local<T> Nan::imp::NanEnsureLocal(const v8::Local<T>&)’ previously declared here
   NAN_INLINE v8::Local<T> NanEnsureLocal(const v8::Local<T> &val) {
                           ^
../../nan/nan.h:757:13: error: ‘node::smalloc’ has not been declared
     , node::smalloc::FreeCallback callback
             ^
../../nan/nan.h:757:35: error: expected ‘,’ or ‘...’ before ‘callback’
     , node::smalloc::FreeCallback callback
                                   ^
../../nan/nan.h: In function ‘v8::Local<v8::Object> NanNewBufferHandle(char*, size_t, int)’:
../../nan/nan.h:761:50: error: ‘callback’ was not declared in this scope
         v8::Isolate::GetCurrent(), data, length, callback, hint);
                                                  ^
../../nan/nan.h:761:60: error: ‘hint’ was not declared in this scope
         v8::Isolate::GetCurrent(), data, length, callback, hint);
                                                            ^
../../nan/nan.h: In function ‘v8::Local<v8::Object> NanNewBufferHandle(const char*, uint32_t)’:
../../nan/nan.h:768:67: error: call of overloaded ‘New(v8::Isolate*, const char*&, uint32_t&)’ is ambiguous
     return node::Buffer::New(v8::Isolate::GetCurrent(), data, size);
                                                                   ^
../../nan/nan.h:768:67: note: candidates are:
In file included from ../../nan/nan.h:25:0,
                 from ../src/GNContext.h:32,
                 from ../src/GNContext.cpp:28:
/home/mike/.node-gyp/5.0.0/include/node/node_buffer.h:31:40: note: v8::MaybeLocal<v8::Object> node::Buffer::New(v8::Isolate*, v8::Local<v8::String>, node::encoding) <near match>
 NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                        ^
/home/mike/.node-gyp/5.0.0/include/node/node_buffer.h:31:40: note:   no known conversion for argument 3 from ‘uint32_t {aka unsigned int}’ to ‘node::encoding’
/home/mike/.node-gyp/5.0.0/include/node/node_buffer.h:43:40: note: v8::MaybeLocal<v8::Object> node::Buffer::New(v8::Isolate*, char*, size_t) <near match>
 NODE_EXTERN v8::MaybeLocal<v8::Object> New(v8::Isolate* isolate,
                                        ^
/home/mike/.node-gyp/5.0.0/include/node/node_buffer.h:43:40: note:   no known conversion for argument 2 from ‘const char*’ to ‘char*’
In file included from ../src/GNContext.h:32:0,
                 from ../src/GNContext.cpp:28:
../../nan/nan.h: In function ‘v8::Local<v8::Object> NanNewBufferHandle(uint32_t)’:
../../nan/nan.h:772:61: error: could not convert ‘node::Buffer::New(v8::Isolate::GetCurrent(), ((size_t)size))’ from ‘v8::MaybeLocal<v8::Object>’ to ‘v8::Local<v8::Object>’
     return node::Buffer::New(v8::Isolate::GetCurrent(), size);
                                                             ^
../../nan/nan.h: In function ‘v8::Local<v8::Object> NanBufferUse(char*, uint32_t)’:
../../nan/nan.h:779:12: error: ‘Use’ is not a member of ‘node::Buffer’
     return node::Buffer::Use(v8::Isolate::GetCurrent(), data, size);
            ^
../src/GNContext.cpp: In static member function ‘static void GNContext::Callback(getdns_context*, getdns_callback_type_t, getdns_dict*, void*, getdns_transaction_t)’:
../src/GNContext.cpp:456:39: warning: ‘void node::FatalException(const v8::TryCatch&)’ is deprecated (declared at /home/mike/.node-gyp/5.0.0/include/node/node.h:282): Use FatalException(isolate, ...) [-Wdeprecated-declarations]
         node::FatalException(try_catch);
                                       ^
getdns.target.mk:92: recipe for target 'Release/obj.target/getdns/src/GNContext.o' failed
make: *** [Release/obj.target/getdns/src/GNContext.o] Error 1
make: Leaving directory '/home/mike/meteor/dns2/node_modules/getdns/build'
gyp ERR! build error 
gyp ERR! stack Error: `make` failed with exit code: 2
gyp ERR! stack     at ChildProcess.onExit (/home/mike/.nvm/versions/node/v5.0.0/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:270:23)
gyp ERR! stack     at emitTwo (events.js:87:13)
gyp ERR! stack     at ChildProcess.emit (events.js:172:7)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:200:12)
gyp ERR! System Linux 3.16.0-4-amd64
gyp ERR! command "/home/mike/.nvm/versions/node/v5.0.0/bin/node" "/home/mike/.nvm/versions/node/v5.0.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/mike/meteor/dns2/node_modules/getdns
gyp ERR! node -v v5.0.0
gyp ERR! node-gyp -v v3.0.3
gyp ERR! not ok 
npm WARN EPACKAGEJSON [email protected] No description
npm WARN EPACKAGEJSON [email protected] No repository field.
npm ERR! Linux 3.16.0-4-amd64
npm ERR! argv "/home/mike/.nvm/versions/node/v5.0.0/bin/node" "/home/mike/.nvm/versions/node/v5.0.0/bin/npm" "install" "getdns"
npm ERR! node v5.0.0
npm ERR! npm  v3.3.6
npm ERR! code ELIFECYCLE

npm ERR! [email protected] install: `node-gyp rebuild`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the [email protected] install script 'node-gyp rebuild'.
npm ERR! This is most likely a problem with the getdns package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node-gyp rebuild
npm ERR! You can get their info via:
npm ERR!     npm owner ls getdns
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /home/mike/meteor/dns2/npm-debug.log
mike@blob:~/meteor/dns2$ 

The list of records used in the DNSSEC tests for portal.rootcanary.org should be a good start for both bogus and secure records.

The module fails to install with the following error:

$ node -v
v7.10.1
$ npm install --save getdns

> [email protected] install /Users/test/projects/test-getdnsapi/node_modules/getdns
> npm run --silent rebuild

  CXX(target) Release/obj.target/getdns/src/GNContext.o
In file included from ../src/GNContext.cpp:28:
../src/GNContext.h:33:10: fatal error: 'getdns/getdns.h' file not found
#include <getdns/getdns.h>
         ^
1 error generated.
make: *** [Release/obj.target/getdns/src/GNContext.o] Error 1

I also tried with Node 6 and Node 9 and the result is the same. My machine is MacOS High Sierra, version 10.13.1 (17B1002)

built and installed getdns
then npm install --save getdns

After a number of warnings about things being deprecated compilation fails with
CXX(target) Release/obj.target/getdns/src/GNConstants.o ../src/GNConstants.cpp: In static member function ‘static void GNConstants::Init(v8::Local<v8::Object>)’: ../src/GNConstants.cpp:239:32: error: ‘GETDNS_RCODE_COOKIE’ was not declared in this scope; did you mean ‘GETDNS_RCODE_BADCOOKIE’? 239 | SetConstant("RCODE_COOKIE",GETDNS_RCODE_COOKIE,exports); | ^~~~~~~~~~~~~~~~~~~ | GETDNS_RCODE_BADCOOKIE make: *** [getdns.target.mk:113: Release/obj.target/getdns/src/GNConstants.o] Error 1 make: Leaving directory '/home/francis/src/resolv/node_modules/getdns/build' gyp ERR! build error gyp ERR! stack Error:make` failed with exit code: 2
gyp ERR! stack at ChildProcess.onExit (/usr/lib/node_modules/npm/node_modules/node-gyp/lib/build.js:194:23)
gyp ERR! stack at ChildProcess.emit (events.js:315:20)
gyp ERR! stack at Process.ChildProcess._handle.onexit (internal/child_process.js:277:12)
gyp ERR! System Linux 5.4.0-72-generic
gyp ERR! command "/usr/bin/node" "/usr/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /home/francis/src/resolv/node_modules/getdns
gyp ERR! node -v v14.16.1
gyp ERR! node-gyp -v v5.1.0
gyp ERR! not ok
npm WARN [email protected] No description
npm WARN [email protected] No repository field.

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! [email protected] install: node-gyp rebuild
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the [email protected] install script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR! /home/francis/.npm/_logs/2021-05-11T11_49_44_685Z-debug.log
`

Hi,
Where load c++ librarie for install ?
regards

The getdns-node readme has since 2014 mentioned that IPv4 and IPv6 dictionary entries will be converted to plain strings for example in just_address_answers. The code has at the same time not done this, with tests to confirm it.

{
  "answer_type": 800,
  "canonical_name": "getdnsapi.net.",
  "just_address_answers": [
    "2a04:b900:0:100::37",
    "185.49.141.37"
  ],
  ...
}

This should be fixed, but after three years I don't think it can be seen as a bugfix semver bump. I think it should be a full version bump; see #15.

Some of the logic closely related to javascript objects but done in the C++ code is bulky and not very straightforward. It is also not always necessary to parse the javascript objects with Native Abstractions for Node.js (NAN), perform a relatively simple check, then return build new NAN objects to return as javascript -- the same check in pure javascript code might have been much easier to write.

It might be a good idea to minimize the C++ to the bare minimum, in favor of pure javascript code. As it is right now, the javascript code is instead the bare minimum, but with some asynchronous handling workaround.

Moving some logic to javascript might help with fixing the sync/async problems outlined in #20 The transaction id handling is unleashing Zalgo, especially as dealing with asynchronous wrappers and/or promises in NAN might be cumbersome.

Hi,

I want to use this library in a desktop application (electron). Will end users need to install the c++ library? Or is that only required to build?

Cheers

Some of the upstream servers used in the tests may or may not be answering for all presumed modes. Verify that they are working, especially 173.255.254.151 which seems to be used in some failed tests on travis.

• nan need to update to 2.x
• compiler need to be g++-4.8 and above for new V8