nat and dns

hi,
I have a setup that looks like :
_____ ____
[ ] 192.168.0.100 [ ]
[ DNS ]------------------------------[ FW ]----
[_____] 192.168.0.254 [____] (isp)

and I want the DNS to answer to queries from the outside what's the proper way of doing this ?

Sincerely

Raphael

I'm presuming that you want to answer queries from everywhere, rather than just from specific hosts, in which case:

iptables -t nat -A PREROUTING --destination $EXTERNAL_IP -p udp --dport 53 -j DNAT --to-destination 192.168.0.100

iptables -t nat -A PREROUTING --destination $EXTERNAL_IP -p tcp --dport 53 -j DNAT --to-destination 192.168.0.100

iptables -A FORWARD --destination 192.168.0.100 -p udp --dport 53 -j ACCEPT

iptables -A FORWARD --destination 192.168.0.100 -p tcp --dport 53 -j ACCEPT

iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT

I'd be interested to hear how you get on by the way, I'm not quite sure that my iptables rulebases are keeping state on DNS requests correctly.

mors omnia vincit

For DNS query only UDP is necesary, not TCP.

Regards,

Samuel Díaz Garcí­a
Director Gerente
ArcosCom Wireless, S.L.L.

mailto:[email protected]
http://www.arcoscom.com
móvil: 651 93 72 48
tlfn/fax: 956 70 13 15

Heh, that's such a common misconception that I almost mentioned it in my original email. Most DNS queries take place over UDP, however if the reply to the query is especially large then a new TCP connection is opened between the client and server. Also zone transfers take place over TCP IIRC, it depends what kind of functionality the DNS server will be providing.

mors omnia vincit

Sorry, you've reason. But I answered that to simplify and thinking about an internal DNS server that only have the intranet names in it and the external queries are redirected throw external servers.

Sorry again.

Samuel Díaz Garcí­a
Director Gerente
ArcosCom Wireless, S.L.L.

mailto:[email protected]
http://www.arcoscom.com
móvil: 651 93 72 48
tlfn/fax: 956 70 13 15

Just to add some information to the correct one below.

Tcp queries are queries greater than 512 bytes. (normally). Microsoft uses to query via tcp with short queries too, I didn’t found any doc or pattern looking the queries to asume why m$ do this.

Zone transfers like Nick said, are all via tcp

-----Mensaje original-----
De: [email protected] [mailto:[email protected]] En nombre de Nick Drage Enviado el: Jueves, 23 de Septiembre de 2004 8:24
Para: [email protected]
Asunto: Re: nat and dns

Heh, that's such a common misconception that I almost mentioned it in my original email. Most DNS queries take place over UDP, however if the reply to the query is especially large then a new TCP connection is opened between the client and server. Also zone transfers take place over TCP IIRC, it depends what kind of functionality the DNS server will be providing.

--
mors omnia vincit

i surprised you didn't...as it comes up here every time DNS is mentioned. and you're 100% right about it being a misconception.

find me a response to a client resolver request that doesn't fit in a single UDP packet, and i'll stop seeing red every time i see someone recommend allowing TCP 53 from any IP to their DNS server (*).

TCP 53 is for zone transfers. there is no reason to allow TCP from any IP's other then your slave servers. i also recommend ACL-ing zone tranfers in your DNS server configuration as well.

(*) the biggest response i've come across that i can recall is an MX record lookup for earthlink.net, which is about 540 bytes on the wire and still "fits" in a single UDP packet. people that manage DNS servers that respond with messages of this size are aware that many people that they want receiving these answers will not allow TCP 53 in through their firewall and act accordingly.

-j

Jason Opperisano <[email protected]>

Theoretically (since I don't know of any such implementation), it is perfectly legal to have resolver library that first tries TCP, and than UDP :-P

Of course, such approach would be waste of network resources (sending one UDP datagram one way, and another the other way is usually at least as fast as only establishihg new TCP connection without sending any data through it).

Anyhow, I don't see why are you going red when you see TCP port 53 open?
If it is possible for random internet site to fetch zone from DNS
server, it is misconfiguration of DNS server, not of the firewall. OSI layers and all that stuff, you know ;-). If your DNS server does not allow you to restrict who can do zone transfers, that you should seriously consider switching to different DNS server that does. It is the same as if you were to restrict one directory on HTTP server to only certain range of IP addresses, and than blame it on firewall when you misconfigure HTTP server.

Aleksandar Milivojevic <[email protected]>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

it comes from the days of BIND offering up remote root exploits more often that i care to remember. not allowing TCP 53 through the firewall allowed one to get a least a couple of winks over the course of a night.

just adding layers to the onion.

-j

Jason Opperisano <[email protected]>

