How to block DNS forwarder domain requests to private IP addresses

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

[markn6262]

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

[johnpoz]

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

[markn6262]

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

[johnpoz]

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