How to block DNS forwarder domain requests to private IP addresses
-
@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.
-
@johnpoz Sigh...I am doing so well I should just stop commenting on this post. ٩(͡๏̯͡๏)۶
Yes, domain override is what you described. What I was trying to mention was host override, and then pasted the statement about domain override. The host override is one entry per host, so also not very scalable.
-
@steveits yeah he could just create a host entry (fqdn) via overrides for every host that is causing the rebind entry. But if his concern is the log entries about rebind, and doesn't want to correctly fix the problem by making sure his customers resolve what they want how they need to resolve it.
rfc1918 in public dns is just not good practice no matter how you look at it, its something that should be clearly avoided.
Here is the solutions I can see without major work with the customers working out any and all of their dns problems and needs.
Disable rebind for specific domains he is seeing the logging for.
Disable rebind protection completely
Don't even let his customers use pfsense for dns, and just have them use some public dns or their own local dns they run, etc. -
@johnpoz Ya, I use to have a rule that pushed all DNS requests to the forwarder but some customers wanted to use Google, OpenDns, etc due to marketing and the belief it was faster even though it wasn't so I didn't argue the point and disabled the rule.
Your last suggestion is the most palatable, could do a similar rule on an alias pool of problem customers and redirect them to a public DNS server. The only small downside is there would be no redundancy if the single public DNS goes down.
I wasn't expecting it would get as far into the weeds but it was educational and I really appreciate you both for the time spent responding. Much appreciated.
-
@markn6262 said in How to block DNS forwarder domain requests to private IP addresses:
The only small downside is there would be no redundancy if the single public DNS goes down.
Why do you need to redirect at all, just let them set their own dns.. Hand out public dns only via dhcp, etc.
You understand these single dns IPs are anycast right? If cloulddns, googledns or quad9 go down they have a major problem.. Not just like 1 box goes offline..
But ok - this is another reason to resolve vs forward ;) Roots go down the whole internet is down doesn't matter where you forward. So cut out the possibility of where you forward going down - and just resolve directly ;)
From my understanding of your pain - log entries of rebind. The simple solution to remove that "problem" is just turn off all rebind protection. There you go no log entries for anything public that resolves rfc1918.. Now no log entries of rebind issues ;)
I have been resolving since unbound was only a package in pfsense, before that even using bind. Never once have I had an dns outage problem because some dns service was offline ;)
You know what I redirect for dns - iot devices that insist on hardcoding dns.. Sorry your not going to be able to use google, your dns queries are going to be resolved via my resolver, not sent to google..
-
@johnpoz I have had the fiber provider's DNS go down (2 servers) while the data was still up so had to temp redirect all DNS to an external server until it was fixed. But yes, I do understand these single dns IPs are anycast, which is why I say the probability is small. The bit about turning off rebind protection seems circular. I get a loss of security just to keep the log clean. In this discussion it has been mentioned it's not a good idea to disable the protection rebind offers so I'm confused your suggesting it again. Why de-harden a firewall only to reduce log entries? This would invite external access to an internal device if they were lucky enough to set a public dns to a private IP that was valid to my local network.
As for handing out public dns via dhcp, I'm doing that now to the forwarder. To do all customers external would be a system wide performance hit. Is there a way to hand out a public dns via dhcp by individual IP or alias leaving all others to use the system general settings pointing to the forwarder (127.0.0.1)?
