Re: [DNSOP] Masataka Ohta's 2004 draft...
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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
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 I'm interested to know. Maybe a coincidence. The NULL MX specifications defines a NULL MX record setup: Exchange : "." (root) Preference: 0 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 when the exchange points to the root? (Pete, Dave, this is my only question/concern, if real, about the NULL MX proposal) -- HLS ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
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 compared their draft (http://tools.ietf.org/html/draft-lee-dnsop-scalingroot-00) to yours. Regards, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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 wrap their tiny minds around that
concept!)
- Kevin
On 7/17/2014 4:59 PM, Dave Crocker wrote:
On 7/17/2014 10:39 AM, John C Klensin wrote:
Hi. For a number of reasons, many of which have been identified
by others, I find this draft and the actions it recommends
distasteful.
Since I'm the doc shepherd:
I have not seen statements by others indicating that the
specification is 'distasteful', although there have been some that
seemed to confuse its functionality with that of SPF.
Feel free to cite the specific comments by others that classed this
as distasteful or the equivalent.
I see it as another step, albeit a small one, in
the direction of prioritizing the prevention of unwanted
messages or connections over successful delivery of legitimate
messages.
A statement of "I don't do X" does not 'prioritize' anything.
The use of information that says "target address Y will not work because
there is not receiver at Y's domain" does not 'prioritize' anything.
The specification is nothing more than a vastly more efficient form of
getting an SMTP 550 Requested action not taken: mailbox unavailable,
except that it is even better than that, because it also precludes
waiting days to discover that there's no service to supply even that
error message.
Hope, it would be better if the specification were historically
accurate and accurate about the protocols it cites.
You do not clearly indicate any historical inaccuracy at issue.
The last sentence of the second paragraph of Section 5
("Security Considerations") of the spec says:
"The normal way to send mail for which a sender wants no
responses remains unchanged, by using an empty
RFC5321.MailFrom address."
First, two issues of terminology:
(1) RFC 5321 does not contain or specify notations like
"RFC5321.MailFrom". That notation was introduced in RFC 5598, a
document that was approved as Informational with a consensus
that, IIR, included some significant desire that it not be
normative or casually treated as normative. If this
First, so what?
Second, a review of the IETF mailing list archive about the document's
Last Call, in May of 2009, shows a nicely solid pattern of support for
the document's publication. Strange that you would call it into
question at this point.
specification wants to use that notation, that is fine. But it
should include an explicit note to that effect in its
introduction or a Terminology section, not bury a "(see
[RFC5598] for the definitions of these terms)" reference in a
parenthetical note in Section 4.1 and then expect readers who
are looking specifically at other sections to pick up on it.
If you want specific text changes, please suggest specific text changes.
Please do not formulate a requirement for change in a fashion that
leaves the authors having to guess whether it will satisfy you.
I believe that the RFC Editor's principle is that, if particular
terminology is needed to correctly understand a specification,
then the reference to the document that defines that terminology
is normative. In this particular case, it seems inconsistent to
consider 2119 normative and 5598 informative since both are used
to define terminology without which the document cannot be
correctly understood.
So, you are suggesting that RFC 5598 be a normative reference here?
(2) Second, RFC 5321 does not contain a concept that it calls an
"empty address". The terminology it does use is "null
reverse-path" (See RFC 5321, Section 3.7). Subject to the
above, if the authors want to say "null address in
RFC5321.MailFrom", I don't think that is sufficiently confusing
to be a problem. But "empty address" could be construed as
MAIL FROM:
in the envelope with nothing following it, and that would be bad
news.
So you are suggesting:
empty RFC5321.MailFrom address
->
null ("<>") reverse-path, per 3.6.3 and 6.1 of RFC 5321
More important, however, RFC 5321 specifies the use of a null
reverse path only for delivery failure and status notifications
and message disposition notifications (see Section 4.5.5 of RFC
5321) and constrains the recipient address to be used. That
section also says
"All other types of messages (i.e., any message which is
not required by a Standards-Track RFC to have a null
reverse-path) SHOULD be sent with a valid, non-null
reverse-path."
And here I was, thinking that "SHOULD" means it is ok /not/ to do what
is being directed, if you have a good reason. Oh, wait...
Specifically referring to Section 3 of
draft-ietf-appsawg-nullmx-05, there is not such thing as a "NULL
MX Resource Record". Ther
[DNSOP] null mx, was Re: Masataka Ohta's 2004 draft...
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 when the exchange points to the root? Null MX records suppress fallback-to-A. The target "." does not have any A records. http://www.ietf.org/mail-archive/web/dnsop/current/msg12153.html Tony. -- f.anthony.n.finchhttp://dotat.at/ Trafalgar: Westerly or southwesterly in far southeast, otherwise northerly, 4 or 5, increasing 6 or 7 later in southeast. Slight or moderate, occasionally rough later. Mainly fair. Moderate or good. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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 resolves to 0.0.0.0 is likely to cause retries and eventual timeouts.
> The null address does, after all, mean "no service offered here".
No, it means "this host" - see RFC 3330.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
Fisher, North German Bight: Northeast 3 or 4. Smooth or slight. Fair. Good.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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 failure, whereas a tagret
>that resolves to 0.0.0.0 is likely to cause retries and eventual timeouts.
In practice, A records of 0.0.0.0 cause mail loops, and I have the logs
to show it. It's a really bad idea.
The version of null MX in the draft has been in wide use since 2006.
If anyone wants to do something different, the proposal needs to
explain why it is so much better than the existing practice that all
of the existing implementations that already work would be willing to
change their code.
R's,
John
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
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 the draft: > However, the costs of using TCP rather than > UDP, in terms of system and network resources, are much higher and > can have significant impact on systems such as name servers that may > receive several thousands of queries per second during normal > operations. is more disturbing to me. Does "several thousands of queries per second during normal operations" with TCP matter? Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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 nitpick your standards point about the null address, Section 2.5.2 of
RFC 4291 says that the IPv6 null address (which it idiomatically calls
"the unspecified address")
"must not be used as the destination address of IPv6 packets or in IPv6
Routing headers"
which effectively amounts to "no service here". Can't get there.
I haven't gone back to see if the IPv4 null address has been similarly
clarified/redefined, because, who still uses IPv4 anyway? :-)
- Kevin
On 7/23/2014 9:54 AM, Tony Finch wrote:
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 resolves to 0.0.0.0 is likely to cause retries and eventual timeouts.
The null address does, after all, mean "no service offered here".
No, it means "this host" - see RFC 3330.
Tony.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
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 when the > exchange points to the root? If millions of anycast root servers without a centralized administrator are distributed world wide, it makes it difficult for NSA monitor queries to all the root servers, because of massive number of them. And, it's not just for NULL MX. Many queries go to the root servers. Masataka Ohta PS OTOH, queries to 8.8.8.8 administrated by google are easy victims of NSA. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
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 in the kernel, not in the DNS server. And if you argue Web servers support far more, the TCP DNS issue is the server should close connections only after a timeout... ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] null mx, was Re: Masataka Ohta's 2004 draft...
> 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, Fallback to A record) logic. >> What will the A query IP resolved to when the exchange points to the root? > > Null MX records suppress fallback-to-A. The target "." does not have any A > records. http://www.ietf.org/mail-archive/web/dnsop/current/msg12153.html So by "suppress" you mean, for the vast wide field of "Null MX" ignorant MTAs, a positive return of a MX record with a preference of zero, a blind A lookup of "." returns an 0 ip value and this causes an inherent cancellation, "suppression" of the outbound attempt? I can understand how a supportive MTA can leverage it, but I was thinking what the impact might be for the legacy MTA. Not all DNS resolvers return the expansion depending on the API and the caching servers in play. -- Hector Santos http://www.santronics.com ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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 have horrible fallout for existing software that does not undestand the magic meaning. @ MX 0 . already has the correct semantics; the only magic in the nullmx spec is to suppress the A and lookups because they will always fail. > "must not be used as the destination address of IPv6 packets or in IPv6 > Routing headers" > > I haven't gone back to see if the IPv4 null address has been similarly > clarified/redefined, because, who still uses IPv4 anyway? :-) Yes, 0.0.0.0 is only for use as a source address. Tony. -- f.anthony.n.finchhttp://dotat.at/ South-east Iceland: Variable 3 or 4, becoming southeasterly 5 or 6 for a time in east. Slight or moderate. Fog patches, occasional rain. Moderate or good, occasionally very poor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Masataka Ohta's 2004 draft...
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-dnsop-scalingroot-00) to yours. this author isn't in toronto so i'll answer here-- i had not and have not compared -lee-dnsop-scalingroot- to -ohta-shared-root-. vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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 negative consequences of software that is slow or defective in their adoption of the new magic meaning of root-name MX targets (i.e. pointless/doomed A/ queries of the root name). - Kevin On 7/23/2014 12:16 PM, Tony Finch wrote: 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 have horrible fallout for existing software that does not undestand the magic meaning. @ MX 0 . already has the correct semantics; the only magic in the nullmx spec is to suppress the A and lookups because they will always fail. "must not be used as the destination address of IPv6 packets or in IPv6 Routing headers" I haven't gone back to see if the IPv4 null address has been similarly clarified/redefined, because, who still uses IPv4 anyway? :-) Yes, 0.0.0.0 is only for use as a source address. Tony. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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 all, mean "no service offered here". (Now,
> if only load-balancer vendors could wrap their tiny minds around that
> concept!)
>
> - Kevin
0.0.0.0 and :: mean "I offer service but I don't currently have a
address / know my address". This is a temp fail rather than a
permanent fail along with a ttl to retry the address lookup.
> On 7/17/2014 4:59 PM, Dave Crocker wrote:
> > On 7/17/2014 10:39 AM, John C Klensin wrote:
> >> Hi. For a number of reasons, many of which have been identified
> >> by others, I find this draft and the actions it recommends
> >> distasteful.
> > Since I'm the doc shepherd:
> >
> > I have not seen statements by others indicating that the
> > specification is 'distasteful', although there have been some that
> > seemed to confuse its functionality with that of SPF.
> >
> > Feel free to cite the specific comments by others that classed this
> > as distasteful or the equivalent.
> >
> >
> >> I see it as another step, albeit a small one, in
> >> the direction of prioritizing the prevention of unwanted
> >> messages or connections over successful delivery of legitimate
> >> messages.
> > A statement of "I don't do X" does not 'prioritize' anything.
> >
> > The use of information that says "target address Y will not work because
> > there is not receiver at Y's domain" does not 'prioritize' anything.
> >
> > The specification is nothing more than a vastly more efficient form of
> > getting an SMTP 550 Requested action not taken: mailbox unavailable,
> > except that it is even better than that, because it also precludes
> > waiting days to discover that there's no service to supply even that
> > error message.
> >
> >
> >> Hope, it would be better if the specification were historically
> >> accurate and accurate about the protocols it cites.
> > You do not clearly indicate any historical inaccuracy at issue.
> >
> >
> >> The last sentence of the second paragraph of Section 5
> >> ("Security Considerations") of the spec says:
> >>
> >>"The normal way to send mail for which a sender wants no
> >>responses remains unchanged, by using an empty
> >>RFC5321.MailFrom address."
> >>
> >> First, two issues of terminology:
> >>
> >> (1) RFC 5321 does not contain or specify notations like
> >> "RFC5321.MailFrom". That notation was introduced in RFC 5598, a
> >> document that was approved as Informational with a consensus
> >> that, IIR, included some significant desire that it not be
> >> normative or casually treated as normative. If this
> > First, so what?
> >
> > Second, a review of the IETF mailing list archive about the document's
> > Last Call, in May of 2009, shows a nicely solid pattern of support for
> > the document's publication. Strange that you would call it into
> > question at this point.
> >
> >
> >> specification wants to use that notation, that is fine. But it
> >> should include an explicit note to that effect in its
> >> introduction or a Terminology section, not bury a "(see
> >> [RFC5598] for the definitions of these terms)" reference in a
> >> parenthetical note in Section 4.1 and then expect readers who
> >> are looking specifically at other sections to pick up on it.
> > If you want specific text changes, please suggest specific text changes.
> >
> > Please do not formulate a requirement for change in a fashion that
> > leaves the authors having to guess whether it will satisfy you.
> >
> >
> >> I believe that the RFC Editor's principle is that, if particular
> >> terminology is needed to correctly understand a specification,
> >> then the reference to the document that defines that terminology
> >> is normative. In this particular case, it seems inconsistent to
> >> consider 2119 normative and 5598 informative since both are used
> >> to define terminology without which the document cannot be
> >> correctly understood.
> > So, you are suggesting that RFC 5598 be a normative reference here?
> >
> >
> >> (2) Second, RFC 5321 does not contain a concept that it calls an
> >> "empty address". The terminology it does use is "null
> >> reverse-path" (See RFC 5321, Section 3.7). Subject to the
> >> above, if the authors want to say "null address in
> >> RFC5321.MailFrom", I don't think that is sufficiently confusing
> >> to be a problem. But "empty address" could be construed as
> >> MAIL FROM:
> >> in the envelope with nothing following it, and that would be bad
> >> news.
> > So you are suggesting:
> >
> >empty RFC5321.MailFrom address
> >->
> >null ("<>") reverse-path, per 3.6.3 and 6.1 of RFC 5321
> >
> >
> >> More important, however, RFC 5321 specifies the use of a null
> >> reverse path only for delivery
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
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 does not required any code
changes and never has. It's simply recognizing a (to me at least)
serendipitous confluence of existing attributes of DNS and SMTP.
No new protocols are being invented and no deviation from those two
standards is being suggested.
Remember, considerate receivers have been adding this MX to their
zones for many years and senders, whether they know it or not, having
been automatically reaping the benefits as a consequence.
This is about as close as it gets to a free lunch on the Internet.
Mark.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] null mx, was Re: Masataka Ohta's 2004 draft...
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 domain "Traceability" aspect with legacy M > TAs > >> performing SMTP "Implicit MX" (No MX record, Fallback to A record) logic. > >> What will the A query IP resolved to when the exchange points to the root? > > > > Null MX records suppress fallback-to-A. The target "." does not have any A > > records. http://www.ietf.org/mail-archive/web/dnsop/current/msg12153.html > > So by "suppress" you mean, for the vast wide field of "Null MX" ignorant MTAs > , a positive return of a MX record with a preference of zero, a blind A look > up of "." returns an 0 ip value and this causes an inherent cancellation, "su > ppression" of the outbound attempt? To me "returns an 0 ip value" means 0.0.0.0 which is incorrect. The lookup returns no ip addresses (unless some locally is overriding the usual result) and without a IP address no connection attempts will be made. A negative caching nameserver will cache this for several hours (up to 24) depending upon how it is configured. For named 3 hours is the defaul max-ncache-ttl. ; <<>> DiG 9.11.0pre-alpha <<>> a . ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31874 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN A ;; AUTHORITY SECTION: . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014072301 1800 900 604800 86400 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 24 13:09:20 EST 2014 ;; MSG SIZE rcvd: 103 ; <<>> DiG 9.11.0pre-alpha <<>> . ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61938 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;. IN ;; AUTHORITY SECTION: . 10800 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2014072301 1800 900 604800 86400 ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 24 13:09:31 EST 2014 ;; MSG SIZE rcvd: 103 > I can understand how a supportive MTA can leverage it, but I was thinking wha > t the impact might be for the legacy MTA. > > Not all DNS resolvers return the expansion depending on the API and the cachi > ng servers in play. > > -- > Hector Santos > http://www.santronics.com > > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
