How to block DNS forwarder domain requests to private IP addresses
-
@markn6262 said in How to block DNS forwarder domain requests to private IP addresses:
because I didn’t needed caching as it added latency.
what? You understand the forwarder also caches.. Clients cache as well, browsers normally also have their own cache, etc.
Caching has the opposite effect, so you ask for something.domain.tld, this would take Xms to get back from either resolver or forwarder.. Next guy that asks for this same thing, he would get it back like normally less than 1ms - since it is cached.. Caching reduces latency in dns lookups, it doesn't add to it.
You might be able to have a discussion that resolving initial lookup might take a few extra ms vs forwarding to something that already has it cached. But in the big picture this is a minuscule delay, and only on the first lookup. And depending - forwarding for this, could add to the latency - since if where you forward doesn't have it cached, it would have to resolve or forward itself to somewhere that does, etc.
-
@johnpoz Thats how it works in concept. But when my fiber dns delivers in 5ms and my local pfsense takes 30ms to do a dns lookup, according to dns speedtest, it didn’t make sense & the bandwidth reduction is minimal. Forwarder may cache, as may the browser, but the fwd’r is nearly a straight passthru as it has little to do but forward minus a quick check on a small custom resolution list. Thats been my experience.
-
@markn6262 Missed that you mentioned resolver. So presumably the “server:…” line wont work in the forwarder.
-
@markn6262 Yeah probably not, you'd have to look up dnsmasq config settings.
Try "Enable Forwarding Mode" in the Resolver though and see if that's faster for you.
-
@markn6262 said in How to block DNS forwarder domain requests to private IP addresses:
my local pfsense takes 30ms to do a dns lookup
Well that is broken.. Looking up something that is cached by your local NS shouldn't take more than like 2ms tops!! Or there is clearly something wrong..
-
@johnpoz Where I forward it's already cached hence the low latency performance. So by using the pfsense resolver it's just a redundant cache.
-
@markn6262 said in How to block DNS forwarder domain requests to private IP addresses:
So by using the pfsense resolver it's just a redundant cache.
again forwarder also caches..
Regardless of if you want to resolve or forward - makes no difference to rfc1918 in public DNS is not a good idea, and yes both the forwarder and resolver will yell at you when it thinks there is a rebind, ie getting rfc1918 back when it doesn't think it should.
-
@johnpoz said in How to block DNS forwarder domain requests to private IP addresses:
rfc1918 in public DNS is not a good idea
Yes, I know rfc1918 in public DNS is not a good idea but that's outside of my control and outside of the customer's control unless I want to track each dns request down to the customer and reach out to them. Don't have the time. Trying the "rebind-domain-ok=/atimetals.com/" entry to see if it eliminates the log entry, although not my preference.
My initial interest was to simply block a dns request outright, to a specific hostname, from forwarding for resolution which should prevent the rebind attack message. Doesn't appear that's possible with the forwarder. Perhaps it is with the resolver but I'm not yet clear from this discussion that it is. Maybe I missed something.
-
@markn6262 you can not "block" a specific request.. You could not answer it, you could send back NX, but you can not really stop a client from asking for something at the server.
If what your after is stopping the logging for rebind, you could put in the entry I gave - this doesn't change anything other than hey don't mind if rfc1918 from that domain.. That is all that command I gave does. The client prob still going to ask for it over and over again, or maybe it won't since it actually got a response, even though its rf1918..
Or you could just turn off rebind protection completely - in the link provided already. If your seeing lots of these for lots of queries - then just turning it completely off might be your easy option.
-
@johnpoz I never got 1ms response time and believe it was utilizing a ram drive too. Perhaps I made the pool too large, it's been quite a few years since using it, maybe 10 years ago. May perform much better now. Also I found the hit ratio was rather poor, like <20% which didn't seem very effective at reducing latency on DNS requests. Especially when the outside latency is only 5ms to begin with. Kind of splitting hairs & wasn't worth the added complexity of the resolver at least in my case use.
-
@markn6262 One option is to create a host override for a domain or hostname, so it resolves to 127.0.0.1 or whatever.
Technically a "hosts" file entry on each device would cause the device to not make the DNS request but that's not very scaleable.
-
@johnpoz By blocking I mean I want to tell the forwarder to not forward the request to the public DNS server. Don't care if the client requests over and over again. I understood your entry would forward the request thereby eliminating the log entry, not that it actually prevented the forwarding of the requested hostname. Do I got it wrong, your custom entry does prevent forwarding the requested hostname for resolution?
-
@markn6262 said in How to block DNS forwarder domain requests to private IP addresses:
Perhaps I made the pool too large
That has nothing to do with it.. Lets be clear on what number you were seeing? An initial query, or a query right after that.. Initial query for something that is not cached is going to be longer.. But the next query should be like zero..
Or maybe your NS is just overloaded? But using the forwarder, and asking for something.domain.tld is going to be cached for the length of the TTL it got back.. So you seeing 5ms is most likely your cached result?
Here something not in my cache
First resolving = 174ms, ask for it again an 0ms
To your cache hit value? That is all going to come down to what is being looked up, ttl values when looked up again, etc.. I am currently running at 76% cache hit.
-
@markn6262 said in How to block DNS forwarder domain requests to private IP addresses:
your custom entry does prevent forwarding the requested hostname for resolution?
No it doesn't - it just allows for rfc1918 to be handed back to the client. Which rebind protection prevents.
-
@johnpoz Never tried on a granular (command line) level as you suggest. I used DNS Benchmark that I presume sends many hostname resolve requests to the list of public or local dns servers. I compared the fiber dns server address and to the pfsense local ip for forwarder vs resolver latency for performance comparison. The forwarder setup was much faster at the time I investigated this. I think the hit ratio you get vs 500 customers can be quite different. Perhaps I should give it another try.
-
@johnpoz That's what I thought.
-
@steveits By hostname entry I presume you mean each "customer" device. Already understand this option but of course wouldn't be practical.
-
@markn6262 said in How to block DNS forwarder domain requests to private IP addresses:
The forwarder setup was much faster at the time I investigated this
Yeah those benchmarks are of limited use in specific scenarios.. Yes quite often asking some public dns for common lookups is going to look faster than something that has to resolve all of them.
But that initial lookup is minor aspect of a well rounded dns setup. 174ms is less than 2 tenths of a second.. Not something to worry about, since the next query for that is going to be zero anyway, etc.
And those numbers can also be skewed in the fact that the resolve time having to work down from roots for something is rarely going to happen, since the gld servers will be cached as well (the ns for the tld) and then the authoritative ns for the domain as well. So if you look up say hostA.domain.tld and it has to be resolved down from roots, when you ask for hostB.domain.tld that doesn't have to happen because the authoritative NS for domain.tld is cached and the query will go direct to an authoritative NS.
Such benchmark tools might be ok if your trying to figure out should you ask googldns or quad9 or your your ISP dns, etc.
But it is of little use in running a well round resolver on your own.. Here is the thing - forward if you want.. Its your choice, but sorry the forwarder caches as well, that is not something special with the resolver.
I would never ever go back to forwarding - I will do my own resolving thank you very much.. I don't care if first time resolving something might take a few ms more.. Means nothing since records are cached. And I also have mine set to prefetch, and also serve 0, and also have min ttl set to 1 hour vs some of the insane 30 second and 5 min ttls being set because they like to track how long your on a site, and you have to ask every 30 seconds for it just tells them you are ;)
Notice the average recursion time and median in my above output- .109 and .045 those are the numbers that tell me how long it normally takes to resolve something. 1/10 of second average is not something user could ever notice.. And that is when its not cached..
-
@markn6262 said in How to block DNS forwarder domain requests to private IP addresses:
@steveits By hostname entry I presume you mean each "customer" device. Already understand this option but of course wouldn't be practical.
A "hosts" file is on each device, e.g. c:\windows\system32\drivers\etc\hosts or /etc/hosts.
A host override is set on the pfSense. Per the Rebinding doc "[rebinding] is automatically overridden for domains in the DNS forwarder domain override list."
-
@steveits said in How to block DNS forwarder domain requests to private IP addresses:
automatically overridden for domains in the DNS forwarder domain override list.
That is different than forwarding to some public NS.. That is an override, that says hey when looking domainX.tld go ask 1.2.3.4, that is not the same as just fowarding all queries to 8.8.8.8
If you set your atimetals.com to forward to specific NS(s) per the override then rebind protection would be disabled for that domain.
if your concern is logs for rebind protection, and you don't care about it - then just turn it completely off.
