test: add non-internet resolveAny tests by addaleax · Pull Request #13883 · nodejs/node

addaleax · 2017-06-22T21:00:03Z

This is a bit of a check to see how people feel about having this kind of test.

Ref: #13137

/cc @nodejs/testing @XadillaX

Checklist

make -j4 test (UNIX), or vcbuild test (Windows) passes
tests and/or benchmarks are included
commit message follows commit guidelines

Affected core subsystem(s)

test/dns

refack · 2017-06-22T21:08:29Z

I'm not against the concept. (personally would prefer a tested implementation but the only one I found is https://www.npmjs.com/package/dnsd 😕 and it's kind of dormant).

Trott · 2017-06-23T05:24:44Z

So this allows a test double for the DNS server? Seems like a 👍 idea to me. Certainly better than not running the tests in CI ever!

addaleax · 2017-06-23T06:54:36Z

@Trott Yes, it’s essentially an implementation of a small fake DNS server. One of the nice things about it is that we can use it to send invalid responses as well, or make testing less dependent on external factors like what kind of records exist for a specific hard-coded domain.

@refack If you want to put the work in it, sure, try to build something with dnsd and open a PR.

gibfahn · 2017-06-23T07:48:23Z

+1 on this (needs something in test/common/README.md, but I'm pretty sure @addaleax is making sure everyone's okay with this first).

personally would prefer a tested implementation

Maybe, but I assume a tailored one can be much more concise (I assume we don't need a full DNS server).

cjihrig · 2017-06-23T13:43:51Z

Is there a specific rule that can be turned off here?

If &~ 0xC000 on the next line is changed to & ~0xC000, then we don't need this ESLint disable comment.

Eslint is unhappy about both the missing space before ~ and after &, so it’s two separate rules.
If &~ 0xC000 on the next line is changed to & ~0xC000, then we don't need this ESLint disable comment.
Right, but I’d consider &~ more idiomatic for bit-twiddling code (because it removes an extra thought iteration, from “bitwise and with some oddly generated mask” to “it’s just removing those bits”).

How about:
constkLengthMask=0xC0;constkOffsetMask=~0xC000;
I get the idiom, but I have to use my fingers to figure out 0xC000 === 0o‭140000‬ == 0b1100000000000000 === 0x3 << 14 and my mind just has to do that. Using a const will allow me to abstract it away 😅

cjihrig · 2017-06-23T13:47:37Z

Not that it really matters, but why not just use standard quote characters here?

But these are the proper quotation marks? ;) (All trolling aside, I’m just used to typing these if it’s not for code, that’s all.)

cjihrig · 2017-06-23T13:50:21Z

There are a couple uses of split() on single characters in this PR. Would the string version work (split('.'))? It seems more readable.

@cjihrig I just literally forgot that split can work with plain strings. Updated :)

refack · 2017-06-26T15:35:27Z

@refack If you want to put the work in it, sure, try to build something with dnsd and open a PR.

Let's do the opposite, publish this as dns-mock (add me and I'll write some tests).

refack · 2017-06-26T15:17:12Z

How about:
constkLengthMask=0xC0;constkOffsetMask=~0xC000;
I get the idiom, but I have to use my fingers to figure out 0xC000 === 0o‭140000‬ == 0b1100000000000000 === 0x3 << 14 and my mind just has to do that. Using a const will allow me to abstract it away 😅

refack · 2017-06-26T15:31:43Z

·@refack This is not a very helpful comment, I have no idea what you are trying to say.

Please define this as a const so it's more obvious what are flags you want.

refack · 2017-06-26T15:32:22Z

Do you need this?

Yes, the linter complains otherwise.

You could replace it with /* eslint-disable required-modules */ at the top of the file the way it is in test/common/wpt.js. I think I'd prefer that. If it's leaking globals, then any tests that use it will complain, so we're covered without importing the common module.

@Trott Sorry for being so late, I’ve updated this PR with eslint-disable required-modules

jasnell · 2017-07-10T15:44:04Z

I'm generally +1 on having this (and love seeing this kind of work) but my one concern is that there are no tests to verify that the common/dns.js script is itself exhibiting correct behavior. That is, if the test server is buggy, we could end up with buggy dns tests if we are not careful. I'm not sure if there's anything we can actually do about it, but it is definitely something to keep in mind.

refack · 2017-07-10T16:04:56Z

I'm not sure if there's anything we can actually do about it, but it is definitely something to keep in mind.

