Good Morning Valdis
Thank you for your prompt reply. Perhaps I did not phrase my question properly.
I know what PTR records are, I know how TCP/IP works & etc (I've done a routed
IP network or two, and worked at an ISP for a while) so please let me re-phrase
my question.
Why is a PTR (or DNS) record with MS TCP different from the standard TCP/IP
record?
(Perhaps it is me in my ignorance, or lack of understanding :o) )
Regards
Sean
-----Original Message-----
From: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
[mailto:Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu]
Sent: 22 October 2002 18:39
To: Sean Jones
Cc: ietf(_at_)ietf(_dot_)org
Subject: Re: Palladium (TCP/MS)
On Tue, 22 Oct 2002 16:42:03 BST, Sean Jones said:
Forgive my ignorance, but what the heck do you mean?
% dig -x 207.46.230.218
;; ANSWER SECTION:
218.230.46.207.in-addr.arpa. 2665 IN PTR microsoft.com.
218.230.46.207.in-addr.arpa. 2665 IN PTR microsoft.net.
218.230.46.207.in-addr.arpa. 2665 IN PTR
www.domestic.microsoft.com.
218.230.46.207.in-addr.arpa. 2665 IN PTR www.us.microsoft.com.
Of course, it isn't that simple - those 4 PTR entries each
point back at a
multihomed host. I was about ready to throw a yellow flag and a 5-yard
procedural penalty until I double-checked RFC2181, section
10.2 - that's legal.
Gonna need a lot longer ACL on that Cisco to actually make it
work (don't
forget all their msft.net servers.
Bringing it back to IETF territory now: Is there a need for
an RFC for
"best practices" in securing the download of software updates (DNSSEC,
PGP signatures, etc)? The two scariest things about online
updates (at least
while wearing my security hat) are the MITM attack (as
demonstrated against
Apple) and the hacked download attack (as has hit
windowsupdate, openssh,
sendmail, and others). If it's WG fodder, I'd specifically
declare the
question of whether the patch *works* as off-topic - the task
is merely
verifying that the bits are the correct bits, and from the
correct vendor.
--
Valdis Kletnieks
Computer Systems Senior Engineer
Virginia Tech