Wildcards in reverse DNS

[Clenna Lumina]

Marc Haber wrote:
> On Fri, Jan 05, 2007 at 10:31:23AM -0800, Clenna Lumina wrote:
>>> On Thu, Jan 04, 2007 at 02:24:11PM -0800, Clenna Lumina wrote:
>>>> Mark Andrews wrote:
>>>>> For those of you who think NAT's are great try connecting
>>>>> to a port forwarded service from behind a NAT.  I've yet
>>>>> to see a NAT box do this right.  The NAT box should be
>>>>> able to loop the traffic around.  Instead we are forced
>>>>> to kludge solutions to this in the DNS.
>>>>
>>>> No, a *properly* behaving NAT should always allow looping
>>>> back. If you are running a NAT that doesn't allow this,
>>>> then it is broken. You cannot put down NAT just because
>>>> of broken implimentations.
>>>
>>> Just show me how to do IPSEC AH via NAT. Or how to connect
>>> to a service that does RFC1413 ident lookups and actually does
>>> something with the returned value.
>>
>> My last company I worked for was running IPSEC (VPN, etc) through
>> their (properly) NATed firewall without any problems.
>
> I guess that this was IPSEC tunnel mode. I specifically asked for
> IPSEC AH for a reason.

AH (auth header), which can be part of an IPSEEC tunnel, does indeed 
choke on most NATs, but it IS possible to get it to work, if a bit 
tricky, and down right impossible on many forms of NAT.

>>  Again, this is a difference between poor implimentations and the
>>  concept your self.  You're attacking the wrong one here.
>
> I am obviously "attacking" somebody who considers herself able to
> judge things that she has not the necessary background knowledge
> about. "It just works for me" is not enough.

Yet you are free to make assertions which are not always right. My my so 
I'm not perfect. I never said I considered my self an ultimate authority 
on all things. I know I'm not perfect. (Btw, I'm not a she, and it's 
pronouned Clenn-aye (like a french sounding ending... just one of those 
really weird names that dont sound like they are spelt.)

Furthur, I never claimed that if it was enough for me, ti was good 
enough for all. I was pointing out that deficiencies you and other point 
out in NAT are more do to poor implimentations than anything else, as 
with the right NAT (and configuration) you can make it do neearly 
anything you need.

Stop trying to brand all of one thing as poor when you have various 
manufactures making completely defferent behaving versions.

>>> Even trying to have a mail server HELO with the right host
>>> name, regardless of whether the machine connected to is on the
>>> internal or an external network, is a challenge if NAT is in
>>> the game.
>>
>> I can't say I've ever seen that be a problem behind a NAT.
>
> Then you need to be around the block a few more times.

Or maybe I've just been using properly configured NATs instead of broken 
or shoddy implimentations. Maybe I took the time to research and test 
several before finding one that actually did things properly. Can you 
say the same?

>> The HELO is usually generated by the address of the server the
>> connecitng mail server is trying to reach,
>
> No. Please read the RFCs before you continue embarrassing yourself
> even more.


I have read them before. I think you simply read what I wrote too 
quickly. Foreign mail server connects. Foreigh server says HELO 
remote-mail-host.domain.com, where remote-mail-host.domain.com IS being 
generated from this connecting foreign host. This is how it's always 
worked.

>> so if it's generating a bad HELO, then thats the fault of the
>> foreign mail server, which is likely not configured correctly to
>> begin with.
>>
>> My personal mail server which sits behind my home NAT, has never
>> failed to get a proper HELO from proper foreign hosts.
>
> It's the connecting server who says HELO, not the server connected to.

That *is* what I said - s/foreign/connecting/

" so if it's generating a bad HELO, then thats the fault of the
  foreign mail server "
  ^^^^^^^

If you weren't so busy insulting everything I say you might have caught 
this one.

>> Just to clear something up, when I said "turn your network world
>> upside down" I mean in the way you think about IP addresses and
>> the like, will be radically different. You can't tell me that
>> 11.22.33.44.55.66.77.88.99.AA.BB.CC.DD.EE.FF.00  is the same as
>> typing out  111.222.333.444  , be it in geenral speak or entering
>> into a conf file or passing along an IP to a friend for setting up
>> a friendly private Quake match.
>
>>> 1 is even shorter than 127.0.0.1.
>
> and 2001:1b18:f:4::4/128 is not _that_ bad. Yes, that's an actually
> workin address.

How does that equate to a full 16 octet IPv6 address? I'm not all the 
keen on all forms of IPv6 ips, but I've never seen it written like you 
have. If you can connect to an IP using a short hand like this (withotu 
breaking anything) that would be great. It's a new concept to get used 
to, but (if it pans out), a welcome one.

If you could suggest a good page to look at that desribes these sorts of 
things, I would appreciate it.

>> Can you really tell me you can easily remember an address that long?
>> I can remebmer a 4 section IP with out any trouble. Remembering an
>> IPv6 address might be possible, no doubt, but you'd likely have to
>> known it rather well, and have a rather good memory.
>
> If DNS is properly used, you don't need to remember IPv6 addresses.
> And, usually, you only need to remember the prefix anyway.

Well you still need to enter them at _some_ point or another into DNS 
(unless you used a $GENERATE to setup a whole block, and even then, 
sometimes manual entries have to be added, ie: myhost.mydomain.com A ip 
and ip PTR myhost.mydomain.com)

>> Actually a couple years ago, after hearing about IPv4 address slowly
>> becoming scarce, I actually sort of invisioned IPv4 being expanded
>> in a similar way telephone numbers were introduced into area codes
>> (and country codes) to furthur divide things. What I envisioned then
>> was anywhere for 1 to 4 extra sections (8 byte IPs.)
>
> Very good idea. Just another migration in ten years. I know people who
> have gone through four phone numbers in three different area codes in
> the last fifteen years.
>
> Geez, this is _one_ thing that we germans did right. No splits, no
> overlays. Only newly assigned numbers get longer. This is based on the
> convenient fact that our number length was never fixed in the first
> place, and we started making them longer long before the existing
> space was depleted so that we had ample _new_ number space to put into
> use which saved us from doing the splits.

Agreed, this approah IS much better :) This is basically wqhat I was 
getting at.

On a side note (
  While I like how the Germans did it, there is an
  obvious benefit to using area codes, especially in a country the
  size of the US. When you see a phone number with an area code,
  you can easily deduce or determine where it may actually be located.

  Germany is a much smaller country, so their method works well for
  them. I don't think this method would of worked all that well in a
  much larger country. however.

  It's the old adage that one solution that works in one situation,
  may not be the best solution in another.

  In the case of the networking, I would favor a German-phone style
  approach :)
)

>> When I first saw an IPv6, it immediately looked like over kill. Like
>> I said, I will be trying it on my own local network to get a real 
>> feel
>> for it. On this note, are there any good documents out ther that 
>> describe
>> what the general conventations are for IPv6 IPs? FOr instance, in
>> IPv4, 192.168/16, 172.16/12, 10/8, are considered LAN-only IP
>> blocks, 127/8 being loopback block.
>
> http://en.wikipedia.org/wiki/Ipv6 seems pretty good to me.

Thank you.