Re: Number of additional records in queries
On 22. 10. 20 19:46, Brown, Chris via Unbound-users wrote: > I appreciate both the replies. I thank you and generally agree. My question > is more practical, though. And there will be no judgement of the answer (at > least by me). > > The state of things as I see it now in regards to the referenced additional > section record check are: > > - A strict reading of the RFCs does not generally prohibit records of any > type or quantity in the additional section of queries. > - A strict reading of the RFCs requires a FORMERR response if two or more OPT > records exist in the additional section. > - Google and other public DNS services generally answer queries with various > records in the additional section. > > - Unbound will attempt to process all queries with a single record in the > additional section. This record can have any type, including OPT. > - Unbound will send a FORMERR response for any query that has more than one > record in the additional section regardless of the type of any of the records. > > Is this the desired behavior in the stock Unbound recursive DNS server? I would say yes, it is very much desired. Rationale: If any future protocol extension makes use of new RR type in additional section and these are silently ignored then we have no way of detecting if the new extension is supported or not. In other words FORMERR is the only future-proof thing to do. Petr Špaček @ CZ.NIC > > Thank you for your time! > > > -Original Message- > From: Joe Abley > Sent: Sunday, October 18, 2020 5:27 PM > To: Tony Finch > Cc: Brown, Chris ; unbound-users@lists.nlnetlabs.nl > Subject: Re: Number of additional records in queries > > On 18 Oct 2020, at 16:04, Tony Finch via Unbound-users > wrote: > >> Brown, Chris via Unbound-users wrote: >> >>> So my question is...am I missing something in some RFC that would >>> break the rules to send non-opt records along with OPT records in the >>> ADDITIONAL section of queries? Or is this just a sanity call Unbound >>> made for...well...some sanity and maybe safety. Missing something else? >> >> I think the only other records you can legitimately put in a query are >> TSIG, TKEY, and SIG(0). > > This feels like one of those situations where even if there's no prohibition > on additional, arbitrary records being included in the additional section, > there's also no known reason for a query to include them and hence no > reliable behaviour that could be expected of a system processing that query > and generating a response. > > I don't think 1035 has any clear advice on the contents of the answer, > authority or additional sections in messages with QR=0. That document is far > from the final word on these matters, of course. > > > Joe
fail: the anchor is NOT ok and could not be fixed
After a system reboot, I get the following message when I run #> sudo systemctl status unbound Oct 23 13:31:38 raspberrypi systemd[1]: Starting Unbound DNS server... Oct 23 13:31:39 raspberrypi package-helper[513]: /var/lib/unbound/root.key has content Oct 23 13:31:39 raspberrypi package-helper[513]: *fail: the anchor is NOT ok and could not be fixed* Oct 23 13:31:39 raspberrypi systemd[1]: Started Unbound DNS server. If I then issue: #> sudo systemctl restart unbound #> sudo systemctl status unbound Oct 23 13:48:30 raspberrypi systemd[1]: Starting Unbound DNS server... Oct 23 13:48:30 raspberrypi package-helper[1294]: /var/lib/unbound/root.key has content Oct 23 13:48:30 raspberrypi package-helper[1294]: *success: the anchor is ok* Oct 23 13:48:31 raspberrypi systemd[1]: Started Unbound DNS server. Why is that? Running unbound 1.9.0 on Debian. Thanks.
RE: Number of additional records in queries
I appreciate both the replies. I thank you and generally agree. My question is more practical, though. And there will be no judgement of the answer (at least by me). The state of things as I see it now in regards to the referenced additional section record check are: - A strict reading of the RFCs does not generally prohibit records of any type or quantity in the additional section of queries. - A strict reading of the RFCs requires a FORMERR response if two or more OPT records exist in the additional section. - Google and other public DNS services generally answer queries with various records in the additional section. - Unbound will attempt to process all queries with a single record in the additional section. This record can have any type, including OPT. - Unbound will send a FORMERR response for any query that has more than one record in the additional section regardless of the type of any of the records. Is this the desired behavior in the stock Unbound recursive DNS server? Thank you for your time! -Original Message- From: Joe Abley Sent: Sunday, October 18, 2020 5:27 PM To: Tony Finch Cc: Brown, Chris ; unbound-users@lists.nlnetlabs.nl Subject: Re: Number of additional records in queries On 18 Oct 2020, at 16:04, Tony Finch via Unbound-users wrote: > Brown, Chris via Unbound-users wrote: > >> So my question is...am I missing something in some RFC that would >> break the rules to send non-opt records along with OPT records in the >> ADDITIONAL section of queries? Or is this just a sanity call Unbound >> made for...well...some sanity and maybe safety. Missing something else? > > I think the only other records you can legitimately put in a query are > TSIG, TKEY, and SIG(0). This feels like one of those situations where even if there's no prohibition on additional, arbitrary records being included in the additional section, there's also no known reason for a query to include them and hence no reliable behaviour that could be expected of a system processing that query and generating a response. I don't think 1035 has any clear advice on the contents of the answer, authority or additional sections in messages with QR=0. That document is far from the final word on these matters, of course. Joe
Re: Troubleshooting: warning: so-sndbuf 4194304 was not granted
Moreover, on Solaris Unbound will not work without this setting. 😉 22.10.2020 19:46, Ralph Dolmans via Unbound-users пишет: On Solaris ndd -set /dev/udp udp_max_buf 8388608. OpenPGP_0x4BEE94A33E3743A7.asc Description: application/pgp-keys OpenPGP_signature Description: OpenPGP digital signature
Re: Troubleshooting: warning: so-sndbuf 4194304 was not granted
On 22-10-2020 12:24, Gil Levy via Unbound-users wrote: > Hi there, > > Hope everyone is doing well these days. > > Using unbound 1.9.0. My config file has > so-dnbuf = 4m > so-rcvbuf = 4m > > When I type #: unbound > I get these warnings: > --- > *[1603203700] unbound[4853:0] warning: so-rcvbuf 4194304 was not > granted. Got 360448. To fix: start with root permissions(linux) or > sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. > > [1603203700] unbound[4853:0] warning: so-sndbuf 4194304 was not granted. > Got 360448. To fix: start with root permissions(linux) or sysctl bigger > net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values. > > [1603203700] unbound[4853:0] error: can't bind socket: Address already > in use for 127.0.0.1 port 5335 > > [1603203700] unbound[4853:0] fatal error: could not open ports* > --- > > Any idea why this should start with a root permission? Shouldn't the > system allocate the RAM during boot? >From the unbound.conf man page: == so-rcvbuf: If not 0, then set the SO_RCVBUF socket option to get more buffer space on UDP port 53 incoming queries. So that short spikes on busy servers do not drop packets (see counter in netstat -su). Default is 0 (use system value). Otherwise, the number of bytes to ask for, try "4m" on a busy server. The OS caps it at a maximum, on linux unbound needs root permission to bypass the limit, or the admin can use sysctl net.core.rmem_max. On BSD change kern.ipc.maxsockbuf in /etc/sysctl.conf. On OpenBSD change header and recompile kernel. On Solaris ndd -set /dev/udp udp_max_buf 8388608. == -- Ralph
Troubleshooting: warning: so-sndbuf 4194304 was not granted
Hi there, Hope everyone is doing well these days. Using unbound 1.9.0. My config file has so-dnbuf = 4m so-rcvbuf = 4m When I type #: unbound I get these warnings: --- *[1603203700] unbound[4853:0] warning: so-rcvbuf 4194304 was not granted. Got 360448. To fix: start with root permissions(linux) or sysctl bigger net.core.rmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.[1603203700] unbound[4853:0] warning: so-sndbuf 4194304 was not granted. Got 360448. To fix: start with root permissions(linux) or sysctl bigger net.core.wmem_max(linux) or kern.ipc.maxsockbuf(bsd) values.[1603203700] unbound[4853:0] error: can't bind socket: Address already in use for 127.0.0.1 port 5335[1603203700] unbound[4853:0] fatal error: could not open ports* --- Any idea why this should start with a root permission? Shouldn't the system allocate the RAM during boot? Thanks.
Re: increasing memory usage (using rpz zones)
Hi Fredrik, On Wed, 2020-10-21 at 22:35 +0200, Fredrik Pettai wrote: > Hi Hanspeter, > > > On 20 Oct 2020, at 15:40, Hanspeter Kunz via Unbound-users < > > unbound-users@lists.nlnetlabs.nl> wrote: > > > > On Fri, 2020-10-16 at 15:56 +0200, Ralph Dolmans via Unbound-users > > wrote: > > > Hi Hanspeter, > > > > > > On 14-10-2020 23:29, Hanspeter Kunz via Unbound-users wrote: > > > > Hi all, > > > > > > > > [replying to my own post] > > > > > > > > Apparently it is normal that unbound uses *a lot of RAM* after > > > > the > > > > initial load of the rpz zones (point 1 below). > > > > > > Does your RPZ zone contain a lot of records with the local data > > > RPZ > > > action? Due to the way the memory allocation is done here this > > > can > > > result in a very memory hungry Unbound instance. We are working > > > on a > > > fix > > > for this. > > > > I am not entirely sure what "local data RPZ action" means. almost > > all > > our records in the rpz zones are CNAMES. > > (All RPZ actions use CNAME ) > > "Local data” action means that the RPZ zone you’re supplying has an > “alternative” answer that’s presented to querying client, redirecting > the client to another host. (This explains why I don’t see your > unbound's memory-hogging behaviour on SUNET unbound instances.) > We rewrite it to answer NXDOMAIN (CNAME .) ah, I understand, thanks for clarifying. > You could try this config example to see if it solves your issue: > > rpz: > name: “a.b.switch.ch." > zonefile: “/var/lib/unbound/a.b.switch.ch.zone" > master: 130.242.XXX.YYY@ > allow-notify: 130.242.XXX.YYY > rpz-action-override: nxdomain<<—— this is the > differentiator > rpz-log: yes > rpz-log-name: a.b > tags: “malware” I tried overriding the action to nxdomain, as suggested. I didn't change anything, unfortunately. still getting the memory leak. Best, Hp smime.p7s Description: S/MIME cryptographic signature
