Brian Dickson wrote:
>>>Ok. But when you resign using arbitrary data controlled by the
>>>attacker, the private key can be obtained. [There is a crypto attack on
>>>rekeying] OOPS!!. Rekeying is out of the question for, say, .com, .net,
>>>etc. I guess you didn't know that.
>>Correction: The a
Dean Anderson wrote:
> I recently read David Blacka's blog entry on Anycast, where Blacka
> asserted that Anycast had to be proven UNstable before anyone should
> consider stability questions. Blacka suggests that non-root operators
> had no experience or data to prove these things unstable--which
Moin!
On Aug 25, 2008, at 14:56 , Masataka Ohta wrote:
> As the, seemingly, only expert on anycast in the world, anycast
> is stable as long as unicast routing is stable.
While that is true, there are situations where unicast reachabilty is
working but anycast reachabilty is not.
> It should be
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations Working Group of
the IETF.
Title : Requirements for Management of Name Servers for the
DNS
Author(s) : W. Hardaker
IE 8 has a mechanism for highlighting the "owning domain" of the current
website in the address bar.[0] As they are not using the Public Suffix
List, I asked if they would explain their algorithm for deciding what to
highlight.
A Microsoft engineer was kind enough to explain the algorithm to me, a
On 19 Aug 2008, at 22:32, Dean Anderson wrote:
> On Mon, 18 Aug 2008, bert hubert wrote:
>>
>> What's the rush with deprecating DNS/TCP btw? It languished in the
>> shade for
>> 25 years..
>
> TCP doesn't work with Anycast, as was stated in RFC1546.
I just returned from a week with no Internet
Hi,
I admit I'm a bit confused.
> # 4> Check L1 == "tv". If so, getDomain returns L2.L1; exit.
> # "tv" is a special-case "completely flat" ccTLD for historical
> reasons.
...
> # 6> Check if L2 in gTLD list "com,edu,net,org,gov,mil,int". If so,
> # getDomain returns L3.L2.L1; exit.
> #
Dear colleagues,
In the IDNAbis working group, the current proposals alter the way IDN
work. One important feature of this is a great deal more flexibility
on what might be registered at any domain. Moreover, the current
proposals allow for local mapping at the client side. Some of us are
unc
David Conrad wrote:
> What is this code trying to do?
The code you quoted returns the number of domain labels, counting from
the right hand end, which are used to make up the "domain" property
(e.g. 2). The code works this way because those are the terms in which
the algorithm was described to me.
Ralf Weber wrote:
>> It should be noted that unicast TCP is unstable if unicast routing
>> is unstable.
>
> Yes, but TCP usually adapts to the problem while anycast can't, as it
> may reach another target.
That unicast TCP fails in unusual cases means we, anyway, need
retry mechanisms, which h
Gervase,
On Aug 25, 2008, at 2:27 PM, Gervase Markham wrote:
> David Conrad wrote:
>> What is this code trying to do?
> The code you quoted returns the number of domain labels, counting from
> the right hand end, which are used to make up the "domain" property
> (e.g. 2). The code works this way b
On 25 aug 2008, at 22.24, Andrew Sullivan wrote:
> To provide clients with a convenient way of learning about the policy
> statements, I think I'll need a facility that I can be fairly sure the
> client could use. One that has occurred to me is the S-NAPTR
> approach, as defined in RFC 3958. My
Moin!
On Aug 26, 2008, at 02:15 , Masataka Ohta wrote:
> Could you elaborate on how fast converging routing protocols can
> be a problem?
Well I believe it was in our case as we did observe some strange
behaviour when starting to test with anycast DNS.
> Anycast TCP fails only when route change
13 matches
Mail list logo
