Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[exdirectory]

I don't see any red indicating packet loss, just a busy connection. I occasionally get some red packet loss, but not very often.

Ronski, see yesterday, lots of red.

[Chrysalis]

The benchmark is not really representative of real world usage, also the DNS resolver will still cache just the same in forwarder mode, that's not an exclusivity to resolver mode.  So really you trying to state, that multiple internet requests are faster going to authoritive servers and root servers vs a single cached result from a DNS cacher.

I have said my 5 pennies worth though, ultimately that's why it can be configured, for everyone to run how they wish to.

[Ronski]

Ronski, see yesterday, lots of red.

See how it goes, apart from the red the graph looks pretty good. Yesterday looking through my results I saw at least one day with quite bit of red, but otherwise perfectly ok, I'm on my phone & tablet at the moment so not quick and easy to find them.

[Chrysalis]

Philip, I am aware of the tool and its outdated approach, I can assure you my knowledge of DNS queries is not based on assumptions, it is just how it works.  For a proper test though you would ignore all of the results to the remote servers and simply benchmark your local resolver twice, once with forwarding enabled, and again with it disabled and take note of the result for that, otherwise you will not be doing apple to apple testing, the unbound resolver itself has its own optimisations and settings which can affect performance vs sending queries direct from the OS resolver which is what those remote tests are doing.

A proper test would be something like this.  This test was also favourable as I skipped the overhead of finding out the authoritive nameserver, I just assumed it was already known and it was still 3x slower.

root@PFSENSE unbound # dig @ns1.imagis.ro floro.ro. | grep "Query time:"       
;; Query time: 31 msec
root@PFSENSE unbound # dig @ns1.imagis.ro floro.ro. | grep "Query time:"
;; Query time: 27 msec
root@PFSENSE unbound # dig @1.1.1.1 floro.ro. | grep "Query time:"     
;; Query time: 9 msec
root@PFSENSE unbound # dig @1.1.1.1 floro.ro. | grep "Query time:"
;; Query time: 9 msec

I will leave it at that though, the good thing about pfSense it offers that flexibility, so each person can use as they wish.
 My post was really just intended to tell you why it's considered easier on the resolver.

[PhilipD]

The benchmark is not really representative of real world usage

    God talk about egg on face, just why not admit when you are wrong and faced with the evidence.  People can read through your politicians reply 

So what is not "real world" about the test?  It takes a random domain name, such as you might find doing a google, and converts it to an IP address.  Just because you are shown to be wrong with your statement please don't try and belittle the time someone has spent testing the concept. 

Okay you are right in one respect it isn't real world, simply because a normal home network would not make hundreds of DNS requests a second, but the fact the test does and shows pfsense is still faster under such unusual loads, where you said it wasn't faster, just disproves your statement all the more.

The default for pfSense is to use the DNS Resolver for good reason, from their help pages https://docs.netgate.com/pfsense/en/latest/services/dns/resolver.html

DNS Resolver
The DNS Resolver in pfSense® utilizes unbound, which is a validating, recursive, caching DNS resolver that supports DNSSEC and a wide variety of options. The DNS Resolver is enabled by default in current versions of pfSense.

By default, the DNS Resolver queries the root DNS servers directly and does not use DNS servers configured under System > General Setup or those obtained automatically from a dynamic WAN. This behavior may be changed, however, using the DNS Query Forwarding option. By contacting the roots directly by default, it eliminates many issues typically encountered by users with incorrect local DNS configurations, and the DNS results are more trustworthy and verifiable with Domain Name System Security Extensions (DNSSEC).

This is why people are trying to use it and this thread exists, as it is recommended and better practice, and is why people spend the time learning and using pfSense because it provides these extra options over and above bog standard consumer gear.  Better to try and fix the problem than work around it by turning it off.

Phil

[PhilipD]

Philip, I am aware of the tool and its outdated approach, I can assure you my knowledge of DNS queries is not based on assumptions, it is just how it works. 

Well you can't get more real world than this (pfSense has the tools to benchmark DNS lookups).

bbc.co.uk - result in 1 ms, nearest to me ISP DNS servers coming in at 8-9ms.

Regards

Phil

[Chrysalis]

I think 1ms is clearly a locally cached result Philip, and local caching works in both modes, anyway I am not going to enter a childish game of me is better than you, you asked a question I provided an answer. 

[PhilipD]

I think 1ms is clearly a locally cached result Philip, and local caching works in both modes, anyway I am not going to enter a childish game of me is better than you, you asked a question I provided an answer.

That's a real world result, so one minute you argue the test isn't real world and discredit it, so when I show a real world result you want tp discredit it as well? Yes a cached result, or are you saying Google or other DNS servers wouldn't have that cached? This real world test is an apples for apples comparison, what you wanted.  The fastest those other DNS servers can get a cached result back to me is 9ms, pfSense is less than 1ms and saves outgoing traffic as well, win win. Any small hit taken on the first non-cached lookup of a domain is paid back many times over serving from the cached result later.

The other benefit is pfSense DNS Resolver honours TTL, that often isn't the case given the number of times working on websites and adding DNS entries other people wait ages to get the newest IP, whereas I never have that issue, and if I do, I can clear the pfSense cache, good luck asking Google to do that.

You started of being childish with the I'm going to belittle this person, as you often do.  Be humble and sometimes admit perhaps you are wrong and that someone might actually have a valid point.  All you've done is continue to obfuscate some valid testing and results then go on to rubbish someone else's bench mark tool, you can't help yourself.

Regards

Phil

[Chrysalis]

