DNS requests filtering

I have a little DNS server at home that I would like to open up so that
name resolution requests from external hosts are accepted. I understand
that something like the following might do the trick:

iptables -A INPUT -s xx.xx.xx.xx -p udp --dport 53 -j ACCEPT

This would accept name resolution requests incoming from IP address
xx.xx.xx.xx. The problem is that I need to use a name, rather than an IP
address, for the host that I want to accept requests from has its IP
address dynamically assigned by DHCP.

Can an IPTables rule meeting the requirements above be written?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Augustus SFX van Dusen wrote:

> iptables -A INPUT -s xx.xx.xx.xx -p udp --dport 53 -j ACCEPT
>
> Can an IPTables rule meeting the requirements above be written?

iptables -A INPUT -s machine.domain.ext -p udp --dport 53 -j ACCEPT

+ "cron" for update "iptables" and resolve the changes of dynamic IP.

- --
Un saludo
Alo [alo(@)uk2.net]
PGP en http://pgp.eteo.mondragon.edu [Get "0xF6695A61 "]
Usuario registrado Linux #276144 [http://counter.li.org]

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEx1/rvzPPcPZpWmERAvOrAJ4s0lKXn+EplBg5fYNn9x3SQRcFBgCgv otE
qw2iUIxWriS+CWmLbTAlo0k=
=aAug
-----END PGP SIGNATURE-----

On Wed, 26 Jul 2006 14:28:27 +0200, Alo wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Augustus SFX van Dusen wrote:
>
>> iptables -A INPUT -s xx.xx.xx.xx -p udp --dport 53 -j ACCEPT
>>
>> Can an IPTables rule meeting the requirements above be written?
>
> iptables -A INPUT -s machine.domain.ext -p udp --dport 53 -j ACCEPT
>
> + "cron" for update "iptables" and resolve the changes of dynamic IP.

This raises two questions concerning what happens when invoking the
iptables rule above from the cron job:

1) If the address has not changed: I think that iptables just keeps
adding the same rule over and over again, which presumbaly is not a good
idea.

2) If the address has changed: The rule for the previous, now obsoleted,
address remains active, which is not what we want.

There are somewhat inelegant ways around this by means of shellscripts,
but I wonder if less convoluted solutions could be developed?

Augustus SFX van Dusen <(E-Mail Removed)> wrote:
> iptables -A INPUT -s xx.xx.xx.xx -p udp --dport 53 -j ACCEPT

> 1) If the address has not changed: I think that iptables just keeps
> adding the same rule over and over again [...]

Correct


> 2) If the address has changed: The rule for the previous, now obsoleted,
> address remains active, which is not what we want.

Also true


> There are somewhat inelegant ways around this by means of shellscripts,
> but I wonder if less convoluted solutions could be developed?


I don't see that shell scripting is inelegant - after all, scripting is
there for solving problems.

My solution to this kind of situation is to create a new chain,
specifically for the task in hand. It's then quite acceptable to flush
it immediately before adding a new rule because one knows that it's
dedicated to single use.

One-off initialisation:
iptables -N FIREWALL_DNS
iptables -A INPUT -p udp --dport 53 -j FIREWALL_DNS

Thereafter, whenever you need to update the rule:
iptables -F -Z FIREWALL_DNS
iptables -A FIREWALL_DNS -s xx.xx.xx.xx -j ACCEPT

Chris

On Thu, 27 Jul 2006 09:30:53 +0100, Chris Davies wrote:

> I don't see that shell scripting is inelegant - after all, scripting is
> there for solving problems.

I did not mean that shell scripting is inherently inelegant, but that a
shell scripting solution for this problem is probably inelegant. The
solution that you propose below illustrates the point.


> My solution to this kind of situation is to
create a new chain,
> specifically for the task in hand. It's then quite acceptable to flush
> it immediately before adding a new rule because one knows that it's
> dedicated to single use.
>
> One-off initialisation:
> iptables -N FIREWALL_DNS
> iptables -A INPUT -p udp --dport 53 -j FIREWALL_DNS
>
> Thereafter, whenever you need to update the rule:
> iptables -F -Z FIREWALL_DNS
> iptables -A FIREWALL_DNS -s xx.xx.xx.xx -j ACCEPT
>
> Chris

On Thu, 27 Jul 2006 09:30:53 +0100, Chris Davies wrote:

> My solution to this kind of situation is to create a new chain,
> specifically for the task in hand. It's then quite acceptable to flush it
> immediately before adding a new rule because one knows that it's dedicated
> to single use.
>
> One-off initialisation:
> iptables -N FIREWALL_DNS
> iptables -A INPUT -p udp --dport 53 -j FIREWALL_DNS
>
> Thereafter, whenever you need to update the rule:
> iptables -F -Z FIREWALL_DNS
> iptables -A FIREWALL_DNS -s xx.xx.xx.xx -j ACCEPT

Just a couple of comments:

1) My iptables command refuses to take -F and -Z at the same time. From
reading the man pages, I would have thought that -F should be enough,
right?

2) With those rules it would seem that any host can ask my DNS for name
resolutions. Adding a rule like

iptables -A FIREWALL_DNS -s 0/0 -j REJECT

seems to accomplish what I want, namely, for all requests to be rejected,
with the exception of those coming from xx.xx.xx.xx.

Is this the right way to do it?

Augustus SFX van Dusen <(E-Mail Removed)> wrote:
> 1) My iptables command refuses to take -F and -Z at the same time

I should have put an "untested" disclaimer against the examples!


> 2) With those rules it would seem that any host can ask my DNS for name
> resolutions. Adding a rule like
> iptables -A FIREWALL_DNS -s 0/0 -j REJECT

You would then get a (small) window of opportunity between the "iptables
-F" and the rule creation where anyone could poke your box. The better
place for it is permanently in the INPUT chain immediately after the
call to FIREWALL_DNS. (This also means if you flush FIREWALL_DNS but
forget to add rules to it, then you don't leave your box wide open.)

Chris