PROBLEMS WITH DNS

PROBLEMS WITH DNS

[Eduardo Franceschini]

bootargs=console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/mtdblock4
mem=30M

and when I boot the omap, I have

Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.1.107
IP-Config: Complete:
      device=eth0, addr=192.168.1.107, mask=255.255.255.0, gw=192.168.1.1,
     host=192.168.1.107, domain=, nis-domain=(none),
     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.

I can get an IP, but when I go to /etc/resolv.conf , I don't have an IP for
DNS server... somebody know what to do?

thanks!

Eduardo

-- 
Eduardo Montenegro Franceschini
Engenharia de Computação - UNICAMP
fone: +55-19-9778-8998
e-mail: edumontenegro@gmail.com
-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: PROBLEMS WITH DNS

[Nishanth Menon]

Eduardo Franceschini stated on 6/8/2007 12:23 PM:
> I can get an IP, but when I go to /etc/resolv.conf , I don't have an
> IP for
> DNS server... somebody know what to do?
To my knowledge, the host resolution order can be configured in
nssswitch.conf.. If you have NIS/NIS+ you could use the same to update
the /etc/hosts from a file... or i think there is someway to configure
using LDAP also..
check any of your linux desktops on the network, see how it is
configured.. it will help u configure ur board too.. I dont know if the
dhcpd daemon would grab the dns server info and update etc files.. u
could check associated documentation too.. personally i hack up my
/etc/hosts and resolv.conf with values i know of..but that'd be quick
and dirty ;)
Regards,
Nishanth Menon

Re: PROBLEMS WITH DNS

[Vadim Lebedev]

Eduardo Franceschini wrote:

> bootargs=console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/mtdblock4
> mem=30M
>
> and when I boot the omap, I have
>
> Sending DHCP requests ., OK
> IP-Config: Got DHCP answer from 0.0.0.0, my address is 192.168.1.107
> IP-Config: Complete:
>      device=eth0, addr=192.168.1.107, mask=255.255.255.0, gw=192.168.1.1,
>     host=192.168.1.107, domain=, nis-domain=(none),
>     bootserver=0.0.0.0, rootserver=0.0.0.0, rootpath=
> NET4: Unix domain sockets 1.0/SMP for Linux NET4.0.
>
> I can get an IP, but when I go to /etc/resolv.conf , I don't have an 
> IP for
> DNS server... somebody know what to do?
>
> thanks!
>
> Eduardo
>
Eduardo,

this DHCP request are sent by kernel mode dhcp client,  which has no access
to resolv.conf to store retrived information

I'dont now if somebody have developped a possibility to retriev this 
info using
user-mode app and store it into resolv.conf...

Maybe one why to do it is to modify kernale mode dhcp client to create a 
procfs entry containig info for resolv.conf
and have /etc/resolv.com  to be symlink to procfs entry
 

Thanks
Vadim

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: PROBLEMS WITH DNS

[Paulo Marques]

Vadim Lebedev wrote:
> Eduardo Franceschini wrote:
> [...]
>> I can get an IP, but when I go to /etc/resolv.conf , I don't have an 
>> IP for
>> DNS server... somebody know what to do?
> [...]
> Maybe one why to do it is to modify kernale mode dhcp client to create a 
> procfs entry containig info for resolv.conf
> and have /etc/resolv.com  to be symlink to procfs entry

I'd say this is just the opposite direction of where things seem to be 
going nowadays.

AFAICS, the current solution to this problem is to use initrd / 
initramfs with a user-space dhcp client and nice script to get the DNS 
information into /etc/resolv.conf.

With this in place you can even drop the DHCP / NFS-root support from 
the kernel and have it all done in user-space.

This seems to be the current trend, and I wouldn't be surprised if the 
options for IP auto config and NFS root were dropped from mainline in 
the future.

-- 
Paulo Marques - www.grupopie.com

"The Computer made me do it."

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: PROBLEMS WITH DNS

[Vadim Lebedev]

