Different forwarder for certain response ip (result ip )

Reindl Harald h.reindl at thelounge.net
Sat Sep 16 13:17:28 UTC 2017

Am 16.09.2017 um 15:12 schrieb Sten Carlsen:
> On 16-09-2017 14.56, Matus UHLAR - fantomas wrote:
>> On 16.09.17 04:19, Omid Kosari via bind-users wrote:
>>> Actually my situation is a bit strange . But as explanation i can say
>>> that
>>> our upstream provider do dns manipulation on normal ports 53 tcp/udp
>>> (please
>>> don't ask why). We may not use vpn or tunnels . The only way is using
>>> alternate ports as forwarders.
>> that explains why you want forwarders on port 443.
>> But it doesn't explain why you forward to google. I still think it's
>> useless, unless your ISP blocks port 53 to public servers.
> This is still not entirely clear to me. I see two possible scenarios,
> please indicate which is closer to your situation:
> 1 - your ISP provides their own DNS servers as part of the service and
> indicate those via DHCP. These servers give mangled replies.
> 2 - ALL traffic on port 53 is mangled in e.g. a router/switch along the
> path according to some rule imposed by the ISP.
> In case 1) which is common, I have used a DNS server locally without
> forwarding with perfect results. It will never ask the ISP's server.
> In case 2) something like your solution is needed. The use of port 443
> is an obvious idea, however DNS uses UDP and HTTPS uses TCP. Your ISP
> appears to be paranoid enough to block also port 443 UDP, so that might
> be one issue.

DNS is using both and when UDP fails it should fallback in any case to 
TCP as it does for large respones - you can likely reject UDP 53 and it 
would still work and as already said: distinct between https and dns 
traffic on the ISP side would require expensive (expensive at least for 
the scale of an ISP) deep packet inspection


for DNSSEC as exmaple TCP is mandatory because the DO-Flag wont fit into 
the default header for UDP

> Would there be any UDP ports open, like streaming services or games? If
> so they may provide a possibility

More information about the bind-users mailing list