Re: [DNSOP] [Last-Call] [Ext] Last Call: (DNS Security Extensions (DNSSEC)) to Best Current Practice
--On Friday, September 23, 2022 19:25 + Amanda Baber
wrote:
> Hi,
>
> IANA uses the term "registry group" to refer to top-level
> registries and "registry" to describe a set of registrations
> (as opposed to a set of sets). There are logistical reasons
> for this, but the use of the term "registry" in particular
> matches the usage in ICANN's MoU with the IETF (and our
> MoU-mandated performance reports).
>
> I should add that we still use the term "sub-registry," but
> only to refer to, e.g., a registry of sub-TLVs for a TLV.
Amanda,
In the hope of getting something else on which I'm working [1]
right, some questions about the above:
If I look at a protocol assignments page, e.g.,
https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml
is "MAIL Parameters" the "top-level registry" aka "registry
group", despite the fact that some of the registries on that
page are associated with different protocols (even if they are
somehow mail-related and, as we have discussed, there are
mail-related registries elsewhere)?
Also some of what I assume are called "registries" ("SMTP
Service Extensions", "SMTP Service Extension Parameters", "Mail
Transmission Types", etc.) are subsidiary to other ones there.
Does that make a difference?
And, is "SMTP Service Extension Parameters" properly a
sub-registry of "SMTP Service Extensions"? And, forgive my
ignorance, but what is a "TLV" in this context?
thanks,
john
[1] draft-ietf-emailcore-rfc5321bis
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] New Version Notification for draft-ietf-dnsop-attrleaf-03.txt
--On Wednesday, March 21, 2018 06:05 -0700 Dave Crocker wrote: > On 3/21/2018 4:05 AM, John R. Levine wrote: > Harmonization for the sake of harmonization is bad, and very little Internet System technology gets it. Just do new stuff better. >> >>> I agree completely. So please forgive my not understanding >>> how your first and third comments are relevant to the >>> current topic, which pertains to ensuring that new >>> behaviors use the new model. > >> I'm not Paul, but I'm guessing that he is referring to >> retroactively changing the naming rules for SRV and other RRs, >> rather than documenting existing practice. > Your attempt at clarification is equally confusing to me, > since it, too, seems to have nothing to do with the current > effort. > > The effort is to create a registry -- which obviously differs > from existing practice -- and to have that registry be used, > going forward. Both the creation and the future use deviate > fundamentally from 'existing practice'. I have to agree with Dave. There is a strong case to be made that the introduction of the underscore convention was a kludge that violated fundamental design assumptions of the DNS and that it was added without considering, much less acting on, what other changes would be needed to support it smoothly. One can imagine other, better, ways to do the same thing. I did consider including it as another example in RFC 8324 but decided against it, which may not have been the right decision. While I think I understand at least some of the reasons why alternatives to the underscore convention were not considered seriously, much less adopted, it is much too late now to change things and this proposal, AFAICT, has absolutely nothing to do with that or any other change to existing protocol or operational practices anyway. Given that one is going to have a list of keywords that are expected to expand over time (or demonstrated to do so whether it was initially expected or not), the absolutely minimal thing that can be done in the interest of _future_ damage is to create a registry of the keywords that are being used in the hope of minimizing the risk of inadvertent use of the same string for different purposes. As Graham points out, we recognized that problem with mail header field names, but there are many other examples as well and I note that we've been gradually altering existing registry definitions to move toward "let's at least prevent conflicts" rather than "registration indicates the IETF needs has blessed this use" (media type and URN namespace registries come immediately to mind). AFAICT, the only change that is being made to existing specs is to provide that, if new keywords are used/added, they should probably be registered too. That is not either harmonization for its own sake or a protocol change; it is just an administrative adjustment in how new keywords or actions are documented. I think the observation that we are needing to do this again suggests something else that I hope the IESG can consider and adopt as part of its review procedures (e.g., maybe in the shepherd template questions). We probably need to be much more aggressive about asking whether new protocols or specs include, or are creating, lists of things that might be expanded in the future, identifying them, and just create the registries the first time around. If FCSF is the default (as Dave suggests here), such a requirement does not imply significant new work or long-term commitments or, e.g., designated experts. It seems to me that would be far preferable to having to go through these later exercises of registry creation (including gathering old data to seed them) that seem to almost always stir up controversies that have little or nothing to do with the registries themselves. However, that suggestion, which I trust the ART ADs are reading and able to share with their colleagues, is very much about doing things right in the future rather than about Dave's modest and focused proposal to, as far as I'm concerned, is just fixing an earlier omission and thereby lowering risk of name conflicts going forward. best, john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
Taking another look at this now that the IETF dust has settled. First, when I wrote my earlier note on the 21st, I had just glanced through the spec, not studied it, and was under the impression that either the SRV entries and registry would not be affected or that all entries in the SRV registry would be folded into the new one. The former would be fine, the latter plausible if it could be done smoothly but I gather there are reasons why it cannot. Two additional, possibly more important, thoughts after reading -05 more closely... (1) The introductory material in the I-D seems to imply that use of labels styled with "_" is a reasonable alternative to creating a new label type. My impression has been that, while there is nothing we can change about what is done and deployed, there has been community consensus that it is a bad idea and that changes have been made to the procedures for defining and registering new RRTYPEs to reinforce the principle that new RRTYPEs should be used and to make their use easier. "Significantly challenging over the life of the DNS" is undoubtedly correct, but that should not be, and presumably is not, the situation today or in recent years. I believe this document should not be advanced until that material is changed to be clear that use of underscore or similar conventions may be a reality but is not a desirable substitute for separate RRTYPEs (with or without that convention as appropriate). (2) I'd encourage people to think through another possibility. I'm not sure it is the right answer, but it is worth more consideration than this draft (at least at -05) appears to be giving it. The issues associated with QTYPE=ANY notwithstanding, it is not clear to me that the set of labels starting with "_" constitute a namespace, any more than the set of labels starting with "xn--" do. It is just a naming convention that identifies the labels as keywords with defined meaning. From that point of view, namespaces are actually per-RRTYPE and the right way to design this document would be as a registry of "_"-introduced keywords, with subregistries for each RRTYPE with which those keywords can be used. Given the way the DNS works, at least as I understand it, there is no DNS protocol conflict between _foo IN XYZ Data1 and _foo IN ABC Data2 Using the same keyword in both cases may be a bad idea but the zone files don't care and, given that queries are typically made for QNAME and QTYPE (etc.) and not the name alone (i.e., with QTYPE=ANY) except for other purposes, I see some advantages of [sub]registry-per-RRTYPE rather than pretending that every label starting with "_" is the same namespace. Of course, one of them is that there is no need to treat SRV as a special, legacy, case or even debate that. The coverage of the current document would be simply a subregistry for SRV (reorganized from the current registry, but that is simply an IANA organizational matter, not a change to what is registered, protocols, etc., plus a subregistry for RRTYPE=TXT and provisions for other subregistries as might be needed in the future. Organizing things that way would have at least one additional advantage: while FCFS may be appropriate for some RRTYPEs, other procedures may be appropriate for others. In a way, SRV is a good example of that distinction. Again, that might not be the right thing to do on balance, but I think it should be examined carefully as an alternative to trying to treat "everything starting with '_' as long as it occupies a particular place in the tree" as a namespace. best, john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
--On Monday, March 26, 2018 00:07 -0700 Paul Vixie wrote: > > > John C Klensin wrote: >> ... >> >> Two additional, possibly more important, thoughts after >> reading -05 more closely... >> >> (1) The introductory material in the I-D seems to imply that >> use of labels styled with "_" is a reasonable alternative to >> creating a new label type. ... > > i think you mean "RRTYPE" as used below, and not "label type". > we flirted with extended label types in the original EDNS0, > but found them to require end-to-end scale (forklift) DNS > protocol evolution which is impossible, rather than hop-by-hop > scale (incremental) evolution which is all we've got left > given the installed base. Yes, sorry. Late at night. >> ... My impression has been that, while there is nothing we >> can change about what is done and deployed, there has been >> community consensus that it is a bad idea and that changes >> have been made to the procedures for defining and registering >> new RRTYPEs to reinforce the principle that new RRTYPEs >> should be used and to make their use easier. "Significantly >> challenging over the life of the DNS" is undoubtedly correct, >> but that should not be, and presumably is not, the situation >> today or in recent years. I believe this document should >> not be advanced until that material is changed to be clear >> that use of underscore or similar conventions may be a >> reality but is not a desirable substitute for separate >> RRTYPEs (with or without that convention as appropriate). > > while i am sympathetic to this point of view, and even share > it, i know that developers of new apps learned from the SPF RR > example "never again" and that they can and have and will > continue to create new apps based on TXT with or without the > IETF's blessing. so i'm expecting your call for the stated > clarification to not reach consensus in this WG. If you are telling me I've fighting a losing battle, I understand that. At the same time, as I trust people have figured out from RFC 8324 and/or Bert's presentation in DNSOP last week, I think there is reason for concern that continuing to add features, especially features with either high intrinsic complexity or significant kludge properties, may eventually push things over some virtual cliff. That makes the fight worth fighting even if most of the battles are lost. >> (2) I'd encourage people to think through another >> possibility. I'm not sure it is the right answer, but it is >> worth more consideration than this draft (at least at -05) >> appears to be giving it. The issues associated with QTYPE=ANY >> notwithstanding, it is not clear to me that the set of labels >> starting with "_" constitute a namespace, any more than the >> set of labels starting with "xn--" do. It is just a naming >> convention that identifies the labels as keywords with defined >> meaning. From that point of view, namespaces are actually >> per-RRTYPE and the right way to design this document would be >> as a registry of "_"-introduced keywords, with subregistries >> for each RRTYPE with which those keywords can be used. Given >> the way the DNS works, at least as I understand it, there is >> no DNS protocol conflict between _foo IN XYZ Data1 >> and >> _foo IN ABC Data2 >> >> Using the same keyword in both cases may be a bad idea but >> the zone files don't care and, given that queries are >> typically made for QNAME and QTYPE (etc.) and not the name >> alone (i.e., with QTYPE=ANY) except for other purposes, I see >> some advantages of [sub]registry-per-RRTYPE rather than >> pretending that every label starting with "_" is the same >> namespace. Of course, one of them is that there is no need to >> treat SRV as a special, legacy, case or even debate that. The >> coverage of the current document would be simply a >> subregistry for SRV (reorganized from the current registry, >> but that is simply an IANA organizational matter, not a >> change to what is registered, protocols, etc., plus a >> subregistry for RRTYPE=TXT and provisions for other >> subregistries as might be needed in the future. >> >> Organizing things that way would have at least one additional >> advantage: while FCFS may be appropriate for some RRTYPEs, >> other procedures may be appropriate for others. In a way, SRV >> is a good example of that distinction. >> >> Again, that might not be the right thing to do on balance, >> but I think it should
Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
--On Monday, March 26, 2018 01:20 -0700 Paul Vixie wrote: > > > John C Klensin wrote: >> >> --On Monday, March 26, 2018 00:07 -0700 Paul Vixie >> wrote: >> >>>> ... My impression has been that, while there is nothing we >>>> can change about what is done and deployed, there has been >>>> community consensus that it is a bad idea and that changes >>>> have been made to the procedures for defining and >>>> registering new RRTYPEs to reinforce the principle that new >>>> RRTYPEs should be used and to make their use easier. >>>> "Significantly challenging over the life of the DNS" is >>>> undoubtedly correct, but that should not be, and presumably >>>> is not, the situation today or in recent years. I believe >>>> this document should not be advanced until that material is >>>> changed to be clear that use of underscore or similar >>>> conventions may be a reality but is not a desirable >>>> substitute for separate RRTYPEs (with or without that >>>> convention as appropriate). > >>> while i am sympathetic to this point of view, and even share >>> it, i know that developers of new apps learned from the SPF >>> RR example "never again" and that they can and have and will >>> continue to create new apps based on TXT with or without the >>> IETF's blessing. so i'm expecting your call for the stated >>> clarification to not reach consensus in this WG. >> >> If you are telling me I've fighting a losing battle, I >> understand that. At the same time, as I trust people have >> figured out from RFC 8324 and/or Bert's presentation in DNSOP >> last week, I think there is reason for concern that >> continuing to add features, especially features with either >> high intrinsic complexity or significant kludge properties, >> may eventually push things over some virtual cliff. That >> makes the fight worth fighting even if most of the battles >> are lost. > > i wish that reality as we will experience it was even halfway > as cut or dried as you describe here. however, just as the > worst abuser of "fake news" later became the most common > accuser of that abuse in others, especially where the news > _wasn't_ fake, so it is that your desire to create new RRTYPEs > in preference to "just use TXT and allocate a new underbar'd > name" will be called, wrongly and unfairly as i see it, but > that won't matter, will be called, "unnec'y increase in system > complexity." therefore, the battle you'll lose will be around > who gets to call which thing by what name, and not around what > problems should be avoided. the shape of this conference table > has been decided -- your remaining decision is where you will > allow yourself to be seated. Again, Paul, I fear you are right, but that does not eliminate my sense that trying to sound the alarm is worthwhile. best, john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
--On Monday, March 26, 2018 09:44 +0100 "John R. Levine"
wrote:
>...
>>> i have reproduced your entire second suggestion here,
>>> because i think it's solid. rrset atomicity means you're
>>> right, and that underbar'ed labels need only be unique
>>> within an RRTYPE, and any registry of such labels can and
>>> therefore should be per-RRTYPE.
>
> Technically, you are completely correct. But since the
> namespace is in effect infinite I would just as soon not have
> to explain to anyone why _foo for SRV means the same thing as
> _foo for URI but different from _foo for TXT. As we've seen
> it's hard enough to understand the separate second level
> underscore namespaces and we're stuck with them.
Ah, but pulling them together into one registry is our old
problem, in disguise, of trying to control behavior by what we
allow to be registered. If, for example, I'm stupid enough to
use "_tcp" as the label of a TXT RR, a single registration tree
won't stop me or cause any DNS problems, it will just help me
add to the confusion. If they are separated, I'm at least
marginally encouraged to document what I'd doing.
At least as I see it, the purpose of a registry like this is to
help non-stupid people avoid conflicts and to provide
documentation pointers for information about the keywords.
Especially if the registry is not expected to grow to a huge
number of entries, asking IANA to create an alphabetical index
of all label keywords (I'm resisting "_Node Name" because I
don't believe this is really a namespace) that could link names
to particular subregistries (possibly more than one) would not
be a big deal.
By contrast, Table 1 of the I-D is
+-+-++
| _NODE NAME | RR | REFERENCE |
+-+-++
| _tcp| SRV | [RFC2782] |
| _udp| SRV | [RFC2782] |
| _sctp | SRV | [RFC2782] |
| _dccp | SRV | [RFC2782] |
| _domainkey | TXT | [RFC6376] |
| _spf| TXT | [RFC7208] |
| _dmarc | TXT | [RFC7489] |
| _vouch | TXT | [RFC5518] |
+-+-++
While not very large, it is sorted by RRTYPE and then not sorted
in any obvious way. Were it to grow significantly, one would
either want the same sort of index or would want to sort it by
label string ("_Node name") and then create an index by RRTYPE.
If we are going to separate "SRV" out, as you and several other
have argued is necessary, we've got two separate registries
already -- SRV and "everything else", with the latter consisting
exclusively of TXT. So, again, going to two subregistries and
provision for expansion from a table that is halfway there
anyway does not seem to me to be a big deal while being closer
to the reality of the DNS (as Paul explained better than I
could).
best,
john
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
--On Monday, March 26, 2018 17:18 +0200 Martin Hoffmann wrote: > John C Klensin wrote: >> >> From that point of view, namespaces are actually >> per-RRTYPE and the right way to design this document would be >> as a registry of "_"-introduced keywords, with subregistries >> for each RRTYPE with which those keywords can be used. Given >> the way the DNS works, at least as I understand it, there is >> no DNS protocol conflict between >> _foo IN XYZ Data1 >> and >> _foo IN ABC Data2 >> >> Using the same keyword in both cases may be a bad idea [...] > > This sort of thing already happens: Both SRV and TLSA use the > _tcp and _udp labels. Perhaps the difference is subtle since in > both cases the label denotes the transport protocol. But names > do represent different things -- a service provided for a > logical entity v. a port of a physical host. The current text of the I-D, as I read it, is intended to bind the use of a given string to a given RRTYPE. From the abstract: "The purpose of the Underscore registry is to avoid collisions resulting from the use of the same underscore-based name, for different services." Subtle or not, that is a collision. I would much prefer to see: SRV [sub]registry ... _tcp [RFC2782] ... TLSA subregistry ... _tcp [RFC] ... rather than _tcp SRV [RFC2782][RFC] the former would also make it easy to say whatever needs to be said about second-level strings. > Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and > OPENPGPKEY all use underscore labels and are currently missing > from the initial table in section 3.1. Sigh. best, john p.s. Some nit-picking in the hope of general improvements to the document. At least for me, the terminology and background explanation needs careful review. In particular (1) The text in Section 1.1 says 'the DNS rules for a "host" (host name) are not allowed to use the underscore character... legal host names [RFC1035]' 1035 does not say that. Its section 2.3.1 is about what is preferred, not what is required (or "legal"). It says "should" and "preferred", but there is no requirement. As far as I know, there has never been a serious attempt to turn that preference into a requirement. Indeed, RFC 8121 says exactly the opposite and, if there were a prohibition, RFC 6055 would have been largely unnecessary. (2) While, AFAICT, it is correct or close to it, the terminology describing the DNS tree structure is awkward. For example, in "_foo._tcp.example.com", it is probably incorrect to refer to "_tcp" as a leaf node because it has substructure. The statement "Each globally-registered underscore name owns a distinct, subordinate name space" does not work if _foo._bar.examplle.com is valid for one RRTYPE but not for a different one (this is another argument for both associating "namespace" terminology with a keyword-RRTYPE pair and a subregistry approach, but the current language is problematic even if we stick with the current model. And, because a casual reader might associate "global" and "right-most" with TLDs and get confused about whether the DNS tree is considered "root up", "root down", or "root right", those terms would probably benefit from an explicit terminology section that describes this documents view of the tree. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another look - draft-ietf-dnsop-attrleaf-05.txt
(top post) Dave, I identified that issue as a nit deliberately. This is a WG document and I believe the document would be improved if a less strong assertion were made, just because the issues of what, exactly, a "host" is for DNS purposes and what it can be called has been a source of controversy among those who seem to enjoy such discussions for about as long as I can remember. Trying to address that issue through this document is unnecessary and has a bit of a "side effect" feel to it -- it would be sufficient to say that there is a convention about using leading underscore followed by a keyword with some RRTYPEs and then move on. To answer your specific question, RFC 2181, Section 11, says "...any binary string whatever can be used as the label of any resource record." I have not checked as to whether one of the many updates to that document modifies that statement, but the point is that _tcp IN A 10.0.0.1 is a perfectly valid record, whether it identifies a "host" or not. It just doesn't have any special interpretation there because there is no special namespace for "_" keywords associated with the "A" RRTYPE. Yes, that means that the use of leading underscores as a contention is a risk, just as the use of "xn--" to identify the need for IDNA processing is a risk. In practice, the risks have proven to be low for both. Maybe they are lower for "_" because the label strings are interpreted only in the context of specific label types, but that is just one more argument for binding the concept of a namespace for these names to the RRTYPE, not global, RRTYPE-independent, use of the DNS. However, I certainly don't have the time or energy to turn the validity of hostnames into a long, drawn-0ut, debate.It is not, IMO, a really serious error in the context of this document, at least unless a explanatory statement made here is cited later as an authoritative definition. If no one else in the WG cares about it, so be it. john --On Monday, March 26, 2018 09:54 -0700 Dave Crocker wrote: > On 3/26/2018 9:14 AM, John C Klensin wrote: >> (1) The text in Section 1.1 says >> >> 'the DNS rules for a "host" (host name) are not allowed >> to use the underscore character... legal host names >> [RFC1035]' >> >> 1035 does not say that. Its section 2.3.1 is about what is >> preferred, not what is required (or "legal"). It says >> "should" > > Note that when that spec was written, we didn't have such > precise and rigid vocabulary rules. > > But RFC 1123 should be cited, especially since it has more > forceful language: "The syntax of a legal Internet host name". > (RFC6055 seems to have missed the import of 'legal'.) > > >> and "preferred", but there is no requirement. As far as I >> know, there has never been a serious attempt to turn that >> preference into a requirement. Indeed, RFC 8121 says exactly >> the opposite > > Please cite the specific text in that RFC you are referencing. > > >> and, if there were a prohibition, RFC 6055 would have been >> largely unnecessary. > > Overall, it appears that your claim is that the underscore > naming convention is predicated on an erroneous interpretation > of 'hostname' restrictions. As such, the entire activity is > broken. > > d/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt
--On Thursday, March 29, 2018 22:00 +0100 Warren Kumari
wrote:
> On Thu, Mar 29, 2018 at 9:52 PM, Dave Crocker
> wrote:
>> On 3/29/2018 1:45 PM, Warren Kumari wrote:
>>>
>>> I don't want to get into if this is the*right* behavior or
>>> not, but it seems like worth mentioning in the draft as it
>>> has much background already...
>>> I can find nothing which states that A / cannot be
>>> associated with underscore names, but they sure don't seem
>>> to work in practice.
>> The current version is:
>>
>>https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf/
>>
>> Please suggest specific text to use and where to put it.
>
> I'm hoping someone will pipe up with "Gee, RFCfoo, Section
> bar, Bullet N clearly says this, I can't believe you never
> knew that"
>
> If that doesn't occur I'll craft text.
Warren, just to clarify where I'm coming from (and noting Paul
Vixie's recent comment). I think there is no question that
putting a label starting with an underscore (or containing one)
on an RRSET that includes an address record would be
ill-advised, nor that some implementations (possibly because
they consider it ill-advised or just plain dumb) won't allow it
or won't make it easy. I think there is no question that
underscores (leading or otherwise) have no more place in either
historical (e.g., RFC 952) host names or the "preferred syntax"
of RFC 1034/1035 than, e.g., "+", "$", "%", or "/" do. I am
reasonably confident that you are not going to find a normative
statement that says that the term "host name" (with or without
an intervening space) is any label, or the left-most label,
associated with one or more address records, nor as statement
that host names in the DNS MUST conform to the preferred syntax.
Indeed, the description in RFC 7719 appears to me to be
consistent with what the specifications actually say and it
contains the same "any octet value" language that appears in
earlier, normative, documents including RFC 8121.
My objection was narrow. The text, even at -06, reads
'"host" (host name) are not allowed to use the
underscore character, this distinguishes the underscore
name from all legal host names [RFC1035]"'
That is objectionable for two reasons. First and most
important, RFC 1035 just does not say that. If the text had
referenced RFC 952 instead, it would have been correct, but
maybe not so useful. Similarly, if it had said, more or less
following 7719, that generally-accepted domain names that
identify hosts ("host names") conform to the preferred syntax of
RFC 1034 (or 1035) and hence do not include underscores, there
would be no problem (if someone wants to take that as proposed
text, feel free).
Second, as has been discussed many times before in the last
decade or two, "legal" is not a good term to use to describe
validity or conformance in RFCs. Our standards are voluntary,
which makes it hard for them to assign legality or illegality
to, in this case, particular bits of syntax. Moreover, the
concept of something being legal or illegal implies that, if the
latter is discovered, I should be able to call the Protocol
Police and have the offending label or its perpetrator arrested.
When last I tried, they were not answering their phone or even
their email. The IESG has pushed back on that term in the past
and should, I believe, be pushing back on it today, regardless
or what might have been said in kinder and gentler times.
However, I believe that this discussion is, however
unintentionally, a distraction from a far more important issue.
The way the DNS, and particularly DNS queries, are defined makes
the idea of a namespace for all labels starting with "_" very
difficult and potentially a source of confusion. While sorting
the registry by RRTYPE is an improvement over earlier versions,
the correct structure is to have subregistries by RRTYPE, each
with whatever keywords (starting with underscore) are
appropriate for use with it listed. I do not believe it is
appropriate to lose that distinction while we quibble about the
language used to describe the syntax of host names.
best,
john
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (DNS Terminology) to Best Current Practice
IESG and others,
Unfortunately and due to some other priorities, I have not been
able to do a comprehensive review of this document. The
following is based on reading through and trying to get an
understanding of this rather long document and its many
definitions, some of which are, as the document itself points
out, somewhat controversial.
First, as far as the definitions are concerned and as far as I
can tell, where a term appeared in RFC 7719 and the definition
has been changed, almost every change is for the better. The
authors and WG are to be commended for that.
I do have some concerns that may be important.
First and recognizing that some of what I'm concerned about now
comes directly out of 7719, unless a definition is completely
uncontroversial (i.e. the term is used the way the document says
it is and has never been used, accepted, or interpreted in any
other way in the community), treating a definition as normative
or claiming consensus for it (without documented evidence) seems
to me to put us on a difficult path: much as we might wish it,
many people are unlikely to change their normal/historical usage
just because we say so. If they don't, and this document
appears to say "these are the definitions and all others are now
wrong" (as it appears to do in many cases), we are likely to add
to confusion rather than reducing it.
Some of the language also appears to overreach a bit. To a
first order approximation, I think the definition of a naming
system is correct, but that is, in part, because I understand
some of the terms used in that definition differently than
others might understand them. Similarly, if a domain name is
"An ordered list of one or more labels" and that definition is
"independent of the DNS RFCs, and the definition here also
applies to systems other than the DNS", then, absent a
definition of "label" that is similarly broad and independent
(and more specific than "An ordered list of zero or more
octets", some things we are normally fairly sure are not domain
names, e.g., the string 128.0.0.1, is a domain name. Probably
don't want to go there -- it is certainly true in some cases,
but one of this document's objectives, at least IMO, should be
to never increase confusion.
And so on.
That leads me to a conclusion that might be painful. These same
definitions were acceptable in 7719 because it made fairly clear
that it was Informational and guidance, not normative. By
promoting the document to BCP, I think we create new problems
and/or an obligation to be far more clear about what is
normative and what is not and what alternative uses of the
terminology might exist. The document does very well about the
latter for some terms but not for others and so, from that point
of view, either needs more work or publication as Informational.
The relationship to 2308 also seems problematic. That document
is a Proposed Standard. This draft mostly references it for
definitions and usage, which is fine. However, in the few
places where it actually changes 2308, it appears to me that we
run into the problem that, historically, we have never allowed a
document that is not strictly standards-track (maturity levels
and all) to update a standards-track document, with no exception
for BCPs. So, if it is necessary to modify ("update") 2308, it
would seem to me to be far preferable to create a
standards-track document that does that, rather than putting a
few words into this document (whether it is then published as
Informational or as BCP). Doing otherwise risks creating
significant confusion as to what the standard actually is or is
not. In that same context, while I note that Appendix A and B
describe changes from 7719, there is no explicit list of changes
made to 2308, something the IESG normally requires in such
updates.
thanks for your consideration,
john
--On Monday, July 30, 2018 14:00 -0700 The IESG
wrote:
>
> The IESG has received a request from the Domain Name System
> Operations WG (dnsop) to consider the following document: -
> 'DNS Terminology'
> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the i...@ietf.org mailing lists by
> 2018-08-13. Exceptionally, comments may be sent to
> i...@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [Ext] Re: Last Call: (DNS Terminology) to Best Current Practice
Paul, Thanks for the thorough response. A few additional comments below; I consider all of these to fall into the "things that should be considered as the document is evaluated" category, not anything resembling showstoppers. --On Monday, August 13, 2018 23:56 + Paul Hoffman wrote: >... >> I do have some concerns that may be important. >> >> First and recognizing that some of what I'm concerned about >> now comes directly out of 7719, unless a definition is >> completely uncontroversial (i.e. the term is used the way the >> document says it is and has never been used, accepted, or >> interpreted in any other way in the community), treating a >> definition as normative or claiming consensus for it (without >> documented evidence) seems to me to put us on a difficult >> path: much as we might wish it, many people are unlikely to >> change their normal/historical usage just because we say so. >> If they don't, and this document appears to say "these are >> the definitions and all others are now wrong" (as it appears >> to do in many cases), we are likely to add to confusion >> rather than reducing it. > > The IETF has a recent history of writing clarifying > terminology documents whose intention is to say "here is the > best way to define some terms" without saying "these are the > definitions and all others are now wrong". For example, BCP > 166 / RFC 6365, "Terminology Used in Internationalization in > the IETF", tries to clarify some of the widely used words and > phrases in internationalization. That BCP says:As in many > fields, there is disagreement in the internationalization > community on definitions for many words. The topic of language >brings up particularly passionate opinions for experts and > non-experts alike. This document attempts to define terms > in a way thatwill be most useful to the IETF audience. > That BCP also has conflicting definitions of common terms, > such as for "glyph". Absolutely. And, of course, I'm familiar with 6365. IIR, we were very sensitive about that problem when 6365 was being assembled and tried very hard to make it clear, with the "As in many fields...", sentence you quote above as part of that effort. When I read the Introduction to draft-ietf-dnsop-terminology-bis-12 (checked the current version today), I don't get nearly that much clarity. Instead, I see language about terminology having evolved (which is fine) and consensus about the definitions, where the latter is, absent qualifying language, usually IETF-speak for "standard" or "what everyone else is doing and you should do too". Nothing in this draft leaps out at me as a invocation of that principle from 6365 -- certainly its comment that 6365 contains terminology, some of which is about the DSN, does not incorporate that terminology model by reference. I assume that the WG does not expect that model to be assumed from the observation that this is a terminology document. The document does mention "other organizations", specifically the WHATWG spec and RSSAC lexicon, as additional sources of definitions. If you, and the WG and community, believe that does the job that the quoted sentence from 6365 does (or was intended to do), I'm ok with that -- I may just be oversensitive to the issue. If not, it would, IMO, be better to include a very similar sentence here, perhaps at the beginning of that "Other organizations" paragraph, than to leave it to the user to infer that intent. >... >> Similarly, if a domain name is >> "An ordered list of one or more labels" and that definition is >> "independent of the DNS RFCs, and the definition here also >> applies to systems other than the DNS", then, absent a >> definition of "label" that is similarly broad and independent >> (and more specific than "An ordered list of zero or more >> octets", some things we are normally fairly sure are not >> domain names, e.g., the string 128.0.0.1, is a domain name. >> Probably don't want to go there -- it is certainly true in >> some cases, but one of this document's objectives, at least >> IMO, should be to never increase confusion. >> >> And so on. > > As Viktor just pointed out, your example *can* be a domain > name, even in the current DNS. The fact that is it typically > not a domain name is irrelevant to the accuracy of the > definition. Who do you believe would be more confused by such > an accurate definition? Actually, I was relying somewhat on the definitions/ statement in RFC 1123. Obviously, if one makes sufficient distinctions between what you call the public DNS and others sorts of domain names (non-public but derived from or assuming 1034/1035 or using the even broader definition of "domain name" in Section 2), it can be one of those. But, referring partially to other notes, as the IETF (and ICANN) have discussed several times in the past, that odd-sounding "will not" language was chosen to avoid having the IETF make (and standardize) an assertion that was well out o
Re: [DNSOP] [Ext] Last Call: (DNS Terminology) to Best Current Practice
Patrik, My personal view is that, if the same (or an extremely similar) term is in use for the cases you enumerate, especially if most of those who use it think they are saying something precise, we are better off listing those cases and making the possible confusion clear. In particular, saying something that appears to point to one particular case and ignoring the others is likely to cause more problems than it solves. For this case, the current definition falls somewhere in between. Partially, I think, because it is a little vague it is not nearly as bad as saying "this is the definitive definition and the term always applies to this case" but not nearly as good as the sort of enumeration you suggest. best, john --On Thursday, August 16, 2018 08:11 +0200 Patrik Fältström wrote: > On 15 Aug 2018, at 22:01, John C Klensin wrote: > >> In that regard, I find the document's definition of "split >> DNS" a little bit frustrating, as I have seen (multiple >> times) a distinction made between names (or a zone) that >> would clearly be part of the public DNS except that they are >> hidden from view and names that are part of a different >... > Is it the case that various alternatives should be enumerated? > > a. When a domain name is used for access to a service we might > have: > > a.1. The same DNS response regardless of who sends the query > (this is the default for DNS) > > a.2. Different responses depending on context (where query is > sent from etc), but still same service (this is CDN) > > b. When different services are accessed depending on context > (enterprise setup) > > b.1. A service is available or not depending on context, > implemented via DNS response or not (version of a.1) > > b.2. Different services are available depending on context, > implemented via different DNS responses > > c. The special case of (b) based on use of different root zone > > : > : > : > >Patrik ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (The .onion Special-Use Domain Name) to Proposed Standard
--On Monday, July 20, 2015 13:50 -0400 Bob Harold wrote: > This thread has taught me more about the .onion names - thanks > for that. But I would have to agree with those that think this > bit of explanation is unnecessary to the RFC and should be > excluded, rather than attempting to clarify it. The RFC only > needs to deal with ".onion". No need to explain the other > parts of the name. FWIW, I tend to agree. If the purpose of the document is to try to lock down the name, it should explain what ONION. is and how it is deployed to the extent needed to justify that and incorporate explanations of how the hierarchical structure is used and accessed, as well as the nature of the protocol itself, by reference if at all.If the intent is to incorporate and/or explain the latter, how TOR works, etc., that is a rather different sort of document. The latter might still try to reserve the top-level name as an "IANA Considerations" effect, but is one over which the IETF would typically want change control as a condition for IETF Stream publication. john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations]
Stephane, Thanks for reading the draft and for your comments. I will study them and see what I can do and will get back to you if I have questions. One general observation: I've tried, when mentioning possible alternate approaches, to provide a partial existence proof that alternatives are possible that could do the job or improve things, not to propose solutions or to be comprehensive able possibilities. Fro example, the blockchain example was mentioned because it is one way -- a way that has gotten a lot of attention lately -- to have an authoritative structured name system without having a hierarchical system and centrally-managed root. I didn't mean to suggest that it was the only such option (it isn't) or the best one (I suspect it is not). As to whether DNSOP wants to get involved, while there are operational issues in the summary I'm trying to make, I see most of them as being consequences of protocol choices that were either poor to start with (like the underspecification of CLASS), poor (more historically than at present) implementations, or that just have not held up (i.e., failed 30-odd years ago to adequately predict the present). So, while I'm sure there are people on the DNSOP list who are, or should be, very interested in the question of whether we are pushing the DNS past its practical limits, I don't see that as specifically an operational problem. Instead, I see it as an issue that affects much of the IETF. That is especially true if, as one person who commented believes, a transition to a DNSng could be more difficult and take longer than the IPv4-> IPv6 transition. In addition, while I would welcome help or even a contributor or co-author or two, I think there are a number of reasons why the contents of this I-D are more appropriately an Independent Submission than any sort of IETF stream document (even an Informational one) that would require a consensus determination. best, john --On Tuesday, June 6, 2017 22:04 +0200 Stephane Bortzmeyer wrote: > draft-klensin-dns-function-considerations is an interesting > document so I take the liberty to copy dnsop, which may be > interested. > > A few remarks about the -01 version: > > It does not seem to mention other naming systems, except a > short reference to "blockchains" (there are many of naming > systems, each with different strengthes and weaknesses than > the DNS). I do not suggest to enumerate them all, rather to > note they exist, and The Solution may not be a replacement of > the DNS but a coexistence of the DNS with other naming systems > (I have trouble believing that one day, we will have One > Perfect Naming System). > >> 3.1. Multiple address types > > In this section, and in some others, I think that you mix > problem description and solutions. For this problem (getting > both A and records with a single query), there is the > solution you mention (QTYPE=ADDR) but there is also having > several questions in the Question section. > > Same issue in "3.13.2. Extensions and Deployment Pressures -- > The TXT RRTYPE" where you mention a solution (new RR types) > and not another one (TXT records below the apex). > >> perceived discrimination against some languages > > Scripts, not languages. And "perceived" is offensive: it _is_ a > discrimination (although we agree there is no obvious > solution). > >> it does not appear that any of them are as satisfactory as a >> system with query privacy designed in might be. > > Both QNAME minimization (RFC 7816) and DNS encryption (RFC > 7858) have seen very little deployment today, so I don't think > we can already conclude they are not satisfactory. > >> The DNS model of master and slave servers, with the latter >> initiating updates based on TTL values, > > The slaves don't use the TTL values, don't they? > >> a subject that is intensely controversial with regard to who >> should control those servers [the root name servers], how >> they should be distributed and where they should be located. > > The problem is only partly technical. For instance, with > today's DNS, it is already possible to have more root name > servers (not thousands, OK, because of the size of the priming > response, but dozens, certainly). This would partially address > the problem. > >> A key design element of the original network object naming >> systems for the ARPANET, largely inherited by the DNS, was >> that the names were identifiers and their being highly >> distinguishable and not prone to ambiguity was important. > > If the main (and may be only) goal were to have unambiguous > identifiers, digits would have been sufficient (a SHA-256 hash > is an unambigous identifier, see RFC 6920). Unlike what you > say, from the beginning, domain names have been expressing > "thoughts and concepts". With a few exceptions, nobody > registers "opaque" domain names. > > Editorial: > >> including a model for negotiating extended functionality >> [RFC2671] > > It is now RFC 6891. >
Re: [DNSOP] What can be done with the DNS and what should be done elsewhere [draft-klensin-dns-function-considerations]
--On Wednesday, June 7, 2017 12:48 +0100 Tony Finch wrote: > Stephane Bortzmeyer wrote: >> >> > The DNS model of master and slave servers, with the latter >> > initiating updates based on TTL values, >> >> The slaves don't use the TTL values, don't they? > > That section is a bit weird. > > Efforts > to use veryshort (or zero) TTLs to simulate > nearly-simultaneous updating maywork up to a point but > appear to impose very heavy loads on serversand > distribution mechanisms that were not designed to accommodate >that style of working. Similar observations can be made > aboutattempts to use dynamic, "server-push", updating > rather than thetraditional DNS mechanisms. While those > might work better thanordinary short TTLs and update > mechanisms as specified in RFC 1034and 1035, they imply > that a "master" server must know the identitiesof (and > have real time access to all of) its slaves, defeating many > of the advantages of caching, particularly those associated > withreduction of query traffic across the Internet. > > It doesn't mention the venerable and widely-deployed NOTIFY, > and seems to muddle up replication to authoritative servers > and cacheing in resolvers. If it is supposed to be talking > about somthing of current relevance, it should refer > explicitly to draft-ietf-dnssd-push or whatever other > developments the author has in mind. It is indeed muddled. Thanks to both of you for pointing that out. I will try to fix. The references are another issue - while I've tried to pick up references as I went along, there are _many_ things that have been discussed, proposed, or even adopted that I haven't picked up, partially because I just don't follow some of the work closely enough. Pointers to them would be appreciated, as would text to go with them. At least in retrospect, someone closer to DNS issues than I am should have written the document I hope this will become and written it several years ago. No one did. The IAB Identifier Program could have taken it on, but they didn't (mostly, AFAICT, for good reasons) and the IAB has now closed it.I don't believe that posting a note to the IETF (or DNSOP) list saying "someone should do this" has ever been particularly productive, especially not in the last few years. WGs like DNSOP appear to be focused on responses to demands for services and behavior from the DNS that can be defined, implemented, and deployed in the relatively short term (as I think they should be -- see earlier response to Stephane). Because I am concerned about weakening the DNS for its original function and the amount of time and energy that appears to be going into "solutions" that just cannot work (the quest for fully-equivalent names, not even limited to pointers to subtrees, comes to mind), my view is that we need to start asking fundamental questions about how far it is sensible to push the boundaries of the DNS, saying in essence about many things that "we need a naming system and database for something, the DNS is out there, so let's put it in the DNS". So, driven by some other issues, including concerns that some of the proposals to "fix" the DNS (or just "fix" IDNs) could weaken it for other purposes, some apparent real disconnects in the broader Internet community about the purpose of the DNS and criteria for DNS success, and the degree to which I believe that some of the requirement are real but that trying to make proposed solutions fit in the DNS prevents work on more comprehensive and effective solutions, I finally started writing.Again, if anyone with the right background wants to be more actively involved, I would really welcome that. best, john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new DNS classes
--On Tuesday, July 04, 2017 6:53 PM +0100 Jim Reid wrote: >> On 4 Jul 2017, at 18:49, Paul Vixie wrote: >> >> while IETF governs the protocol, ICANN only governs the IN >> class. i expect that there will be other classes some day, in >> order to avoid some aspect of ICANN. > > Attempts have already been made to do just that. It would be > nice not to have to put out those fires all over again. Jim, Paul, First of all, if only because "QCLASS=ANY" is supposed to do something sensible, one really cannot have different, per-Class, roots (more of that argument and the difficulties for many of the things people have wanted to use CLASSes for in recent years appears in draft-sullivan-dns-class-useless). While I don't believe "useless", I don't see any hope for using the CLASS mechanism to "avoid ... ICANN". More important, given historical difficulties with adoption and broad deployment of new features, I suggest that anyone who sees ICANN avoidance as am important goal would find establishing an alternate root and building support for it far easily and more plausible than anything that could be done with CLASSes, if only because an ICANN-free class mechanism would, AFAICT, require a root (even for Class=IN) that was not controlled by ICANN anyway. Having enough of the world get aggravated enough at ICANN (or some other entity of one's choice) to make general adoption of an alternate root plausible is another matter and I don't think we are there, at least yet. The level of confusion and global inconsistencies that would accompany any transition to a different root and root management structure would be bad enough that I hope the day at which that aggravation threshold is reached does not come even if, ICANN seems to be trying some days. Those who are contemplating that sort of adventure might find at least parts of draft-klensin-dns-function-considerations amusing reading. In particular, Section 3.6 briefly addresses the topic of different CLASSes as a mechanism for doing new and different things (technical or administrative). best, john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
--On Wednesday, July 05, 2017 8:01 AM -0400 Suzanne Woolf wrote: > (not sure which hat. Probably doc shepherd.) >... >> This is a very good question. We weren't asked to answer >> that question, so we didn't. It is assumed throughout the >> document that various proponents of special use domains have >> good reasons for wanting them, and further that it is already >> accepted in principle that if their reason for wanting them >> is valid, they can have them (modulo technical constraints >> like delegation). So we didn't delve into that. But perhaps >> we should have. > > I'd go a step further: RFC 6761 alludes to some general > reasons, but assumes people who'd go through the IETF > standards process or an IESG approval process to get an entry > in the special use names registry have good enough reasons > that the special handling requested should be accepted as part > of the DNS protocol. (I'm one of the people who isn't > comfortable with this assertion, but we're living with what > RFC 6761 says, not what I think it should have said.) > > That is, RFC 6761 leaves to other processes to assess the > value of the request and the reasons offered, but strictly > speaking doesn't require them to be documented or evaluated; > required documentation for the registry entry consists mostly > of assessing how it interacts with the DNS, not its primary > use. (Sec. 4 starts by saying "If it is determined that > special handling of a name is required in order to implement > some desired new functionality," the registry entry policy > applies, but openly avoids describing how that determination > should be made.) >... > I think the observation that people aren't really required > to document what problem they are trying to solve with their > special use name is in the draft, but perhaps could be more > explicit. > > Some few people already have been convinced that there should > be some general guidance available for making the > determination that a domain name requires special handling in > the DNS. But that also seems to be a different document. Suzanne, Independent of "general guidance", I think the combination of the I-D, this thread to date, and your comments above make an extremely strong case for updating RFC 6761 to require documentation of the problem and discussion of other alternatives and why they are unworkable. Whatever else the problem statement does, I think it makes it clear that yet another special name should be viewed as a preference only if there are no reasonable alternatives rather than, e.g., an option for global vanity names. While "general guidance for making the determination" would be, IMO, desirable, I can imagine months (or years) of quibbling before agreement could be reached on such criteria. In the interim, I'd think a requirement for documentation and explanation sufficient to satisfy the IETF would be in order if only as an interim measure to prevent proposals whose main justification is "because I want one of my very own". Anyone in DNSOP want to write a one-page RFC? john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] new DNS classes
--On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker wrote: > There are changes to the DNS that are practical and those that > are not. For better or worse, I can't see any way that > teaching DNS to use new classes makes any sense at this point. > The only point at which it would have made sense was when > internationalization happened. But the path chosen makes more > sense. As the author of the I-D that proposed using a Class to deal with internationalization, it would not have worked, and the two important reasons are perhaps worth understanding. First, that approach included a transition strategy that permitted legacy clients and registrations to keep working in a way that users would see as normal. But that strategy depends on CLASSes sharing the same root and hierarchy. At Paul points out, that interpretation of 1034/1035 is not universally accepted and implemented. Second, IIR, we intended that the different CLASS allow a different set of matching rule assumptions and conditions. Because labels must generally be interpreted and compared before CLASS values are accessed and, perhaps more important, in optimization of databases, one probably needs label types to do that, not CLASSes. And label types don't have a good history. > ICANN will manage whatever bits of the DNS consensus agrees it > should manage. The only events likely to break consensus would > be an attempt by some government to strong arm ICANN into a > breach of faith with the community and succeeding or some > really spectacular peculation. We disagree about that, but I no proof that my impressions/ predictions are any better than yours. > It seems to me that if people want to do anything new with DNS > that they should use prefixes, new RRs or both as the > mechanism, not the class which is limited anyway. > > DNS is not a full service directory. Nor does it need to be. A > UDP packet is big enough for a link, a fingerprint and a > digital signature. That is all that you ever need. As I think you know, I just love "all you will ever need" statements about the Internet (and its predecessors) although my favorite remains "we will never need more than 8 bits of address space". > The X.500 and UDDI models were broken because there is no > point in putting information into a directory if the service > can return it in a service handshake. The X.500 and UDDI approaches failed because... sorry, I lost count of the reasons :-( john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
--On Thursday, July 6, 2017 09:11 +1000 Mark Andrews wrote: >... > And the actual presentation limit for LDH with DNS is 253 > (encodes as 255 octets on the wire). Remember URI names do > not have a final period and the each label has length octet > when encoded as a DNS name and the name is terminated by the > root label (0x00) in DNS wire form and the DNS wire name is > limited to 255 octets. Mark, My apologies for nit-picking, but RFC 3986, Section 3.2.2 is quite clear than DNS names in URIs are permitted to have a final period and encouraged to do so under some circumstances. Specifically, "The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." and should be if it is necessary to distinguish between the complete domain name and some local domain." I don't think that changes the 253 octet limit, but the comment about URIs is misleading and could contribute to an, IMO, already high level of confusion about what RFC 3986 does or does not specify. The same subsection of RFC 3986 also uses the term "host subcomponent" for what you are referring to as a name and allows it to be a "registered name" (or ) that might not be a DNS name or reference at all -- whether it is or not is scheme-dependent. best, john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
--On Friday, July 7, 2017 10:42 +1000 Mark Andrews wrote: >> The same subsection of RFC 3986 also uses the term "host >> subcomponent" for what you are referring to as a name and >> allows it to be a "registered name" (or ) that >> might not be a DNS name or reference at all -- whether it is >> or not is scheme-dependent. >... > Which really should never have been allowed. Beyound the UI > everything should be absolute. Relative names in URI really > don't work in practice because search lists are not > constistent even inside a single organisation. Mark, it is no secret that I'm not a fan of relative URIs or of 3986 generally. But the latter is, for better or worse, a full standard that went through the IETF process. If you think it is seriously flawed, I'd encourage you to write in I-D to fix it and see if you can get it through the system. My experience predicts that any attempt to do such a thing will produce an outcry about the astronomical number of web pages that contain and depend on such references and the only slightly smaller number of them that are used every day, but maybe you will do better than I did when I tried to get something with far narrower scope through the system. > I had my ISP hand me a relative link for their support pages. > IT DID NOT WORK. There support line got a call complaining > about it. With the above in mind, so? The number of links most of us see a week that don't work --whether the references are relative or absolute-- is rather too large to view one failure as horrible breakage in the model. john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: getaddrinfo() and searching
--On Friday, 28 September, 2007 09:48 +1000 Mark Andrews
<[EMAIL PROTECTED]> wrote:
>...
>> It's not. Even without IPv6, having search domains means you
>> can get unexpected results. If that's not acceptable, don't
>> complain, but put a period behind your FQDNs.
>
> Please state were in RFC 952 a final period is legal in
> a hostname.
>
> Remember applications take HOSTNAMES not DOMAIN NAMES.
> There are HOSTNAMES that you cannot store in the DNS.
> There are DOMAIN NAMES that are not legal HOSTNAMES.
Mark, your recollection and understanding of history and
vocabulary may be different from mine (and probably is), but I
think you are getting confused by some informal terminology and
risking confusing others even further.
RFC 952 in fact prohibits trailing periods in domain names used
as host names, but 952 is a very early document, superceded by
all sorts of things both formally and informally. I note, for
example, that it has been a rather long time since every
boundary router on the network (a "gateway") had a name ending
in "-GW" or "-GATEWAY". Please don't read sentences of 952 out
of context and consider them binding.
You will not find the "hostname" versus "domain" distinction
made in RFC 1034. 1034 and its conceptual predecessors
discusses the domain name system as a replacement for the
hostname one and even notes (correctly) that different
applications have different syntax rules for names for hosts.
To make the ambiguity worse, when the term "host" or "hostname"
is used in applications in conjunction with the DNS, that term
often refers to the leaf-note label and not to the FQDN. See,
for example, section 3.7 of RFC 821, which describes
"Fred.Cambridge.UK" as a possible "host-and-domain identifier".
However, the familiar "mailbox" is defined as
::= "@"
Note that it is not
"@"
or
"@"
RFC 1034 also seems to believe that all fully-qualified (aka
"absolute") domains names, including those used to refer to
hosts, end in a period, even if that period is typographically
omitted for convenience. Of course, it also contains a
masterwork of apparently-circular definition: "A domain is
identified by a domain name, and consists of that part of the
domain name space that is at or below the domain name which
specifies the domain."
While 1034 suggests that the trailing period is always
permitted, even if it is implied, Section 2.3.1 of 1035 gives a
syntax that doesn't permit them. But it does so without trying
to distinguish between a "host" and a "domain". In particular,
it says that [all of] "The labels must follow the rules for
ARPANET host names", which is ultimately a reference to 952
although 1035 repeats the rule. That rule is applied to all
labels, not just the leaf one or ones identifying hosts.
As an indirect illustration of this, note that 1035 Section 3.5
describes IN-ADDR.ARPA as supporting "host address to host name
mapping". That mapping is to an FQDN, not a label or "hostname"
as you use the term above.
RFC 1123 makes explicit provision for trailing dots in
application interfaces to domain names ("hosts") while noting
that RFC 822 (and 821) do not permit that syntax in the
protocols. Nothing has ever permitted a UI designer, even for a
mail-related program, from accepting the trailing dot as long as
it is removed (and any searching or aliases resolved) before the
name goes out on the wire.
So I believe the distinction you are trying to make is not
historically supported, not particularly helpful, ambiguous, and
probably just plain wrong.
regards,
john
___
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
[DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
--On Thursday, 27 September, 2007 18:45 -0700 Paul Hoffman <[EMAIL PROTECTED]> wrote: > The Security Considerations section for this document is much > too narrow. It ignores one of the main reasons that many > organizations purposely choose to provide recursive lookup to > the public, namely for their own roaming users. Without an > open, known-good nameserver at a fixed address, roaming users > need to trust whatever is given to them by their ISP at the > moment, and it is reasonable for organizations to consider >... Hi. I want to express general agreement with Paul's comment, but also to stress the importance of one of the points he has made... Even if one ignores attacks of the usual sorts (i.e., bad acts conducted out of malice or juvenile behavior) the ISP who plays alternate root, DNS query interception and diversion, and similar games is too large for comfort and probably growing. Paul's explanation of this: > - Some ISPs use DNS servers that purposely do not follow the > same good practices that the organization uses. In particular, > some ISPs have used bogus TLDs and name-lookup services to > generate revenue. covers most of the problem, but it is perhaps also useful to point out that some of these ISPs try to block DNS traffic that is not directed to their preferred servers. For many users and enterprises, the warning implicit in not being able to reach their own servers under those circumstances is an important, and security-enhancing, source of information. Of course, some of those ISPs take the next step and divert all DNS traffic, regardless of specified destination, to their own servers, but the fact that simply making recursive nameservers available doesn't solve it (at least absent well-deployed DNSSEC) doesn't mean that the often-useful "use your own server" approach is useless or should be avoided. > The Security Considerations section needs to deal with these > issues, even if they do not change the advice given in section > 4. Yeah. john ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
--On Thursday, July 03, 2014 12:03 -0700 The IESG
wrote:
> The IESG has received a request from the Applications Area
> Working Group WG (appsawg) to consider the following document:
> - 'A NULL MX Resource Record for Domains that Accept No Mail'
>as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and
> solicits final comments on this action. Please send
> substantive comments to the i...@ietf.org mailing lists by
> 2014-07-17.
Hi. For a number of reasons, many of which have been identified
by others, I find this draft and the actions it recommends
distasteful. 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. I continue to believe that prioritization is
undesirable, at least without fundamentally converting the email
infrastructure to an "acknowledge on delivery because there is
no expectation of successful deliveries" one rather than the
current protocols, which focus on notifications for
non-delivery.That is not a strong technical objection and is
definitely not intended to be an argument against publication if
the IESG concludes that there is community consensus for doing
this, especially since, of the changes that could be motivated
as above, this is one of the more benign.
Hope, it would be better if the specification were historically
accurate and accurate about the protocols it cites.
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
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.
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.
(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.
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."
So. there isn't any "The normal way to send mail for which a
sender wants no responses" -- RFC 5321 and other specs
significantly constrain the cases in which null reverse-paths
may be used. If this specification intends that notifications
that are generated in response to a null MX record, then that
needs to be made an explicit requirement to conform with the
language of RFC 5321.
Some additional observations that suggest this document needs
additional work before approval, probably with an intervening
additional Last Call:
(a) Sloppy DNS terminology has been the source of many problems
(see recent discussions of "dotless domains" in
draft-klensin-dotless-terminology-harmful; "hostname" used to
describe a DNS entry that contains an address RR, a DNS entry
where the owner also owns at least one address RR, and the first
(leftmost) component of an FQDN (with additional ambiguity as to
whether a zone break is implied); and considerable confusion
about terms like "resolver". Whether the IETF steps forward to
try to clean up previous messes or not, it certainly should not
countenance making things worse.
Specifically referring to Section 3 of
draft-ietf-appsawg-nullmx-05, there is not such thing as a "N
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
Hi.
I have a few questions that I don't want to clutter the IETF
list about but about which I would hope DNS experts, especially
DNS root operations experts, would step in if they have
opinions. IESG copied only for the record. I want to stress
that these are questions: I may know enough to ask them but
can't even competently speculate on the answers.
The new specification proposes what is, in essence, a
convention. If an SMTP-Sender (to use the original and very
precise terminology), while doing the required lookup for an MX
RR, encounters
IN MX 0 .
it is expected to abort the message-sending process -- no
further lookups, not connection attempts, no queuing.
At least in the near term, some SMTP Server ("MTA")
implementations will conform to that rule (many already use it)
and some won't. For the latter, they will presumably do what
the SMTP specs say to do. In summary, that is to look up the
address(es) associated with the root and try to open a mail
connection to one of them. When that connection fails
(presumably times out), the SMTP server may decide to try more
(or all) of the other addresses. When all of those it chooses
to try fail, it is then required to queue the message, retrying
the process (potentially to all 13 root servers) at regular
intervals for an extended period of time.
It is impossible for me to estimate the actual likely volume of
such connection attempts. I suggest that any such estimate
would be no better than a wild guess. It is clear that the
requirement for retries and the number of root servers (i.e.,
that there is more than one address record) provides a
multiplier effect on the number of MTAs and misdirected messages
that do not follow the convention.
Given that the DNS configurations for some domains are using
this convention now, it should be possible to measure
present-day SMTP connection attempts to the root servers. I
don't know if anyone has those data. Because such attempts
could originate from multiple causes, it might also be hard to
interpret if it existed... beyond my experience.
So, three (obviously-related) questions:
(1) I understand that there have been concerns from time to time
about the load caused by spurious queries to the root servers.
These would not be spurious DNS queries (I assume primarily UDP)
but spurious TCP connections to a port that I assume no
contemporary root server uses to accept mail. Is that potential
change in load an issue that anyone should be concerned about?
(2) Would you recommend that the root servers take any special
action to mitigate the potential problem? Such action might
involve a port 25 responder that immediately closes connections
(at least reducing timeout waits), or a fake SMTP server that
would allow a connection to be opened, then immediately send a
5yz response to the SMTP sender. If the SMTP specs are followed
by the sender, the latter would prevent attempts on other root
server address and the queuing behavior. Either obviously
involves some additional resources.
(3) Independent of the answer to the question above, does the
possibility of DNS operational impact as the result of this
convention merit comments in the I-D that are not now present
and, if so, what should be said?
Recommendation: if the participants in DNSOP consider either of
the above questions (and they are only questions) to be
significant, it may be worthwhile to ask the IESG to postpone a
decision on this document until this WG has an opportunity to
comment.
The above is obviously independent of the concerns about
terminology that I raised in my Last Call response. As some of
you know, sloppy and ambiguous terminology in discussions of the
DNS has become a pet peeve of mine. If no one else cares, or
cases enough to put effort into the problem -- even to prevent
new ambiguous usage from entering the vocabulary via IETF
standards track documents -- then I will go back to whining into
my beer and stop trying to waste other's time on the issues.
best,
john
___
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
--On Friday, July 18, 2014 23:18 +1000 Mark Andrews
wrote:
>> At least in the near term, some SMTP Server ("MTA")
>> implementations will conform to that rule (many already use
>> it) and some won't. For the latter, they will presumably do
>> what the SMTP specs say to do. In summary, that is to look
>> up the address(es) associated with the root and try to open a
>> mail
>
> No. Lookup the address _at_ _the_ _root_. This is _not_ the
> addresses of the root servers.
I tried to make clear that I'm ignorant of many of the details
here, so, if there is no issue, I apologize for wasting people's
time.
If the answer to those questions is "not an issue", that is the
answer and the end of the discussion.
However, because I'm paranoid, let me mention an issue in
passing without any reason to believe that it is a problem in
practice.
For SMTP (and at least some other applications) there has always
been a question about what to do with DNS queries in mixed IPv4
and IPv6 environments when the application wants to get both
sets of addresses. I vaguely remember an idea about a query
type of "ADDEESS" (or equivalent) that would return both A and
RRs but, as far as I know, it didn't go anywhere. If there
are best practices recommendations for applications writers in
this area, I don't think they have been widely disseminated in
the applications development community. The poor bewildered
application author then has two choices, both of which appear to
be rational. One is to issue two queries, one for A RRs and one
for , and then sort things out in the application. The
other is to issue an ANY query and sort the relevant information
out from it. I at least superficially understand the problems
with the latter and you obviously understand them much better.
But, should an application writer make that choice (and, again,
clear advice has not been broadly disseminated), a query for the
root does get back address records.
It is probably sensible to conclude that the number of
implementations that are that stupid doesn't make the issue
worth worrying about but that should be your conclusion, not
mine, because I am obviously out of my depth here.
john
___
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
--On Friday, July 18, 2014 06:46 -0700 Paul Vixie wrote: >... >> There are no addresses associated with the root, so the mail >> server will immediately report a delivery error. RFC 5321 >> section 5.1 paragraph 2 final sentence. >> >> The SMTP server will not try to connect to the root name >> servers, as your message suggested. > > true as stated. > > what's unstated here is that every SMTP sender who encounters > such an MX without understanding its new meaning will do two > or three lookups: ". MX", [". ",] and ". A". if they are > behind an RDNS that doesn't do negative caching (and there are > many, though none of them are open source; the open source > RDNS servers do negative caching right) then these two or > three queries will flow through to the authority servers for > "." which is to say the root name servers. Paul, Thanks. I obviously got the question wrong but, if it accidentally called attention to an issue that deserves even minimal consideration, I don't mind looking and feeling stupid. I obviously knew about the multiple queries but, by thinking about this from an SMTP context, was more concerned about the connection and queuing part of the problem. FWIW, many SMTP servers will deal with a negative answer from a DNS query by queuing the message (for the historical reason that a DNS change might not yet have caught up with the server queried). While the port 25 issue that I incorrectly focused on will not arise, the two or three queries you mention might, depending on the behavior of the resolver on which that SMTP server calls, be repeated at each queue retry interval. Again, I'm not competent to evaluate whether that is an issue or not. thanks again, john p.s. Just one or two lookups against the root. The sequence would be an MX lookup for the putative mail delivery domain (which should not affect the root servers), then ". A" and, optionally, ". ", in either order. While some implementations have historically done it, SMTP (at least as of RFC 5321) forbids doing an MX lookup on the information obtained from the DATA of a prior MX query. ___ 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
(copying John Levine given his recent summary on the IETF list as well as his co-author role) --On Friday, July 18, 2014 10:36 -0400 Olafur Gudmundsson wrote: >> If this is a worry for the root server operators (but I >> thought they had said in the past that it doesn't pose a >> problem) then the draft could specify a canonical >> address-less domain lower down the hierarchy, e.g. >> empty.as112.arpa (making use of the AS112 DNAME proposal). >... > Many years ago Joe Abley and I suggested to create a special > name for exactly this purpose a name that was guaranteed to > never exist in the DNS thus the first lookup would always > return NXDOMAIN thus the A+ lookups would never take > place. http://tools.ietf.org/html/draft-jabley-sink-arpa-03 One more general observation and then I'm going to stop and leave this part of the issue to you folks. I believe there is fairly general (if still a bit "rough") consensus in the email community that having some clear, DNS-based, way for a system to indicate that it does not accept email.Long ago, there was some hope that WKS records would solve that problem (and others like it), but we know how that worked out. Today's problem, IMO, is that, while there is little debate about "DNS-based solution", or even "DNS-based solution involving something special in the relevant MX record", I haven't seen a careful analysis by DBS experts on which of several DNS approaches have the least bad operational properties. If a particular SMTP implementation is aware of and follows the spec, almost any consensus indicator that doesn't conflict with other things should be fine -- ".", "***", a special name in example.com or example.net, the proposal above, or something else, because there will be a string compare within the SMTP server and no lookups will be done. Since SMTP prohibits non-ASCII domain names, one might even consider something Like "фиктивный.example.com" or "虚假.example.com" (literally, not as IDNA A-labels) which would cause many SMTP servers to do something nasty that does not involve the DNS. DATA containing "." has the advantage of already being deployed, so anything else has to offer enough marginal value to overcome the assumptions that go with existing practice. But, modulo that issue, I don't think the SMTP community really cares what the string is as long as there is a string and a mechanism (Tony and others have said as much). The only issue that is, IMO, really important is with side-effects or damage caused by SMTP implementations that do not know about the convention or conform to the spec. They will certainly do lookups; how far they will get and whether they will requeue and try again depends somewhat on the string chosen and, modulo the observation about non-ASCII bogus strings, that is your area of expertise and not mine (or that of the AppsAWG). Given that the IETF used to pride itself on the application and quality of cross-area review, I think it is desirable and appropriate that the DNS community generally, and DNSOP in particular, weigh in on the string. I'd be happiest, and I'm confident that John L would be too, if the answer was any of * Just fine, "." is no problem * Ok, "." isn't likely to cause enough of an incremental problem to be worth worrying about. * We really wish you had asked ten years ago, but don't see "." as causing enough of an incremental problem to be worth the difficulties associated with getting existing implementations to change their ways. But, again in the spirit of cross-area review, I'd really like it --and, as someone who periodically plays email expert on television, be a lot more comfortable-- if DNSOP had enough of a discussion to advise on this. I would hope that, if the advice were "use a different string, preferable , because..." the IESG and the advocates of "no mail received here" indicator MXs would pay careful attention. And I'd like to see the spec reflect the analysis, if only in an appendix, which may require someone on the DNSOP list to help John L with text. But that is, as always, secondary to getting the spec, protocol, and operational issues right. john ___ 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
--On Friday, July 18, 2014 14:59 -0400 John R Levine wrote: >> Today's problem, IMO, is that, while there is little debate >> about "DNS-based solution", or even "DNS-based solution >> involving something special in the relevant MX record", I >> haven't seen a careful analysis by DNS experts on which of >> several DNS approaches have the least bad operational >> properties. > > But, John, this is the one that's implemented in many popular > MTAs, has been in daily use for the better part of a decade, > and has no observed issues at all that I ever heard of. No > doubt it sends some traffic to the root servers, but have any > root server surveys ever even mentioned A or query > traffic to "." ? If you head read all of my note, you would have noticed that I expressed a strong preference for staying with "MX ." unless there were compelling reasons for doing something else. "Compelling" is a pretty high bar, but I think we need to ask and then listen. Also see below. As to "no observed issues" and indications of support in the many popular MTAs you have cited elsewhere, I think counting SMTP implementations is essentially bogus for reasons discussed (and claims made) in another thread on the IETF list. For those with the patience for the analysis, see [1] below. More relevant, I think, is that the deployment scale for this convention has nothing to do with how many SMTP servers implement it -- whether they do by string matching (also see below) or by giving a "just stop here" interpretation to certain types of DNS responses to lookup of MS DATA field contents. If no one created an "MX ." entry, then the number or types of servers who were prepared to deal with one in a special way would be completely irrelevant and the number of queries to the root would be zero. Now we both know that there are a bunch of "MX ." records out there. I assume the number is not very large compared to the total number of nodes in the DNS that own address records or even that number less the number of nodes who have MX records that point to SMTP servers. But the load on the root as the result of this convention (whether "approved" by the IETF or not) is, unless my brain is completely not working today, dependent on how often such records are encountered less the number of systems that trap the "." convention locally. If the reason for asking for IETF approval is to encourage more nodes to be associated with these records (otherwise, you presumably wouldn't be looking for standards track) then more "MX ." entries are likely to result in more DNS queries -- how many more is, I believe, anyone's guess although I discuss some parameters below. Part of the issue here is an SMTP subtlety (or perhaps an RFC 5321 glitch). Your spec says (Section 3) "The DNS root is not a valid host name, so a NULL MX record can not be confused with an ordinary MX record." That is clearly true. But, while an SMTP implementation could invoke the "operational necessity" provision of 5321 and make a string comparison check rather than sending a query to the root, SMTP does not require that the DATA associated with an MX record pass SMTP tests of "valid host name" (in SMTP a rather restrictive bit of local syntax); it basically requires that whatever is out there be looked up, with validity (getting back an address record) depending on what the DNS has to say (see 5321 Section 5.1) So, again with the stipulation that I may still not fully understand the issues here, I'd look, not at numbers of SMTP server implementations, or even the amount of traffic they might carry, but the number of MX RRs with "." in the DATA. I'd assume that number would grow significantly and asymptotically after this specification is approved and more operators install the records and then with the growth in the Internet (or the DNS). The actual number of queries would depend on the subset of those nodes that were hit, either intentionally or by mistake. I don't think we have any way to estimate that. In any event, if one believes in Internet growth and that "don't send me mail" MX records are a good idea, there will be a lot more of them in the future, maybe enough to justify a change now if one is otherwise appropriate (or maybe not). My apologies for not thinking of it sooner but, if I were worried about DNS root server impacts (email messaging with mistakes about domains may be such a small percentage of traffic to not count) or even unnecessary DNS traffic minimization more generally, I'd recommend that this new specification explicitly update Section 5.1 of RFC 5321 to require that DNS servers make a string-comparison test against "." (or whatever the string turns out to be) and stop if it is found rather than doing DNS lookups on whatever is in the data field. As an alternative, 5321 could be updated to require checking the contents of MX DATA against the SMTP mailbox domain rules. Neither would affect anything that exists today that is reasonable
Re: [DNSOP] Last Call: (A NULL MX Resource Record for Domains that Accept No Mail) to Proposed Standard
--On Friday, July 18, 2014 20:39 +0100 Tony Finch wrote: > John C Klensin wrote: >> >> If a particular SMTP implementation is aware of and follows >> the spec, almost any consensus indicator that doesn't >> conflict with other things should be fine -- > > There are actually more constraints than you imply in your > message. Yes, almost certainly. >> "." > > Has the advantage of being implemented and deployed. Has the > disadvantage of directing useless queries to the root name > servers from MTAs that do not understand null MX records. > >> "***" > > MX target names should obey the LDH host name rules. I completely agree, but SMTP imposes no such requirement. > You won't > be able to enter this target into many DNS admin tools since > they enforce LDH syntax. Some nameservers (e.g. BIND) will by > default refuse to load a zone with a non-hostname MX target. Does that imply that this spec should contain a warning that loading one of these "null MX" records may require a configuration change in one's nameserver? Just asking. > This loses the advantages of a "." target and fails to keep > useless queries away from the root name servers. > >> a special name in example.com or example.net, > > These domains are reserved for use in examples, not for > production purposes. Are their name servers scaled up enough > to handle stray queries from MTAs that don't understand null > MX records? Yep. Sorry for not selecting a better example, but I hope the point was clear. > This question applies to any non-"." target. The reason I > suggested using AS112 was because it is designed for sinking > unwanted queries that should not have leaked out in the first > place. But I still prefer to stick with ".". Ok, thanks for clarifying. >> Since SMTP prohibits non-ASCII domain names, one might even >> consider something Like "фиктивный.example.com" or >> "虚假.example.com" (literally, not as IDNA A-labels) which >> would cause many SMTP servers to do something nasty that does >> not involve the DNS. > You are muddling up the IDNA layers here. The MX target comes > from the DNS so if you try to put an IDNA name there it has to > be encoded as an A-label before you put it in the DNS. If you > try hard you can put un-encoded UTF-8 in the DNS, but then it > would violate the hostname rules in a similar way to "***". I'm actually not... and sorry if I wasn't clear. Because SMTP doesn't impose any restrictions on what it can pick up from MX DATA (presumably the only limits are those imposed by 2181) and knows nothing about IDNA, un-encoded UTF-8 (or, for that matter, un-encoded UTF16 or something else as long as it is within the 64 byte label limit, is just meaningless trash -- far further up the "trash" scale than "**". If an implementation chooses to apply host name checks (or SMTP mailbox domain name validity checks) that seems wise to me, but goes beyond what SMTP requires. > It is likely that there are MTAs which do not check that MX > targets actually obey hostname syntax, so this kind of hack is > not going to reliably suppress lookups. Exactly. They are different examples of guaranteed bogus strings; they don't help a bit with the query problem. If we really want help with the query problem, we need to update SMTP (see previous over-long note to DNSOP, which I'll forward to you under separate cover. >> They will certainly do lookups; how far they will get and >> whether they will requeue and try again depends somewhat on >> the string chosen > > I think it depends more on the MTA's and/or postmaster's > attitude to DNS misconfiguration. Some are quicker to permfail > than others. Yep, And that is independent of whether we agree about what constitutes "DNS misconfiguration". Had you said "misconfiguration, abuse, or stupidity", we'd probably agree. :-) john ___ 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
(Warning to DNSOP and IESG -- this response is going to descend quickly into SMTP esoterica and is probably safe to ignore from a DNS perspective) --On Friday, July 18, 2014 22:39 +0100 Tony Finch wrote: > John C Klensin wrote: > >> > MX target names should obey the LDH host name rules. >> >> I completely agree, but SMTP imposes no such requirement. > > RFC 974 specifies that the target of an MX record is a host > name. And so? RFC 2821 obsoleted 974. As far as I can tell, it says nothing at all about the DATA field in an MX record, leaving pulling that information out and looking it up in the DNS to be inferred from context and a parenthetical comment "(perhaps taken from the preferred MX record)". It does use the term "host addresses" and "destination host", but in a too-informal context to assume that people would infer "host name" (aside: whatever that means) in the DNS sense. After 14+ years, I no longer remember and cannot reconstruct whether that was a DRUMS screwup or mine although the WG is ultimately responsible for not reviewing carefully enough. When RFC 5321 was done, we obviously knew there was a problem with the 2821 text because its text improves on the situation. The pre-5321 change log doesn't say much that sheds light on the change, other than saying that the description of MX handing was changed in -10 (one of several post-Last-Call versions). The relevant section is more clear and it does explicitly say "the data field of that response MUST contain a domain name. That domain name, when queried, MUST return at least one address record (e.g., A or RR)". But that is it: "domain name". One can read that as an invocation of the discussion in Section 2.3.5 but that isn't the only possible reading. The section invokes 1035 and "a sequence of letters, digits, and hyphens drawn from the ASCII character set." The following sentence reads "Domain names are used as names of hosts and of other entities in the domain name hierarchy." so, while 2.3.5 (if one believes that the text in 5.1 invokes it) requires LDH, it does not require a "host name".If one doesn't believe that 2.3,5 is invoked, then a domain name is presumably just an FQDN conforming to 1034/1035 as interpreted by 2181). There is, fwiw, some additional test in 2.3.5 that further muddies the waters. That is definitely not a good example of clarity or precision. Mea culpa, with or without comments about quality of review. I have tightened things up in the 5321bis editing copy (yes, there is such a thing). >... >> Does that imply that this spec should contain a warning that >> loading one of these "null MX" records may require a >> configuration change in one's nameserver? > > No, because "." doesn't violate LDH syntax. (What admin GUIs > do is another matter...) Those admin GUIs or text input converters were what I was concerned about (should have said "nameserver configuration interface" or words to that effect). Your call (and John L.'s). john ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