Paulo Marques wrote:

> Vadim Lebedev wrote:
>
>> Eduardo Franceschini wrote:
>> [...]
>>
>>> I can get an IP, but when I go to /etc/resolv.conf , I don't have an 
>>> IP for
>>> DNS server... somebody know what to do?
>>
>> [...]
>> Maybe one why to do it is to modify kernale mode dhcp client to 
>> create a procfs entry containig info for resolv.conf
>> and have /etc/resolv.com  to be symlink to procfs entry
>
>
> I'd say this is just the opposite direction of where things seem to be 
> going nowadays.
>
> AFAICS, the current solution to this problem is to use initrd / 
> initramfs with a user-space dhcp client and nice script to get the DNS 
> information into /etc/resolv.conf.
>
> With this in place you can even drop the DHCP / NFS-root support from 
> the kernel and have it all done in user-space.
>
> This seems to be the current trend, and I wouldn't be surprised if the 
> options for IP auto config and NFS root were dropped from mainline in 
> the future.
>
Kernel mode dhcp client solutions allows muuch faster boot sequences...
for embedded stuff 15-20 secs boot speed advantage is important....

Vadim

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: PROBLEMS WITH DNS

[Paulo Marques]

Vadim Lebedev wrote:
> Paulo Marques wrote:
> 
>> Vadim Lebedev wrote:
>>
>>> Eduardo Franceschini wrote:
>>> [...]
>>>
>>>> I can get an IP, but when I go to /etc/resolv.conf , I don't have an 
>>>> IP for
>>>> DNS server... somebody know what to do?
>>>
>>> [...]
>>> Maybe one why to do it is to modify kernale mode dhcp client to 
>>> create a procfs entry containig info for resolv.conf
>>> and have /etc/resolv.com  to be symlink to procfs entry
>>
>>
>> I'd say this is just the opposite direction of where things seem to be 
>> going nowadays.
>>
>> AFAICS, the current solution to this problem is to use initrd / 
>> initramfs with a user-space dhcp client and nice script to get the DNS 
>> information into /etc/resolv.conf.
>>
>> With this in place you can even drop the DHCP / NFS-root support from 
>> the kernel and have it all done in user-space.
>>
>> This seems to be the current trend, and I wouldn't be surprised if the 
>> options for IP auto config and NFS root were dropped from mainline in 
>> the future.
>>
> Kernel mode dhcp client solutions allows muuch faster boot sequences...
> for embedded stuff 15-20 secs boot speed advantage is important....

I can't see why a user space client running from initramfs with 
basically the same code as the in-kernel dhcp client would be much 
slower. I'd be surprised if the difference is more than a few milliseconds.

So the real problem is to find a dhcp client that is actually as simple 
as the in-kernel one. "udhcpc"[1] might just do what you want.

The only other argument I can see for in-kernel dhcp is that it is 
easier to configure than it is to setup an initramfs filesystem. As soon 
as that problem is somehow solved, I don't see the advantage in keeping 
the in-kernel version.

-- 
Paulo Marques - www.grupopie.com

"Very funny Scotty. Now beam up my clothes."

[1] http://udhcp.busybox.net/

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: PROBLEMS WITH DNS

[Hans-Jürgen Koch]

Am Freitag 08 Juni 2007 21:05 schrieb Paulo Marques:

> 
> The only other argument I can see for in-kernel dhcp is that it is 
> easier to configure than it is to setup an initramfs filesystem. As soon 
> as that problem is somehow solved, I don't see the advantage in keeping 
> the in-kernel version.

Please don't forget the people who mount their root file system via NFS.
I'd say this is the main reason for having DHCP in the kernel.

Hans


-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: PROBLEMS WITH DNS

[Paulo Marques]

