How to block DNS forwarder domain requests to private IP addresses

[markn6262]

Is there a simple way to block DNS requests by domain name so it doesn't result in 100's of "possible DNS-rebind attack detected" dns resolver messages an hour? Adding address=/hostname.com/10.10.10.10 to the forwarder's custom options doesn't do it. I only have the forwarder not the resolver enabled.

[johnpoz]

@markn6262 what is the error you getting?

Your going to need to provide some more info, for the life of me have no idea what your asking about.

A rebind is when you forward somewhere for dns and get back an rfc1918 address. What exactly are you forwarding too? Your isp? What is the hostname that is being asked for that is coming back rfc1918?

[markn6262]

@johnpoz I get the error "Jun 28 17:31:16 dnsmasq 70303 possible DNS-rebind attack detected: atip.atimetals.com" every couple minutes. Coming from a customer that has forward port rules & a 1:1 pure nat per customer each having their own internal/external IP pair.

What add'l info you need?

[johnpoz]

@markn6262 said in How to block DNS forwarder domain requests to private IP addresses:

atip.atimetals.com

Yeah that is messed up honestly... That resolves on the public internet with a 10 address

;; QUESTION SECTION:
;atip.atimetals.com.            IN      A

;; ANSWER SECTION:
atip.atimetals.com.     21600   IN      A       10.134.200.19

Why do they want that to resolve to a rfc1918 address, that would never work on the internet.

If you want to use that internally for them, then you should resolve that to the 10 address, that entry should not be in public dns space.

As a quick hack to make the errors stop, you could set that a a private domain, and it would allow rfc1918 responses.

Like this
rebind-domain-ok=/atimetals.com/

But that not correct way to solve the issue.

https://docs.netgate.com/pfsense/en/latest/services/dns/rebinding.html

Again public dns should not resolve to rfc1918 addresses.

If they are behind your pfsense with a nat, the domain on the public internet should resolve to the public IP your forwarding to their server IP on your rfc1918 network.

[markn6262]

@johnpoz There must be a lot of bad dns entries for exploitation to rfc1918 addresses. It swamps the resolver log. I read bout that trick elsewhere on this forum. But I’d rather not punch thru many dns rebind holes. With 500 customers I get a lot of these msgs but this hostname is by far the worst. I don’t think the customers know. Probably in a javascript to a commonly used webpage they visit. Thot there might be a way to suppress the message to specific hostnames without allowing it to actually rebind. Your trick has the base hostname atimetals.com which resolves to Microsoft. The hostnames atip.atimetals.com & nls.atimetals.com resolve to rfc1918.

[johnpoz]

@markn6262 setting the domain like that makes sure anything that resolves from that domain, if comes back rfc1918 is fine.

You could just turn off all rebind protection.. Its quite possible you have customers registering their rfc1918 in public space via some ddns sort of thing.

But generally speaking rfc1918 in public space is BAD.. That is why they setup rebind protection, its not a good idea to resolve rfc1918 in address for domains that resolve on the public internet.

I don't know your setup or what your trying to do for your customers, but if they are registering their rfc1918 in public space - its not a good idea, and you should look to correct that. Nobody on the public internet is going to be able to get their anyway - if want their users to use their services.

[SteveITS]

@markn6262 In the DNS Resolver "custom options" add the two lines:

server:
private-domain: "atimetals.com"

[markn6262]

@johnpoz Like I say I don’t think the customers are setting up anything. I’m just trying to serve customers Internet service. I thought these were legitimate DNS hacks that somebody else set up for the express purpose of rebinding attacks. I really don’t want to disable rebind protection. Thanks for your feedback.

[markn6262]

@steveits Thanks, I’ll try your suggestion and see if it quashes the log entry influx.

[markn6262]

@steveits I thot all custom option entries were single line like;
address=/smartsourcestaging.dell.com/10.10.10.10
Sure a 2 line entry is the proper syntax? Will every entry after “server:” behave differently? Should this be placed as the last entry?

[markn6262]

@steveits Got it.

[johnpoz]

@steveits he not using the resolver - he is using the forwarder, that is what he stated..

@markn6262 said in How to block DNS forwarder domain requests to private IP addresses:

I only have the forwarder not the resolver enabled.

Or @markn6262 did you mean you have the resolver (unbound) in forwarder mode?

[SteveITS]

@johnpoz Ah, my bad. I keep forgetting that exists because we always set up Resolver to forward (to filtered DNS).

[johnpoz]

@markn6262 also just so we are clear

https://www.rfc-editor.org/rfc/rfc1918.txt

  If an enterprise uses the private address space, or a mix of
  private and public address spaces, then DNS clients outside of
  the enterprise should not see addresses in the private address
  space used by the enterprise, since these addresses would be
  ambiguous.

I don't know if this ever got ratified..
https://www.ietf.org/proceedings/52/I-D/draft-ietf-dnsop-dontpublish-unreachable-01.txt
IP Addresses that should never appear in the public DNS

I would suggest you figure out how your clients are putting 10 space in the public dns - this is a really bad idea..

[markn6262]

@johnpoz Yes I meant as stated, the forwarder. I stopped using the resolver because I didn’t needed caching as it added latency.

[johnpoz]

@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.

[markn6262]

@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]

@markn6262 Missed that you mentioned resolver. So presumably the “server:…” line wont work in the forwarder.

[SteveITS]

@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.

[johnpoz]

@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..