Combining DNS and NATD

[bob prohaska]

Kevin Darcy <kcd at daimlerchrysler.com> wrote:
> Even if the nameserver were to provide such a "tag", it would have to be 
> propagated through the resolver routines, picked up by the client app, 
> which would then need an interface to the networking stack to be able to 
> tag the packets that the client is using to connect to the server. 
> That's an awful lot of redesign work to accommodate a kludge (IMO) like NAT.

I agree, it's a kludge! And, if others have to adapt to  it, it isn't
worth the trouble. If the kludge can be kept  private, it might be worth
doing.

> I suppose if more client apps used SRV records, then you could 
> theoretically direct different clients to different ports dynamically, 
> and then use port forwarding. However, SRV record support hasn't even 
> made it into web browsers yet, let alone clients of less-common protocols...

I guess the real question I'm getting at is this: Can a nameserver answer
a query with more detail than just an IP4 address? Will IP4 clients pay
attention to any extra detail? Sounds as if you think not.

It isn't too hard to imagine a nameserver answering a query for a
non-routeable host address with its own (routeable) address and
a port number. 

When a reply comes to that port number, the nameserver/router must
notice the special port number, figure out which (private) host is
being referred to, and strip off the special port number, forwarding
the original packet to the intended host on the private network.

At this point it's just an academic question, but a practical answer
might have economic value.

Thanks for reading!

bob prohaska