Subject: [RAM] server referrals

From: RJ Atkinson <[email-masked]>
Date: Thu, 18 Jan 2007 11:06:19 -0500

Earlier, Brian Carpenter said:
% The problem with that thought experiment is that it fails even in
% thought. There are lots of client/server scenarios where the FQDN of
% the client is unknown or non-existent. It's the identifier (sic)
% presented by the transport layer that is known by the server, and  
which
% the server may need to refer to 3rd party servers.

I don't think there is a real problem with taking a client's
identifier (and potentially locator, depending on what layer
one does this and sundry implementation choices) to determine
the right FQDN.

- One can do a reverse lookup on the identifier to get an FQDN
	(details omitted for now; this is a thought exercise)
	- Even people without Internet clues now generally have both
	  forward/reverse domain-names associated with their IP address(es).
   	  That FQDN might be of the form c123456.hooville.cox.net,
	  but for referral purposes the form of the FQDN doesn't matter.
- One can ask the client what it's FQDN is, and even (if desired)
	then do a forward lookup on the FQDN to validate the claim
	(details omitted, but consider IP option or ICMP message)

So I think we have on-the-shelf solutions for the issue you
outline in the quoted text above.

It would separately help if you gave a real-world example of
where such referrals to 3rd party servers is commonly done
today.

Yours,

Ran

_______________________________________________
RAM mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 18 Jan 2007 17:27:56 +0100

I'll leave someone like Ted Hardie to respond on practical cases
of referrals. As far as reverse DNS lookup goes, there are certainly
lots of hosts that don't have one, and can we really build an architecture
that depends on something as baroque as reverse DNS?

     Brian

On 2007-01-18 17:06, RJ Atkinson wrote:
> % presented by the transport layer that is known by the server, and which

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 18 Jan 2007 12:23:18 -0500

On  18 Jan 2007, at 11:27, Brian E Carpenter wrote:
> As far as reverse DNS lookup goes, there are certainly
> lots of hosts that don't have one, and can we really
> build an architecture that depends on something as baroque as  
> reverse DNS?

The current architecture already depends on Reverse DNS working,
for LOTS of things, including getting SMTP email delivered.

In practice, lots of servers already simply refuse connections
from hosts without reverse DNS present.

If the main thing that broke for lack of reverse DNS
would be server referrals, that would seem fine.  After all,
the clients that did not work would be in the position
to fix the issue that caused the referral to not work
as expected.  The problem might exist in pockets, but it
could be corrected locally and incrementally, so scaling
wouldn't be an issue.

Most residential ISPs have reverse DNS that works -- globally,
because of various pressures unrelated to the topics here
(example: security, proving to registries that allocated
address space is in use).  Even the dialup folks now generally
have a working reverse DNS.  Neither group did a decade ago,
but things are a bit better now, or so I'm told.

Yours,

Ran

---

From: Roland Dobbins <[email-masked]>
Date: Thu, 18 Jan 2007 15:11:43 -0800

> from hosts without reverse DNS present.

This is somewhat true on the global Internet; it is manifestly untrue  
in private/enterprise networks, unfortunately.

-----------------------------------------------------------------------
Roland Dobbins <[email-masked]> // 408.527.6376 voice

                     Technology is legislation.

                         -- Karl Schroeder

---

From: John Schnizlein <[email-masked]>
Date: Thu, 18 Jan 2007 12:29:49 -0500

If we are going in down this path, please ensure that what is  
necessary is included in the draft about this:
draft-ietf-dnsop-reverse-mapping-considerations-01.txt

On Jan 18, 2007, at 12:23 PM, RJ Atkinson wrote:
>> As far as revehey are). This gets into things like the
     difference between "hot potato routing" (forward the packet to
     a peer AS as close to the source as possible), versus "cold
     potato routing" (forward the packet to the same peer AS, but
     closer to the destination). Engineers from network operators
     could talk about this sort of thing much better than I could,
     but I sort of suspect that this might be difficult.

I am also suspecting that the damage to the host stacks might be
more significant than all of these concerns combined.

Ross

---

From: John Schnizlein <[email-masked]>
Date: Thu, 18 Jan 2007 12:29:49 -0500

rse DNS lookup goes, there are certainly

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 19 Jan 2007 08:03:45 +0100

I'm not disputing the reality that synthetic reverse DNS for
clients is widely practised and widely checked. But it is a
hack. My question is whether we should be considering relying
on such a hack for a new routing architecture.

     Brian

On 2007-01-18 18:29, John Schnizlein wrote:
> If we are going in down this path, please ensure that what is necessary 
> is included in the draft about this:
>>> build an architecture that depends on something as baroque as reverse 
>>> DNS?
>>

---

From: McTim <[email-masked]>
Date: Fri, 19 Jan 2007 13:06:08 +0300

> on such a hack for a new routing architecture.

Certainly not IMHO!

-- 
Cheers,

McTim
$ whois -h whois.afrinic.net mctim

---

From: Thomas Narten <[email-masked]>
Date: Mon, 22 Jan 2007 13:26:07 -0500

> 	  but for referral purposes the form of the FQDN doesn't

IMO, this assertion needs to be shown to be true. I suspect its very
much not.

A few years back, I was dealing with a sysadmin that blocked ssh
logins from IP addresses for which there was no reverse DNS mapping. I
found that when I was on the road, I often couldn't log in.  When
talking about this with some folk at (I believe) RIPE, they observed
that the reverse tree was becoming less and less usefully
populated. I'm pretty sure there is data around about this from folk
that walk the tree as part of checking delegations and such.

Thomas