If we run /test/internet/ on a regular basis we could infer that the net-less tests are correct.

addaleax · 2017-07-10T16:07:54Z

Just to mention it again, the main scenario that prompted this is checking how our code handles invalid responses, something we won’t be able to do with a “proper” DNS server.

jasnell · 2017-07-10T16:40:01Z

Yeah, good point :-)

addaleax · 2017-07-12T16:42:45Z

CI: https://ci.nodejs.org/job/node-test-commit/11081/

Original commit message: ares_parse_naptr_reply: make buffer length check more accurate 9478908a490a6bf009ba58d81de8c1d06d50a117 introduced a length check for records parsed by `ares_parse_naptr_reply()`. However, that function is designed to parse replies which also contain non-NAPTR records; for A records, the `rr_len > 7` check will fail as there are only 4 bytes of payload. In particular, parsing ANY replies for NAPTR records was broken by that patch. Fix that by moving the check into the case in which it is already known that the record is a NAPTR record. Ref: c-ares/c-ares@18ea996

This is a bit of a check to see how people feel about having this kind of test. Ref: nodejs#13137 PR-URL: nodejs#13883 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>

addaleax · 2017-07-15T16:26:57Z

Added c-ares/c-ares@18ea996 because both the test proposed here and our existing internet tests (make test-internet) are currently broken after the security release.

CI is green: https://ci.nodejs.org/job/node-test-commit/11128/

addaleax · 2017-07-23T14:21:21Z

Landed in e76c49d, 69f653d

@nodejs/lts The first commit here (e76c49d) should make it to v4.x and v6.x, it fixes a bug from this month’s security release. I’ve added lts-watch labels, is that enough? Unfortunately the tests here themselves depend on v8.x-only features of Node. (Sorry for the mess, I didn’t plan it that way when I opened the PR. 😄)

Original commit message: ares_parse_naptr_reply: make buffer length check more accurate 9478908a490a6bf009ba58d81de8c1d06d50a117 introduced a length check for records parsed by `ares_parse_naptr_reply()`. However, that function is designed to parse replies which also contain non-NAPTR records; for A records, the `rr_len > 7` check will fail as there are only 4 bytes of payload. In particular, parsing ANY replies for NAPTR records was broken by that patch. Fix that by moving the check into the case in which it is already known that the record is a NAPTR record. Ref: c-ares/c-ares@18ea996 PR-URL: #13883 Reviewed-By: James M Snell <jasnell@gmail.com>

This is a bit of a check to see how people feel about having this kind of test. Ref: #13137 PR-URL: #13883 Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Colin Ihrig <cjihrig@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>

Original commit message: ares_parse_naptr_reply: make buffer length check more accurate 9478908a490a6bf009ba58d81de8c1d06d50a117 introduced a length check for records parsed by `ares_parse_naptr_reply()`. However, that function is designed to parse replies which also contain non-NAPTR records; for A records, the `rr_len > 7` check will fail as there are only 4 bytes of payload. In particular, parsing ANY replies for NAPTR records was broken by that patch. Fix that by moving the check into the case in which it is already known that the record is a NAPTR record. Ref: c-ares/c-ares@18ea996 PR-URL: #13883 Reviewed-By: James M Snell <jasnell@gmail.com>

Original commit message: ares_parse_naptr_reply: make buffer length check more accurate 9478908a490a6bf009ba58d81de8c1d06d50a117 introduced a length check for records parsed by `ares_parse_naptr_reply()`. However, that function is designed to parse replies which also contain non-NAPTR records; for A records, the `rr_len > 7` check will fail as there are only 4 bytes of payload. In particular, parsing ANY replies for NAPTR records was broken by that patch. Fix that by moving the check into the case in which it is already known that the record is a NAPTR record. Ref: c-ares/c-ares@18ea996 PR-URL: nodejs#13883 Reviewed-By: James M Snell <jasnell@gmail.com>

Original commit message: ares_parse_naptr_reply: make buffer length check more accurate 9478908a490a6bf009ba58d81de8c1d06d50a117 introduced a length check for records parsed by `ares_parse_naptr_reply()`. However, that function is designed to parse replies which also contain non-NAPTR records; for A records, the `rr_len > 7` check will fail as there are only 4 bytes of payload. In particular, parsing ANY replies for NAPTR records was broken by that patch. Fix that by moving the check into the case in which it is already known that the record is a NAPTR record. Ref: c-ares/c-ares@18ea996 PR-URL: #13883 Reviewed-By: James M Snell <jasnell@gmail.com>

