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
Why is a PTR (or DNS) record with MS TCP different from the standard TCP/IP
(Perhaps it is me in my ignorance, or lack of understanding :o) )
Sent: 22 October 2002 18:39
To: Sean Jones
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 220.127.116.11
;; ANSWER SECTION:
18.104.22.168.in-addr.arpa. 2665 IN PTR microsoft.com.
22.214.171.124.in-addr.arpa. 2665 IN PTR microsoft.net.
126.96.36.199.in-addr.arpa. 2665 IN PTR
188.8.131.52.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
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
Apple) and the hacked download attack (as has hit
sendmail, and others). If it's WG fodder, I'd specifically
question of whether the patch *works* as off-topic - the task
verifying that the bits are the correct bits, and from the
Computer Systems Senior Engineer