-
Notifications
You must be signed in to change notification settings - Fork 29.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: add non-internet resolveAny tests #13883
Conversation
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). |
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! |
@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. |
+1 on this (needs something in
Maybe, but I assume a tailored one can be much more concise (I assume we don't need a full DNS server). |
} else { | ||
// Pointer to another part of the packet. | ||
assert.strictEqual(length & 0xC0, 0xC0); | ||
// eslint-disable-next-line |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a specific rule that can be turned off here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If &~ 0xC000
on the next line is changed to & ~0xC000
, then we don't need this ESLint disable comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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”).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about:
const kLengthMask = 0xC0;
const kOffsetMask = ~0xC000;
I get the idiom, but I have to use my fingers to figure out 0xC000 === 0o140000 == 0b1100000000000000 === 0x3 << 14
and my mind just has to do that. Using a const
will allow me to abstract it away 😅
test/common/dns.js
Outdated
|
||
buffers.push(new Uint16Array([ | ||
parsed.id, | ||
// default to “standard response” |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not that it really matters, but why not just use standard quote characters here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.)
test/common/dns.js
Outdated
switch (rr.type) { | ||
case 'A': | ||
rdLengthBuf[0] = 4; | ||
buffers.push(new Uint8Array(rr.address.split(/\./g))); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There are a couple uses of split()
on single characters in this PR. Would the string version work (split('.')
)? It seems more readable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@cjihrig I just literally forgot that split
can work with plain strings. Updated :)
Let's do the opposite, publish this as |
} else { | ||
// Pointer to another part of the packet. | ||
assert.strictEqual(length & 0xC0, 0xC0); | ||
// eslint-disable-next-line |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about:
const kLengthMask = 0xC0;
const kOffsetMask = ~0xC000;
I get the idiom, but I have to use my fingers to figure out 0xC000 === 0o140000 == 0b1100000000000000 === 0x3 << 14
and my mind just has to do that. Using a const
will allow me to abstract it away 😅
test/common/dns.js
Outdated
buffers.push(new Uint16Array([ | ||
parsed.id, | ||
// default to “standard response” | ||
parsed.flags === undefined ? 0x8180 : parsed.flags, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
😵
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
·@refack This is not a very helpful comment, I have no idea what you are trying to say.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please define this as a const
so it's more obvious what are flags you want.
test/common/dns.js
Outdated
|
||
// Naïve DNS parser/serializer. | ||
|
||
require('../common'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you need this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the linter complains otherwise.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@Trott Sorry for being so late, I’ve updated this PR with eslint-disable required-modules
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 |
If we run |
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. |
Yeah, good point :-) |
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>
Added c-ares/c-ares@18ea996 because both the test proposed here and our existing internet tests ( CI is green: https://ci.nodejs.org/job/node-test-commit/11128/ |
@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 |
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: #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: #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: #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>
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), orvcbuild test
(Windows) passesAffected core subsystem(s)
test/dns