Dynamisches DNS mit Duck DNS und Barracuda NextGen Firewall F

Was ist DDNS?

Dynamisches DNS oder DDNS ist eine Technik, um Domains im Domain Name System (DNS) dynamisch zu aktualisieren. Der Zweck ist, dass ein Computer (bspw. ein PC oder ein Router) nach dem Wechsel seiner IP-Adresse automatisch und schnell den dazugehörigen Domaineintrag ändert. So ist der Rechner immer unter demselben Domainnamen erreichbar, auch wenn die aktuelle IP-Adresse für den Nutzer unbekannt ist. Wikipedia

Der populärste Vertreter ist sicherlich Dyn.com (früher auch DynDNS.org), jedoch gibt es das gratis Service schon länger nicht mehr. Darum gibt es auch viele freie Angebote die Versuchen den Platz einzunehmen, eines davon ist Duck DNS. Es verspricht eine einfach Nutzung und hat IPv4 und IPv6 Support. Der unbezahlte Account kann bis zu 5 Domains mit IPs versehen und das über einen einfachen HTTPS Post.

Damit war der Weg bereit für eine Implementierung von Duck DNS auf einer NextGent Firewall F von Barracuda und ich war überrascht wie einfach und schnell sie zu realisieren war.

Continue reading “Dynamisches DNS mit Duck DNS und Barracuda NextGen Firewall F”

wpad DNS resolution not working

After rolling out the proxy settings within my network, there is another nice feature I stumbled upon:
“Networks using Windows 2003 and/or 2008 Servers as a DNS do or can block wpad request by default.”

Nice if you do not use it – but kinda hard to find if you need it and don’t know it.

Windows 2008 is straight forward to configure and Microsofts KB is helping.
Windows 2003 is a different story. I found Chris Dents homepage to address the issue because Microsofts KB ist nor very useful. I looked into the registry and surprisingly the so called global query block list was disabled (as the handbook says but why does it now work).

Nevertheless – without deleting the entries for wpad and restarting the DNS Server service the wpad URL wasn’t able to be resolved.

So be aware of that 🙂

Enabling or Disabling the Global Query Block List

Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
Name EnableGlobalQueryBlockList
Data Enable: 1; Disable: 0

The default is disabled.

Managing the Global Query Block List

Key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters
Name GlobalQueryBlockList
Type REG_MULTI_SZ (Multi-String Value)
Data wpad isatap

Proxy Auto-Configuration and its challenges

I was a fan of WCCP for setting up transparent proxy within a network – it always seemed the easiest way but all together it only seemed like that. A lot of problems came up in the past few month on customer sides and within my installation so I decided to give Proxy Auto-Configuration a try.

Biggest benefit of using PAC (Proxy Auto-Configuration) is: “You get rid of transparent proxy.” That makes life easier – but before I had to learn a lot of stuff the hard way.

Rollout the URL for the PAC File without touching the client

2 Options are available – DNS and Option 252 for DHCP

Easiest way is DHCP and the configuration therefore is straight forward. Extend your DHCP configuration with the option 252 and put the URL for the PAC file as a value into. The client fetches with the next renew of the DHCP settings also the proxy information.

DHCP has a higher priority than DNS: if DHCP provides the WPAD URL, no DNS lookup is performed. Notice that Firefox and Chrome do not support DHCP, only DNS.

Next step is to set up DNS for the browsers lacking DHCP support. It’s also straight forward – redirect any request for wpad.yourinternaldomain.com to the PAC file server. The browser is going to fetch the file wpad.dat (which is our PAC file) from the file server.

Verify your Clients

Very important for your client PCs and/or applications is that they are set to auto-detect proxy settings from your network. If this is not set up – you have to touch the client or use some kind of scripting to set that on your browsers.

PAC file hosting

One challenge could be the PAC file hosting. If you use a webserver – it is important that every PAC file (nevertheless if it is called proxy.pac or wpad.dat) sent to the client gets the right MIME type. The MIME type of the configuration file must be “application/x-ns-proxy-autoconfig”.

If you are using DNS to get the PAC file – every client is requesting the wpad.dat file from the URL mentioned above on port 80.

PAC file hosting with Cisco Ironport Web Appliance

If you are using a Cisco Ironport S-Series or Web Appliance – a lot of things get handled by the Ironport itself. MIME type is set right and a few other things which we are talking right now.

Ironports PAC file hosting lets you specify a port for the PAC file service – per default 9001. If you use DNS – the PAC file service has to listen on port 80 as well. That is not a problem as long as you are not using port 80 for your web proxy service and your AsyncOS Version is 7.x
Just add the port 80 to the PAC file service and submit the changes.

Next step is to upload your PAC file – the PAC File can have any name as long as you can remember it and use it right if you set up your DHCP settings. Ironport also supports multiple PAC files as long as they have a different name. That’s it if you can use DHCP – every DHCP pool within your network could fetch a different PAC file from the same Ironport Appliance.

Talking about DNS – you need to host wpad.dat files – Ironport is helping out. In the section “Hostnames for Serving PAC Files Directly” you can set up a GET hostname (the URL the client is using to access the PAC hoster) and choose a PAC file from your uploaded one and Ironport is renaming it on demand for the client requesting.

For example, if you enter wsa.example.com in the Hostnames field and pacfile1.pac in the Default PAC File for “Get/” Request through Proxy Port field, then requests for http://wsa.example.com/ fetch pacfile1.pac and requests for http://wsa.example.com/default.pac fetch default.pac.

Additional Information