Re: Socket buffer space?
On Tue, Dec 11, 2018 at 05:46:10PM +0100, Havard Eidnes wrote:
>
> Hmm, I already have that, but I wonder, how big is "bigger"? Well,
> looks like the answer is that BIND tries to probe for the biggest it
> can be allowed to set on startup, by starting with a large value and
> approximately halfing it successively if I read the code right. BIND
> doesn't log what setting it is using, though...
>
I stumbled across this thread today after also investigating what socket
buffer size is actually chosen by BIND. I noticed the code behaved
a bit differently then what I tought from first looking at it.
On my linux machine with net.core.rmem_max set to the system default of
"212992" I was expecting the "again" goto loop to decrease the rcvbuf
until setsockopt succeeded, but setsockopt actually succeeds even if the
requested size is larger than what is allowed by that limit.
What happens is that the setsockopt succeeds, but the actual value set is the
maximum allowed by net.core.rmem_max (which ends up being doubled). The
doubling is described in socket(7):
===
SO_RCVBUF
Sets or gets the maximum socket receive buffer in bytes. The kernel doubles
this value (to allow space for
bookkeeping overhead) when it is set using setsockopt(2), and this doubled
value is returned by getsock‐
opt(2). The default value is set by the /proc/sys/net/core/rmem_default
file, and the maximum allowed
value is set by the /proc/sys/net/core/rmem_max file. The minimum (doubled)
value for this option is 256.
===
Here is a standalone version of set_rcvbuf() that I yanked out of BIND 9.11.6
codebase with some printfs sprinkled in for added visibility:
===
#include
#include
#include
#include
#include
#include
#include
#include
#define ISC_SOCKADDR_LEN_T unsigned int
#define ISC_PLATFORM_HAVEIPV6 1
#define TUNE_LARGE 1
/*%
* The size to raise the receive buffer to (from BIND 8).
*/
#ifdef TUNE_LARGE
#ifdef sun
#define RCVBUFSIZE (1*1024*1024)
#else
#define RCVBUFSIZE (16*1024*1024)
#endif
#else
#define RCVBUFSIZE (32*1024)
#endif /* TUNE_LARGE */
static int rcvbuf = RCVBUFSIZE;
static void
set_rcvbuf(void) {
int fd;
int max = rcvbuf, min;
ISC_SOCKADDR_LEN_T len;
// Added stuff
int final;
ISC_SOCKADDR_LEN_T final_len;
printf("requested SO_RCVBUF size (max): %d\n", max);
fd = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP);
#if defined(ISC_PLATFORM_HAVEIPV6)
if (fd == -1) {
switch (errno) {
case EPROTONOSUPPORT:
case EPFNOSUPPORT:
case EAFNOSUPPORT:
/*
* Linux 2.2 (and maybe others) return EINVAL instead of
* EAFNOSUPPORT.
*/
case EINVAL:
fd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_UDP);
break;
}
}
#endif
if (fd == -1)
return;
len = sizeof(min);
if (getsockopt(fd, SOL_SOCKET, SO_RCVBUF, (void *)&min, &len) == 0 &&
min < rcvbuf) {
printf("initial SO_RCVBUF size (min) %d is less than %d,
attempting to increase it\n", min, rcvbuf);
again:
printf("attempting to set SO_RCVBUF to rcvbuf (%d)\n", rcvbuf);
if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF, (void *)&rcvbuf,
sizeof(rcvbuf)) == -1) {
printf("setsockopt failed\n");
if (errno == ENOBUFS && rcvbuf > min) {
printf("errno was ENOBUFS\n");
printf("max: %d\n", max);
max = rcvbuf - 1;
printf("new max: %d\n", max);
rcvbuf = (rcvbuf + min) / 2;
printf("new rcvbuf: %d\n", max);
goto again;
} else {
//printf("errno was not ENOBUFS (was: %s)\n",
strerror(errno));
rcvbuf = min;
printf("min rcvbuf: %d\n", rcvbuf);
goto cleanup;
}
} else {
printf("setsockopt succeeded\n");
min = rcvbuf;
printf("new min: %d\n", min);
}
if (min != max) {
printf("min (%d) not equal to max (%d)\n", min, max);
rcvbuf = max;
goto again;
}
}
final_len = sizeof(final);
if (getsockopt(fd, SOL_SOCKET, SO_RCVBUF, (void *)&final, &final_len)
== 0 ) {
printf("final SO_RCVBUF size: %d\n", final);
}
cleanup:
close (fd);
}
int main() {
set_rcvbuf();
return 0;
}
=
BIND 9.14.2 configure problem
Hi Folks, I am attempting to build BIND 9.14.2 on a CentOS 7 machine, and having problems with "configure: error: ECDSA support in OpenSSL is mandatory." When I build OpenSSL 1.1.1c, I have tried to explicitly enable ECDSA when running config (first attempt was to just leave the defaults): ./config no-shared enable-ecdsa -prefix=/opt/tmp/openssl make make install However when I specify this freshly built OpenSSL 1.1.1c install location when configuring BIND 9.14.2, it still complains: checking for openssl/ssl.h in /opt/tmp/openssl/... yes checking whether compiling and linking against OpenSSL works... yes checking for OpenSSL >= 1.0.0 or LibreSSL... yes checking for CRYPTO_zalloc... yes checking for EVP_CIPHER_CTX_new... no checking for EVP_CIPHER_CTX_free... no checking for EVP_MD_CTX_new... no checking for EVP_MD_CTX_free... no checking for EVP_MD_CTX_reset... no checking for HMAC_CTX_new... no checking for HMAC_CTX_free... no checking for HMAC_CTX_reset... no checking for HMAC_CTX_get_md... no checking for ECDSA_sign... no configure: error: in `/tmp/bind-9.14.2': configure: error: ECDSA support in OpenSSL is mandatory. Hoping that someone can point me in the right direction to resolve this issue. Thanks, Greg Rabil ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.14.2 configure problem
greg.ra...@bt.com wrote: > However when I specify this freshly built OpenSSL 1.1.1c install > location when configuring BIND 9.14.2, it still complains: Try LD_RUN_PATH=/opt/tmp/openssl/lib ./configure --with-openssl=/opt/tmp/openssl What's probably happening is that the configure script's OpenSSL test programs are not being correctly linked to the OpenSSL that you specified on the command line. Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: Variable 4 or less, becoming northeasterly 3 to 5 later. Slight, occasionally moderate in north. Fog patches, rain later. Moderate, occasionally very poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: BIND 9.14.2 configure problem
That makes sense, but unfortunately it does not resolve the problem. I've tried specifying LD_RUN_PATH and LD_LIBRARY_PATH, and exporting them both as well, but BIND 9.14 configure script still complains about lack of ECDSA support in OpenSSL. Greg -Original Message- From: Tony Finch [mailto:d...@dotat.at] Sent: Friday, June 7, 2019 11:03 AM To: Rabil,AG,A Gregory,JTK2 R Cc: bind-us...@isc.org Subject: Re: BIND 9.14.2 configure problem greg.ra...@bt.com wrote: > However when I specify this freshly built OpenSSL 1.1.1c install > location when configuring BIND 9.14.2, it still complains: Try LD_RUN_PATH=/opt/tmp/openssl/lib ./configure --with-openssl=/opt/tmp/openssl What's probably happening is that the configure script's OpenSSL test programs are not being correctly linked to the OpenSSL that you specified on the command line. Tony. -- f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: Variable 4 or less, becoming northeasterly 3 to 5 later. Slight, occasionally moderate in north. Fog patches, rain later. Moderate, occasionally very poor. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.14.2 configure problem
The script reports everything is missing. You’ll need to check config.log for more details what’s happening. Anyway it should work with stock OpenSSL, so why don’t you just use that? Cheers, Ondrej -- Ondřej Surý — ISC > On 7 Jun 2019, at 17:12, wrote: > > That makes sense, but unfortunately it does not resolve the problem. I've > tried specifying LD_RUN_PATH and LD_LIBRARY_PATH, and exporting them both as > well, but BIND 9.14 configure script still complains about lack of ECDSA > support in OpenSSL. > > Greg > > -Original Message- > From: Tony Finch [mailto:d...@dotat.at] > Sent: Friday, June 7, 2019 11:03 AM > To: Rabil,AG,A Gregory,JTK2 R > Cc: bind-us...@isc.org > Subject: Re: BIND 9.14.2 configure problem > > greg.ra...@bt.com wrote: > >> However when I specify this freshly built OpenSSL 1.1.1c install >> location when configuring BIND 9.14.2, it still complains: > > Try > > LD_RUN_PATH=/opt/tmp/openssl/lib ./configure --with-openssl=/opt/tmp/openssl > > What's probably happening is that the configure script's OpenSSL test > programs are not being correctly linked to the OpenSSL that you specified on > the command line. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: > Variable 4 or less, becoming northeasterly 3 to 5 later. > Slight, occasionally moderate in north. Fog patches, rain later. Moderate, > occasionally very poor. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: BIND 9.14.2 configure problem
Hi Ondrej, My intent is to build BIND 9.14 as a statically linked binary. The details of the config.log reveal that the OpenSSL tests are using dlopen, and since I have only a static library, those tests fail. I worked around the problem by specifying LDFLAGS=-ldl. Thanks, Greg -Original Message- From: Ondřej Surý [mailto:ond...@isc.org] Sent: Friday, June 7, 2019 11:16 AM To: Rabil,AG,A Gregory,JTK2 R Cc: d...@dotat.at; bind-us...@isc.org Subject: Re: BIND 9.14.2 configure problem The script reports everything is missing. You’ll need to check config.log for more details what’s happening. Anyway it should work with stock OpenSSL, so why don’t you just use that? Cheers, Ondrej -- Ondřej Surý — ISC > On 7 Jun 2019, at 17:12, wrote: > > That makes sense, but unfortunately it does not resolve the problem. I've > tried specifying LD_RUN_PATH and LD_LIBRARY_PATH, and exporting them both as > well, but BIND 9.14 configure script still complains about lack of ECDSA > support in OpenSSL. > > Greg > > -Original Message- > From: Tony Finch [mailto:d...@dotat.at] > Sent: Friday, June 7, 2019 11:03 AM > To: Rabil,AG,A Gregory,JTK2 R > Cc: bind-us...@isc.org > Subject: Re: BIND 9.14.2 configure problem > > greg.ra...@bt.com wrote: > >> However when I specify this freshly built OpenSSL 1.1.1c install >> location when configuring BIND 9.14.2, it still complains: > > Try > > LD_RUN_PATH=/opt/tmp/openssl/lib ./configure > --with-openssl=/opt/tmp/openssl > > What's probably happening is that the configure script's OpenSSL test > programs are not being correctly linked to the OpenSSL that you specified on > the command line. > > Tony. > -- > f.anthony.n.finchhttp://dotat.at/ Viking, North Utsire: > Variable 4 or less, becoming northeasterly 3 to 5 later. > Slight, occasionally moderate in north. Fog patches, rain later. Moderate, > occasionally very poor. > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to > unsubscribe from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
BIND ignores queries from specific privileged source ports
Can someone explain why BIND (I'm using bind-9.9.4-73.el7_6.x86_64 but have also tried 9.10.3-P4-Ubuntu) seems to ignore DNS queries initiated from specific privileged source ports but not others? Example: [root@ns ~]# dig +short -b 127.0.0.1 @localhost google.com 172.217.6.110 [root@ns ~]# dig +short -b 127.0.0.1#1 @localhost google.com 172.217.6.110 [root@ns ~]# dig +short -b 127.0.0.1#50 @localhost google.com 172.217.6.110 [root@ns ~]# dig +short -b 127.0.0.1#19 @localhost google.com ;; connection timed out; no servers could be reached [root@ns ~]# dig +short -b 127.0.0.1#14 @localhost google.com 172.217.6.110 [root@ns ~]# dig +short -b 127.0.0.1#13 @localhost google.com ;; connection timed out; no servers could be reached While it would be ideal for clients to use source port randomization and initiate queries from random ephemeral ports, I don't control all the clients or the NAT routers in between the client and the server. Queries using a source port of 13 and 19 are dropped while queries from port 1, 50, and 14 are answered. This has been confirmed via a network capture as well. I checked the ARM, but didn't see what knob(s) I could tweak to control this behavior. Anyone know? Thanks, --Blake ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND ignores queries from specific privileged source ports
Named drops those ports as they can be used in reflection attacks.
Sane NAT developers avoid those ports for just that reason. The
full list is below.
static int
ns_client_dropport(in_port_t port) {
switch (port) {
case 7: /* echo */
case 13: /* daytime */
case 19: /* chargen */
case 37: /* time */
return (DROPPORT_REQUEST);
case 464: /* kpasswd */
return (DROPPORT_RESPONSE);
}
return (DROPPORT_NO);
}
> On 8 Jun 2019, at 7:56 am, Blake Hudson wrote:
>
> Can someone explain why BIND (I'm using bind-9.9.4-73.el7_6.x86_64 but have
> also tried 9.10.3-P4-Ubuntu) seems to ignore DNS queries initiated from
> specific privileged source ports but not others?
>
> Example:
>
> [root@ns ~]# dig +short -b 127.0.0.1 @localhost google.com
> 172.217.6.110
> [root@ns ~]# dig +short -b 127.0.0.1#1 @localhost google.com
> 172.217.6.110
> [root@ns ~]# dig +short -b 127.0.0.1#50 @localhost google.com
> 172.217.6.110
> [root@ns ~]# dig +short -b 127.0.0.1#19 @localhost google.com
> ;; connection timed out; no servers could be reached
> [root@ns ~]# dig +short -b 127.0.0.1#14 @localhost google.com
> 172.217.6.110
> [root@ns ~]# dig +short -b 127.0.0.1#13 @localhost google.com
> ;; connection timed out; no servers could be reached
>
>
> While it would be ideal for clients to use source port randomization and
> initiate queries from random ephemeral ports, I don't control all the clients
> or the NAT routers in between the client and the server. Queries using a
> source port of 13 and 19 are dropped while queries from port 1, 50, and
> 14 are answered. This has been confirmed via a network capture as well. I
> checked the ARM, but didn't see what knob(s) I could tweak to control this
> behavior. Anyone know?
>
> Thanks,
> --Blake
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
