Subject: How to find initiating host address?

From: "������" <[email-masked]>
Date: Sat, 18 Sep 1999 15:03:56 +0900

I have a question on the operation of resolver and name server.

As far as I understand, the resolver of a host, say A,
sends query to name server in "recursive" mode.
Then the name server, say firstNS,  performs the query in referal
manner,
and it queries to other name servers, say NS2, .., lastND,
accroding to domain name.
Is it correct?

Then, the lastNS has no clue on which host initially generate the query.

Only what the lastNS knows is the firstNS that has performed the query
on the behalf of the initiating host.

My next question is:
Is there any method for the lastNS to find out what is the host that
initiated
the query?
This may useful to reply differently according to the initiator.
For example, the lastNS may have a list qualified host to reply, and
then
the lastNS veryfies the host address before replying.

If there is no mechnism in the existing internet standard,
is there any RFCs related with this issue?

Please let me know if anyone who has idea on extending the DNS standard.

IMHO, a field, "initiator" or something, may be inserted in DNS query,
and
this field must be copied to recursibe querries.

Thanks in advance!

---

From: Robert Elz <[email-masked]>
Date: Sun, 19 Sep 1999 01:50:34 +1000

Date:        Sat, 18 Sep 1999 15:03:56 +0900
    From:        "@|?lAw" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Is it correct?

That's a reasonable description of a possible scenario, yes.

  | Then, the lastNS has no clue on which host initially generate the query.

That's right.   Of course, it is also possible that lastNS never actually
gets the query, one of the other NS2... in the chain might have known it
and returned it - which in a sense makes it the lastNS for this query, but
it isn't the lastNS you had in mind (not onw who would have any special
knowledge of the answer that is being returned pr any motivation for
playing with it).

  | Is there any method for the lastNS to find out what is the host that
  | initiated the query?]

No.

  | This may useful to reply differently according to the initiator.

That must never be done.   DNS information is cached and passed around all
over the place.   There's no way to confine this kind of information.  The
only way to have different hosts see different DNS responses is to have them
in totally separate DNS worlds, where all possibility of information
leakage is very carefully guarded against.

  | IMHO, a field, "initiator" or something, may be inserted in DNS query,
  | and this field must be copied to recursibe querries.

No, that can't work, caching means that information is given out by
any random DNS server on the internet.

Eg: in your example, when firstNS does the lookup for client A, it
remembers the answer it received.   When some other client (which might
or might not be in any way related to A) does a lookup, firstNS just
returns the answer it obtained before (assuming the second query is
within the time to live of the answer when it was obtained initially).

The whole DNS is designed around the philosophy of there being one common
set of data that is equally available to all who ask.   Changing this is
no simple thing to achieve.

kre

---

From: "������" <[email-masked]>
Date: Mon, 20 Sep 1999 11:05:09 +0900

Thanks for kind reply.

> within the time to live of the answer when it was obtained initially).

Of course, that's correct in case of caching.
However, the lastNS, the owner of the resource record, may set TTL = 0
in the reply. That is, the record will not be cached.Every time the resource is
asked, the query must be replied by thelastNS that owns the resource record.
This technique already is used in bi-directional NAT(network address
translation).

> no simple thing to achieve.

I do not mean that the DNS philosophy has to be changed.An additional option
field in the query format does no harm to current
DNS implementation but might be useful in some applications.
For example, NSs may collect statistics on who generates the query.
And an NS may reply one server among equivalent servers with the same domain
name. The replied server is the nearest one from the initiator of the
DNS query. Similar technique is in use at the "Cisco DistributedDirector",
where the replied server is the nearest one from the firstNS,
not from the initiator.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 20 Sep 1999 11:24:29 +0200

Source dependent replies are generated today by queries for netscape.com;
I'm sure they are not the only ones to do so.

(netscape.com generates a zero-lifetime CNAME pointing to a host that it 
guesses is "close" to you - the name tells you a bit about its assumptions, 
so it can be fun querying various resolvers and seeing what comes back).

Strengthens my point made repeatedly over the last 5 years that there needs 
to be some way applications can make even a half-hearted guess at network 
metrics - if there isn't an architecturally clean way, people will find 
other ways.

                         Harald
