On 10/21/2013 08:54 AM, Keith Mitchell wrote:
Applying the same 5-years' now-outside hindsight to this, the benefits
of all that port randomization work seem murky at best - does anyone
have data on many real Kaminsky cache-poisoning attacks took place in
that time ?
The Kaminsky vulnerability
> From: Warren Kumari
> >> I suspect they're more interested in getting "registry lock" in place
> >> rather than DNSSEC.
> >> Most of the attacks against Google have involved changing the name servers
> >> completely ..
> >
> > Through social engineering and sometimes through directed a
On Oct 21, 2013, at 4:39 PM, Phil Regnauld wrote:
> Michele Neylon - Blacknight (michele) writes:
>>
>>> Yes, I've noticed that Google is still not signing. Maybe the
>>> continuing hijackings of their ccTLD domains will move them.
>>
>> I suspect they're more interested in getting "registry
Michele Neylon - Blacknight (michele) writes:
>
> > Yes, I've noticed that Google is still not signing. Maybe the
> > continuing hijackings of their ccTLD domains will move them.
>
> I suspect they're more interested in getting "registry lock" in place rather
> than DNSSEC.
That'd be a
> From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?=
> > On what do you base your claims about the fatal costs of DNSSEC
> > validation?
>
> I wrote that the costs are high, not fatal.
I'm sure I'm not the only person who read your words as a claim
that validation should not be enabled because of those
On 21 Oct 2013, at 19:32, Vernon Schryver wrote:
>
> Yes, I've noticed that Google is still not signing. Maybe the
> continuing hijackings of their ccTLD domains will move them.
I suspect they're more interested in getting "registry lock" in place rather
than DNSSEC.
Most of the attacks agai
On Mon, Oct 21, 2013 at 11:32 AM, Vernon Schryver wrote:
>> From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?=
>> Economics also include costs. The operational cost of deploying DNSSEC
>> validation on resolvers remains high - there are still frequent key
>> rotation and signing errors that cause various
> From: =?ISO-8859-1?Q?Colm_MacC=E1rthaigh?=
> Economics also include costs. The operational cost of deploying DNSSEC
> validation on resolvers remains high - there are still frequent key
> rotation and signing errors that cause various DNS subtrees to be
> unresolvable.
On what do you base you
On Oct 21, 2013, at 11:54, Keith Mitchell wrote:
>
> Then ISC/BIND response to Kaminsky in 2008 was to burn perhaps 50% of
> the company's product-wide development and support resources over that
> year to co-ordinating, fixing, disclosing, patching, releasing and
> evangelizing the solution to th
On Mon, Oct 21, 2013 at 8:54 AM, Keith Mitchell wrote:
> Then ISC/BIND response to Kaminsky in 2008 was to burn perhaps 50% of
> the company's product-wide development and support resources over that
> year to co-ordinating, fixing, disclosing, patching, releasing and
> evangelizing the solution t
On 21 Oct 2013, at 16:54, Keith Mitchell wrote:
> Applying the same 5-years' now-outside hindsight to this, the benefits
> of all that port randomization work seem murky at best -
There was/is a vulnerability and it's been (sort of) plugged. Surely that's a
Good Thing? Even if it just means the
On 10/21/2013 11:04 AM, Colm MacCárthaigh wrote:
>> remembering that the vulnerabilities you are reporting and the
>> workarounds you're recommending will be judged according to
>> engineering economics. if we assume that dnssec is practical on a
>> wide enough scale that it could prevent the v
Jo Rhett wrote:
> Tony, you seem to be confused about how dns and mail work. Fallback to
> host deliver when an MX doesn't exist was poor behavior in the original
> RFC, and has been fully deprecated behavior for more than 20 years now.
You might like to review section 5 of RFC 2821 and RFC 5321
On Mon, Oct 21, 2013 at 12:17 AM, Paul Vixie wrote:
> i apologize for my sloppy wording. i mean full deployment, in either case.
> your claims and your proposed workarounds will be evaluated through the lens
> of engineering economics. as vernon schryver has been (unsuccessfuly thus
> far) trying
On 2013-10-21 16:26 , Chris Adams wrote:
> Once upon a time, Jo Rhett said:
>> On Oct 21, 2013, at 4:37 AM, Tony Finch wrote:
>>> MX pointing to CNAME probably will work.
>>
>> Not in my experience. Not with either sendmail or postfix.
>
> I've (unfortunately) seen many domains set up MX->CNAME-
Once upon a time, Jo Rhett said:
> On Oct 21, 2013, at 4:37 AM, Tony Finch wrote:
> > MX pointing to CNAME probably will work.
>
> Not in my experience. Not with either sendmail or postfix.
I've (unfortunately) seen many domains set up MX->CNAME->A, and sendmail
and postfix both delivered to th
> From: Haya Shulman
> > My problem with your findings is that your are grossly overstating
> > their significance. None of them will ever be seen in the wild. As
> > As http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 and
> > as I've said, showing the inevitiable weakness of port ra
On Oct 21, 2013, at 4:37 AM, Tony Finch wrote:
> MX pointing to CNAME probably will work.
Not in my experience. Not with either sendmail or postfix.
> CNAME pointing to anything should work, except for the historical screwup
> in the way mail software handles CNAME.
Again, I don't perceive this
Tony Finch wrote:
> Jeroen Massar wrote:
>> "Don't use CNAMEs in combination with RRs which point to other names"
>>
>> And thus CNAME -> MX -> A falls under that too.
>
> No, it is only names in RDATA that should not refer to CNAMEs.
CNAMES (and DNAMEs in a different form) cause all kinds of un
Hi Tony,
On 21.10.13 13:37, Tony Finch wrote:
In practice, this depends a lot in the RR in question. NS pointing to
CNAME is not going to work. MX pointing to CNAME probably will work.
I can assure you that there are many MTA implementations which stricly
check that MXs point to A/ Record
>
> My problem with your findings is that your are grossly overstating
> their significance. None of them will ever be seen in the wild. As
> As http://link.springer.com/chapter/10.1007/978-3-642-33167-1_16 and
> as I've said, showing the inevitiable weakness of port randomization
> is good.
We f
Jeroen Massar wrote:
> "Don't use CNAMEs in combination with RRs which point to other names"
>
> And thus CNAME -> MX -> A falls under that too.
No, it is only names in RDATA that should not refer to CNAMEs.
In practice, this depends a lot in the RR in question. NS pointing to
CNAME is not goi
>
> your text above shows a drastic misunderstanding of both dns and dnssec.
> a correctly functioning recursive name server will not promote
> additional or authority data to answers. poison glue in a cache can
> cause poison referrals, or poisoned iterations, but not poisoned answers
> given to a
On 21.10.13 02:52, David Conrad wrote:
On Oct 20, 2013, at 2:16 PM, Vernon Schryver wrote:
Should the people working on DNS implementations prioritize making
their DNSSEC code more robust and easier to use above or below
addressing your issues?
I'd say "below".
Resolver operators (hopefully)
Haya Shulman wrote:
> I understood that you asked two questions:
> (1) by this, do you mean that you have found a fragmentation based attack
> that works against DNSSEC?
> (2) by this, do you mean that if DNSSEC is widely deployed, your other
> recommendations are unnecessary?
>
> --
>
> Correct m
On 2013-10-18 10:46 , Doug wrote:
> Hello,
>
> $ idig plus.google.com mx
> plus.google.com.1200INCNAMEplus-china.l.google.com.
> plus-china.l.google.com. 600INMX40 alt3.aspmx.l.google.com.
> plus-china.l.google.com. 600INMX50 alt4.aspmx.l.google.com.
> plus-
26 matches
Mail list logo
