Well, I don't know how others do it, but when I need to deploy a LAN DNS server I use BIND. One gets total control over configuration options, and you can be certain it will not break under heavy load like the DNS stub in some cheap home routers tend to do.
I don't really see why such strict measures would be taken at a provider level. On a business level, SPF is probably moot since the company mail is unlikely to go via SMTP at least until well past the firewall. At any rate, TXT records is actually the old way of implementing SPF, since it has its own type by now (DNS record type 99). The use of TXT for SPF is not deprecated yet, but I hope it will be soon because it is a sloppy messy way of handling things. On 15 October 2012 09:22, Rocco Radisch <[email protected]> wrote: > True that. Limiting the length might be a solution, but txt records are > used for SPF so tricky on provider level. Bind is like a dns server swiss > knife. Although, I haven't come across many deployments using bind as LAN > dns server? > > > > On 14/10/2012 17:23, Benjamin Tayehanpour wrote: > > A very easy way of blocking DNS tunnelling (given a forced local DNS > server in your control) would be to block all TXT replies, or even to limit > the length of a query so the base32-encoded data simply will not fit. None > of these measures would hamper ordinary usage, and both of these are > standard configuration options in BIND, and, I'm sure, in many other DNS > daemons, so blocking it is quite trivial. > > But it probably will go unnoticed for quite some time, unless you use > disruptive amounts of resources. > > On 14 October 2012 16:10, Rocco Radisch <[email protected]> wrote: > >> ICMP can be blocked, hence its boring. Look at DNS tunnelling and you >> will quickly realise where the real hammer is. Ok, for speed reasons an >> openvpn tunnel on udp port 53 might be an alternative if outgoing DNS >> traffic is not blocked. DNS tunnelling uses the internal DNS servers to >> relay traffic, which is difficult to block. So, with all outbound traffic >> blocked and with only access to internal resources it is still possible to >> go to Facebook with the help of an internal DNS server ;-) That can only be >> mitigated on the DNS server itself and there are not so many options yet. >> Snort might be able to tell the difference (if listening on LAN). >> Same principles work with local provider's Hotspot - "please load more >> credit" sites. Or, for the tech novices, just look up WiFree. It uses all >> mentioned methods (udp, tcp, icmp, dns) seemingly together. >> >> Rocco >> >> >> On 14/10/2012 12:42 PM, [email protected] wrote: >> >> However, most ops have probably not even heard about ICMP tunnelling. >> Even if this one has, examining the contents of the ICMP Echo payload will >> probably not be the first thing an ordinary op does. She will probably >> think you are ICMP flooding the target, though, and that is probably a >> graver offence than a little tunnelling. >> >> If it's a public hotspot you probably have nothing much to fear, though, >> as you are anonymous and practically impossible to trace. >> >> Phillip Simbwa <[email protected]> <[email protected]> wrote: >>> >>> >The ICMP tunnelling trick was quite nifty. It will light most pieces of >>> >network >>>> >>>> monitoring softwares up like Christmas trees, though, but chances are >>>> public >>>> hotspot providers do not monitor traffic that closely. >>> >>> >>> My man is working with just a Linksys wireless router <cough> </cough> >>> If i was one of his stress boys, and my casual reconn indicated that >>> the Linksys was his strongest weapon; I wouldn't put much effort to it >>> (it would be over kill). >>> >>> But if the wireless router is loaded with ddwrt, i would tread more >>> carefully -- the network admin may not be the ordinary nice guy. He >>> may have a few surprises up his sleeve (e.g dumping logs from the >>> Linksys to some remote server for ana >>> lysis). >>> In such a situation, >>> going with ICMP/DNS tunneling is like carrying a knife to a gun fight. >>> >>> >>> >>> >> >> _______________________________________________ >> The Uganda Linux User Group: http://linux.or.ug >> >> Send messages to this mailing list by addressing e-mails to: [email protected] >> Mailing list archives: http://www.mail-archive.com/[email protected]/ >> Mailing list settings: http://kym.net/mailman/listinfo/lug >> To unsubscribe: http://kym.net/mailman/options/lug >> >> The Uganda LUG mailing list is generously hosted by INFOCOM: >> http://www.infocom.co.ug/ >> >> The above comments and data are owned by whoever posted them (including >> attachments if any). The mailing list host is not responsible for them in >> any way. >> >> >> >> _______________________________________________ >> The Uganda Linux User Group: http://linux.or.ug >> >> Send messages to this mailing list by addressing e-mails to: >> [email protected] >> Mailing list archives: http://www.mail-archive.com/[email protected]/ >> Mailing list settings: http://kym.net/mailman/listinfo/lug >> To unsubscribe: http://kym.net/mailman/options/lug >> >> The Uganda LUG mailing list is generously hosted by INFOCOM: >> http://www.infocom.co.ug/ >> >> The above comments and data are owned by whoever posted them (including >> attachments if any). The mailing list host is not responsible for them in >> any way. >> > > > > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in any > way. > > > > _______________________________________________ > The Uganda Linux User Group: http://linux.or.ug > > Send messages to this mailing list by addressing e-mails to: > [email protected] > Mailing list archives: http://www.mail-archive.com/[email protected]/ > Mailing list settings: http://kym.net/mailman/listinfo/lug > To unsubscribe: http://kym.net/mailman/options/lug > > The Uganda LUG mailing list is generously hosted by INFOCOM: > http://www.infocom.co.ug/ > > The above comments and data are owned by whoever posted them (including > attachments if any). The mailing list host is not responsible for them in > any way. >
_______________________________________________ The Uganda Linux User Group: http://linux.or.ug Send messages to this mailing list by addressing e-mails to: [email protected] Mailing list archives: http://www.mail-archive.com/[email protected]/ Mailing list settings: http://kym.net/mailman/listinfo/lug To unsubscribe: http://kym.net/mailman/options/lug The Uganda LUG mailing list is generously hosted by INFOCOM: http://www.infocom.co.ug/ The above comments and data are owned by whoever posted them (including attachments if any). The mailing list host is not responsible for them in any way.
