Re: Bind - OPT UDPsize=1232 ?
--On 1 June 2021 at 13:03:12 +0200 Anand Buddhdev wrote: On 01/06/2021 12:55, Karl Pielorz wrote: Hi Karl, Anyone know why the Bind query appears to set such a low UDPsize? - We've nothing in our config setting sizes, or maximums. Here's an answer: https://bind9.readthedocs.io/en/v9_16_16/notes.html#notes-for-bind-9-16-16 Regards, Anand Hi, Thanks for the pointer - ok, yes I can see it's probably EDNS / Flag day related etc. I missed that - probably as it's never caused us an issue. Annoyingly a value of 1232 causes a TCP fallback to a server out of our control that doesn't do TCP very well. Even more annoyingly - all the 'flag day' / online test sites we can find - it works with, and passes all the tests. Which means even if there were a chance of getting the remote server fixed it's going to get "well, it works everywhere else and the online tests say it's a pass..." Thanks again though, -Karl ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind - OPT UDPsize=1232 ?
Hi, If I switch between having Bind go lookup a name, and dig - I can see a difference in tcpdump, i.e. Bind 9.16.16: 11:44:19.041785 IP (tos 0x0, ttl 64, id 3613, offset 0, flags [none], proto UDP (17), length 66) Us.54445 > Them.53: 3636 [1au] MX? somedomain.org. ar: . OPT UDPsize=1232 DO (38) So, Bind is uses 'OPT UDPsize=1232 DO (38)' Whereas, dig on the same host generates: 11:48:19.294690 IP (tos 0x0, ttl 64, id 28121, offset 0, flags [none], proto UDP (17), length 78) Us.30953 > Them.53: 19570+ [1au] MX? somedomain.org. ar: . OPT UDPsize=4096 (50) Dig uses 'OPT UDPsize=4096 (50)' Anyone know why the Bind query appears to set such a low UDPsize? - We've nothing in our config setting sizes, or maximums. Thanks, -Karl ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind stats - denied queries?
--On 1 December 2020 at 10:30:21 -0600 Chuck Aurora wrote: As for the wrong question - I don't get why it's 'wrong' to ask if there's a better way of getting the total number of "denied" entries Sorry, I skimmed the post quickly and thought you simply were asking about parsing the stats file. np - I'm happily staring at statistics channel output now, Cheers, -Karl ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind stats - denied queries?
--On 1 December 2020 at 10:14:50 -0600 Chuck Aurora wrote: On 2020-12-01 04:43, Karl Pielorz wrote: So, as the original person that posted the question :) My question still stands (I'd never presumed this was valid traffic) - what I'm trying to find out if buried within the trove of stats produced by 'rndc stats' is there any counter, that counts: " Nov 30 00:00:00 client @0xX X.X.X.X#48536 (.): query (cache) './ANY/IN' denied " I think you are asking the wrong question and looking at the wrong feature. You can probably do what you're after with statistics-channels. https://ftp.isc.org/isc/bind9/cur/9.16/doc/arm/html/reference.html#statis tics-channels-statement-grammar Thanks - I'll go check that out - it looks far better / correct than parsing the stats file. As for the wrong question - I don't get why it's 'wrong' to ask if there's a better way of getting the total number of "denied" entries such as the one above, rather than 'cat /var/log/messages | grep | wc -l' type affair ? - Unless 'denied' effectively appears as some other stat already? At this stage we're trying to work out how much traffic is getting denied (as it's likely junk) vs. regular responses etc. -Karl ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RRL outcome on legitimate traffic...
--On 1 December 2020 at 08:24:50 -0600 Lyle Giese wrote: You need to look at the reply named sends when it trips and starts limiting UDP traffic source from a given IP address. It tells the requestor to try again using TCP instead of UDP. So if the requestor is a legit dns server, it will retry using TCP and still get a valid answer. Named does not blindly just drop traffic. Hmmm, I thought it did for RRL limit hits? (i.e. that's the point - to stop sending responses). Documentation for rate-limit seemed a bit patchy e.g. KB aa-00994 references to "See ARM 6.2.15" - which doesn't exist. In fact a lot of the KB documents reference Bind 9.9 - and things have moved on. But I can see it's better explained in the current ARM / Section 4.2.14.19 now. In fact, that entry also covers/says "Legitimate clients react to dropped or truncated response by retrying with UDP or with TCP respectively" - looks like it documents where these are in stats as well (RateDropped / QryDropped et'al) - so I think I'm good to go. -Karl ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RRL outcome on legitimate traffic...
Hi all, So there's been quite a thread - that originally started as "Bind stats - denied queries" - and morphed into a whole discussion on spoofed UDP, logging, RRL etc. In my original post - I never said the original traffic was likely legitimate in anyway (just so we're clear - I didn't start that aspect of that thread). So, Obviously RRL is pretty much all you can do with this stuff - presumably, if someone throws a lot of queries that 'trip' the RRL - but, say spoofed from another ISP's actual DNS servers/network - the idea is that those IP's legitimate UDP queries will start getting dropped :( - but the other ISP's DNS will then, hopefully switch from UDP to TCP to get an answer? Looking at the distribution of rubbish we're seeing - I'm suspecting some of the limits would have to be 'really low' to catch some of this stuff (i.e. some times we just see 5 queries from an IP, and then nothing for hours - even from within the same /24). Obviously the server can weather a quite a bit of this, and you can't "block everything" (which is - in a circle, why I was asking originally about getting stats for it :) Regards, -Karl ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind stats - denied queries?
--On 30 November 2020 at 08:53:27 -0600 Lyle Giese wrote: Be careful 'rejecting' these outright. These queries are UDP traffic(not TCP) and the source address is easily forged. RRL is the correct way to limit these. So, as the original person that posted the question :) My question still stands (I'd never presumed this was valid traffic) - what I'm trying to find out if buried within the trove of stats produced by 'rndc stats' is there any counter, that counts: " Nov 30 00:00:00 client @0xX X.X.X.X#48536 (.): query (cache) './ANY/IN' denied " i.e. 'Denied' queries. I can see stats for pretty much everything, e.g. Queried, notified, all the different record types - there's a block in the stats file of: " 749045 queries resulted in nxrrset 45 queries resulted in SERVFAIL 15291 queries resulted in NXDOMAIN " But I was expecting to see something like: 34343 queries resulted in DENIED But I can't see it - or anything that's really applicable? And, as everyone else is talking about RRL - is there a stat that would appear for that, e.g. 234829 queries resulted in RATELIMIT Or similar? Currently we're just trying to easily graph the DENIED queries to see how much of the total traffic it is. -Karl ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Bind stats - denied queries?
Hi, We've been seeing a huge increase in 'denied queries' against a couple of Bind servers we look after (Bind 9.16.9) - these are currently logged as: " Nov 30 00:00:00 client @0xX X.X.X.X#48536 (.): query (cache) './ANY/IN' denied " This appears like it might be someone trying (unsuccessfully) to use us as an amplifier / reflector. We've got Bind's statistics file setup - but I can't see there's any entry for these "denied" queries? - As we'd really like to monitor this. If anyone knows what stat these turn up in the statistics file (if at all?) Thanks, -Karl ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND-9.16.1 memory leak?
--On 17 April 2020 at 15:45:16 +0200 sth...@nethelp.no wrote: We have what appears to be a significant memory leak in BIND-9.16.1. ... Running a ps command for the named process every minute and logging the result, I see the named virtual memory size (VSZ) increasing at around 1.2 Mbyte/minute, and the resident size (RSS) increasing at around 0.85 Mbyte/minute. No problems due to this so far, but pretty obviously it's not viable in the long run. I tried reading the CHANGES from 9.16.2, and didn't see anything which suggested a fix for a memory leak problem. Any suggestions? Hi, I seem to remember we got 'bitten' by large memory use when moving from a previous version of bind - do you have 'max-cache-size' set in your config? As far as I can remember, the 'default' is to take 90% of the memory on the machine. This is great, unless the machine has lots of other stuff going on etc. I think we noticed this during bind startup (i.e. from syslog output). On our boxes we set it to "something sensible" - rather than using the default. Might not be your problem - but thought it was worth mentioning / checking. -Karl ___ 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
