Mark,
On 11-03-15 05:39, Mark Andrews wrote:
2) Authoritative servers don't launch queries.
>>>
>>> Has NEVER been true. SOA/IXFR queries are done regularly by
>>> authoritative servers. For over the last decade queries for
>>> nameserver addresses have been done for NOTIFY.
>>
>> Okay, but
In message <54ffe769.4020...@pletterpet.nl>, Matthijs Mekking writes:
> Mark,
>
> On 11-03-15 05:39, Mark Andrews wrote:
> 2) Authoritative servers don't launch queries.
> >>>
> >>> Has NEVER been true. SOA/IXFR queries are done regularly by
> >>> authoritative servers. For over the last d
Mark Andrews wrote:
> In message <1fb3db93-eb08-4864-9d3c-e48da9fc5...@redbarn.org>, P Vixie writes:
>> > Tsig won't scale for something like this. Please consider sig0.
>
> I've got no objection to sig(0) but why won't it scale? There is
> a existing relationship so public key cyptography isn't
Darcy Kevin (FCA) wrote:
> Regarding the statement "query type ANY 'matches all RR types CURRENTLY
> IN THE CACHE'."
>
> Actually, there's nothing in RFC 1034 that clearly *mandates* this
> behavior
It is sort-of specified in the algorithm in section 4.3.2 which says,
4. Start matching down
On 3/11/15, 13:31, "Doug Barton" wrote:
>Neither solves the problem of authenticating the entity which is sending
>the DS update.
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.
Perhaps
On 3/11/15 11:11 AM, Edward Lewis wrote:
On 3/11/15, 13:31, "Doug Barton" wrote:
Neither solves the problem of authenticating the entity which is sending
the DS update.
Note that my request was not for a means to update the parent but to
prevent the child from shooting themselves in the foot
On 3/11/15, 14:19, "Doug Barton" wrote:
>I think it would be Ok to put up a large, difficult to ignore warning
>that the user is about to do something painfully stupid, sure. How much
>farther than that to go is an exercise for the implementors.
To go a little deeper into what I witnessed up clo
On 3/11/15 11:45 AM, Edward Lewis wrote:
To sum up something - one thing I learned during my stints in operations -
many of the assumptions held by protocol engineers and architects about
how a protocol is put to work are far from reality. (Not that the
engineers and architects are wrong in thei
On Tue, 10 Mar 2015, Edward Lewis wrote:
So, why can't the name server find the DS set, run a check and barf if
there's a problem? Barf - either refusing to load the zone or refusing to
change the zone that is already running.
Please - if there are more impediments, suggest them. I may have
Hi everybody,
From our blog post just now, where we instroduced 'dnsdist' a smart DNS load
balancing tool that is not PowerDNS specific. The project is very fresh,
which is why we'd appreciate any input on useful features within our chosen
niche.
It has lots of Lua hooks to implement just about
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 operator for
the zone, and the registrar(s) failed
bert hubert wrote:
>
> http://blog.powerdns.com/2015/03/11/introducing-dnsdist-dns-abuse-and-dos-aware-query-distribution-for-optimal-performance/
Thanks for linking to my notes about keepalived.
I should perhaps have made it clearer that I am only using keepalived for
failover, not for load bal
> On Mar 11, 2015, at 16:18, Rob Foehl wrote:
> What about the case of bad data in the parent, regardless of where it lands
> on the malice / stupidity scale? Loud warnings to this effect at zone
> (re)load time would be one thing, but refusing to load the zone entirely
> would mean the bro
13 matches
Mail list logo