Original commit message: ares_parse_naptr_reply: make buffer length check more accurate 9478908a490a6bf009ba58d81de8c1d06d50a117 introduced a length check for records parsed by `ares_parse_naptr_reply()`. However, that function is designed to parse replies which also contain non-NAPTR records; for A records, the `rr_len > 7` check will fail as there are only 4 bytes of payload. In particular, parsing ANY replies for NAPTR records was broken by that patch. Fix that by moving the check into the case in which it is already known that the record is a NAPTR record. Ref: c-ares/c-ares@18ea996 PR-URL: nodejs/node#13883 Reviewed-By: James M Snell <jasnell@gmail.com>

Original commit message: ares_parse_naptr_reply: make buffer length check more accurate 9478908a490a6bf009ba58d81de8c1d06d50a117 introduced a length check for records parsed by `ares_parse_naptr_reply()`. However, that function is designed to parse replies which also contain non-NAPTR records; for A records, the `rr_len > 7` check will fail as there are only 4 bytes of payload. In particular, parsing ANY replies for NAPTR records was broken by that patch. Fix that by moving the check into the case in which it is already known that the record is a NAPTR record. Ref: c-ares/c-ares@18ea996 PR-URL: #13883 Reviewed-By: James M Snell <jasnell@gmail.com>

addaleax added dns Issues and PRs related to the dns subsystem. dont-land-on-v4.x test Issues and PRs related to the tests. labels Jun 22, 2017

nodejs-github-bot added the test Issues and PRs related to the tests. label Jun 22, 2017

cjihrig approved these changes Jun 23, 2017
View reviewed changes

refack reviewed Jun 26, 2017
View reviewed changes

refack mentioned this pull request Jul 5, 2017
test: investigate flakiness of parallel/test-async-wrap-getasyncid#13020
Closed

addaleax force-pushed the dns-tests branch from 3f21f79 to fe457baCompare July 6, 2017 22:40

refack approved these changes Jul 6, 2017
View reviewed changes

jasnell approved these changes Jul 14, 2017
View reviewed changes

addaleax force-pushed the dns-tests branch from fe457ba to 340c986Compare July 15, 2017 04:26

addaleax added 2 commits July 15, 2017 18:59

addaleax force-pushed the dns-tests branch from 340c986 to 9c1e270Compare July 15, 2017 11:00

addaleax added lts-watch-v4.x labels Jul 23, 2017

gibfahn removed the dont-land-on-v6.x label Jul 24, 2017

addaleax mentioned this pull request Jul 24, 2017
v8.3.0 proposal #14452
Closed

addaleax mentioned this pull request Aug 2, 2017
v8.3.0 proposal #14594
Merged

MylesBorins added backported-to-v4.x and removed lts-watch-v4.x labels Aug 16, 2017

MylesBorins mentioned this pull request Aug 16, 2017
v6.11.3-proposal #14852
Merged

rvagg mentioned this pull request Sep 13, 2017
cares: sync with upstream, fully adopt v1.13.0 #15378
Closed

MylesBorins mentioned this pull request Sep 20, 2017
v4.8.5 proposal #15507
Closed

MylesBorins mentioned this pull request Oct 25, 2017
v4.8.6 proposal #16500
Merged

Uh oh!

Uh oh!

Conversation

addaleax commented Jun 22, 2017

Checklist

Affected core subsystem(s)

Uh oh!

refack commented Jun 22, 2017

Uh oh!

Trott commented Jun 23, 2017

Uh oh!

addaleax commented Jun 23, 2017

Uh oh!

gibfahn commented Jun 23, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TrottJun 23, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

refack commented Jun 26, 2017

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

refackJun 26, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

TrottJun 27, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jasnell commented Jul 10, 2017

Uh oh!

refack commented Jul 10, 2017• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

addaleax commented Jul 10, 2017

Uh oh!

jasnell commented Jul 10, 2017

Uh oh!

addaleax commented Jul 12, 2017

Uh oh!

addaleax commented Jul 15, 2017

Uh oh!

addaleax commented Jul 23, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

8 participants

TrottJun 23, 2017•
edited
Loading

refackJun 26, 2017•
edited
Loading

TrottJun 27, 2017•
edited
Loading

refack commented Jul 10, 2017•
edited
Loading