Well, those days are hopefully over. Modern BIND is just as secure as any other service (hm, thinking about it, this isn't much of an argument ;-) ). Plus, it runs as unpriviledged user in chrooted jail just fine (this one is an argument).

Let me guess, you named your firewall shrek.817west.com?

Aleksandar Milivojevic <[email protected]>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

AIX uses just TCP, even for a plain query.

Best regards,
Jozsef
-
E-mail : [email protected], [email protected] PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
Address : KFKI Research Institute for Particle and Nuclear Physics

          H-1525 Budapest 114, POB. 49, Hungary

Microsoft uses tcp for queries too.

-----Mensaje original-----
De: [email protected] [mailto:[email protected]] En nombre de Samuel Díaz García
Enviado el: Jueves, 23 de Septiembre de 2004 8:10
Para: Netfilter Mailing List
Asunto: Re: nat and dns

For DNS query only UDP is necesary, not TCP.

Regards,

correctly.

Samuel Díaz Garcí­a
Director Gerente
ArcosCom Wireless, S.L.L.

mailto:[email protected]
http://www.arcoscom.com
móvil: 651 93 72 48
tlfn/fax: 956 70 13 15

Wrong. If reply does not fit into single UDP datagram, client will reissue the query over TCP.

Aleksandar Milivojevic <[email protected]>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

seems to work well, thanks...

Use DNAT target. In short what you need to do is:

  iptables -A FORWARD -m state --state NEW -j ACCEPT
  iptables -A FORWARD -p icmp -m state --state RELATED -j ACCEPT
  iptables -A FORWARD -i ext_if -o int_if -d 192.168.0.100 \
     -p udp --port 53 -m state --state NEW -j ACCEPT
  iptables -A FORWARD -i ext_if -o int_if -d 192.168.0.100 \
     -p tcp --port 53 -m state --state NEW -j ACCEPT

  iptables -t nat -A PREROUTING -i ext_if -d ext_ip \
     -p udp --port 53 -j DNAT --to-address 192.168.0.100
  iptables -t nat -A PREROUTING -i ext_if -d ext_ip \
     -p tcp --port 53 -j DNAT --to-address 192.168.0.100

Aleksandar Milivojevic <[email protected]>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

Sorry, a little bit off topic, but I allways go red about such kind of crappy rules:

Do you know what you just did? You've just allowed any kind of connections, protocols to any port and from/to any destionation. Cute, isn't it? Remember, --state NEW, never ever have meant, and I doubt it'll ever mean that this is an tcp connection with only SYN bit set. It could be everyting, ACK,URG,PSH etc. So guess what, you just open a wide hole in your so called "firewall" machine. You better use --tpc-flags or --syn alias for such purposes. --state NEW can be used for redundant firewalling for example, but for me it has no use.

Regards,
Dimitar

P.S. Why I go red? Because there're thousands of people who use it, and they learned it from someone like you.

"The only thing necessary for the triumph of evil is for good men to do
nothing."
                                                  --Edmund Burke. 

if you're going to go on a tirade about the problem with that rule, at least point out the actual problem: it doesn't specify the inbound interface and/or source network(s):

  iptables -A FORWARD -i $INTERNAL_IF -m state --state NEW -j ACCEPT  

modifying it to use "-p tcp --syn" still allows all TCP traffic through the FORWARD chain in both directions.

-j

Jason Opperisano <[email protected]>

Quoting Dimitar Katerinski <[email protected]>
Date: Fri, 24 Sep 2004 01:02:11

The above was an obvious typo that I made. It should have read ESTABLISHED, not NEW, of course. It kinda suprised me that it took so long before anybody noticed.

As for using only --state NEW in my other rules vs specifying tcp flags, there were some discussions before on the list about it. For most part it will just prevent nmap and similar programs to do some types of tests used to remotely determine OS type. Personally, I do use tcp-flags option in combination with --state NEW. And what I sometimes type when giving examples (mostly not, becase of pure laziness on my part) is that they are examples and that reader should add additional flags to make it more tight.

Maybe yes, maybe no. The bottom line is that probability of somebody getting burned by not using tcp-flags (or simply syn) option is quite low. But if that's going to make you so much happier person, I can start typing mile long examples instead of giving hints. I could bet that out of those thousands, there will be at least 99% that will fail to realize that 2.6 series of kernels is extremely trigger happy to load ipv6 module (which will automatically assign link local IPv6 addresses to all Ethernet interfaces), and that is much more serious problem than omiting --syn or whatever...

Aleksandar Milivojevic <[email protected]>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7

i regret not pointing out in my response that it was obvious to me that this was a typo, and not any reflection on the poster in any way, shape, or form.

precisely. the rules that get posted here are to illustrate the point, not our recommendations of what makes a perfect firewall.

i know as well as anyone that the easiest path is to lurk and wait for typo to pounce upon.

-j

Jason Opperisano <[email protected]>