David Conrad wrote:
Since I mentioned it and some folks said where is it?:
http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03
In what context, did you mention it?
Masataka Ohta
On 7/23/2014 7:57 AM, Masataka Ohta wrote:
David Conrad wrote:
Since I mentioned it and some folks said where is it?:
http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03
In what context, did you mention it?
Masataka Ohta
Masataka,
On Jul 23, 2014, at 7:57 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
wrote:
David Conrad wrote:
Since I mentioned it and some folks said where is it?:
http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03
In what context, did you mention it?
I asked if
Potentially dumb question: what does this magic meaning MX target
(.) offer, that a target resolving to a null address (0.0.0.0 and/or
::0) does not? No protocol or code changes required.
The null address does, after all, mean no service offered here. (Now,
if only load-balancer vendors could
Hector Santos hsan...@isdg.net wrote:
What has been crossing my mind regarding this NULL MX setup, was the possible
privacy issue with NULL MX root domain Traceability aspect with legacy MTAs
performing SMTP Implicit MX (No MX record, Fallback to A record) logic.
What will the A query IP
Kevin Darcy k...@chrysler.com wrote:
Potentially dumb question: what does this magic meaning MX target (.)
offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does
not? No protocol or code changes required.
A target of . causes an immediate permanent failure, whereas a
In article alpine.lsu.2.00.1407231447050.13...@hermes-1.csi.cam.ac.uk you
write:
Kevin Darcy k...@chrysler.com wrote:
Potentially dumb question: what does this magic meaning MX target (.)
offer, that a target resolving to a null address (0.0.0.0 and/or ::0) does
not? No protocol or code
David Conrad wrote:
I asked if the authors had compared their draft
(http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) to yours.
Hm, the draft inappropriately assumes having a lot of
anycast addresses is better even though several ones are
enough.
But, the following statement in
Well OK, so it's a semi-dumb question. But if we're going to assign
magic meaning to something, why not assign magic meaning to the null
address *specifically*in*the*context*of*SMTP*message*delivery*strategy*,
i.e. auto-fail messages destined for the null address and never retry them?
To
In your previous mail you wrote:
Does several thousands of queries per second during normal
operations with TCP matter?
= yes because it is at the limit current OSs can do on cheap stock
hardware...
Regards
francis.dup...@fdupont.fr
PS: I wrote OS because the first reached perf limit is
David Conrad wrote:
Masataka,
On Jul 23, 2014, at 7:57 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
wrote:
http://tools.ietf.org/html/draft-ietf-dnsop-ohta-shared-root-server-03
In what context, did you mention it?
I asked if the authors had compared their draft
OK, fair enough. Just as long as we understand and properly record the
design decision that was made here:
I.e. we're more afraid of the negative consequences of software/OSes
that don't treat null addresses reasonably (i.e. pointless/doomed
retries, possible self-looping) than we are of the
In message 53cfbb29.7040...@chrysler.com, Kevin Darcy writes:
Potentially dumb question: what does this magic meaning MX target
(.) offer, that a target resolving to a null address (0.0.0.0 and/or
::0) does not? No protocol or code changes required.
And just to be clear, nullmx as proposed
In message 6bbec3af-4370-4f19-8e01-54f7646d8...@isdg.net, Hector Santos write
s:
On Jul 23, 2014, at 9:46 AM, Tony Finch d...@dotat.at wrote:
Hector Santos hsan...@isdg.net wrote:
What has been crossing my mind regarding this NULL MX setup, was the possi
ble
privacy issue with
14 matches
Mail list logo