--
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Paul A Vixie <[email-masked]>
Date: Mon, 20 Sep 1999 15:03:11 -0700

> I'm sure they are not the only ones to do so.

sure, but...

> so it can be fun querying various resolvers and seeing what comes back).

...this is one of the reasons the netscape home page often does not load
the first time, and it's a silly thing to do for caching reasons, but at
least it's something the standards allow.

(and yes, i sometimes deliberately use a far-away dns proxy just so that
the responses servers want to tune for "me" can be as stupid as possible;
and i know from direct observation that hundreds of thousands of modem
pool users have the same misdirection in their dns lookup path -- cool, huh?)

> metrics - if there isn't an architecturally clean way, people will find 

what happened to sonar?  it was a good start in the right direction.

---

From: "������" <[email-masked]>
Date: Tue, 21 Sep 1999 16:06:39 +0900

> metrics - if there isn't an architecturally clean way, people will find

  Could you give any reference on the "netscape.com"?
and What was your point,
You mean there should be someway to measure network metrics
or there should be some way to determine who initiate the querry ?
Do you happen to have material, white paper, TM etc on this problem.

In my case, I am going to make a special NAT + DNS that will respond
diferently according to who initiate the query.
If the currunt DNS standard have no such feature,
the initiator(or source)  optional field can be added in query and
subsequent NS may just copy this field.
Then the last NS, the owner of the resource record, can make use of that field.

 What do you think about this?

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 21 Sep 1999 15:38:53 +0200

>what happened to sonar?  it was a good start in the right direction.

we drafted the author to the IESG. Predictable effects on SONAR.
Anyone want to pick it up?

                     Harald

---

From: Richard Johnson <[email-masked]>
Date: Thu, 23 Sep 1999 18:37:58 -0700 (PDT)

> metrics - if there isn't an architecturally clean way, people will find 

I've been thinking about this for a while as well.  Cisco's
DistributedDirector product has this same problem.  Since ping's
almost never make it through the firewall, a lot of people try to use
a traceroute method, hoping to at least get an RTT to the last system
long the path which will respond.  This takes a LOT longer than a
ping, however, and also results in a LOT more traffic on the net.

My simple-minded, first-cut proposal would be either an option to the
ICMP echo, or another type of ICMP echo which, basically, says, "if
you're planning on dropping this packet, please do me the service of
sending me a reply from from yourself".  This means you could send
this new type of ping packet toward your destination and if a firewall 
decided to drop it, they would (hopefully) send you back a response
saying, "I've dropped your packet, but here's my reply instead".  Now
you have exactly the same information you have gotten from the
traceroute, much faster than traceroute and without all of the network 
traffic.

Yes, I know it would take years get this standardized and implemented
enough to be useful, but if we don't start the process soon, it'll
take longer.

Yes, I know this doesn't give you the RTT to your destination, but I
submit that firewall people will *never* give you that information
anyway (for security reasons), and this is the best you're going to
get, so you may as well get it quickly and easily.

I'll shut up now.  :-)

/raj

---

From: Paul A Vixie <[email-masked]>
Date: Thu, 23 Sep 1999 19:38:41 -0700

"blast"ing SYNs is actually the best way to reach 80% efficiency.
(round robin is 50% efficient for two hosts, 33% for three, and
worse for more.)

the cost to a server of the getting a SYN, sending a SYN ACK, and
then getting an RST because the initiator got an earlier SYN ACK
from some other responder is actually quite low.  this wasn't true
until the 2600 boyz taught us all about syn-flooding, but at this
point in time, the state you have to hold when you won't be the
winner in a SYN-blast is not considered in any way expensive.

getting above 80% requires something a hell of a lot stronger than
ICMP.  that last 20% is all about best window size under full pipe
conditions, not about RTT.  the state you have to keep, and share,
to make that work is just too heavy.  (been there, did that, didn't
even get a t-shirt.)

int multiconnect(int s, const struct sockaddr *salist, int numsa);

this assumes the existence of sa_len, and that there is no options
mask -- neither of which is practical if this is going to take off.
but a BSD kernel implementation of the above is only a few hours of
work, and like i said, it solves 80% of the multiple-server problem.

i guess, looked at that way, this isn't a dns issue.  but since the
message i'm replying to came from namedroppers, i'll reply that way.