Hans-Jürgen Koch wrote:
> Am Freitag 08 Juni 2007 21:05 schrieb Paulo Marques:
> 
>> The only other argument I can see for in-kernel dhcp is that it is 
>> easier to configure than it is to setup an initramfs filesystem. As soon 
>> as that problem is somehow solved, I don't see the advantage in keeping 
>> the in-kernel version.
> 
> Please don't forget the people who mount their root file system via NFS.
> I'd say this is the main reason for having DHCP in the kernel.

I can't forget about them, since I'm one of them ;)

initramfs is built _into_ the kernel image, so it is as available as the 
kernel image itself.

The great thing about having initramfs mounting your root filesystem is 
that it is much more flexible than the kernel can ever be. You can, for 
instance, setup an ssh tunnel into the nfs server and mount your root 
file system through there.

There is no ending to the options you have with user space. The problem 
is that the really simple setups that are today handled internally by 
the kernel would require more work to setup :(

-- 
Paulo Marques - www.grupopie.com

"As far as we know, our computer has never had an undetected error."
Weisert

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php

Re: PROBLEMS WITH DNS

[Russell King - ARM Linux]

On Fri, Jun 08, 2007 at 08:36:04PM +0200, Vadim Lebedev wrote:
> Kernel mode dhcp client solutions allows muuch faster boot sequences...
> for embedded stuff 15-20 secs boot speed advantage is important....

Then complain to the user space dhcp client solutions; they can make
their implementation as fast as the kernel solution if they so wished.
There's nothing magic about the kernel dhcp client.

Re: PROBLEMS WITH DNS

[Russell King - ARM Linux]

On Fri, Jun 08, 2007 at 07:39:43PM +0200, Vadim Lebedev wrote:
> this DHCP request are sent by kernel mode dhcp client,  which has no access
> to resolv.conf to store retrived information

The kernel mode dhcp client is for supporting root-NFS, where you
need to bring up a network interface in order to access your root
filesystem.

It's not supposed to be a subsitute for having a dhcp client in your
local rootfs if you have a local rootfs.

> I'dont now if somebody have developped a possibility to retriev this 
> info using user-mode app and store it into resolv.conf...

The kernel doesn't even ask for DNS information when querying the DHCP
server, so the DHCP server doesn't supply that information.

RE: Problems with DNS

[Cedric Blancher]

Le dim 07/09/2003 à 14:15, Владимир Потапов a écrit :
> DNS worked ok.Thank you.
> But my mail server only can send message from local to the internet,
> but don't accepting any mail from internet.
[...]
> -A PREROUTING -d 121.1.1.1 -i eth0 -p tcp -j DNAT --to-destination
> 192.168.5.2 
> -A PREROUTING -d 121.1.1.1 -i eth0 -p udp -j DNAT --to-destination
> 192.168.5.2 
> -A POSTROUTING -o eth0 -j SNAT --to-source 121.1.1.1
> -A allow -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j ACCEPT 
> -A allow -p tcp -m tcp -m state --state RELATED,ESTABLISHED -j ACCEPT 
> -A allow -p tcp -j LOG 
> -A allow -p tcp -j DROP  
> -A FORWARD -d 192.168.5.2 -i eth0 -o eth1 -p tcp -m tcp --dport 25 -j
> allow 
> -A FORWARD -s 192.168.5.2 -i eth1 -o eth0 -p tcp -m tcp --dport 25 -j
> allow

Because you do exactly the same mistake than before. You do not have a
rule to accept returning packets for STMP connections, both way, as they
are not destined to TCP port 25, but sourced from this port.

As I mentionned before, you _really_ should get rid of this "allow"
chain and have everything handled with a generic ESTABLISHED,RELATED
state matching at ruleset top :

	-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
	-A FORWARD -d 192.168.5.2 -i eth0 -o eth1 -m state \
		--state NEW -p tcp -m tcp --dport 25 --syn -j ACCEPT
	-A FORWARD -s 192.168.5.2 -i eth1 -o eth0 -m state \
		--state NEW -p tcp -m tcp --dport 25 --syn -j ACCEPT

> In log I see that other mail server want to connect to me at sport 25.
> But it's not correct.

You should copy the log entry so one can show you what's wrong with it.



PS : please keep Cc to the list as every thread can be useful for other
     people with similar issues (i.e. reply all).

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

RE: Problems with DNS

[Владимир Потапов]

You should copy the log entry so one can show you what's wrong with it.

194.67.23.25 -outside mail server from that i tried to send mail to my mail server.


 New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88 TOS=0x00 PREC=0x00 TTL=55 ID=2475 DF PROTO=TCP SPT=25 DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 
 New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88 TOS=0x00 PREC=0x00 TTL=55 ID=4691 DF PROTO=TCP SPT=25 DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 
 New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88 TOS=0x00 PREC=0x00 TTL=55 ID=8159 DF PROTO=TCP SPT=25 DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 
 New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88 TOS=0x00 PREC=0x00 TTL=55 ID=14216 DF PROTO=TCP SPT=25 DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 
 New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88 TOS=0x00 PREC=0x00 TTL=55 ID=31847 DF PROTO=TCP SPT=25 DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 
 New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88 TOS=0x00 PREC=0x00 TTL=55 ID=60204 DF PROTO=TCP SPT=25 DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 
 New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88 TOS=0x00 PREC=0x00 TTL=55 ID=891 DF PROTO=TCP SPT=25 DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 
 New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88 TOS=0x00 PREC=0x00 TTL=55 ID=1009 DF PROTO=TCP SPT=25 DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 
 New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88 TOS=0x00 PREC=0x00 TTL=55 ID=51986 DF PROTO=TCP SPT=25 DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 
 New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88 TOS=0x00 PREC=0x00 TTL=55 ID=40364 DF PROTO=TCP SPT=25 DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 

RE: Problems with DNS

[Cedric Blancher]

Le dim 07/09/2003 à 15:34, Владимир Потапов a écrit :
> 194.67.23.25 -outside mail server from that i tried to send mail to my
> 	mail server.
>  New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88
> 	TOS=0x00 PREC=0x00 TTL=55 ID=2475 DF PROTO=TCP SPT=25
> 	DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0 
>  New not syn: IN=eth0 OUT=eth1 SRC=194.67.23.25 DST=192.168.5.2 LEN=88
> 	TOS=0x00 PREC=0x00 TTL=55 ID=4691 DF PROTO=TCP SPT=25
> 	DPT=49073 WINDOW=57920 RES=0x00 ACK PSH FIN URGP=0
[...]

These logs have been raised by a rule you did not show in the ruleset
you gave. This rule has a -j LOG --log-prefix "New not syn: " target and
is supposed to match packets with state NEW that are not syn ones (-m
state --state NEW -p tcp -m tcp ! --syn). This does not happens very
often on SMTP flows, so this kind of log is a bit strange to me. Can we
see you whole ruleset ?

Without a complete ruleset, it is unlikely one can provide valuable help
if there's side effects.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

RE: Problems with DNS

[Cedric Blancher]

Le sam 06/09/2003 à 12:53, Владимир Потапов a écrit :
> And which chain a need yo add to ruleset?

Just rewrite your ruleset as follow :

# nat table
-A PREROUTING -t nat -d 121.1.1.1 -i eth0 -p tcp -j DNAT \
		--to-destination 192.168.5.2
-A PREROUTING -t nat -d 121.1.1.1 -i eth0 -p udp -j DNAT \
		--to-destination 192.168.5.2
-A POSTROUTING -t nat -o eth0 -j SNAT --to-source 121.1.1.1

# filter table
-A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
-A FORWARD -d 192.168.5.2/255.255.255.255 -i eth0 -o eth1 -m state \
		--state NEW -p tcp -m tcp --dport 53 --syn -j ACCEPT
-A FORWARD -d 192.168.5.2/255.255.255.255 -i eth0 -o eth1 -m state \
		--state NEW -p udp -m udp --dport 53 -j ACCEPT
-A FORWARD -s 192.168.5.0/255.255.255.0 -i eth1 -o eth0 -m state \
		--state NEW -p tcp -m tcp --dport 53 --syn -j allow
-A FORWARD -s 192.168.5.0/255.255.255.0 -i eth1 -o eth0 -m state \
		--state NEW -p udp -m udp --dport 53 -j ACCEPT

It should provide the same filtering functionnalities you wanted, plus
returning packets accept through ESTABLISHED,RELATED rule. If you really
want to restrict it to TCP and UDP only, just replace this rule with two
more specific ones :

-A FORWARD -m state --state ESTABLISHED,RELATED -p udp -j ACCEPT
-A FORWARD -m state --state ESTABLISHED,RELATED -p tcp -j ACCEPT

I removed rules that seems redundant, in particular your TCP flags check
rule that was replaced with --syn switch addition. I also restricted
inbound DNS filtering to 192.168.5.2 only.

Hope this helps.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE

Problems with DNS

[Владимир Потапов]

I have some problems with DNS and iptables.

  ------------      ETH1 ----------------------------- ETH0    ----------
 | DNS SERVER|-----------| Packet filter with iptables|--------|Internet|
  ------------           ------------------------------        ----------
This is my rules for forwarding dns packets from eth0 to eth1 and from eth1
to eth0 :
121.1.1.1 - eth0 routable IP.
192.168.5.2 - DNS_DMZ IP.
192.168.5.0/255.255.255.0 -DMZ subnet.
-A PREROUTING -d 121.1.1.1 -i eth0 -p tcp -j DNAT --to-destination
192.168.5.2
-A PREROUTING -d 121.1.1.1 -i eth0 -p udp -j DNAT --to-destination
192.168.5.2
-A POSTROUTING -o eth0 -j SNAT --to-source 121.1.1.1
-A FORWARD -d 192.168.5.0/255.255.255.0 -i eth0 -o eth1 -p tcp -m
tcp --dport 53 -j allow
-A FORWARD -s 192.168.5.0/255.255.255.0 -i eth1 -o eth0 -p tcp -m
state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -d 192.168.5.0/255.255.255.0 -i eth0 -o eth1 -p udp -m
udp --dport 53 -j ACCEPT
-A FORWARD -s 192.168.5.0/255.255.255.0 -i eth1 -o eth0 -p tcp -m
tcp --dport 53 -j allow
-A FORWARD -s 192.168.5.0/255.255.255.0 -i eth1 -o eth0 -p udp -m
udp --dport 53 -j ACCEPT
-A allow -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN -j ACCEPT
-A allow -p tcp -m tcp -m state --state RELATED,ESTABLISHED -j ACCEPT
-A allow -p tcp -j LOG
-A allow -p tcp -j DROP

Problem:
My packet filter couldn't forward dns udp query to the internet and from
internet to local .What I'm doing wrong ?

-----
With best regards,
    Potapov Vladimir.

Re: Problems with DNS

[Cedric Blancher]

Le ven 05/09/2003 à 19:47, Владимир Потапов a écrit :
> I have some problems with DNS and iptables.
[...]
> Problem:
> My packet filter couldn't forward dns udp query to the internet and from
> internet to local .What I'm doing wrong ?

I just quote UDP DNS related rules, for TCP stuff seems OK.

> -A POSTROUTING -o eth0 -j SNAT --to-source 121.1.1.1
> -A FORWARD -d 192.168.5.0/255.255.255.0 -i eth0 -o eth1 -p udp -m
> udp --dport 53 -j ACCEPT
> -A FORWARD -s 192.168.5.0/255.255.255.0 -i eth1 -o eth0 -p udp -m
> udp --dport 53 -j ACCEPT

Your requests will get forwarded for there's a rule in FORWARD chain to
accept them (2nd one below). But, there's no rule to accept returning
packets. You so have to implement rules to accept them, both way.

You can also use state matching, allowing ESTABLISHED UDP packets to go
through FORWARD chain. At this time, you only use state matching for TCP
ones.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE