Subject: [dhcwg] 2nd Last Call for MIF DNS server selection document

From: Hui Deng <[email-masked]>
Date: Fri, 30 Sep 2011 23:29:18 +0800

Dear all
 
Based on 1st round WG LC, the authors have received significant advice about revision and submited a new version accordingly:
http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt
 
And we plan to issue a second round WG LC, and cc to DHCWG, DNSEXT, DNSOP related working groups, please DNSEXT/DNSOP chairs help to forward to the MLs since I may not subscribe to them.
 
This is a 2 weeks with little extension LC, it will finish on October 17,
Please send substantive review and editorial comments to [email-masked]
 
Thanks a lot for youre view
Best regards,
 
Margaret and Hui

Below are Teemu's writeup about the revision:
 
I uploaded -05 update so that next comments would take into account changes
I already did based on discussions with Murray (as was copied to this list).
The biggest clarifications related to how DNS queries are sent to different
servers and when all servers are waited for answers (if reply is not
validated) and when not. I.e. this text:
--
  A node SHALL send requests to DNS servers in the order defined by the
  priority list until an acceptable reply is received, all replies are
  received, or a time out occurs.  In the case of a requested name
  matching to a specific domain or network rule accepted from any
  interface, a DNSSEC-aware resolver MUST NOT proceed with a reply that
  cannot be validated using DNSSEC until all DNS servers on the
  priority list have been contacted or timed out.  This protects
  against possible redirection attacks.  In the case of the requested
  name not matching to any specific domain or network, first received
  response from any DNS server MAY be considered acceptable.  A DNSSEC-
  aware node MAY always contact all DNS server in an attempt to receive
  a response that can be validated, but contacting all DNS servers is
  not mandated for the default case as in some deployments that would
  consume excess resources.
--
       Teemu
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> ext [email-masked]
> Sent: 20. syyskuuta 2011 22:10
> To: [email-masked]
> Cc: [email-masked]
> Subject: [mif] I-D Action: draft-ietf-mif-dns-server-selection-05.txt
- 显示引用文字 -
>
> A New Internet-Draft is available from the on-line Internet-Drafts
directories.
> This draft is a work item of the Multiple Interfaces Working Group of the
> IETF.
>
>       Title           : Improved DNS Server Selection for Multi-Interfaced
> Nodes
>       Author(s)       : Teemu Savolainen
>                           Jun-ya Kato
>                           Ted Lemon
>       Filename        : draft-ietf-mif-dns-server-selection-05.txt
>       Pages           : 26
>       Date            : 2011-09-20
>
>    A multi-interfaced node is connected to multiple networks, some of
>    which may be utilizing private DNS namespaces.  A node commonly
>    receives DNS server configuration information from all connected
>    networks.  Some of the DNS servers may have information about
>    namespaces other servers do not have.  When a multi-interfaced node
>    needs to utilize DNS, the node has to choose which of the servers to
>    contact to.  This document describes DHCPv4 and DHCPv6 option that
>    can be used to configure nodes with information required to perform
>    informed DNS server selection decisions.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.txt

---

From: <[email-masked]>
Date: Wed, 19 Oct 2011 06:42:46 +0000

Hi all,

This second WGLC resulted in very few comments. In the DHC WG we discussed
about DHCPv4 option structure and in MIF there was a comment about
document-internal reference bug.

I have now uploaded a version six that contains:

-          Fixes to the DHCPv4 option structure

-          Highlighting stricter length limitation in case of DHCPv4 option

-          Fix to the reference bug

-          Small fixes to missing DHCPv4 considerations in sections 4.5 and
4.6.

Please see diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-mif-dns-server-selection-06

If no further comments, I think this document is ready to go to the IESG.

Thank you,

                Teemu

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext
Hui Deng
Sent: 30. syyskuuta 2011 18:29
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [mif] 2nd Last Call for MIF DNS server selection document

Dear all
 
Based on 1st round WG LC, the authors have received significant advice about
revision and submited a new version accordingly:
http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.t
xt
 
And we plan to issue a second round WG LC, and cc to DHCWG, DNSEXT, DNSOP
related working groups, please DNSEXT/DNSOP chairs help to forward to the
MLs since I may not subscribe to them.

 
Margaret and Hui

 
- 显示引用文字 -
directories.
>       Filename        : draft-ietf-mif-dns-server-selection-0 5.txt
>       Pages           : 26
>       Date            : 2011-09-20
>
>    can be used to configure nodes with inform ation required to perform
http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-05.t
xt

---

From: Ray Bellis <[email-masked]>
Date: Wed, 19 Oct 2011 10:39:59 +0000

On 19 Oct 2011, at 07:42, <[email-masked]>
 <[email-masked]> wrote:

> Hi all,
>  
> This second WGLC resulted in very few comments. In the DHC WG we discussed about DHCPv4 option structure and in MIF there was a comment about document-internal reference bug.
>  
> -          Small fixes to missing DHCPv4 considerations in sections 4.5 and 4.6.
>  
> Please see diff: http://tools.ietf.org/rfcdiff?url2=draft-ietf-mif-dns-server-selection-06

Apologies for the late comment - I have been tied up with my own WG and been off sick too.

I have concerns about §4.6:

"A bare name (a name without any dots) MUST be first treated as a pre-
 DNS hostname, and only after that the name SHALL be appended with
 domain information and described DNS server selection logic be
 utilized."

When new gTLDs are introduced it is likely for brand-name gTLDs that they will wish to use bare names in the DNS (i.e. a single label hostname) for their primary web sites.

Hence bare names may become much more frequently used as DNS names, and §4.6 wouldn't permit those to work unless '.' is also in the suffix list.

My own view is that DNS search suffixes should be deprecated and that they cause more harm than good.

A related issue is that they encourage the sharing of abbreviated URLs that don't work when the recipient is not using the right search suffix, perhaps because they're off site.  Some of my colleagues often share documents on our intranet by sending around links like <http://intranet/path>.  If I'm off site not only will that not work, but it could result in a connection to the wrong server and a potential leakage of credentials.

I've discussed these issues with search suffixes with various other DNS folk and not heard any disagreement.

See also <http://www.circleid.com/posts/20110620_domain_names_without_dots/> from Vixie for some informed commentary on this issue.

I'd like to hear the authors' thoughts on these.  I'm not sure that this draft necessarily needs any significant changes - it may only require changes to ensure that bare names are also considered as potential DNS names in their own right.

I'm also considering taking up Vixie's challenge and writing up a draft to formally deprecate search suffixes.

kind regards,

Ray

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Oct 2011 07:23:15 -0400

> When new gTLDs are introduced it is likely for brand-name gTLDs that they will wish to use bare names in the DNS (i.e. a single label hostname) for their primary web sites.

I don't see why IETF should give a flying *#&(*#$ what the owners of brand-name gTLDs want.   Brand-name gTLDs are an exceedingly stupid idea, and treating single label names as anything other than local abbreviations flies in the face of 25+ years of practice.   

The best thing that IETF could do is to make sure that use of single-label gTLDs is so unreliable that no megacorporation would dare use them.

Keith

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 19 Oct 2011 09:26:34 -0400

Note: I trimmed the cc:s down to just the lists, but if we're going to
pursue this dicussion we probably ought to follow up in mif, since
that's where the draft comes from.  That's why I set reply-to.  Also,
I sent this first from the wrong address, so apologies to those who
see it twice.

On Wed, Oct 19, 2011 at 07:23:15AM -0400, Keith Moore wrote:

> I don't see why IETF should give a flying *#&(*#$ what the owners of
> brand-name gTLDs want.  Brand-name gTLDs are an exceedingly stupid
> idea, and treating single label names as anything other than local
> abbreviations flies in the face of 25+ years of practice.

If you said, "25+ years of practice illustrating how broken the
search-path mechanism is," I'd agree with you.

I think it is largely true that single-label domain names are going to
fail to work in all sorts of amusing ways that will surprise gullible
people who forked over a pile of cash for the privilege of registering
them.  Nevertheless, the search path mechanism has never worked very
well and is notoriously unreliable in the face of split-brain DNS.
Still, too many people continue to rely on the search path for this
document to be the place to deprecate it.  But I agree with Ray (and
apparently Paul Vixie) that the mechanism ought to go away.

Now that Ray has mentioned it, however, perhaps a sentence along these
lines in the second paragraph of 4.6 would be useful:

    It should be noted that the DNS search list mechanism may cause
    surprising results when used with more than one network at a time.

That addresses the other point that Ray was making: search list-style
bare names are often broken if you're not on the right network, and
the point of this draft is precisely that you're _not_ on only one
network, so it isn't clear what "the right network" is.

> The best thing that IETF could do is to make sure that use of
> single-label gTLDs is so unreliable that no megacorporation would
> dare use them.

And clearly that will work, because the IETF has a long record of
success of standing before the tide and telling it to stop.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 19 Oct 2011 09:48:23 -0400

> search-path mechanism is," I'd agree with you.

I agree that search paths are somewhat broken.   What's not broken is the idea of using single-label names as local names.  

> well and is notoriously unreliable in the face of split-brain DNS.

split-brain DNS is an abomination that should be eradicated from the planet.

> apparently Paul Vixie) that the mechanism ought to go away.

I don't think it should necessarily go away.  But perhaps it needs to be better defined, and/or more advice needs to be given to applications about how to deal with single-label names.

> network, so it isn't clear what "the right network" is.

and sometimes, single-label names are set up to work correctly on multiple networks - the salient point being that the meaning of the name might be inherently context-sensitive.

> success of standing before the tide and telling it to stop.

this isn't a tide.  this is a small number of parties bent on abuse of the Internet.  they deserve to fail.

Keith

---

From: Matthew Ryan <[email-masked]>
Date: Wed, 19 Oct 2011 08:44:59 -0700

Reading through the diff made me realize that the format
I suggested for the DHCPv4 option has a problem with it -
fortunately, easily fixed.  There is also potential confusion
with the naming chosen for the domains-and-networks length
octet.

  The domains-and-networks length octet, which is now called
'Payload length' is defined to be the length of only the
domains-and-networks field.  I think, given the name, combined
with the position in the option, people may incorrectly
interpret it as including the length of the DNS server IP
addresses.

  I believe the octet should be moved to just before the
domains-and-networks field.  This will not only make it
abundantly clear that it only covers the length of that
field, but also make it easier to parse.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     CODE      |     Len       | Reserved  |prf|  Primary DNS  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Primary DNS cont. (IPv4 address)           | Secondary DNS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Secondary DNS cont. (IPv4 address)          |  Payload len  |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                          Domains and networks                 |
|                          (variable length)                    |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  The other option would be to leave the payload-length octet
where it is and redefine it to include the DNS server IP addresses,
but the reduces the possible number and length of domains that
can be included.

  In either case, it's a bad idea to have something of the form
<length> <something> <value>, where <length> only covers <value>.
I should've caught that before suggesting the format, but it
completely slipped my mind - my apologies.

 - Matt

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Oct 2011 16:06:42 +0000

The DHCP changes look good.  You can get multiple selection tuples in DHCPv4 if you want, but you seem to have decided its not important, which is fine by me.   Let me know if you want me to explain how to do that.

However, I reread the text on server selection, and it still has a serious and easily exploited security flaw.   In order for DNSSEC validation to save you from an attack, it has to be the case that you look the name up on every possible name server to see if any claim it's in a signed zone.   If one does, it has to be validated.   Right now it looks like if the "trusted" server doesn't sign the zone, the DNSSEC validation will never happen.   We dealt with this by trusting some networks more than others, and that eliminates a lot of the risk.

For example, in the case of a hotel net we're okay, because it will be less trusted than the 3G network.   The case I am most concerned with is when you VPN to a site that is not trusted: the default behavior will be to prefer the VPN link, because we presume it is more trustworthy.  A consultant who VPNs to multiple corporate sites could be spoofed here though, as could a user of a firewall bypass VPN.

Unfortunately, I don't know of a way to fix this that doesn't fire up both radios for every query.   Leaving this off by default is probably the best we can do, but it might be good to add more text to the security considerations section describing specific exploit scenarios.   The text in 10.1 and 10.2 doesn't address this particular attack vector.

I would propose adding a requirement that there be a mode, off by default, enabled by UI, in which the resolver just fires up both radios, battery be damned, but I am not sure anyone would use it, because it would be difficult to explain why and when they should.

So practically speaking, I am just proposing a tweak to the security considerations.   I will send text if you don't object.   Sorry for the late review.

---

From: Margaret Wasserman <[email-masked]>
Date: Wed, 19 Oct 2011 12:07:27 -0400

Hi Keith,

> split-brain DNS is an abomination that should be eradicated from the planet.

Split DNS exists and is in wide-spread use, and that is just a fact.  We don't have the power to eradicate it, nor do we currently have a better solution for the types of things that people use split DNS for.

Margaret

---

From: <[email-masked]>
Date: Wed, 19 Oct 2011 17:43:03 +0000

> From: ext Matthew Ryan [mailto:[email-masked]]
> Sent: 19. lokakuuta 2011 18:45
> To: Savolainen Teemu (Nokia-CTO/Tampere)
> Cc: dhc WG
> Subject: Re: [dhcwg] [mif] 2nd Last Call for MIF DNS server selection
> document
> 
>   Reading through the diff made me realize that the format I suggested for
> the DHCPv4 option has a problem with it - fortunately, easily fixed.
There is
> also potential confusion with the naming chosen for the domains-and-
> networks length octet.
> 
>   The domains-and-networks length octet, which is now called 'Payload
> length' is defined to be the length of only the domains-and-networks
field.  I
> think, given the name, combined with the position in the option, people
may
> incorrectly interpret it as including the length of the DNS server IP
addresses.
> 
>   I believe the octet should be moved to just before the domains-and-
> networks field.  This will not only make it abundantly clear that it only
covers
> the length of that field, but also make it easier to parse.
> 
>  0                   1                   2                   3

The problem with this is that it would take DNS server IPv4 addresses out of
the 32-bit boundary, which does not look very nice and can cause
implementation issues as well (there are OSes/CPUs where 32 bit values must
locate at 32bit boundaries in memory, otherwise they have to be moved/copied
per-byte).

>   The other option would be to leave the payload-length octet where it is
and
> redefine it to include the DNS server IP addresses, but the reduces the
> possible number and length of domains that can be included.

I like this one - the option length is anyway dictated by the "Len" field's
one byte limitation, right? So we can as well define this "payload len" to
include DNS server IP addresses and reserved+prf. But in that case it would
be almost the same as "Len" field (1 byte difference), so what do we need
the "payload len" again?-)

Best regards,

	Teemu

---

From: <[email-masked]>
Date: Wed, 19 Oct 2011 17:58:39 +0000

Ted, thank you for comments. 

Please feel free to propose text - I love constructive text proposals:-)
During following week would be nice, if possible, so that we can move
forward with the draft before the next IETF.

Now that you say it, we might state that not any VPN can be trusted by
default (but VPN is an example here), but e.g. a VPN Configuration Profile
could enable the setting for that particular VPN connection. If the trusted
VPN then **cks you up, then, well, trusted parties sometimes do that..

Best regards,

	Teemu

> From: ext Ted Lemon [mailto:[email-masked]]
> Sent: 19. lokakuuta 2011 19:07
> Cc: Hui Deng; <[email-masked]>; dnsext List; [email-masked] WG; DHC WG;
> [email-masked]; [email-masked]
> The DHCP changes look good.  You can get multiple selection tuples in
> DHCPv4 if you want, but you seem to have decided its not important, which
> is fine by me.   Let me know if you want me to explain how to do that.
> 
> However, I reread the text on server selection, and it still has a serious
and
> easily exploited security flaw.   In order for DNSSEC validation to save
you
> from an attack, it has to be the case that you look the name up on every
> possible name server to see if any claim it's in a signed zone.   If one
does, it
> has to be validated.   Right now it looks like if the "trusted" server
doesn't
> sign the zone, the DNSSEC validation will never happen.   We dealt with
this
> by trusting some networks more than others, and that eliminates a lot of
the
> risk.
> 
> For example, in the case of a hotel net we're okay, because it will be
less
> trusted than the 3G network.   The case I am most concerned with is when
> you VPN to a site that is not trusted: the default behavior will be to
prefer
> the VPN link, because we presume it is more trustworthy.  A consultant who
> VPNs to multiple corporate sites could be spoofed here though, as could a
> user of a firewall bypass VPN.
> 
> Unfortunately, I don't know of a way to fix this that doesn't fire up both
> radios for every query.   Leaving this off by default is probably the best
we
> can do, but it might be good to add more text to the security
considerations
> section describing specific exploit scenarios.   The text in 10.1 and 10.2
> doesn't address this particular attack vector.
> 
> I would propose adding a requirement that there be a mode, off by default,
> enabled by UI, in which the resolver just fires up both radios, battery be
> damned, but I am not sure anyone would use it, because it would be
difficult
> to explain why and when they should.
> 
> So practically speaking, I am just proposing a tweak to the security
> considerations.   I will send text if you don't object.   Sorry for the
late
> review.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 19 Oct 2011 14:34:16 -0400

I'm not sure where it would belong, exactly, but certainly between
"best practices" and DNSSEC security concerns, is the basic tenet:

The DNS is a unified namespace.

This leads to a number of potential issues, which can largely be
addressed by viewing the issues from the perspective of a unified
name-space's root. And by providing lots of literal and explicit
examples.

E.g.:
- It is recommended that use of private namespaces be restricted to
subdomains of legitimately-assigned domains by the domain owner
exclusively (e.g. ".private.example.com." and NOT ".private.")
- It is recommended that unofficial namespaces be avoided where
practical to do so (e.g. .local, .fake-domain, .TBD)
- It is recommended that any and all domain names be anchored with a
trailing "." when expressed in text form, regardless of scope
(global/private, bare TLD or otherwise) to remove any possible
ambiguity (e.g. ".example.com.", NOT ".example.com" which might
suggest use of search lists)
- It is recommended that inconsistent or conflicting namespace or
contents be avoided (e.g. split DNS with same labels having different
RVALUEs) (possibly handled by non-anchored names and search lists,
which result in unambigous names upon expansion)
- It is recommended that handling of restricting access to "private"
namespaces be handled in a manner that does not induce look-up
failures if the "wrong" nameserver is consulted first (e.g. ISP/global
before VPN/private, have ".private.example.com." return something
OTHER than NXDOMAIN, e.g. servfail or whatever anyone smarter than me
suggests)
- It is recommended that configured Trust Anchors (for private
namespaces) and "learned" Trust Anchors (KSK or ZSK of securely
delegated zones) be handled in a manner compatible with any usage of
split DNS (so that signature validation is deterministic)
- It is recommended that private namespaces underneath secure global
namespaces be DNSSEC-protected with either a global learned Trust
Anchor, or a configured Trust Anchor
- It is recommended that private namespaces be DNSSEC-protected where
practical to do so

The above is just off the top of my head as possible text that could
be used. Comments on style, content, etc., are more than welcome.

Brian

On Wed, Oct 19, 2011 at 1:58 PM,  <[email-masked]> wrote:
> _______________________________________________
> dnsext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
>
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Oct 2011 19:07:25 +0000

On Oct 19, 2011, at 1:43 PM, <[email-masked]<mailto:[email-masked]>>
 <[email-masked]<mailto:[email-masked]>> wrote:
The problem with this is that it would take DNS server IPv4 addresses out of
the 32-bit boundary, which does not look very nice and can cause
implementation issues as well (there are OSes/CPUs where 32 bit values must
locate at 32bit boundaries in memory, otherwise they have to be moved/copied
per-byte).

DHCP options are never aligned, and must be copied, so this is a non-issue.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Oct 2011 19:08:58 +0000

On Oct 19, 2011, at 1:58 PM, <[email-masked]<mailto:[email-masked]>>

I suppose requiring the user to explicitly mark the VPN trusted would help.

---

From: Matthew Ryan <[email-masked]>
Date: Wed, 19 Oct 2011 13:38:13 -0700

> locate at 32bit boundaries in memory, otherwise they have to be moved/copied

Except you are already subject to that issue, since there is no
guarantee that the start of the option will be aligned on
any particular 16 or 32 bit boundary.  An option that appears
before this option may cause it to be non-aligned.  Implementations
of DHCP can't require options or their contents to have a given
alignment.

> the "payload len" again?-)

Option concatenation - since you want the ability (to match the DHCPv6
version) of being able to specify multiple redirections, e.g., having
foo.com go to 1.1.1.1/1.1.1.2, and bar.com go to 2.2.2.1/2.2.2.2.

And now I realize that aspect was lost somewhere along the way.  From
an earlier mail in the discussion (modified to correct the position of
the payload length octet, and stealing verbiage from prior RFCs), the
actual option format should be:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  option-code  |   option-len  |   dssd-list (var. length) ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  option-code:   (TBD)

  option-len:    Length of the option in octets

  dssd-list:     One or more instances of DNS Server Selection Data,
                 defined below.

  Each instance of DNS Server Selection Data is formatted as follows:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Reserved  |prf|         Primary DNS (IPv4 address)            |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Pri DNS cont. |        Secondary DNS (IPv4 address)           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Sec DNS cont. |  Payload len  |                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
  |                                                               |
  |                          Domains and networks                 |
  |                          (variable length)                    |
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The following paragraph in section 4.3 should be removed:
   The OPTION_DNS_SERVER_SELECT contains one or more domains the related
   primary and secondary DNS servers have particular knowledge of.  The
   option can occur only once in a single DHCPv4 message and is limited
   in length.  The maximum length in octets for the domains and networks
   field is 245 octets.

and replaced with:
   The DHCPv4 long-options mechanism described in [RFC 3396] MUST be
   used if the option exceeds the maximum DHCPv4 option size of 255
   octets.

The bit about DNS servers having knowledge about related domains
is already covered in the description of the "Domains and networks"
field.

And finally, in Section 6, you should change:
   The size limitation is stricter in the case of DHCPv4  where only
   one option instance is possible with maximum of 245 octets for
   domains and networks list.  In the case of DHCPv6 the restriction
   is not as strict.
to something like:
   This is especially true for DHCPv4, where the maximum DHCP packet
   size may be as low as 576 octets.
   
 - Matt

---

From: <[email-masked]>
Date: Wed, 19 Oct 2011 21:03:18 +0000

No, we decided against suboptions and concatenation as well - to just have single option and strictly limit the lenght of the domains-field. If I recall correctly, it was due DHCPv4 relays in some cases limiting the available DHCPv4 message size.. That's why the latest version is changed in so many locations related to this issue.

Ok on alignment issue.

Could we then remove the second length field and hence gain one additional byte for domains variable lenght field?

--
Sent from my Nokia N9

On 19.10.2011 23:38 ext Matthew Ryan wrote:

0 1 2 3

option-code: (TBD)

0 1 2 3

and replaced with:

- Matt

---

From: Matthew Ryan <[email-masked]>
Date: Wed, 19 Oct 2011 15:45:28 -0700

> Could we then remove the second length field and hence gain one additional byte for domains variable lenght field?

That seems strange to me, since the DHPCv6 version is able
to specify multiple redirections.  It's beyond the scope of
DHCP, so I can only assume that the other WG(s) decided
the feature wasn't necessary for IPv4 networks, but is
still necessary for IPv6 networks.

If that is indeed the case, then yes, you can just remove the
payload length octet from section 4.3 in draft -06.

 - Matt

---

From: Mark Andrews <[email-masked]>
Date: Thu, 20 Oct 2011 11:06:05 +1100

In message <[email-masked]>, Margaret Wass
erman writes:
> Split DNS exists and is in wide-spread use, and that is just a fact.  We don'
> t have the power to eradicate it, nor do we currently have a better solution 
> for the types of things that people use split DNS for.
> 
> Margaret

That said there is little technical need for split brain with IPv6
only networks.  IPv4 networks and RFC 1918 addresses created a
technical problem (ambigious address use) that split brain DNS
addresses.

Publishing ULA addresses on the public internet shouldn't cause
problem.  One could even publish link local addresses on the public
internet if we added a globally unique differentiator for the link
to the records.

e.g.
	AAAA <domain> 

The domain would announced in RAs so that nodes on the link could
correctly filter the responses.  It would also allow getaddrinfo
to fill in scope.

8 byte address records would have solved the RFC 1918 address issue.
First 4 bytes are the A records and the next 4 are the public address
of the NAT or 0.0.0.0.  Resolvers would just filter out anything
that wasn't to 0.0.0.0 or their public NAT address.  One could have
even used them to route throuh the NAT using LSR.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: <[email-masked]>
Date: Thu, 20 Oct 2011 07:01:17 +0000

Hi Ray,

> From: ext Ray Bellis [mailto:[email-masked]]
> Sent: 19. lokakuuta 2011 13:40
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>; <[email-masked]>;
> <[email-masked]>
> Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server selection
> document
> 
DNS
> hostname, and only after that the name SHALL be appended with  domain
> information and described DNS server selection logic be  utilized."
> 
> When new gTLDs are introduced it is likely for brand-name gTLDs that they
> will wish to use bare names in the DNS (i.e. a single label hostname) for
their
> primary web sites.
> 
> Hence bare names may become much more frequently used as DNS names,
> and §4.6 wouldn't permit those to work unless '.' is also in the suffix
list.
>
> I'd like to hear the authors' thoughts on these.  I'm not sure that this
draft
> necessarily needs any significant changes - it may only require changes to
> ensure that bare names are also considered as potential DNS names in their
> own right.

Okay, I understand there is no clear consensus yet how these single label
names should be handled by the resolvers at the first place? Should resolver
first treat them as pre-DNS hostnames, then as DNS hostnames, and then try
search list? The DNS server selection logic would be applied already when
resolving single label name, i.e. the network could provide a single label
domain "brand" in the domains list.

Maybe section 4.6 could be like this, perhaps (changes in second paragraph
and title)?
--
4.6.  Interactions with DNS search lists and single label hostnames

   A node may be configured with DNS search list by DHCPv6
   OPTION_DOMAIN_LIST [RFC3646] or DHCPv4 Domain Search Option
   [RFC3397].

   A bare name (a name without any dots) MUST be first treated as a pre-
   DNS hostname, after which resolution of the name SHALL be attempted
   with DNS, and as a last resort the name SHALL be appended with
   domain information. DNS server selection logic SHALL be 
   utilized for both of the latter two DNS using methods.

   Resolution for the name containing any dots SHOULD first be attempted
   with DNS servers of all interfaces.  Only if the resolution fails the
   node SHOULD append the name with search list domain(s) and then again
   utilize improved DNS server selection algorithm to decide which DNS
   server(s) to contact.
--

Best regards,

	Teemu

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Oct 2011 10:50:09 +1300

Teemu,

I don't believe this is a topic where consensus in MIF is very relevant.
It needs to be decided in a much wider community rather than as a subsidiary
question in a MIF document. I suggest leaving it FFS (for further study)
in MIF.

Regards
   Brian Carpenter

On 2011-10-20 20:01, [email-masked] wrote:
> ------------------------------------------------------------------------
> 
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif

---

From: David Conrad <[email-masked]>
Date: Thu, 20 Oct 2011 18:19:41 -0700

On Oct 20, 2011, at 6:07 PM, Keith Moore wrote:
> It might that IETF should consider "bare names" out of its scope, except perhaps to say that they're not DNS names, they don't have to necessarily be mappable to DNS names, and that their use and behavior is host and application-dependent.

Can we please not redefine what a "DNS name" is to meet a particular agenda?

Isn't it sufficient to say a 'bare name' does not conform to a hostname as defined in RFC 952 and modified by RFCs 1122?

Regards,
-drc

---

From: <[email-masked]>
Date: Fri, 21 Oct 2011 07:15:05 +0000

Brian,

Would the following text be then ok? Please note I changed the domain addition from SHOULD to MAY, if there is going to be attempt to deprecate/redefine/update search list logics. Or do you think it should remain SHOULD?
--
4.6.  Interactions with DNS search lists

   A node may be configured with DNS search list via DHCPv6
   OPTION_DOMAIN_LIST [RFC3646] or via DHCPv4 Domain Search Option
   [RFC3397].

   A bare name (a name without any dots) MUST be first treated as a pre-
   DNS hostname or handled by other means that, as of this writing, are
   under discussion in the IETF and that are out of the scope of this
   document.  If the bare name resolution fails, the name MAY then be
   appended with the domain information.  If the bare name is appended
   with the domain information the described DNS server selection logic
   SHALL be utilized for the resulting name.

   Resolution for the name containing any dots SHOULD first be attempted
   with DNS servers of all interfaces.  Only if the resolution fails the
   node MAY append the name with search list domain(s) and then again
   utilize improved DNS server selection algorithm to decide which DNS
   server(s) to contact.
--

Best regards,

	Teemu

> From: ext Brian E Carpenter [mailto:[email-masked]]
> Sent: 21. lokakuuta 2011 00:50
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: [mif] [dnsext] 2nd Last Call for MIF DNS server selection
> document
> 
> Teemu,
> 
> question in a MIF document. I suggest leaving it FFS (for further study) in MIF.
> 
> Regards
>    Brian Carpenter
> 
> >> Subject: Re: [dnsext] [mif] 2nd Last Call for MIF DNS server
> >> selection document
> >>
> >> When new gTLDs are introduced it is likely for brand-name gTLDs that
> >> they will wish to use bare names in the DNS (i.e. a single label
> >> hostname) for
> > their
> >> primary web sites.
> >>
> >> necessarily needs any significant changes - it may only require
> >> changes to ensure that bare names are also considered as potential
> >> DNS names in their own right.
> >
> > Okay, I understand there is no clear consensus yet how these single
> > label names should be handled by the resolvers at the first place?
> > Should resolver first treat them as pre-DNS hostnames, then as DNS
> > hostnames, and then try search list? The DNS server selection logic
> > would be applied already when resolving single label name, i.e. the
> > network could provide a single label domain "brand" in the domains list.
> >
> > Maybe section 4.6 could be like this, perhaps (changes in second
> > paragraph and title)?
> > --

---

From: <[email-masked]>
Date: Fri, 21 Oct 2011 07:21:51 +0000

(resending only to mailing list recipients)

Brian,

Do you agree that nodes' behavioral differences between "foo" and "foo."
names is out of the scope of this particular MIF draft?

There could perhaps be another draft, which would say that if name is "foo"
it should not be appended with search lists but "foo." might? And whatever
other differences in their handling would be, and what impacts it would have
e.g. intranet designers?

Please see also in another email my suggestion for section 4.6 text. That
text should now allow possible changes for the bare name handling while
still allowing coexistence with DNS server selection.

Best regards,

Teemu

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Brian Dickson
> Sent: 21. lokakuuta 2011 06:16
> To: Keith Moore
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]; Brian E Carpenter
> I think we can skirt this rat-hole if we separate the two following
distinct
> cases:
> 
> Case A: "foo"
> Case B: "foo." (with terminating "dot").
> 
> Case B meets the technical requirements of a Fully Qualified Domain Name,
> structurally speaking.
> Case A does not.
> 
> Case A is a "bare name", case B is not.
> 
> If we stick to the notions of FQDN versus anything else, we can avoid
> entering the rat-hole, IMHO.
> 
> (I.e., We don't need to get into any issues over the number of labels in
an
> FQDN; an FQDN does not require treatment, special or otherwise; etc.,
etc.,)
> 
> Brian Dickson
> 
> On Thu, Oct 20, 2011 at 9:38 PM, Keith Moore <moore@network-
> heretics.com> wrote:
> >
> > On Oct 20, 2011, at 9:19 PM, David Conrad wrote:
> >
> >>> It might that IETF should consider "bare names" out of its scope,
except
> perhaps to say that they're not DNS names, they don't have to necessarily
be
> mappable to DNS names, and that their use and behavior is host and
> application-dependent.
> >>
> > I wasn't trying to do so.
> >
> >> Isn't it sufficient to say a 'bare name' does not conform to a hostname
as
> defined in RFC 952 and modified by RFCs 1122?
> >
> > Probably.  I'm just suggesting that trying to nail down the behavior of
such
> names is probably a rathole as well as likely to cause significant
disruption.

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Oct 2011 21:07:41 -0400

Keith

---

From: Keith Moore <[email-masked]>
Date: Thu, 20 Oct 2011 21:38:58 -0400

> Isn't it sufficient to say a 'bare name' does not conform to a hostname as defined in RFC 952 and modified by RFCs 1122?

Probably.  I'm just suggesting that trying to nail down the behavior of such names is probably a rathole as well as likely to cause significant disruption.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Oct 2011 12:49:49 +1100

In message <[email-masked]>, David Conrad
 writes:
> > It might that IETF should consider "bare names" out of its scope, except pe
> rhaps to say that they're not DNS names, they don't have to necessarily be ma
> ppable to DNS names, and that their use and behavior is host and application-
> dependent.
> 
> Isn't it sufficient to say a 'bare name' does not conform to a hostname as de
> fined in RFC 952 and modified by RFCs 1122?

The problem is that they *are* hostnames, just not "domain style" (RFC 952)
or "hierarchical" (RFC 921) hostnames.

---

From: Brian Dickson <[email-masked]>
Date: Thu, 20 Oct 2011 23:15:32 -0400

distinct cases:

Case A: "foo"

Case B meets the technical requirements of a Fully Qualified Domain
Name, structurally speaking.
Case A does not.

(I.e., We don't need to get into any issues over the number of labels
in an FQDN; an FQDN does not require treatment, special or otherwise;
etc., etc.,)

Brian Dickson

---

From: <[email-masked]>
Date: Fri, 21 Oct 2011 07:15:06 +0000

Brian,

Best regards,

Teemu

distinct
an
etc.,)
except
be
as
such
disruption.

---

From: Ray Bellis <[email-masked]>
Date: Fri, 21 Oct 2011 07:46:30 +0000

> names is out of the scope of this particular MIF draft?

In my view neither the draft nor MIF should be encoding any changes to client name resolution behaviour that depend on the "bareness" of a supplied name.

Existing OSes have many varying algorithms for deciding which name service(s) to use to resolve any particular name, some of which have user-configurable knobs (e.g. "options: ndots" in /etc/resolv.conf).

By all means use server selection once the OS has decided that "DNS" is the correct name service, but that algorithm shouldn't IMHO impact or otherwise specify the prior name service selection algorithm.

> it should not be appended with search lists but "foo." might?

If anything it would be the other way around - 'foo.' is explicitly already full qualified, and MUST NOT be appended with search lists.

Ray

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Oct 2011 22:30:08 +1100

In message <CAH1iCiqsN-R87VK3vKityPsY+NXA=[email-masked]>
> in an FQDN; an FQDN does not require treatment, special or otherwise;

A domain style hostname have periods *seperating* labels.  RFC 952.
 
> Brian Dickson
> 
> On Thu, Oct 20, 2011 at 9:38 PM, Keith Moore <[email-masked]> w=
> rote:
> >
> >>> It might that IETF should consider "bare names" out of its scope, excep=
> t perhaps to say that they're not DNS names, they don't have to necessarily=
>  be mappable to DNS names, and that their use and behavior is host and appl=
> ication-dependent.
> >>
> >> Can we please not redefine what a "DNS name" is to meet a particular age=
> nda?
> >
> >> Isn't it sufficient to say a 'bare name' does not conform to a hostname =
> as defined in RFC 952 and modified by RFCs 1122?
> >
> > Probably. =A0I'm just suggesting that trying to nail down the behavior of=
>  such names is probably a rathole as well as likely to cause significant di=
> sruption.
> >
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Oct 2011 10:04:50 -0400

> names is out of the scope of this particular MIF draft?

That's not how I would state it.   I think handling of "foo." is something that IETF can define, but handling of "foo" is probably better left undefined.

And honestly I don't see why handling of non-DNS names like "foo" is in scope for MIF.    

As for lookup of DNS names, results of DNS lookup on any interface should be considered valid for all interfaces. 

> it should not be appended with search lists but "foo." might?

Actually, it's the other way around.  "foo." is already an FQDN and shouldn't be subject to any search lists.  The behavior of lookups of "foo" is implementation dependent, but it's common practice to subject it to searching.  

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Oct 2011 10:10:07 -0400

> Would the following text be then ok? Please note I changed the domain addition from SHOULD to MAY, if there is going to be attempt to deprecate/redefine/update search list logics. Or do you think i…

Associating MUST with undefined behavior makes no sense at all.

>   utilize improved DNS server selection algorithm to decide which DNS

Names containing dots SHOULD NOT (perhaps MUST NOT) be subject to searches.  They should already be considered fully qualified.

Just because a lookup "fails" does not mean that the name is not valid.  It could fail for temporary reasons, or because the TLD server wasn't reachable.

Back before there was a .CS TLD, searching on names containing dots was common.   Lots of computer science departments had .CS subdomains (e.g. cs.utk.edu used to be my mail domain), and people were accustomed to being able to send mail to moore@cs or [email-masked]).   Once the .CS TLD was defined it became obvious that domains containing any dots should not be subject to search.

Keith

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Oct 2011 15:07:49 +0000

On Oct 21, 2011, at 3:15 AM, <[email-masked]<mailto:[email-masked]>>

I tend to agree with others who have observed that this question is beyond the WG's core competency.  But there really is a mif question having to do with how search lists are handled.   Personally I tend to side with the crowd that believes that DNS search lists should be deprecated with extreme prejudice, but if the consensus is otherwise, I think this draft you describe does need to be written.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Oct 2011 15:11:11 +0000

On Oct 21, 2011, at 10:04 AM, Keith Moore wrote:
And honestly I don't see why handling of non-DNS names like "foo" is in scope for MIF.

Because such names are typically resolved using DNS search lists, and at lease one mechanism for setting up search lists is interface-specific.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 21 Oct 2011 15:19:06 +0000

On Oct 21, 2011, at 11:13 AM, Keith Moore wrote:
IMO: search lists are useful, but only with "bare names" - and the behavior of those should be implementation dependent.  Trying to nail it down will break too much widespread practice.

On a desktop workstation they are useful, because you can largely trust the security of the physical network.   On mobile nodes, though, they are harmful, because they open up a really easy avenue for exploit.

On MIF nodes, they also open up potential for mistakes.   So if we are to meet the spirit of your request here, it will still require a document describing what the mistakes are, and providing advice on how to avoid them.

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Oct 2011 11:13:24 -0400

On Oct 21, 2011, at 11:07 AM, Ted Lemon wrote:

> On Oct 21, 2011, at 3:15 AM, <[email-masked]>

Names containing "." should not be subject to search lists.  Given a name like foo.bar, there's no reliable way to tell whether "bar" is a TLD or a subdomain of something in the search list. 

(No, trying to look up "foo.bar" starting from the DNS root, and failing over if that lookup fails, is not sufficient, because of (a) temporary failures and (b) it still doesn't tell you what the user _meant_.  It makes much more sense to say that any name containing a "." is unambiguously an FQDN.)

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Oct 2011 11:22:23 -0400

> Because such names are typically resolved using DNS search lists, and at lease one mechanism for setting up search lists is interface-specific.

I don't think it's MIF's job to try to make all existing hacks work, while limiting its scope to specifying how hosts and apps implement things.  

I think it's potentially reasonable for MIF to say things like "here's how you should configure your networks if you want them to be usable from hosts with multiple interfaces."

Also, the subject of multiple active interfaces per host exposes a number of cracks in the Internet architecture, and also exposes cracks in some of the hacks that people have used to work around cracks in the Internet architecture.   IMO, MIF should not be trying to add more hacks.  MIF should primarily do what's best for the Internet architecture in the long term, realizing that IPv4 and therefore RFC 1918 are at EOL.  Hacks to accommodate the existing world should be considered of secondary importance, and should only be considered if they don't pollute the architecture in the long run.

Also, it's arguable that v6 link-local addresses should not be used by applications, even on ad hoc networks, because randomly-generated ULIA prefixes are much better.  And the way you figure out which interface(s) to use in order to reach ULIAs is via routing protocols, not via assuming that a DNS query is specific to a particular network interface.

---

From: Keith Moore <[email-masked]>
Date: Fri, 21 Oct 2011 11:31:06 -0400

> On a desktop workstation they are useful, because you can largely trust the security of the physical network.   On mobile nodes, though, they are harmful, because they open up a really easy avenue…

True.  But unsecured DNS is easily exploited regardless of whether bare names are used.  (and I've never bought the idea that DNSSEC verification can reasonably be done by an external host)

(When I think about things, I generally assume that nearly all nodes are mobile, because that's clearly the way things are going.  I expect that desktop workstations - in the sense of hosts that serve individual users and have fixed locations in the network - will be almost nonexistent in a very short time.  They don't need to be special-cased.)

> On MIF nodes, they also open up potential for mistakes.   So if we are to meet the spirit of your request here, it will still require a document describing what the mistakes are, and providing advi…

Understood.   I just think it's going to be tricky to do that without breaking a lot of existing behavior.  But in principle, there's nothing wrong with describing security vulnerabilities and workarounds for those.

Keith

---

From: <[email-masked]>
Date: Fri, 21 Oct 2011 18:54:23 +0000

Now that more people are involved in discussions, this bare name / DNS
search list area seems to look like quite a deep swamp without clear IETF
consensus.

Perhaps we should discuss first if this particular topic (=section 4.6) is
needed in this document at all, because, after all, the focus is on
selecting the DNS server based on matching domains. 

Best regards,

	Teemu

> From: ext Keith Moore [mailto:[email-masked]]
> Sent: 21. lokakuuta 2011 17:10
> Cc: [email-masked]; [email-masked]; [email-masked];
> > Would the following text be then ok? Please note I changed the domain
> addition from SHOULD to MAY, if there is going to be attempt to
> deprecate/redefine/update search list logics. Or do you think it should
> remain SHOULD?
> > --
> Names containing dots SHOULD NOT (perhaps MUST NOT) be subject to
> searches.  They should already be considered fully qualified.
> 
> Just because a lookup "fails" does not mean that the name is not valid.
It
> could fail for temporary reasons, or because the TLD server wasn't
> reachable.
> 
> Back before there was a .CS TLD, searching on names containing dots was
> common.   Lots of computer science departments had .CS subdomains (e.g.
> cs.utk.edu used to be my mail domain), and people were accustomed to
> being able to send mail to moore@cs or [email-masked]).   Once the .CS TLD
> was defined it became obvious that domains containing any dots should not
> be subject to search.
> 
> Keith
>

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Oct 2011 08:29:33 +1300

Teemu,

I think that the spirit of what you propose is correct, but as Keith points
out it really isn't appropriate to use RFC 2119 language about a pragmatic
approach that clearly lies outside the definition of the DNS namespace.
If an implementor is willing to take the risk of transforming www.example
into www.example.com, because at the time of writing there is no TLD "example",
that's the implementor's risk, but it shouldn't be dignified with normative
keywords IMHO.

Regards
   Brian Carpenter

---

From: Ted Lemon <[email-masked]>
Date: Sat, 22 Oct 2011 19:41:58 +0000

On Oct 21, 2011, at 11:31 AM, Keith Moore wrote:
True.  But unsecured DNS is easily exploited regardless of whether bare names are used.  (and I've never bought the idea that DNSSEC verification can reasonably be done by an external host)

Yes.   But if a bare name is used, a bogus search list can also bypass DNSSEC validation.

---

From: Doug Barton <[email-masked]>
Date: Sat, 22 Oct 2011 11:42:56 -0700

On 10/21/2011 08:13, Keith Moore wrote:
> Names containing "." should not be subject to search lists.  Given a
> name like foo.bar, there's no reliable way to tell whether "bar" is a
> TLD or a subdomain of something in the search list. 

I've been following this discussion, mostly in the hopes that it would
go away. :)  However since the discussion keeps circling I thought I'd
throw in my 2 cents.

1. I think we're all in agreement that dot-terminated names (e.g.,
example.) should not be subject to search lists. I personally don't have
any problems with any document mentioning that this is the expected
behavior.

2. I think most of us agree that a bare label (no dots, e.g., example)
will almost certainly be subject to a search list. My suggestion would
be that the common behavior be described in a "here be dragons" format,
without attempting to be proscriptive.

3. For hostnames with a dot (although not necessarily ending in a TLD,
such as foo.example) I think it's reasonable to say that the desired
behavior is to first try to look them up "as is" without applying a
search list, and if that fails to then apply the search list; with the
same caveat as above, descriptive language for this document instead of
proscriptive.

In regards to 3, let's say I have a domain, example.org. In my network I
have various subdomains that represent various network segments, let's
say foo, bar, and baz. Personally, I find it convenient to put
'example.com' in the search list for all of my hosts, and then type 'ssh
host.bar' and go off on my merry way. Yes, I understand that in my
simple example I could theoretically put all 3 subdomains in the search
list. Now assume that my network isn't actually that simple ...

hth,

Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

---

From: Keith Moore <[email-masked]>
Date: Sat, 22 Oct 2011 15:21:00 -0400

> any problems with any document mentioning that this is the expected

agree.  however there are standard protocols for which a trailing dot in a domain name is a syntax error.

> without attempting to be proscriptive.

mostly agree.   I don't think "will almost certainly be subject to a search list" is accurate, though I do think "may be subject to a search list" is reasonable.

> same caveat as above, descriptive language for this document instead of

Strongly disagree.  That would leave users without a protocol-independent way of unambiguously specifying "this is a fully-qualified domain name".

The practice of applying search lists to names with "."s in them needs to die.

Keith

---

From: Matthew Pounsett <[email-masked]>
Date: Sun, 23 Oct 2011 02:39:23 -0400

> agree.  however there are standard protocols for which a trailing dot in a domain name is a syntax error.

Any protocol that makes a standard FQDN a syntax error is itself in error.  Not to say that these don't exist, but if people are writing protocols that can't deal with a properly formatted FQDN they need to stop.  Now.

> The practice of applying search lists to names with "."s in them needs to die.

I can't agree with this statement.  As others have said, the practice of using a search list to allow 'ssh foo.bar' to reach 'foo.bar.example.com' isn't going anywhere, and there are a lot of people that make extensive use of the convenience.  Ask any security professional about how easy it is to compete with convenient access.

I think we need to accept that this practice is here to stay, and figure out how to deal with it on those terms.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 23 Oct 2011 19:16:44 +0000

On Oct 23, 2011, at 2:39 AM, Matthew Pounsett wrote:
I think we need to accept that this practice is here to stay, and figure out how to deal with it on those terms.

There is no secure way to do search lists in a MIF environment.   Or, really, even in a SIF environment.   So saying "we just have to deal with it," while it may seem pragmatic, is really just avoiding the issue: it won't go away just because we ignore it.

Remember: it used to be the case that people would authenticate rsh traffic using the source IP address, and this persisted long after it was clear that it was untenable.   But the practice has been largely eliminated at this point.   So it's not the case that just because some practice is "crucial," it will inevitably persist forever.

The way search lists ought to be handled in a UI is to come up with a list of all the names that match the term the user has typed, and offer the user the opportunity to select which of those names to choose.   But that's a UI hack, so essentially out of scope.   Also, in order to do this in a MIF environment, you have to try resolving the name on both interfaces, which some people think is not acceptable.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Oct 2011 10:49:21 +1100

In message <[email-masked]>, Matthew Pounse
tt writes:
> Any protocol that makes a standard FQDN a syntax error is itself in error.  N
> ot to say that these don't exist, but if people are writing protocols that ca
> n't deal with a properly formatted FQDN they need to stop.  Now.

Except it isn't a standard hostname.  Periods *seperate* labels in
hostnames RFC 952.  They DO NOT appear at the end of hostnames.

Appending a period to the end of a name is user interface hack to
prevent searching.  If is also a way to prevent the appending of
the current origin to all names in a DNS master file as the current
origin is always appended if it isn't done.

In addition single labels are not HEIRACHICAL / DOMAIN STYLE names
as envisioned when we went from a flat namespace of simple hostnames
to a heirarchical namespace.

	foo.bar is a heirachical hostname.
	bar is a simple hostname.

Why are we trying to bring them back on a global context?

> > Strongly disagree.  That would leave users without a protocol-independent w
> ay of unambiguously specifying "this is a fully-qualified domain name".
> > 
> I can't agree with this statement.  As others have said, the practice of usin
> g a search list to allow 'ssh foo.bar' to reach 'foo.bar.example.com' isn't g
> oing anywhere, and there are a lot of people that make extensive use of the c
> onvenience.  Ask any security professional about how easy it is to compete wi
> th convenient access.
> 

People deal with all sorts of changes.  Point out the obvious
security flaws, make enough fuss, vendors have to ship with this
behaviour gone/disabled.  People stop worrying about it.

---

From: Keith Moore <[email-masked]>
Date: Sun, 23 Oct 2011 21:17:41 -0400

> Any protocol that makes a standard FQDN a syntax error is itself in error.  Not to say that these don't exist, but if people are writing protocols that can't deal with a properly formatted FQDN the…

Per RFC 952, a standard FQDN does not contain a trailing dot.   Neither do email addresses nor domains in URLs.    Changing that set of embedded practices is much more difficult than changing the expectations of the relative few who currently expect names with dots to be subject to search lists.

> I can't agree with this statement.  As others have said, the practice of using a search list to allow 'ssh foo.bar' to reach 'foo.bar.example.com' isn't going anywhere, and there are a lot of people that make extensive use of the convenience.

It needs to die because it's fundamentally broken.   Vanity TLDs will only make it worse.   I understand that there are sites that use it and people who are accustomed to it.   I don't pretend that we can stop them.   We can, however, explain the negative consequences of doing this (some of which might be specific to systems with multiple interfaces), and recommend that they transition away from that practice.   And recommendations for systems with multiple interfaces can be chosen in such a way as to allow search lists to break even more.

Keith

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 23 Oct 2011 21:18:19 -0400

Hi,

> hostnames RFC 952.  They DO NOT appear at the end of hostnames.

Isn't there the the root label, which is the null string, at the end
of all FQDNs, so the period at the end does separate labels?

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>

---

From: Mark Andrews <[email-masked]>
Date: Mon, 24 Oct 2011 14:57:38 +1100

In message <[email-masked]>
, Donald Eastlake writes:
> > In message <[email-masked]>, Matthew =
> Pounse
> > tt writes:
> >>
> >> Any protocol that makes a standard FQDN a syntax error is itself in erro=
> r.  N
> >> ot to say that these don't exist, but if people are writing protocols th=
> at ca

Not in hostnames. See RFC 952.

> Thanks,
> Donald
> ==============================

---

From: [email-masked]
Date: Mon, 24 Oct 2011 08:08:22 +0200 (CEST)

> It needs to die because it's fundamentally broken.   Vanity TLDs will only make it worse.   I understand that there are sites that use it and people who are accustomed to it.   I don't pretend that…

I routinely use short names (and thus search lists) in my work. I am
aware of vanity domains, and of RFC 1535. Have I stopped using short
names and search lists? No, the convenience is just too great.

In trying to stop the use of short names and search lists I believe
you're trying to fight human nature. It's a waste of time, and unlikely
to be productive.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Oct 2011 06:53:05 -0400

> you're trying to fight human nature. It's a waste of time, and unlikely

Just to be clear, I'm not trying to forbid the use of search lists with "bare" (single-label) names.   I'm just pointing out that for the vast majority of the contexts in which domain names are used, the expectation is that a domain name that contains a "." is fully-qualified.  The need for domain names to behave consistently from one host to another and one application to another is much, much more important, than the need to apply search lists to queries of domain names that contain "."s.

---

From: Alex Bligh <[email-masked]>
Date: Mon, 24 Oct 2011 12:19:21 +0100

--On 24 October 2011 06:53:05 -0400 Keith Moore 
<[email-masked]> wrote:

> I'm just pointing out that for the vast majority of the contexts in which
> domain names are used, the expectation is that a domain name that
> contains a "." is fully-qualified.

This is sampling bias.

In the vast majority of contexts where domain names (term used
loosely) are used, those domain names contain at least one dot.

In the vast majority of contexts where domain names (term used
loosely) are used, those domain names are fully qualified.

It is therefore statistically unsurprising that in the vast
majority of contexts where domain with a dot in them, are used
they are fully qualified.

The question here should be "where search lists are used, are
they frequently used in combination with domain names that
are not fully qualified". I would suggest the answer to this
question is "yes". If so, then to the extent that search lists
are supported, you need to make them interwork names with
dots in them. Moreover, with a search list of "example.com",
having "mail" work, but not "mail.dev" is going to be a
pretty surprising outcome.

I think the two options are either deprecating search lists
(or not supporting them), or supporting them properly, in
which case they must be used whatever domain name is
specified, and the way to avoid using a search list
is the same old hack as before (i.e. putting a dot on the
end).

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Mon, 24 Oct 2011 12:20:50 +0100

> Yes.   But if a bare name is used, a bogus search list can also bypass

For the hard of understanding, please could you expand on this?

Doesn't the client know the full name being looked up, even with a search
list?

-- 
Alex Bligh

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Oct 2011 07:29:55 -0400

On Oct 24, 2011, at 7:19 AM, Alex Bligh wrote:

> --On 24 October 2011 06:53:05 -0400 Keith Moore <[email-masked]> wrote:
> 

No, I don't think so.  The vast majority of contexts where domain names are used, are contexts in which the domain is supplied by one party and (at least potentially) used by another party.  Email addresses, URLs, domain names written on advertisements and business cards, etc.  

> question is "yes".

That's not a useful way to phrase the question, because there's no way for software to know whether or not the user intends that a name containing "." is fully-qualified.

> If so, then to the extent that search lists

It will be surprising to that relatively small portion of users that relies on search lists being applied to multi-label names.   But overall, having a clear, visible distinction between names for which searching is potentially applied (i.e. bare or single-label names), and names for which searching is not applied (multi-label names) results in less surprising behavior for everyone.

> is the same old hack as before (i.e. putting a dot on the

Supporting search lists "properly" is NOT using them whenever a domain name is specified.  That makes all domain names context-sensitive, and breaks every application that uses domain names supplied by other parties or in other contexts.

Keith

---

From: Alex Bligh <[email-masked]>
Date: Mon, 24 Oct 2011 12:55:29 +0100

--On 24 October 2011 07:29:55 -0400 Keith Moore 
<[email-masked]> wrote:

>>> I'm just pointing out that for the vast majority of the contexts in
>>> which domain names are used, the expectation is that a domain name that
> No, I don't think so.  The vast majority of contexts where domain names
> are used, are contexts in which the domain is supplied by one party and
> (at least potentially) used by another party.  Email addresses, URLs,
> domain names written on advertisements and business cards, etc.

Of course, but that explicitly excludes every case where a search
list is useful. That's why I'm saying you have to look at the
cases were a search list is used. In large organisations "domain names"
(used loosely) can have dots in and be expected to have
search list items appended. Given search list use is rare,
it's obviously going to be rare to have them with dots.

> That's not a useful way to phrase the question, because there's no way
> for software to know whether or not the user intends that a name
> containing "." is fully-qualified.

You are begging the question. Of course the name "foo.bar" is
ambiguous. That's precisely /why/ there is a search list, so
foo.bar is only looked up if foo.bar.example.com (or whatever)
does not exist. The existence of the "if" step means that the
software cannot know what the domain means (in the sense
of what it will ultimately resolve to) without doing a lookup.

> It will be surprising to that relatively small portion of users that
> relies on search lists being applied to multi-label names.   But overall,
> having a clear, visible distinction between names for which searching is
> potentially applied (i.e. bare or single-label names), and names for
> which searching is not applied (multi-label names) results in less
> surprising behavior for everyone.

I do not think you have established that a relatively small number
of users of search lists use multi-label names. I suspect that
is not true.

> Supporting search lists "properly" is NOT using them whenever a domain
> name is specified.  That makes all domain names context-sensitive, and
> breaks every application that uses domain names supplied by other parties
> or in other contexts.

I don't have RFC references to hand, but precisely for the reasons you have
set out above, I do not believe there is anything within them that search
lists should only be used if "a domain name is specified", precisely
because it's impossible to tell whether a string with dots in it is "a
domain name", or merely something to go on the front of search lists.

What you are, I think, saying, is that you want to change the behaviour of
search lists so they only work with single labels. What I'm saying is that
there are likely to be a significant number of users of search lists who
are affected by that, as they currently pass things with dots in them. A
completely unscientific analysis I know, but every internet company I have
worked with since we moved out of uucp naming has done this, and not
because I have told them to. Even current 20 person software house does
this. So, if you are going to substantially break search lists (which is
not inherently a bad idea - they have caused all sorts of trouble in times
past), you might as well just deprecate them or not support them.

-- 
Alex Bligh

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Oct 2011 08:16:17 -0400

On Oct 24, 2011, at 7:55 AM, Alex Bligh wrote:

> 
> 
> --On 24 October 2011 07:29:55 -0400 Keith Moore <[email-masked]> wrote:
> 
> 
> list is useful.

That's the point - search lists are not appropriate most of the time, and it's very hard for software to distinguish the cases where they are potentially appropriate from the cases when they're not, and it's not possible for software to do this in all cases.

The presence or absence of a '.' is a simple and easily-understood convention.  It might be somewhat inconvenient for large organizations that currently rely on search lists for multi-label names, but overall that's a small price to pay in exchange for having consistent behavior of domain names across the board.  

The only reason that those organizations have managed to get away with it so far is that TLDs (particularly TLDs with more than 2 characters) have been relatively few in number.  But with vanity TLDs this will no longer be the case.

> ambiguous.

No, it's not ambiguous.  It's fully qualified.  

> That's precisely /why/ there is a search list, so
> does not exist.

That's insane.   That allows a local enterprise to change the meaning of every domain name.  Domain names are supposed to have the same meaning everywhere in the Internet.

> of users of search lists use multi-label names. I suspect that

My assumption is that search lists in conjunction with multi-label names are mostly used within fairly large enterprises, but search lists are potentially in much wider use.

> are affected by that, as they currently pass things with dots in them.

No disagreement on that point.  But search lists always have been broken.  It's just unfortunate that DNS APIs have supported them for so long, and their behavior has become entrenched in several organizations (including some that ought to know better).

My belief is that local names (i.e. bare or single-label names) are useful and necessary but their behavior cannot really be standardized.  So letting them continue to be subject to search lists is a useful compromise that is less drastic than doing away with search lists entirely.  It also has the virtue of being a simple rule that users can easily understand (a name with a "." is always fully qualified and usable in a global context, a name without a "." is ambiguous and only useful in a local context).

Keith

---

From: Danny Mayer <[email-masked]>
Date: Mon, 24 Oct 2011 13:18:40 -0400

> Why are we trying to bring them back on a global context?

I'm not even sure why we are having this discussion. You are right, of
course.

DNS doesn't know anything about search lists, nor does it care. Any
valid string presented to DNS is by definition a FQDN and DNS will
proceed accordingly. If the application choosing to consult a domain
search list it's up to that application, but DNS is not involved in the
consultation.

Danny

---

From: Doug Barton <[email-masked]>
Date: Mon, 24 Oct 2011 13:52:34 -0700

> That's the point - search lists are not appropriate most of the time, and it's very hard for software to distinguish the cases where they are potentially appropriate from the cases when they're not…

There's been something missing from this discussion, and I finally put
my finger on it. TMK most stub resolvers have an option similar to this
one from ISC's:

ndots:n
        sets a threshold for the number of dots which
        must appear in a name given to res_query() (see
        resolver(3)) before an initial absolute query
        will be made.  The default for n is “1”, mean‐
        ing that if there are any dots in a name, the
        name will be tried first as an absolute name
        before any search list elements are appended to
        it.

So it seems that this question is already a matter of local policy,
which given the number and quality of the divergent views seems
eminently reasonable. Can we move on now?

Doug

--

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Oct 2011 16:58:49 -0400

> eminently reasonable. Can we move on now?

No, because relying on "local policy" is not sufficient for interoperability.

I think there's a need for IETF to document why any other value than 1 is a Bad Idea, and more to the point, why it will break things.    The problem isn't entirely specific to hosts with multiple interfaces.  But given that using multiple interfaces makes the problem worse, MIF might want to take on some of the work of documenting why it will break things.

Keith

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 Oct 2011 18:50:24 -0400

> No, because relying on "local policy" is not sufficient for interoperability.

For interoperability, one can use absolute names, with the trailing dot,
or specify that in the context of whatever protocol, all names are to be
taken as relative to the root, or use other than a printed
representation.  In some cases this may require that implementations use
resolver interfaces which make it clear that a name to be resolved is
absolute, or that they append the empty label to relative names before
passing them on to the resolver.

On the other hand, in user interface, which is primarily where relative
names are intended to be used, local policy is quite sufficient.  As
long as I and the software on my machine agree on what a name I type
means, it's none of the IETF's business.

Can an enterprise change the name of every domain name?  On machines
they control, yes.

While I agree wholeheartedly with the notion of a unique domain name
space, I also believe that mapping a relative or abbreviated name onto
that namespace is _entirely_ a matter of local policy.  It is perhaps
appropriate for the IETF to provide mechanisms for distributing that
policy, for those who wish to use them, but not to dictate what the
policy must be.

> I think there's a need for IETF to document why any other value than 1
>  is a Bad Idea, and more to the point, why it will break things.

It's not a Bad Idea, and it doesn't break things, or at least not so
badly that the convenience isn't worth it.  In this, I speak from years
of operational experience, not only of personal use of also that of the
many users of systems I operate support.

Do things get worse as new TLDs appear?  Yes, sometimes.

Have we mostly had to abandon use of relative names ending in .cs and
other two-letter suffixes?  Yes, but we _mostly_ didn't use them anyway,
due to our deep namespace and the appearance of those domains in our
search list (here, "foo.bar" usually means "foo.bar.cs.cmu.edu").

Does that mean we're abandoning "options ndots:2"?  Not aggressively.
It has faded over time, but more due to a failure to actively apply it
to newer systems than to any conscious decision that it's a problem.

Further, given this position, I wonder why you think even a value of 1
is acceptable in the face of vanity TLDs.  I know why I do, both from
the perspective of an IETF (it's a local policy matter, period) and for
myself (search for local names first, don't trust DNS results (yet) for
security, and write absolute names when you want to bypass search
lists).

> The
>  problem isn't entirely specific to hosts with multiple interfaces. 
>  But given that using multiple interfaces makes the problem worse, MIF
>  might want to take on some of the work of documenting why it will
>  break things.

I can see how using an untrusted search list makes it worse.

I can also see how using multiple sets of nameservers which provide
different views of the namespace makes things worse, and I can see how
using multiple interfaces makes this more likely.  But, that has nothing
to do with search lists and occurs even if every name is always treated
as absolute.  I can see two answers to this:

1) Use DNSSEC
2) Don't trust results from unsecured DNS for anything important.

I fail to see how using multiple interfaces makes the problem worse, in
itself.  Can you elaborate?

-- Jeff

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 Oct 2011 20:04:52 -0400

On Mon, 2011-10-24 at 19:30 -0400, Keith Moore wrote:
> On Oct 24, 2011, at 6:50 PM, Jeffrey Hutzelman wrote:
> 
> uh, no.   Names with trailing dots aren't allowed in many contexts.  
>  And in some of the contexts in which they are allowed, they get
>  "canonicalized" to names without trailing dots.

Yup; that's a problem.  And I agree that changing it may not be the most
practical solution to the problem.

> > representation.
> ...so a DNS name means different things in one context than in another.  Bad Idea.

Hm?  Not at all.  Really, only unambiguous names ought to ever appear on
the wire.  One way for a protocol to do that is too use absolute names
exclusively; another is to use "relative" names which are always
relative to the root; this is the same as using absolute names without
the trailing dot.  Another is to use names relative to some unambiguous
origin, as is done in DNS master files.

The important thing is that a name always mean the same thing, not that
it be represented the same way in all protocols.

> >  In some cases this may require that implementations use
> > names are intended to be used, local policy is quite sufficient.
> 
> no.  Domain names are written on buses, billboards, business cards. 
>  They do get transcribed, quite often actually, and they need to have
>  the same meanings when typed in as they do when clicked on.

Yup, that's a problem, too, in many ways.  Of course, such names should
always be fully-qualified; you can't expect useful results if you use a
relative name on the side of a bus.  Or at least, you can't unless you
really meant an absolute name but left off the trailing dot, which is
what everyone will think you meant anyway.

> Some people are working way too hard to try to save something that was
>  never a good idea in the first place.   
> 
> I'm not arguing that all software that currently applies searching to
>  names with dots in them has to die a violent death, and immediately
>  either be updated or deleted from all computers everywhere (as
>  if...).  I'm just saying that IETF should recommend against the
>  practice of using search lists with multi-label names, and document
>  the harm that it does.  Sites can still do it if they want to, or they
>  can manage their own transitions away from using search paths for such
>  names, on their own timeframes.   After all, this has been a practice
>  for ~30 years in some places, nobody should expect it all to change
>  overnight.

Right.  That's what local policy _is_.
Of course it's reasonable for the IETF to recommend default policy, and
describe some of the pitfalls associated with other possible policies.
And I certainly agree that ndots:1 is a reasonable default policy that
will work for most people while causing few problems.  Which makes it
convenient that it's what most vendors already do today.

> > that namespace is _entirely_ a matter of local policy.
> 
> That's a convenient philosophy if you _only_ care that local things
>  interoperate with one another.

I only care that abbreviated names work for local things.  For non-local
things, I find it acceptable that fully-qualified names must be used to
obtain interoperability.

> > is acceptable in the face of vanity TLDs.

> Because (a) local names are essential, (b) the ability to distinguish
>  local names from FQDNs is also essential, and (c) use of a
>  single-label name as a local name (meaning, a name subject to local
>  interpretation) is a very widespread and well-entrenched practice.  
>  Sites that associate address (or MX) records with vanity TLDs will
>  lose, and they deserve to lose.

OK; on these points we agree.

Note, however, that to me "local interpretation" means as defined by me
and whoever else is involved in setting policy for me, and _not_ as
defined by the coffee shop I happen to be sitting in.  IMHO, local names
are useless if I cannot depend on their meaning.

Ideally, it would be desirable to have an interoperable way to have
multi-label local names.  When "local" gets to be large, a flat
namespace becomes unwieldy, but abbreviation is still highly desirable.
Why should I have to type more to talk to a relatively nearby machine
that is part of my organization than to talk to a total stranger?

But, since such a thing is basically impossible, I am satisfied with the
idea that, as a matter of local policy, I can decide that some things
that would otherwise be treated as fully-qualified are instead treated
as local names.  Other people shouldn't get to decide that for me
without my permission, of course.

> >  I know why I do, both from
> The way you write an absolute name is to include a '.' in it.

Well, yes.

-- Jeff

---

From: Keith Moore <[email-masked]>
Date: Mon, 24 Oct 2011 19:30:08 -0400

> For interoperability, one can use absolute names, with the trailing dot,

uh, no.   Names with trailing dots aren't allowed in many contexts.   And in some of the contexts in which they are allowed, they get "canonicalized" to names without trailing dots.

> names are intended to be used, local policy is quite sufficient.

no.  Domain names are written on buses, billboards, business cards.  They do get transcribed, quite often actually, and they need to have the same meanings when typed in as they do when clicked on.

In a small number of cases, where a user gets immediate feedback after he types in the name and before a host attempts to contact a server, it might be sufficient to "canonicalize" a name, show the user how the name will actually be interpreted, and let him click "ok" before contacting the server.   But even then, what if the "canonicalization" is wrong?  How is the user supposed to know how to tell the software to treat the name as an FQDN?  If he types in the '.', the dot will disappear when the name is canonicalized.   That's not exactly effective reinforcement.   It says to the user "you should not have typed in that final dot".  And the practice of not using a trailing "." is nearly universal.  Changing that practice is much harder than changing from IPv4 and IPv6.

Some people are working way too hard to try to save something that was never a good idea in the first place.   

I'm not arguing that all software that currently applies searching to names with dots in them has to die a violent death, and immediately either be updated or deleted from all computers everywhere (as if...).  I'm just saying that IETF should recommend against the practice of using search lists with multi-label names, and document the harm that it does.  Sites can still do it if they want to, or they can manage their own transitions away from using search paths for such names, on their own timeframes.   After all, this has been a practice for ~30 years in some places, nobody should expect it all to change overnight.

>  As long as I and the software on my machine agree on what a name I type means, it's none of the IETF's business.

(So what?  It's also none of IETF's business if you _______________  <---- pick anything that is utterly senseless here)

Of course, you can do whatever you want.  But IETF should promote practices that make good sense, even though we realize that some people will decide for themselves to not follow them.

> Can an enterprise change the name of every domain name?  On machines

Of course they can.  But it makes absolutely no sense for IETF to bless that practice or to ignore it when we know that it does harm.  

The presumption of the standards is that you want your machines to interoperate with other machines.  If you don't want interoperability, have a day - screw things up however you want.  (as long as you only affect your own machines, of course.).  Nobody's forcing you to keep your machines conforming.

> that namespace is _entirely_ a matter of local policy.

That's a convenient philosophy if you _only_ care that local things interoperate with one another.

>  It is perhaps

IETF's job is to help the Internet work,  not to endorse every bit of local brain damage that people are attached to.

> Do things get worse as new TLDs appear?  Yes, sometimes.

Be prepared for it to happen more often.  Do you really want to rethink your naming scheme every time someone creates a vanity TLD that happens to collide with some subdomain of cmu.edu?   Even if that's only once every year or three, how often does it need to happen before it's no longer worth the trouble?

I mean, I'm sure that the relevant people at CMU are quite capable of evaluating that decision for themselves.    An IETF RFC isn't going to tell them anything that they can't figure out already.   But that's not true of Internet users, network administrators, software implementors in general.

> is acceptable in the face of vanity TLDs.

Because (a) local names are essential, (b) the ability to distinguish local names from FQDNs is also essential, and (c) use of a single-label name as a local name (meaning, a name subject to local interpretation) is a very widespread and well-entrenched practice.   Sites that associate address (or MX) records with vanity TLDs will lose, and they deserve to lose.

Keith

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 24 Oct 2011 20:30:53 -0400

> list. Now assume that my network isn't actually that simple ...

For example, suppose that each of foo, bar, and baz in turn has a number
of subdomains, and that the total number of such 4th-level domains is
over 250.  Now, imagine that major resolver implementations limit the
search list to a total of 6 domains...

---

From: Doug Barton <[email-masked]>
Date: Mon, 24 Oct 2011 14:29:37 -0700

> No, because relying on "local policy" is not sufficient for interoperability.

I don't see how local resolution issues feed into interoperability here.

> I think there's a need for IETF to document why any other value than 1 is a Bad Idea, and more to the point, why it will break things.    The problem isn't entirely specific to hosts with multiple…

That seems to be an opinion of yours that isn't widely shared.

--

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Oct 2011 17:20:37 +0000

> That seems to be an opinion of yours that isn't widely shared.

The fact that many of us are tired of this interminable rathole and want it to stop is not an indication that we agree with you, Doug. Consensus is not, or at least should not be, determined by counting the number of email messages for and against.

---

From: Doug Barton <[email-masked]>
Date: Tue, 25 Oct 2011 11:33:24 -0700

On 10/25/2011 10:20, Ted Lemon wrote:
>>> I think there's a need for IETF to document why any other value
>>> than 1 is a Bad Idea, and more to the point, why it will break
>>> things.    The problem isn't entirely specific to hosts with
>>> multiple interfaces.  But given that using multiple interfaces
>>> makes the problem worse, MIF might want to take on some of the
>>> work of documenting why it will break things.
>> 
> The fact that many of us are tired of this interminable rathole and
> want it to stop is not an indication that we agree with you, Doug.
> Consensus is not, or at least should not be, determined by counting
> the number of email messages for and against.

Thank $DEITY that's true, or Keith would "win" every "vote." :)

--