In message <55007bea.90...@dougbarton.us>, Doug Barton writes:
> On 3/11/15 1:38 AM, Paul Vixie wrote:
> >>Tsig won't scale for something like this. Please consider sig0.
>
> Neither solves the problem of authenticating the entity which is sending
> the DS update.
Doug please explain this claim
Paul Hoffman writes:
> On Mar 10, 2015, at 6:25 AM, Yunhong Gu wrote:
> > So the problem is, why NOTIMP? REFUSED sounds like a better choice.
>
> +1. "REFUSED" exactly describes what is going on.
One down side there, however, is that REFUSED as understood by
resolvers commonly has the semantic
Once upon a time, Paul Hoffman said:
> If a resolver is sending an ANY before it sends its actual request, that
> could be a problem. However, they shouldn't be doing that.
A problem with ever using ANY to get "more information" from a cache is
the client's/applications's assumption that all req
On 3/11/15 1:38 AM, Paul Vixie wrote:
Tsig won't scale for something like this. Please consider sig0.
Neither solves the problem of authenticating the entity which is sending
the DS update.
The child synchronization draft does a better job, even though I still
don't like that idea either.
Paul Wouters writes:
> So if the MX or record has expired from the cache but another
> RRtype with larger TTL (say NS) is still in there, your ANY query will
> fail to find records.
The client is behaving correctly. The ANY query isn't guaranteed to find
the MX, but you're wrong in claiming t
On 3/11/15, 16:52, "Tony Finch" wrote:
>Edward Lewis wrote:
>>
>> Note that my request was not for a means to update the parent but to
>> prevent the child from shooting themselves in the foot. A much less
>> involved operation.
>
>In this immediate case the problem was caused by a change of op
Packet size is harder to analyze. ANY often pulls some records that
aren't used, and if the site isn't configured carefully then ANY can
even end up falling back to TCP, costing bytes _and_ packets. On the
other hand, there are a huge number of Internet sites that don't have a
noticeable volume of
Dough Barton changed the topic, so I hope this isn't too far off the new
topic.
On Wed, 11 Mar 2015, Doug Barton wrote:
> [...] to prevent zone walking. We were routinely told that it was stupid
> to care about the contents of your zones, since that was all data that
> is published on the public I
On 3/11/15, 15:32, "Doug Barton" wrote:
>It's unfortunate that while on the one hand the IETF makes nice smoochy
>noises about wanting input from operators, on the other hand that input
On 3/12/15, 12:41, "Fred Morris" wrote:
>I'm not attending IETF events, so I don't know what is occurring, bu
In message <3d558422-d5da-4434-bded-e752ba353...@flame.org>, Michael Graff
writes:
> What problem are we specifically trying to solve here again?
A non-problem for most of us.
> Michael
If one really wants to reduce the number of packets required with
SMTP processibg just write a RFC that says
10 matches
Mail list logo
