Nico Kadel-Garcia wrote:
> Peter Fokkinga wrote:
>> Quoting Nico Kadel-Garcia <nkadel@xxxxxxxxx>:
>>> Peter Fokkinga wrote:
>>>> [...]
>>>> Now for the real spooky part:
>>>> 1. I booted into dom0 (no xend)
>>>> 2. executed `telnet 129.125.14.12 daytime`, it works
>>>> 3. started xend
>>>> 4. executed `telnet 129.125.14.12 daytime`, it still works (surprise!)
>>>> 5. executed `telnet 129.125.14.13 daytime`, it does not work
I don't get this part. Why do you think 5 would work just because 4
worked? They are different IP addresses. You never proved that 5 would
have worked before 3 was executed.
>> But I'm using ip adresses, not names? I don't see how DNS fits in
>> this picture.
> I can't swear to this, but when you use anything to reach out to the
> net, it assumes first that the word or name is a hostname, and tries to
> look that up. It resolves IP addresses as IP addresses, and DNS names as
> IP addresses, and then has to turn that into appropriate local or
> gateway MAC addresses based on ARP data, etc., etc., etc. DNS caches
> store the information locally, so no additional lookups happen. If it's
> not stored locally in your DNS cache, then it tries to do a DNS lookup,
> and in your case fails as it tries to look up 129.154.14.13 from your
> DNS system.
>
> I don't think a numerical hostname is first resolved as a number, for a
> whole bunch of historical and procedural reasons. It still does DNS the
> first time.
The resolver shouldn't try to look up a dotted quad. The problem here
is possibly the remote host verifying that the forward and reverse
mappings of the client host match in order to avoid hostname spoofing.
--
Christopher G. Stach II
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home