<feed xmlns='http://www.w3.org/2005/Atom'>
<title>nginx.git/src/core/ngx_resolver.c, branch release-1.30.0</title>
<subtitle>nginx</subtitle>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/'/>
<entry>
<title>Resolver: fixed off-by-one read in ngx_resolver_copy().</title>
<updated>2026-02-23T18:12:32+00:00</updated>
<author>
<name>Roman Arutyunyan</name>
<email>arut@nginx.com</email>
</author>
<published>2026-02-23T14:29:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=edb4d2ffa746ba30bcae90e9527d5512b3de2c5b'/>
<id>edb4d2ffa746ba30bcae90e9527d5512b3de2c5b</id>
<content type='text'>
It is believed to be harmless, see a similar change 077a890a76ff.

Reported-by: geeknik &lt;geeknik@protonmail.ch&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is believed to be harmless, see a similar change 077a890a76ff.

Reported-by: geeknik &lt;geeknik@protonmail.ch&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Resolver: fixed memory leak for the "ipv4=off" case.</title>
<updated>2022-07-14T17:26:54+00:00</updated>
<author>
<name>Sergey Kandaurov</name>
<email>pluknet@nginx.com</email>
</author>
<published>2022-07-14T17:26:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=14341ce2377d38a268261e0fec65b6915ae6e95e'/>
<id>14341ce2377d38a268261e0fec65b6915ae6e95e</id>
<content type='text'>
This change partially reverts 2a77754cd9fe to properly free rn-&gt;query.

Found by Coverity (CID 1507244).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
This change partially reverts 2a77754cd9fe to properly free rn-&gt;query.