Philip both google and cloudflare honour TTL values, even as low as a few seconds.  The original point made was in reference to the number of lookups been carried out.   In addition its been a long time since i seen any UK ISP's DNS not honour DNS records.

Unbound the resolver on pfSense will still cache records locally in forwarder mode, so any reference to caching performance is the same in both configuration's, if you are in forwarder mode, it does not disable the cache so if something is cached at 1ms, it will be cached in both modes, the difference is in uncached performance, unless you are using serve expired or increasing the min ttl overriding the domain's expiry, in a typical home family environment there will be a high miss ratio.  In this situation both configurations will send out the queries over the internet, in the forwarder mode the query will be sent to a DNS cacher, such as isp DNS or google DNS, those due to their high levels of traffic will very likely have the record in their cache for popular domains, it is effectively a level 2 cache in this respect.

If I came across as saying this would be faster in every single use case, then I apologise for been misleading, as I never intended to say that, my intention was to say in a low traffic environment the miss ratios will be higher on the local resolver, and as a result more queries get sent upstream.  Its the queries that get sent upstream where the behaviour is different. If you have a forwarder configured, you effectively have a level 2 cache, a second shot of hitting a cache so to speak, the hit ratios on large public resolver's will be high due to the sheer amount of traffic they have.

This explanation is not intended to say it will always be faster, which might be why you think I posted it, but it is to explain why I posted that advice.

I have contributed code to the development of Unbound (the DNS resolver that pfSense uses), and to pfSense itself in its DNS resolver implementation.

The issue I have with your posts is that you seem to have decided to go on a personal tirade against me, when all I did was reply to try to answer a question you asked, Alex disagrees with my advice which is fine, but he hasn't acted in the same way as yourself.

Bear in mind this is a topic on a specific VM problem, the guys in here are trying to resolve an issue with latency spikes whilst using pfSense and it got discovered this was in relation to the behaviour of the resolver.  This may make no sense as to why the change of configuration has such an impact on that, but it does.

[exdirectory]

So yesterday showed no real improvment over the previous day in terms of switching on DNS Forwarding, not for me anyway.

Could be that 2.4.5 p1 already fixed something, and/or VM fixed something since May, or maybe me messing with the coax cables fixed a problem as I no longer see preRSErrors.

BQM below. So this maybe the best I can get.

I am going to try three more things before I give up though...

1, Fully turning off ipv6 and leaving that for a day,
2, Try adding QOS to the incoming ping to see if that reduces packet loss,
3, Checking logs to see which devices on my LAN might be hammering (incorrectly) the WAN line

I need to learn how to do these first though.

[Alex Atkin UK]

The issue I have with your posts is that you seem to have decided to go on a personal tirade against me, when all I did was reply to try to answer a question you asked, Alex disagrees with my advice which is fine, but he hasn't acted in the same way as yourself.

I'm actually using TLS forwarding to Cloudflare personally, I was merely pointing out that Netgate themselves seem to recommend using full resolution as its the only method guaranteed to give unfiltered, unadulterated results.

Resolver = Pure DNS, slowest on cache misses
Forwarding over TLS = Security from ISP snooping, also somewhat slow
Plain Forwarder = Fastest result

[Ronski]

Back home now after a very nice week of social distancing on the Isle of Wight.

I've had a look and found a TBB ping graph from 1st of April, just to show how bad my connection was.

[exdirectory]

Ronski,

Nice!! Mine was pretty bad during March, I do not have a record though.

I have posted on VM forum, someone said "There should be no "red fringing" on your BQM, that's packet loss." and went on to say I need an engineer.

I went to try and set up traffic shaping for my incoming ping for QOS. But to be honest I got lost in pfSense.

Have you got a record of how you did it?

[Ronski]

I would suggest they don't totally know what they are talking about, TBB monitor works by pinging our IP addresses, if a router anywhere on the network is overly busy those pings are pretty much the lowest of the low and could well get dropped, resulting in red.

I occasionally get red dropped packets, these two are the worse one's I could find although I have seen worse - it is VM after all, but others have smaller red bits.

https://www.thinkbroadband.com/broadband/monitoring/quality/share/918c4f2e85166f199554fec205e338f4321e09d6-25-09-2020
https://www.thinkbroadband.com/broadband/monitoring/quality/share/7863a2ea038bd11a0de2b077249b23f0d5c157cf-26-08-2020

If you do decide to pursue getting a engineer out good luck on that one, it won't go well, telephone support hasn't a clue what modem mode is and they are obsessed with wi-fi, been there done that and got the grey hairs to prove it 

I've got no idea if I setup QOS for pings, I doubt it, but if I did it will be in the build thread.

[Alex Atkin UK]

I would suggest they don't totally know what they are talking about, TBB monitor works by pinging our IP addresses, if a router anywhere on the network is overly busy those pings are pretty much the lowest of the low and could well get dropped, resulting in red.

I occasionally get red dropped packets, these two are the worse one's I could find although I have seen worse - it is VM after all, but others have smaller red bits.

Yeah I'd have to say they're talking rubbish, you'll pretty much ALWAYS get packet loss if your line is maxed out as like you say, ping traffic is the first to get dropped/delayed.  Not to mention that we don't know exactly how long BQM actually waits for a response before declaring it lost.  Then theres backhaul (not to mention backhoe) problems, temporary work, etc.  Its unrealistic to expect to NEVER get packet loss and unless you have QoS prioritising ping packets (not necessarily advised but I do), even your own router likely drops/delays them under load.

I probably don't go a week without seeing some packet loss over my VPN connections on Plusnet or Zen.