Subject: domain name query in kernel

From: <[email-masked]>
Date: Tue, 12 Nov 2002 16:41:07 +0800

hi,
is there any function call which can get host+domain name from IPv4 / IPv6 address?
from kernel level.
thanks.
zhao kai

---

From: "Randall Stewart (cisco)" <[email-masked]>
Date: Fri, 15 Nov 2002 06:57:57 -0600

>is there any function call which can get host+domain name from IPv4 / IPv6 address?
This is the basic problem with that feature. The only way you can
do this is to create a process that listens to the kernel for queries.. then
the kernel would need to send it a request and block that kernel
thread... waiting
for the process to read the request and then make the DNS query and then
write back down the response..

Now taking a step backwards and looking at the feature:

Why did we add it to SCTP?
- The reason was to help SCTP pass through NAT's better.

Now I think this is where I blew it in not seeing the right argument to get
it removed from the RFC... The basic problem with the above is it DOES NOT
work..

Think about it:

If I send a

INIT(no-addresses)-------------->

This will pass through a NAT ok.. no problem

The idea of the host name address was to

INIT(host-name-address)--------->

and then on the other side lookup(hostname)
and come up with a list of IP-a/IP-b/IP-c

In other words to support multi-homing through NATs..

But I did not think in detail on this (as I have now)... If you did do
this it WOULD NOT help you get through a NAT. Two of the nats
in the above example would NOT know ANYTHING about the
state (except of course the one that came through). The two
NAT's would not be aware of any translation choice the single
NAT the INIT went through would make... so really the host-name
address is broken!! It won't do what it was supposed to do... when in
fact the INIT with no address will at least let SCTP and NAT's co-exist.

My STRONGEST recomendation to any SCTP implementor is to NOT NOT NOT
implement this feature!!

Spend your time doing something far more worth while like PR-SCTP and
ADD-IP.

I think we have a solution for NAT's and we can then kill this feature when
we go to draft- standard..

R

-- 
Randall R. Stewart
ITD
Cisco Systems Inc.
[email-masked] 815-342-5222(cell) or 815-477-2127(office)