In message <6bbec3af-4370-4f19-8e01-54f7646d8...@isdg.net>, Hector Santos write
s:
>
> > On Jul 23, 2014, at 9:46 AM, Tony Finch wrote:
> >
> > Hector Santos wrote:
> >>
> >> What has been crossing my mind regarding this NULL MX setup, was the possi
> ble
> >> privacy issue with NULL MX root
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 pr
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.
>
> The null address does, after
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 n
David Conrad wrote:
> Masataka,
>
> On Jul 23, 2014, at 7:57 AM, Masataka Ohta
> 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
> (http://tools.ietf.org/html/draft-lee-
Kevin Darcy wrote:
> 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?
Because that will
> On Jul 23, 2014, at 9:46 AM, Tony Finch wrote:
>
> Hector Santos 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, Fallbac
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
Hector Santos 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 resolved
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 n
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 i
In article you
write:
>Kevin Darcy 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 fa
Kevin Darcy 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 tagret
that re
Hector Santos 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 resolved to
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
Hector,
On Jul 23, 2014, at 8:37 AM, Hector Santos wrote:
> Maybe a coincidence. The NULL MX specifications defines a NULL MX record
> setup:
I think this is unrelated. The context was in discussions relating to
alternative mechanisms for obtaining root name service.
Regards,
-drc
sig
Masataka,
On Jul 23, 2014, at 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?
I asked if the authors had compar
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
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
_
19 matches
Mail list logo
