Sounds like an AOR record with flag bits would help there, too, so long as
the authoritative server returned it in the addition section. The client asks
for the MX, and gets the AOR so it doesn't have to do A or requests
separately.
Doesn't solve the problem, because you can't infe
On Mar 1, 2012, at 7:59 AM, John R Levine wrote:
>> It is the caching of non-asked-for data, be it Auth, Additional, CNAME
>> chains, etc, which enables race-until-win attacks like the Kaminski attack.
>>
>> Thus a resolver MUST NEVER cache data that wasn't specifically asked for if
>> it can'
It is the caching of non-asked-for data, be it Auth, Additional, CNAME chains,
etc, which enables race-until-win attacks like the Kaminski attack.
Thus a resolver MUST NEVER cache data that wasn't specifically asked for if it
can't DNSSEC validate this information. It can use the additional da
John R Levine wrote:
>
> Sounds like an AOR record with flag bits would help there, too, so long as
> the authoritative server returned it in the addition section. The client asks
> for the MX, and gets the AOR so it doesn't have to do A or requests
> separately.
Doesn't solve the p
On Wed, Feb 29, 2012 at 10:22:55AM +0100, Shane Kerr wrote:
> Paul,
>
> On Tuesday, 2012-02-28 18:40:30 +,
> Paul Vixie wrote:
> > i'd start over with a new port number first. dns wire encoding is
> > already wildly complicated.
> The main (only?) advantage of doing it with EDNS is that yo
It is also not very useful from the MTA point of view, since the MTA can't
tell if A or records are missing because they don't exist or there
wasn't enough space in the DNS reply etc. So in most cases (especially an
IPv6 aware MTA getting no records in reply) the MTA still has to
follow
John R Levine wrote:
> > > the additional section. MX queries already have their kludge,
> > > returning A and records.
> >
> > I'm pretty sure MX queries do NOT have a kludge. I don't believe that
> > the additional section is actually used by any servers these days,
>
> Really? Caches thr
On Mar 1, 2012, at 6:08 AM, John R Levine wrote:
>>> the additional section. MX queries already have their kludge,
>>> returning A and records.
>>
>> I'm pretty sure MX queries do NOT have a kludge. I don't believe that
>> the additional section is actually used by any servers these days,
>
the additional section. MX queries already have their kludge,
returning A and records.
I'm pretty sure MX queries do NOT have a kludge. I don't believe that
the additional section is actually used by any servers these days,
Really? Caches throw away additional sections even when they're
John,
On Wednesday, 2012-02-29 16:47:16 -,
"John Levine" wrote:
> >The main (only?) advantage of doing it with EDNS is that you can work
> >with existing name servers. It means adding more logic to our already
> >fabulously complicated resolvers to get full benefit, but nobody ever
> >said D
10 matches
Mail list logo