Found by Coverity (CID 1507244).
</pre>
</div>
</content>
</entry>
<entry>
<title>The "ipv4=" parameter of the "resolver" directive.</title>
<updated>2022-07-12T17:44:02+00:00</updated>
<author>
<name>Ruslan Ermilov</name>
<email>ru@nginx.com</email>
</author>
<published>2022-07-12T17:44:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=5178da4f94fbae1daec2800bc7fd74cd2923c5bd'/>
<id>5178da4f94fbae1daec2800bc7fd74cd2923c5bd</id>
<content type='text'>
When set to "off", only IPv6 addresses will be resolved, and no
A queries are ever sent (ticket #2196).
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
When set to "off", only IPv6 addresses will be resolved, and no
A queries are ever sent (ticket #2196).
</pre>
</div>
</content>
</entry>
<entry>
<title>Resolver: make TCP write timer event cancelable.</title>
<updated>2022-06-02T03:17:23+00:00</updated>
<author>
<name>Aleksei Bavshin</name>
<email>a.bavshin@f5.com</email>
</author>
<published>2022-06-02T03:17:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f2fcc03d3aa6f0e0a457a994dbc743b5b63ad035'/>
<id>f2fcc03d3aa6f0e0a457a994dbc743b5b63ad035</id>
<content type='text'>
Similar to 70e65bf8dfd7, the change is made to ensure that the ability to
cancel resolver tasks is fully controlled by the caller.  As mentioned in the
referenced commit, it is safe to make this timer cancelable because resolve
tasks can have their own timeouts that are not cancelable.

The scenario where this may become a problem is a periodic background resolve
task (not tied to a specific request or a client connection), which receives a
response with short TTL, large enough to warrant fallback to a TCP query.
With each event loop wakeup, we either have a previously set write timer
instance or schedule a new one.  The non-cancelable write timer can delay or
block graceful shutdown of a worker even if the ngx_resolver_ctx_t-&gt;cancelable
flag is set by the API user, and there are no other tasks or connections.

We use the resolver API in this way to maintain the list of upstream server
addresses specified with the 'resolve' parameter, and there could be third-party
modules implementing similar logic.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Similar to 70e65bf8dfd7, the change is made to ensure that the ability to
cancel resolver tasks is fully controlled by the caller.  As mentioned in the
referenced commit, it is safe to make this timer cancelable because resolve
tasks can have their own timeouts that are not cancelable.

The scenario where this may become a problem is a periodic background resolve
task (not tied to a specific request or a client connection), which receives a
response with short TTL, large enough to warrant fallback to a TCP query.
With each event loop wakeup, we either have a previously set write timer
instance or schedule a new one.  The non-cancelable write timer can delay or
block graceful shutdown of a worker even if the ngx_resolver_ctx_t-&gt;cancelable
flag is set by the API user, and there are no other tasks or connections.

We use the resolver API in this way to maintain the list of upstream server
addresses specified with the 'resolve' parameter, and there could be third-party
modules implementing similar logic.
</pre>
</div>
</content>
</entry>
<entry>
<title>Core: added the ngx_rbtree_data() macro.</title>
<updated>2021-06-21T06:42:43+00:00</updated>
<author>
<name>Vladimir Homutov</name>
<email>vl@nginx.com</email>
</author>
<published>2021-06-21T06:42:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=8b927107287094f018cc6f5addc543e79f88ec74'/>
<id>8b927107287094f018cc6f5addc543e79f88ec74</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Resolver: explicit check for compression pointers in question.</title>
<updated>2021-05-25T12:17:50+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2021-05-25T12:17:50+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=e860ecce82f1ee9cffb228d29d3ad61375b29aff'/>
<id>e860ecce82f1ee9cffb228d29d3ad61375b29aff</id>
<content type='text'>
Since nginx always uses exactly one entry in the question section of
a DNS query, and never uses compression pointers in this entry, parsing
of a DNS response in ngx_resolver_process_response() does not expect
compression pointers to appear in the question section of the DNS
response.  Indeed, compression pointers in the first name of a DNS response
hardly make sense, do not seem to be allowed by RFC 1035 (which says
"a pointer to a prior occurance of the same name", note "prior"), and
were never observed in practice.

Added an explicit check to ngx_resolver_process_response()'s parsing
of the question section to properly report an error if compression pointers
nevertheless appear in the question section.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since nginx always uses exactly one entry in the question section of
a DNS query, and never uses compression pointers in this entry, parsing
of a DNS response in ngx_resolver_process_response() does not expect
compression pointers to appear in the question section of the DNS
response.  Indeed, compression pointers in the first name of a DNS response
hardly make sense, do not seem to be allowed by RFC 1035 (which says
"a pointer to a prior occurance of the same name", note "prior"), and
were never observed in practice.

Added an explicit check to ngx_resolver_process_response()'s parsing
of the question section to properly report an error if compression pointers
nevertheless appear in the question section.
</pre>
</div>
</content>
</entry>
<entry>
<title>Resolver: simplified ngx_resolver_copy().</title>
<updated>2021-05-25T12:17:45+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2021-05-25T12:17:45+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f85d7016949b34119b5f4c53ddbfac4f199b4343'/>
<id>f85d7016949b34119b5f4c53ddbfac4f199b4343</id>
<content type='text'>
Instead of checking on each label if we need to place a dot or not,
now it always adds a dot after a label, and reduces the resulting
length afterwards.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Instead of checking on each label if we need to place a dot or not,
now it always adds a dot after a label, and reduces the resulting
length afterwards.
</pre>
</div>
</content>
</entry>
<entry>
<title>Resolver: reworked ngx_resolver_copy() copy loop.</title>
<updated>2021-05-25T12:17:43+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2021-05-25T12:17:43+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=f1dd1d50e090b32a765295daea5f167f1077d706'/>
<id>f1dd1d50e090b32a765295daea5f167f1077d706</id>
<content type='text'>
To make the code easier to read, reworked the ngx_resolver_copy()
copy loop to match the one used to calculate length.  No functional
changes.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
To make the code easier to read, reworked the ngx_resolver_copy()
copy loop to match the one used to calculate length.  No functional
changes.
</pre>
</div>
</content>
</entry>
<entry>
<title>Resolver: fixed label types handling in ngx_resolver_copy().</title>
<updated>2021-05-25T12:17:41+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2021-05-25T12:17:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=bbd403a7ab3810fe82ecd1d6ebca9fc34d68126a'/>
<id>bbd403a7ab3810fe82ecd1d6ebca9fc34d68126a</id>
<content type='text'>
Previously, anything with any of the two high bits set were interpreted
as compression pointers.  This is incorrect, as RFC 1035 clearly states
that "The 10 and 01 combinations are reserved for future use".  Further,
the 01 combination is actually allocated for EDNS extended label type
(see RFC 2671 and RFC 6891), not really used though.

Fix is to reject unrecognized label types rather than misinterpreting
them as compression pointers.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Previously, anything with any of the two high bits set were interpreted
as compression pointers.  This is incorrect, as RFC 1035 clearly states
that "The 10 and 01 combinations are reserved for future use".  Further,
the 01 combination is actually allocated for EDNS extended label type
(see RFC 2671 and RFC 6891), not really used though.

Fix is to reject unrecognized label types rather than misinterpreting
them as compression pointers.
</pre>
</div>
</content>
</entry>
<entry>
<title>Resolver: fixed off-by-one read in ngx_resolver_copy().</title>
<updated>2021-05-25T12:17:38+00:00</updated>
<author>
<name>Maxim Dounin</name>
<email>mdounin@mdounin.ru</email>
</author>
<published>2021-05-25T12:17:38+00:00</published>
<link rel='alternate' type='text/html' href='https://git.sigsegv.uk/nginx.git/commit/?id=077a890a76fff4f071776184aed881b5f314c98a'/>
<id>077a890a76fff4f071776184aed881b5f314c98a</id>
<content type='text'>
It is believed to be harmless, and in the worst case it uses some
uninitialized memory as a part of the compression pointer length,
eventually leading to the "name is out of DNS response" error.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
It is believed to be harmless, and in the worst case it uses some
uninitialized memory as a part of the compression pointer length,
eventually leading to the "name is out of DNS response" error.
</pre>
</div>
</content>
</entry>
</feed>
