Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

From: Tony Finch <[email-masked]>
Date: Thu, 1 Feb 2018 14:41:53 +0000

Paul Vixie <[email-masked]> wrote:
> Ray Bellis wrote:
> >
> > Won't that cause the resolver to cycle through every root server letter
> > hoping for one that doesn't give that answer?
>
> yes. that's what REFUSED is taken to mean, and also, why we never use it for
> data-dependent conditions. only the initiator's identity matters in the
> consideration of whether to transmit REFUSED or not.

That's not entirely true - if you are asking an authoritative-only server
then you get REFUSED or not depending on whether the QNAME is in an
authoritative zone.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Malin, Hebrides: North 7 to severe gale 9, decreasing 5 or 6 later. High
becoming rough or very rough. Wintry showers. Mainly good.

---

From: Ray Bellis <[email-masked]>
Date: Thu, 1 Feb 2018 15:00:23 +0000

> then you get REFUSED or not depending on whether the QNAME is in an

Right, but the resolver behaviour is to assume that that server is a
lame delegation, and therefore go try in the others in case they're not
lame.

If they're all lame, the resolver then returns SERVFAIL.

Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Feb 2018 12:00:19 -0500

> hoping for one that doesn't give that answer?

It might, yes.  But that's a poor reason to give an authoritative
answer that a name which does exist instead does not.  Such resolvers
are broken under 6761 anyway, and shouldn't be making such a request.
But lying about the answer is not in keeping with 6761.  There remains
some controversy about what the right answer would be, given some
interpretations of REFUSED.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 01 Feb 2018 09:11:37 -0800

Tony Finch wrote:
> Paul Vixie<[email-masked]>  wrote:
>> Ray Bellis wrote:

that's what this group has reached consensus on in recent months, yes. 
to me that's a servfail condition, because the initiator may have better 
knowledge than the server operator. i can re-quote the scriptures on 
this point if my non-participation in the recent consensus seems 
unjustified.

servfail and refused are equivalent in one sense: the proper reaction to 
either is to remove that server from consideration for that query (retry 
won't help), and to perhaps keep it out of consideration for similar 
queries (same apparent bailiwick) for some holddown period.

-- 
P Vixie

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Feb 2018 12:26:44 -0500

On Wed, Jan 31, 2018 at 04:15:07PM +0000, Viktor Dukhovni wrote:
> return NXDomain is likely the best option for now.  The other
> alternative is to actually serve the expected data:
> 
>     localhost. IN A 127.0.0.1
>     localhost. IN AAAA ::1
> 
> but I don't think that'd be better.

It has the notable advantage that it's what the RFC says to do.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Feb 2018 12:31:22 -0500

> that's what this group has reached consensus on in recent months, yes.

I think I missed that consensus.  I was under the impression that
there was still disagreement about it, but that in any case the answer
should definitely not be RCODE 3.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Thu, 01 Feb 2018 09:33:37 -0800

> It has the notable advantage that it's what the RFC says to do.

while i would separately be happy to outlaw queries for this name by 
resolvers, i agree that actually serving and signing the data would meet 
the standard of "reasonable expectations", and ought to be debated.

as to the first, i harken again to RFC 1535, which advises implementers 
of host stub resolver libraries, but which adds or subtracts or modifies 
no on-the-wire patterns. that's how bad behaviour is managed, and not by 
mandating that my local RDNS server not answer for localhost.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Feb 2018 11:45:26 -0600

> It has the notable advantage that it's what the RFC says to do.

As a general principle, when what the RFC says to do is not the right thing to do, the solution is to update the RFC, not to ignore the problem.   So a statement in the form you have used, while it may make sense when we are talking about whether or not an implementation of the RFC is correct, is meaningless when what we are talking about is whether the RFC is correct.

Your and Paul's responses to this seem to take the position that what matters is consistency.   We should not return NXDOMAIN, because localhost has meaning, and NXDOMAIN doesn't.   But this misunderstands what NXDOMAIN means.   What NXDOMAIN means is "there is no such name in the DNS."   It doesn't mean "there is no such name."

It would be nice if there were an error code that said "you're looking in the wrong place for an answer," but there are two problems with this.   First, it's not actionable.   Looking for localhost in the DNS is a programming error.   When a program is broken, telling it that it is broken doesn't do any good.   What we want is to return a response that doesn't make things worse.   Returning REFUSED makes things worse.   Returning NXDOMAIN does not.

Second, there's no trust model for such a response.   The trust model for NXDOMAIN is clear, and we know how to do it.   The trust model for e.g. REFUSED is nonexistent.

Whether we should place special requirements on recursive resolvers is certainly something that is up for debate.   But what the right response is, if we don't place special requirements on recursive resolvers, seems extremely straightforward to me.   If you believe that the right response is not NXDOMAIN, your reason needs to be something more than "that's what the RFC says to do."

---

From: Tony Finch <[email-masked]>
Date: Thu, 1 Feb 2018 17:47:01 +0000

Paul Vixie <[email-masked]> wrote:
> Tony Finch wrote:
> >
> > if you are asking an authoritative-only server then you get REFUSED or
> > not depending on whether the QNAME is in an authoritative zone.
>
> that's what this group has reached consensus on in recent months, yes. to me
> that's a servfail condition, because the initiator may have better knowledge
> than the server operator.

I take SERVFAIL from an auth-only server to mean "I know about that zone
but it is broken right now" (e.g. expired). I think this is a useful
three-way distinction.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Malin, Hebrides: North 7 to severe gale 9, decreasing 5 or 6, then backing
south later. High becoming rough or very rough. Showers. Good.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Feb 2018 15:48:33 -0500

On Thu, Feb 01, 2018 at 11:45:26AM -0600, Ted Lemon wrote:
> 
> As a general principle, when what the RFC says to do is not the right thing to do, the solution is to update the RFC, not to ignore the problem.

I strongly agree with this (as I think or anyway hope you know), and
if my response seemed to be an appeal to the mythical authority of the
RFC series then I apologise.  My intent was to point out, instead,
that RFC 6761 has a position about this, and it is quite clear and
also contrary to the behaviour of the root servers.  Since RFC 6761
has IETF consensus, I am not convinced that the response from the
roots is right.  Since an NXDOMAIN response causes the _very problem_
that the draft this thread is about is attempting to fix -- literally
by making the effect in question more ubiquitous -- it seems to me
that the burden of proof lies upon others.

> Your and Paul's responses to this seem to take the position that what matters is consistency.   We should not return NXDOMAIN, because localhost has meaning, and NXDOMAIN doesn't.   But this misund…

But of course, there _is_ a name "localhost" in the DNS.  It's already
defined, in the RFCs, to this effect.  RFC 6761 defines
special-purpose domain names, not domain names that are outside the
DNS.  It so happens that this domain name _is_ in the DNS, precisely
because RFC 6761 recommends that it be so (unlike, for example, what
it says for .invalid or what RFC 6762 says for .local).  The point is
rather that localhost is a universal reference to the loopback
address.  Since it is a universal truth, it is true in the IN class,
and that means that any server on the Internet ought to know this.

> Returning REFUSED makes things worse.   Returning NXDOMAIN does not.

The goal in the draft is to make things break for the host making the
request, even though it should not have made that request.  Returning
REFUSED and returning NXDOMAIN both have that effect.  But returning
NXDOMAIN also breaks the semantics of DNS, which I think it worse.

> Second, there's no trust model for such a response.   The trust model for NXDOMAIN is clear, and we know how to do it.   The trust model for e.g. REFUSED is nonexistent.

Nonsense.  The trust model for refused is, "You asked and were
denied."  Signable denial of service strikes me as possibly the most
abusable service on the Internet :)

> Whether we should place special requirements on recursive resolvers is certainly something that is up for debate.

RFC 6761 _already_ places such requirements, it seems to me.

> If you believe that the right response is not NXDOMAIN, your reason needs to be something more than "that's what the RFC says to do."
>

I believe I offered such reasons in rather more detail in a different
message (one to which you did not respond) where I reviewed the draft
at greater length.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Feb 2018 15:26:40 -0600

On Feb 1, 2018, at 2:48 PM, Andrew Sullivan <[email-masked]> wrote:
> I strongly agree with this (as I think or anyway hope you know)

Yes, I will admit I was a bit surprised that you put it that way, although as you say, your position is more clear in your formal review of the document.

As for why I responded to this and not to the formal review, the answer is that the formal review was a bit overwhelming.  You made a lot of assertions of fact that didn't sound like fact to me—they sounded like strongly-held opinion.   You are a much more experienced DNS expert than I am, so for me to argue you away from those opinions is a tall order—I don't think you've really expressed the underlying belief that is the keystone to the whole edifice.

The problem I have is that to me it's dead obvious that the name hierarchy and the set of names in the DNS are not the same thing.   We've had that discussion before.   We even published a document about it, which hasn't quite made its way out of the RFC editor queue yet.   It seems to me that it is demonstrably the case that these two sets are disjoint.

But you explain your reasoning on the basis that clearly they are the same set, and that they are the same set is left unexamined.   So if we were to succeed in understanding why we disagree on this point, it would be necessary to dig down into that.

Having seen you give keynotes at the plenary, I know that you are deeply concerned about computer security.   The reason that I am in favor of the behavior I'm propounding is that I think it closes a small security gap through which a truck might some day be driven, to our woe.   So to me, the need to leave that gap, which I admit is small, open, seems inconsistent with what I know of you.

So clearly you value this idea that localhost is a name that exists in the DNS, even though it doesn't exist in the DNS.   It might be fruitful to explore that further.   It might also be a waste of time.   I don't honestly know.   But that is, I think, the key to our disagreement.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 1 Feb 2018 16:41:01 -0500

Hi,

On Thu, Feb 01, 2018 at 03:26:40PM -0600, Ted Lemon wrote:
> 
> As for why I responded to this and not to the formal review, the answer is that the formal review was a bit overwhelming.  You made a lot of assertions of fact that didn't sound like fact to me—they sounded like strongly-held opinion.

Hmm.  I should do better.  I apologise.

> The problem I have is that to me it's dead obvious that the name hierarchy and the set of names in the DNS are not the same thing.

Me too.  Hence the distinction with local and invalid compared to localhost.

> But you explain your reasoning on the basis that clearly they are the same set, and that they are the same set is left unexamined.

No, I'm arguing that the _existing behaviour_ according to RFCs and
long-standing practice (including that of the BSD resolver) is that
the distinction between the global DNS zones and the handling of
localhost is not observed in the way that it most certainly (by
documentation) should be for local.  I don't think it's ok to try to
legislate by RFC, and I think that this is an example of attempting to
do so: to make a name that already appears today in the DNS
(localhost) go away.  Every root server on the planet, _for its own
purposes_, ought to be authoritative for localhost.  There is no
reason therefore that it should present a lie (NXDOMAIN) when asked by
someone else.  That's different from local, where in fact in the DNS
there _is_ no zone beneath local.

I hope that at least explains what I'm worried about.  I do think that
keeping the distinction between "domains in the DNS" and "domains" is
useful.  I think we may disagree about the boundary.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 01 Feb 2018 13:50:43 -0800

Andrew Sullivan <[email-masked]> writes:

> But of course, there _is_ a name "localhost" in the DNS.
> It's already defined, in the RFCs, to this effect.

You can probably have your cake and eat it too by saying "sure,
hypothetically it exists in the DNS because it's magically reserved in
an RFC; but there is no data for it so any queries for it for any type
will always return 'does not exist'".  See!  Problem solved!

Returning anything other than NXDOMAIN and NSEC* for it is crazy,
because the reality is that the name does not exist in the root zone
data (and should not exist).  Let's not start adding special exceptions.

We could do something crazy like "return NXDOMAIN" and don't set the
AA bit, because the DNS is not authoritative for that domain (and
others, like .onion).  But I'm not sure that helps anyone, and adds
unneeded complexity to an already too complex code base.

-- 
Wes Hardaker
USC/ISI

---

From: Mark Andrews <[email-masked]>
Date: Fri, 2 Feb 2018 09:39:36 +1100

> On 2 Feb 2018, at 8:50 am, Wes Hardaker <[email-masked]> wrote:
> 

> data (and should not exist).  Let's not start adding special exceptions.

Actually the name SHOULD exist in the public root zone as a insecure
delegation to a empty zone (SOA and NS records only) so that DNSSEC works
without special processing for those that wish to support using the DNS
to resolve localhost.  This should have been done when the root zone was
initially signed.

Unsigned NOERROR NODATA for localhost/A and localhost/AAAA is a perfectly
fine answer from the global DNS.  This is ZERO NEED for NXDOMAIN to be
returned from the global DNS for those lookups. There is zero NEED for those
answers to be signed.  The global DNS doesn’t know what address should be
returned for local host.  It doesn’t have to be 127.0.0.1 or ::1.  The choice
of address is a local decision.  I’ve had localhost in a chroot virtual host
be 127.0.0.2 so that processed running in that chroot virtual host talked to
their own instance of localhost.

> unneeded complexity to an already too complex code base.

Onion is not localhost.  .onion is a protocol switch.  .localhost isn’t
a protocol switch.  There is NOTHING wrong with returning A and AAAA records
for .localhost from the local DNS resolver.  If you NEED to support types
other that A and AAAA you MUST run a local resolver to do this as there IS
NO OTHER MECHANISM TO DO THAT!

I have no problem with hostnames lookup API’s not looking for A and AAAA records
for localhost in the DNS.  I have big problems with taking it any further than
that.  

Mark

> -- 
> Wes Hardaker
> USC/ISI
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Feb 2018 19:27:20 -0600

On Feb 1, 2018, at 3:41 PM, Andrew Sullivan <[email-masked]> wrote:
> I think that this is an example of attempting to
> (localhost) go away.

Okay, but this simply isn't true.   I think you actually responded to the dig traces I sent earlier.   The root servers securely deny the existence of localhost.  Existing practice is that localhost does not appear in the DNS.   The fact that the RFCs currently differ from existing practice is a problem that the current document is trying to solve.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 2 Feb 2018 12:35:06 +1100

> On 2 Feb 2018, at 12:27 pm, Ted Lemon <[email-masked]> wrote:
> 

No. That is localhost does not exist in the ICANN root zone, not that localhost
does not appear in the DNS.  There is a distinction.

   4.  (Caching) recursive DNS servers MUST respond to queries for
       localhost names with NXDOMAIN.

Is trying to to make it “go away”.

Mark

---

From: Paul Vixie <[email-masked]>
Date: Thu, 01 Feb 2018 17:40:11 -0800

Ted Lemon wrote:
> On Feb 1, 2018, at 3:41 PM, Andrew Sullivan <[email-masked]
> <mailto:[email-masked]>> wrote:
> Okay, but this simply isn't true. I think you actually responded to the
> dig traces I sent earlier. The root servers securely deny the existence
> of localhost. Existing practice is that localhost does not appear in the
> DNS. The fact that the RFCs currently differ from existing practice is a
> problem that the current document is trying to solve.

the root zone has never supported this.

whereas, every rdns server i've operated since 1987 has supported this.

so you may be arguing past each other as to whether localhost does or 
does not "appear in the dns".

since we're talking about dig, here's mine. i do localhost with RPZ now.

> ; <<>> DiG 9.9.5-3ubuntu0.17-Ubuntu <<>> localhost
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58186
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;localhost.                     IN      A
>
> ;; ANSWER SECTION:
> localhost.              5       IN      A       127.0.0.1
>
> ;; AUTHORITY SECTION:
> dns-policy.vix.com.     30      IN      NS      localhost.
>
> ;; Query time: 47 msec
> ;; SERVER: 24.104.150.212#53(24.104.150.212)
> ;; WHEN: Thu Feb 01 17:35:27 STD 2018
> ;; MSG SIZE  rcvd: 86

i think if you want to stop people from asking the localhost question in 
dns, you can recommend that operating system libraries work that way, 
and there will probably be uptake.

but if you want to stop people from answering it, that's an on-wire 
change from "isn't causing complaints" to "unknown", which isn't strong 
motivation, and in any case, is not enforceable.

i have not seen an explaination of why you're fixing what you think is a 
bug in gethostbyname() by asking for changes to online dns configs.

-- 
P Vixie

---

From: Joe Abley <[email-masked]>
Date: Thu, 1 Feb 2018 20:46:01 -0500

> On Feb 1, 2018, at 20:27, Ted Lemon <[email-masked]> wrote:
> 

Entertaining though it is to watch everybody talk across each other, I'm running short on popcorn.

Can we take a brief pause to acknowledge that "the DNS" as a phrase is highly ambiguous and think about whether we mean the protocol, any particular implementation, any particular installation or the namespace (and if so, which one, since there are many, even if our context is a single Root Server System serving a single Root Zone, note capitals, which I think it should be).

Joe

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Feb 2018 20:03:08 -0600

> Can we take a brief pause to acknowledge that "the DNS" as a phrase is highly ambiguous and think about whether we mean the protocol, any particular implementation, any particular installation or t…

This is the distinction I was trying to hit (and that I think Andrew agreed on) when I made the distinction between the set of all domain names, and the set of names "in the DNS."

---

From: Joe Abley <[email-masked]>
Date: Thu, 1 Feb 2018 21:57:35 -0500

> On Feb 1, 2018, at 21:03, Ted Lemon <[email-masked]> wrote:
> 

Which distinction? I think I listed at least four degrees of freedom.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Feb 2018 21:32:50 -0600

> Which distinction? I think I listed at least four degrees of freedom.

Good point.   Possibly that is where the disconnect is.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 2 Feb 2018 13:05:34 -0500

On Thu, Feb 01, 2018 at 08:46:01PM -0500, Joe Abley wrote:
> 
> Can we take a brief pause to acknowledge that "the DNS" as a phrase is highly ambiguous

Yes.

> and think about whether we mean the protocol,

I mean this and 

> any particular installation or the namespace (and if so, which one, since there are many, even if our context is a single Root Server System serving a single Root Zone, note capitals, which I think it should be).

this but

> any particular implementation, 
> 

not this.

That is, I think that localhost is a DNS name in the context of the
Internet DNS root zone.  I think that because RFC 2606 and RFC 6761
say so, and because I was under the impression that the Internet root
zone operated by IANA still conforms to RFCs.  It's apparent now to
me, however, that the Internet root does not actually answer for
localhost.  I find this surprising and wrong.  It is also possibly
part of the reason for the complaint that people can't rely on the
name "localhost", since a query to the root for that name will get a
cacheable response saying authoritatively that the name does not
exist.  I don't know whether that _is_ part of the problem, of course.
I note that SAC045 observes that localhost was in the top 10 "invalid
TLDs" queried between 2006 and 2009.  (I realise now that when that
came out I didn't check to see whether the root was responding as RFC
6761 said it should.  This was plainly a mistake on my part.)

As Mark says elsewhere in this thread, localhost is not a protocol
switch.  It's a name in the context of the global, Internet DNS;
respoding authoritatively with NXDOMAIN is therefore wrong.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Bob Harold <[email-masked]>
Date: Fri, 2 Feb 2018 13:25:54 -0500

On Thu, Feb 1, 2018 at 4:26 PM, Ted Lemon <[email-masked]> wrote:

> As a general principle, when what the RFC says to do is not the right
> thing to do, the solution is to update the RFC, not to ignore the problem.
>
>
> Yes, I will admit I was a bit surprised that you put it that way, although
> as you say, your position is more clear in your formal review of the
> document.
>
> As for why I responded to this and not to the formal review, the answer is
> that the formal review was a bit overwhelming.  You made a lot of
> assertions of fact that didn't sound like fact to me—they sounded like
> strongly-held opinion.   You are a much more experienced DNS expert than I
> am, so for me to argue you away from those opinions is a tall order—I don't
> think you've really expressed the underlying belief that is the keystone to
> the whole edifice.
>
> The problem I have is that to me it's dead obvious that the name hierarchy
> and the set of names in the DNS are not the same thing.   We've had that
> discussion before.   We even published a document about it, which hasn't
> quite made its way out of the RFC editor queue yet.   It seems to me that
> it is demonstrably the case that these two sets are disjoint.
>
> But you explain your reasoning on the basis that clearly they are the same
> set, and *that* they are the same set is left unexamined.   So if we were
> to succeed in understanding why we disagree on this point, it would be
> necessary to dig down into that.
>
> Having seen you give keynotes at the plenary, I know that you are deeply
> concerned about computer security.   The reason that I am in favor of the
> behavior I'm propounding is that I think it closes a small security gap
> through which a truck might some day be driven, to our woe.   So to me, the
> need to leave that gap, which I admit is small, open, seems inconsistent
> with what I know of you.
>
> So clearly you value this idea that localhost is a name that exists in the
> DNS, even though it doesn't exist in the DNS.   It might be fruitful to
> explore that further.   It might also be a waste of time.   I don't
> honestly know.   But that is, I think, the key to our disagreement.
>

Could someone explain the security problem?  If it really is bigger than
the problems that will be caused by changing resolvers to answer with
NXDOMAIN, then you might convince me.

-- 
Bob Harold

---

From: Mark Andrews <[email-masked]>
Date: Sat, 3 Feb 2018 07:11:33 +1100

The problem is that search lists are being applied when “localhost” is being entered into name lookup APIs and is being matched against localhost.example which isn’t expected to  to a address on the current machine and that the search list may be auto constructed or come from a untrusted source.

There is also a small risk that hotspots will return something other than a local address if a address lookup for .localhost is made. 

This is all in the context of processing  urls.

Localhost is the last remanent of the pre hierarchical host scheme. 

The risks are eliminated if the name APIs use local lookup sources in those contexts.

Then you have legacy clients. As long as the servers for the namespace on the public Internet don’t return A or AAAA records for localhost the issue is addressed there.

You then have the recursive server where you would like it, by default, return a answer without contacting the root servers.  The only safe way to do that is to have it serve a empty zone for localhost.  As this zone isn’t linked into the global DNSSEC chain of trust the root zone needed a insecure delegation for localhost. 

-- 
Mark Andrews

> On 3 Feb 2018, at 05:25, Bob Harold <[email-masked]> wrote:
> 
> 
> Could someone explain the security problem?  If it really is bigger than the problems that will be caused by changing resolvers to answer with NXDOMAIN, then you might convince me.  
> 
> -- 
> Bob Harold
>

---

From: Lanlan Pan <[email-masked]>
Date: Sun, 04 Feb 2018 03:31:51 +0000

Mark Andrews <[email-masked]>于2018年2月3日周六 上午4:11写道：

> The problem is that search lists are being applied when “localhost” is
> being entered into name lookup APIs and is being matched against
> localhost.example which isn’t expected to  to a address on the current
> machine and that the search list may be auto constructed or come from a
> untrusted source.
>

If only consider about http: http://seclists.org/bugtraq/2008/Jan/270
Web browser can also ban this "localhost.example".
CA Single Sign-On might help to solve the "same site" cookie expose problem.

> There is also a small risk that hotspots will return something other than
> a local address if a address lookup for .localhost is made.
>
> Then you have legacy clients. As long as the servers for the namespace on
> the public Internet don’t return A or AAAA records for localhost the issue
> is addressed there.
>
> You then have the recursive server where you would like it, by default,
> return a answer without contacting the root servers.  The only safe way to
> do that is to have it serve a empty zone for localhost.  As this zone isn’t
> linked into the global DNSSEC chain of trust the root zone needed a
> insecure delegation for localhost.
>
>
>
> --
> Mark Andrews
>
>> Yes, I will admit I was a bit surprised that you put it that way,
>> although as you say, your position is more clear in your formal review of
>> the document.
>>
>> As for why I responded to this and not to the formal review, the answer
>> is that the formal review was a bit overwhelming.  You made a lot of
>> The problem I have is that to me it's dead obvious that the name
>> hierarchy and the set of names in the DNS are not the same thing.   We've
>> had that discussion before.   We even published a document about it, which
>> hasn't quite made its way out of the RFC editor queue yet.   It seems to me
>> that it is demonstrably the case that these two sets are disjoint.
>>
>> But you explain your reasoning on the basis that clearly they are the
>> same set, and *that* they are the same set is left unexamined.   So if
>> we were to succeed in understanding why we disagree on this point, it would
>> be necessary to dig down into that.
>>
>> So clearly you value this idea that localhost is a name that exists in
>> the DNS, even though it doesn't exist in the DNS.   It might be fruitful to
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Feb 2018 13:49:44 +1100

> On 4 Feb 2018, at 2:31 pm, Lanlan Pan <[email-masked]> wrote:
> 
> 
> 

We may as well ban www.example because that can return 127.0.0.1 as well. :-)

The first step to fixing this is to record the address that cookies are learnt
from and not allow them to be sent to address with a different scope.  This
would address this issue as www.paypal.com has a different address scope
to localhost.paypal.com.  This however isn’t something for dnsop.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 4 Feb 2018 23:20:09 -0500

> We may as well ban www.example because that can return 127.0.0.1 as well. :-)

www.example.com <http://www.example.com/> is never presumed to be local.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Feb 2018 16:18:10 +1100

> On 5 Feb 2018, at 3:20 pm, Ted Lemon <[email-masked]> wrote:
> 
> www.example.com is never presumed to be local.

And localhost.example.com isn’t local either.  The problem is that either of them
can be a non-global scope address.

The original problem is that HTTP doesn’t specify that names learn across the
wire, including from on disk html files, need to be treated as absolute names.
This is HTTP’s mess due to allowing relative names in what is transmitted over
the wire.  This should be sent back to HTTP say FIX YOUR INSECURE PROTOCOL.

The second bugtraq issue is also HTTP’s insecure security model that doesn’t
take into account that addresses have scopes.  Again that is for HTTP to fix.

Mark

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Feb 2018 01:10:10 -0500

> the wire.  This should be sent back to HTTP say FIX YOUR INSECURE PROTOCOL.

That's totally orthogonal to the question we are considering.   It's also nonsense.   How does HTTP, a protocol, know the source of an IP address that it's been given by the name resolution API?   Does the API even give you a way to tell?   What you mean is that the implementation should know the difference.  This is what the document is doing.   It's saying that the API should never look this name up in the DNS.

> take into account that addresses have scopes.  Again that is for HTTP to fix.

HTTP should certainly be smart about scopes, and I would argue that "machine scope" is not a scope in which connections should be assumed to be trustworthy, so indeed in a sense that you are right.

But the reason for wanting the DNS to not return answers for localhost is that implementations may get this wrong, and if they do we want it to fail safe.   So again, your premise is valid, but doesn't apply.

As for search lists, I think it's reasonable to say that search lists, which are not part of the DNS protocol, should not be applied to the bare label 'localhost.'   If the document said that DNS servers should treat FQDNs containing the label 'localhost' specially other than when it is the top-level label, that would be wrong.   But it doesn't say that.   It just specifies the handling of localhost with respect to searchlists, and what it says is correct and important.   If I can supply you a search list and use that to trick you into connecting to a remote service rather than a local one, that's a significant attack surface.

---

From: Mark Andrews <[email-masked]>
Date: Mon, 5 Feb 2018 17:51:30 +1100

> On 5 Feb 2018, at 5:10 pm, Ted Lemon <[email-masked]> wrote:
> 
> That's totally orthogonal to the question we are considering.

No it is not! The browser knows where the name came from.

If HTTP treated ALL NAMES AS ABSOLUTE then href="http://localhost/" would result
in EXACTLY ONE possible lookup in the DNS, /etc/hosts, NIS(YP), LDAP etc.  Similarly href=“http://some.partially.complete.name/“ won’t resolve to
some.partially.complete.name.example.com when run by a employee of example.com.

HTTP is a security nightmare because it is specified that those names may not be
absolute.  Fix that security hole and there is no need to touch this draft for
the reason it was brought up.

>   It's also nonsense.   How does HTTP, a protocol, know the source of an IP address that it's been given by the name resolution API?   Does the API even give you a way to tell?   What you mean is that the implementation should know the difference.  This is what the document is doing.   It's saying that the API should never look this name up in the DNS.

SMTP all names are absolute. You call the name API’s with searching disabled.
The implementation is broken is search is enabled.

HTTP names may be relative. You don’t call the name API’s with searching disabled
and you get a security mess as a result.

STOP SEARCHING!!!!  IT IS NOT NEEDED.

> But the reason for wanting the DNS to not return answers for localhost is that implementations may get this wrong, and if they do we want it to fail safe.   So again, your premise is valid, but doe…

Just fix the browsers.  IT IS NOT THE DNS’S JOB TO FIX UP HTTP’S MESS
and in doing so BREAK OTHER THINGS!!!!!!!!!!!!

> As for search lists, I think it's reasonable to say that search lists, which are not part of the DNS protocol, should not be applied to the bare label 'localhost.'   If the document said that DNS s…

Search lists should not be applied to any name learnt over the wire.

---

From: Matthew Kerwin <[email-masked]>
Date: Mon, 5 Feb 2018 18:28:14 +1000

If HTTP treated ALL NAMES AS ABSOLUTE then href="http://localhost/" would
result
in EXACTLY ONE possible lookup in the DNS, /etc/hosts, NIS(YP), LDAP etc.
Similarly href=“http://some.partially.complete.name/“ won’t resolve to
some.partially.complete.name.example.com when run by a employee of
example.com.

HTTP is a security nightmare because it is specified that those names may
not be
absolute.  Fix that security hole and there is no need to touch this draft
for
the reason it was brought up.

In fact it is specified that they may not be DNS names at all.  However...

RFC 3986, on which HTTP relies for the 'host' part of its URIs, says to use
"http://localhost./" for an absolute FQDN.  So it's actually the users'
problem.

But catching it somewhere convenient seems a hell of a lot less problematic
than trying to fix the users.  And catching it in DNS seems a lot less
problematic than rewriting RFC 3986 (or rewriting HTTP to not use that part
of 3986).

>   It's also nonsense.   How does HTTP, a protocol, know the source of an
IP address that it's been given by the name resolution API?   Does the API
even give you a way to tell?   What you mean is that the implementation
should know the difference.  This is what the document is doing.   It's
saying that the API should never look this name up in the DNS.

SMTP all names are absolute. You call the name API’s with searching
disabled.
The implementation is broken is search is enabled.

And if it's broken, it currently fails open. This proposal makes it fail
closed.

HTTP names may be relative. You don’t call the name API’s with searching
disabled
and you get a security mess as a result.

It can be handy, though. "http://dev01/" or "http://dev02/" is much easier
to type.

> HTTP should certainly be smart about scopes, and I would argue that
"machine scope" is not a scope in which connections should be assumed to be
trustworthy, so indeed in a sense that you are right.
>
> But the reason for wanting the DNS to not return answers for localhost is
that implementations may get this wrong, and if they do we want it to fail
safe.   So again, your premise is valid, but doesn't apply.

> As for search lists, I think it's reasonable to say that search lists,
which are not part of the DNS protocol, should not be applied to the bare
label 'localhost.'   If the document said that DNS servers should treat
FQDNs containing the label 'localhost' specially other than when it is the
top-level label, that would be wrong.   But it doesn't say that.   It just
specifies the handling of localhost with respect to searchlists, and what
it says is correct and important.   If I can supply you a search list and
use that to trick you into connecting to a remote service rather than a
local one, that's a significant attack surface.

What about the name I type in the address bar?

Cheers
-- 
Matthew Kerwin

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Feb 2018 11:52:23 -0500

> No it is not! The browser knows where the name came from.

Walk me through it.   How does the browser know where the name came from?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 5 Feb 2018 11:55:38 -0500

On Feb 5, 2018, at 3:28 AM, Matthew Kerwin <[email-masked]> wrote:
> 
> It can be handy, though. "http://dev01/ <http://dev01/>" or "http://dev02/ <http://dev02/>" is much easier to type.

"password123" is easier to type (and remember!) than "rtuzb2tZ6xbsg", too.   :)

The way to make things easier is to design better user interfaces that still fail safe, not to leave attack surfaces open for convenience' sake.

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 06 Feb 2018 04:58:34 +0000

> Walk me through it.   How does the browser know where the name came from?

we can return NXDOMAIN for localhost. , little influence.

If we decide to ban localhost.example,  there is an assumption we have
accepted: the "localhost" subdomain to 127.0.0.1 is fault, because of http
cookie flaw.
The divergence is:  where is the best postion to ban it / mitigate it ?
1) dns :  this draft.
2) browser: browser can ban the request to localhost.example, or even the
request to subdomain xxx.example whose ip address is 127.0.0.1 .
3) http protocol:  CA Single Sign-On (CA SSO) ,  Token Binding for TLS, etc.

There are some security policy effect concerns:
1) how many security accidents have caused by this "localhost.example", is
it a serious security problem with low attack cost ?
As far as I can see, this attack's successful preconditions:
- servers doesn't sperate diffferent website.
- attacker must gain the server privilege, open a unusually port to give a
local http service. ---- this is a high risk alarm trait.
- attacker must fraud users to visit the flaw url.

2) is this the most important http cookie expose disaster area ?
As far as I can see,  many recursive resolvers hijack nxdomain, and return
an A record for advertising, similar with this cookie expose and more
widely.

3) If we ban localhost.example, will the operators use another abbreviation
to replace localhost, such as "127.0.0.1 localmachine" ?
operators are usually lazy, hardly to stop search list, and might hardly to
avoid abbreviation.
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Feb 2018 00:17:06 -0500

On Feb 5, 2018, at 11:58 PM, Lanlan Pan <[email-masked]> wrote:
> If we decide to ban localhost.example,

Nobody is proposing that we ban localhost.example.

> 1) how many security accidents have caused by this "localhost.example", is it a serious security problem with low attack cost ? 

Every security exposure has zero attacks until it is first successfully attacked.   Then the floodgates tend to open! :)

---

From: Lanlan Pan <[email-masked]>
Date: Tue, 06 Feb 2018 05:39:17 +0000

> Nobody is proposing that we ban localhost.example.

Sorry for my poor english.

I mean that in  *5.2.  'localhost' labels in subdomains*
<https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02>,
localhost.example.com. => localhost.  ( equal to ban it at dns ? )

*For example, even with a searchlist of "example.com <http://example.com>"
in place for a given   network, the name "localhost" will not be resolved
as   "localhost.example.com <http://localhost.example.com>." but as
"localhost.", and   "subdomain.localhost" will not be resolved as
"subdomain.localhost.example.com <http://subdomain.localhost.example.com>."
but as "subdomain.localhost.".*

> Every security exposure has zero attacks until it is first successfully
> attacked.   Then the floodgates tend to open! :)
>

 This flood predition was published at 2008, :-)
http://seclists.org/bugtraq/2008/Jan/270
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Feb 2018 00:50:18 -0500

On Feb 6, 2018, at 12:39 AM, Lanlan Pan <[email-masked]> wrote:
> I mean that in  5.2.  'localhost' labels in subdomains <https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02>,  localhost.example.com <http://localhost.example.com/>. => localhost.  ( equal to ban it at dns ? )

The text says:

   Hosts like "localhost.example.com" and
   "subdomain.localhost.example.com" contain a "localhost" label, but
   are not themselves localhost names, as they do not fall within
   "localhost.".  Therefore, they are not directly affected by the
   recommendations in this document.  They have no resolution guarantees
   one way or another, and should not be given special treatment, either
   in DNS or in client software.

That's pretty clear.   This document is not forbidding the appearance of such names in the DNS, nor the resolution of such names.

The following paragraph says:

   Note, however, that the admonition against searchlist usage could
   affect their resolution in practice, as discussed in Section 3 <https://tools.ietf.org/html/draft-ietf-dnsop-let-localhost-be-localhost-02#section-3>.  For
   example, even with a searchlist of "example.com" in place for a given
   network, the name "localhost" will not be resolved as
   "localhost.example.com." but as "localhost.", and
   "subdomain.localhost" will not be resolved as
   "subdomain.localhost.example.com." but as "subdomain.localhost.".

Admonition might be a poor choice of words here.   Nonetheless, the point this text is making is simply that if you type in "localhost," you will always get 127.0.0.1, even if there is a searchlist for "example.com <http://example.com/>" and the name "localhost.example.com <http://localhost.example.com/>" exists.   This is explained in the text referenced above in section 3:

       Application software MUST NOT use a searchlist to resolve a
       localhost name.  That is, even if DHCP's domain search option
       [RFC3397 <https://tools.ietf.org/html/rfc3397>] is used to specify a searchlist of "example.com" for a
       given network, the name "localhost" will not be resolved as
       "localhost.example.com." but as "localhost.", and
       "subdomain.localhost" will not be resolved as
       "subdomain.localhost.example.com." but as "subdomain.localhost.".

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 9 Feb 2018 17:55:08 -0500

Hi,

> That's pretty clear.   This document is not forbidding the appearance of such names in the DNS, nor the resolution of such names.

Instead, it is wanting to have its cake and eat it too.  Because…

>    affect their resolution in practice, as discussed in Section 3

…of the "admonition" (or whatever you want to call it).  In effect,
the document requires special-casing of "localhost" as a label in
every searchlist context.

If the goal is to say, "The search list is evil, and should not be
used," then say that.  Otherwise, what this document is _really_ doing
is altering STD13's search list processing, to include special-casing
of down-tree names.  I think that is the case despite this bit:

>        [RFC3397 <https://tools.ietf.org/html/rfc3397>] is used to
>        specify a searchlist of "example.com" for a given network,
>        the name "localhost" will not be resolved as

The reason I think that is because of the earlier part:

   2.  Application software MAY recognize localhost names as special, or
       MAY pass them to name resolution APIs as they would for other
       domain names.

If you can just pass this to a resolution API, then it's actually the
resolution API that needs to know to handle the search list rules
according to this new specification (this part of the specification
does not say that you can only use the API if you can tell the API not
to use search lists, &c).

I really do sympathise with the goal of the document, but I think it
is making a bigger change than it seems to understand.  And anyway, I
don't understand how the original 6761 text is the wrong approach:
given that it isn't even being followed on the Internet today, there's
no reason to suppose that this alternative approach is going to make
things any better.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Fri, 9 Feb 2018 19:21:05 -0500

> every searchlist context.

This is really fascinating.   To me what this code requires it something like the following, in any affected stub resolver:

resolve(name):
  if (name == 'localhost'):
    return [IPv4Addr('127.0.0.1'), IPv6Addr('::1')]
  if labelcount(name) == 1:
    for domain in searchlist:
     result = resolve_dns(labelconcat(name, domain))
       if len(result) != 0:
         return result
  return resolve_dns(name)

What is needed without this restriction, is either the same code, because it's what is obvious to any thinking person (kidding!) or:

resolve(name):
  if labelcount(name) == 1:
    for domain in searchlist:
     result = resolve_dns(labelconcat(name, domain))
       if len(result) != 0:
         return result
  if (name == 'localhost'):
    return [IPv4Addr('127.0.0.1'), IPv6Addr('::1')]
  return resolve_dns(name)

So to me there is no obvious architectural superiority to what you think is correct.   It's just a question of whether to test for localhost before or after the domain search list loop.   The standard you refer to currently says:

Relative names are either taken relative to a well known origin, or to a list of domains used as a search list.  Relative names appear mostly at the user interface, where their interpretation varies from implementation to implementation, and in master files, where they are relative to a single origin domain name.  The most common interpretation uses the root "." as either the single origin or as one of the members of the search list, so a multi-label relative name is often one where the trailing dot has been omitted to save typing.

So in fact what we are saying is completely consistent with STD13, in the sense that STD13 does not require some other behavior than what we are specifying.   It's true that behaviors that are allowed by STD13 are forbidden by this document.   That's the point.  What this admonition does is to remove an ambiguity in the specification, and for good reason.

Yet to you it appears to be self-evident that the second code sample is correct, and the first is "having your cake and eating it too."   Obviously you are seeing something here that I am not.   Can you point it out?

> to use search lists, &c).

Yes, applications may anticipate broken APIs and do the right thing prophylactically.   But APIs should do the right thing anyway.   Is that what you mean with the cake bit?

>  there's

Essentially what you are saying is that because existing name servers do not take advantage of this attack surface, there is no reason to remove it.   :)

---

From: Warren Kumari <[email-masked]>
Date: Sat, 10 Feb 2018 20:21:14 +0000

On Fri, Feb 9, 2018 at 10:55 PM, Andrew Sullivan <[email-masked]> wrote:
> used," then say that.

<with no hats at all>
Interestingly enough, Steve Sheng and I wrote just such a document a
number of years ago (around the time of the initial name-collisions
drama). Even though I'm 95% sure it included the phrase "tilting at
windmills" my search foo fails me at the moment... but it basically
deprecated search list processing in the DNS.
There are many things which would be safer, less complex, and safer if
search lists didn't exist -- would people be interested in discussing
the idea, or is it just too out there?
</hats>

>  Otherwise, what this document is _really_ doing
> of down-tree names.
> I think that is the case despite this bit:
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Feb 2018 16:18:59 -0500

> the idea, or is it just too out there?

I think there's not much to discuss.   Whenever it comes up, there's a loud protest that search lists are way too convenient to deprecate, and then it gets dropped.   I'd be game to try again—it's possible that we've finally learned not to leave stupid attack surfaces open.

---

From: Joe Abley <[email-masked]>
Date: Sat, 10 Feb 2018 16:21:50 -0500

Hi Warren,

I think the advice is good, but I wonder what the practical effect of writing it down would be. I doubt it would change any of the entrenched habits in enterprise systems and networking in our remaining lifetimes, for example, but perhaps I'm just being overly grumpy and am ignorant of some important dynamic that would change for the better.

On the other hand if the goal is simply to try and ensure that future work product of the IETF doesn't depend on search list processing, perhaps that's worth writing down? If we are the intended audience and the document's purpose is to document a consensus decision, perhaps that's a reason to work on it.

Joe

> On Feb 10, 2018, at 15:21, Warren Kumari <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 10 Feb 2018 16:27:47 -0500

Well, for example, when the DHC working group was considering the search
list option for DHCPv6, I argued that there should be no such option
because search lists are bad.   My argument was rejected.   Had the IETF
officially deprecated searchlists prior to that, there would be no DHCPv6
search option, and that attack surface would not exist.

On Sat, Feb 10, 2018 at 4:21 PM, Joe Abley <[email-masked]> wrote:

> Hi Warren,
>
> I think the advice is good, but I wonder what the practical effect of
> writing it down would be. I doubt it would change any of the entrenched
> habits in enterprise systems and networking in our remaining lifetimes, for
> example, but perhaps I'm just being overly grumpy and am ignorant of some
> important dynamic that would change for the better.
>
> On the other hand if the goal is simply to try and ensure that future work
> product of the IETF doesn't depend on search list processing, perhaps
> that's worth writing down? If we are the intended audience and the
> document's purpose is to document a consensus decision, perhaps that's a
> reason to work on it.
>
>
> Joe
>
> >>> That's pretty clear.   This document is not forbidding the appearance
> of such names in the DNS, nor the resolution of such names.
> >>>
> >>

---

From: Joe Abley <[email-masked]>
Date: Sat, 10 Feb 2018 16:33:01 -0500

On Feb 10, 2018, at 16:27, Ted Lemon <[email-masked]> wrote:

> Well, for example, when the DHC working group was considering the search list option for DHCPv6, I argued that there should be no such option because search lists are bad.   My argument was rejected.   Had the IETF officially deprecated searchlists prior to that, there would be no DHCPv6 search option, and that attack surface would not exist.

I wonder whether there's a useful difference between "deprecate" (which has connotations of banning something that is in active use and is unlikely to go away) and providing architectural guidance that IETF protocols shouldn't incorporate, encourage or rely upon search list processing.

In any case, I interpret your data point as agreement with my second paragraph :-)

Joe

---

From: Warren Kumari <[email-masked]>
Date: Sat, 10 Feb 2018 21:38:54 +0000

> Hi Warren,
<obviously no hats>

> I think the advice is good, but I wonder what the practical effect of writing it down would be. I doubt it would change any of the entrenched habits in enterprise systems and networking in our rema…

Yup - hence my recollection that the document mentioned tilting at windmills.

> On the other hand if the goal is simply to try and ensure that future work product of the IETF doesn't depend on search list processing, perhaps that's worth writing down? If we are the intended au…

Ok, that might be a useful thing to do -- documenting the issues
caused by search lists, possibly recommending against using them
(look, a windmill!), and that IETF technologies shouldn't rely on them
would be a good start. I'll try to find the original document - it's
possible that we never actually hit the submit button, Steve would
know. I don't think I have the time/ energy/desire to work on it, but
if others want to take up the pen...

W

</>

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 10 Feb 2018 22:36:54 +0000

> the idea, or is it just too out there?

FWIW, I am having no success at all convincing anyone when grumbling
about all the truncated names in URLs (that rely on search lists)
at current place of work.  And, sadly, I don't think it is especially
atypical...

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 10 Feb 2018 18:52:47 -0500

Hi,

First, let me be clear that I am (personally) not now, nor have I ever
been, a member of the resolver implementation party; so my opinion is
biased about what is obvious.  If various resolver-writers were to
chime in to say that what is obvious to you is obvious to them too
(and I don't think we need perfect consensus, as usual), then I'll
cheerfully withdraw. Nobody ever wants to see samples of my C code,
including me.

> This is really fascinating.   To me what this code requires it something like the following, in any affected stub resolver:

One architectural point I _think_ I've been trying to make is exactly
that "in any affected stub resolver" is in fact the entire universe of
deployed resolvers (including stubs).  We have zero reason to suppose
that old habits will die -- hard, soft, or at all -- within another
generation, given the results we got with EDNS0.  So, I think I am
asking, "Why isn't the original 6761 advice better?"  That advice
would have the root zone return RDATA appropriate to the QNAME
"localhost" (depending on RRTYPE).  It has no advice about TTL, if I
recall correctly, so one could trivially set it to the maximum.  Maybe
if the roots did this, everyone else would follow 6761 too.

>     return [IPv4Addr('127.0.0.1'), IPv6Addr('::1')]

But what you have just done there is short-circuited the search
processing, thereby retroactively making "localhost" a restricted
_label_ in every network that relies on search processing.  Now, I
think that such networks are broken in deep ways[1].  Those ways are,
however, mostly unobserved by many network operators.  The operators we
are trying to sort out -- the ones who already aren't following 6761
-- are entirely unlikely to believe this advice either.

> So to me there is no obvious architectural superiority to what you think is correct.

I don't think it is _correct_.  I believe the existing state of
affairs is bad.  I also think that good architecture doesn't just come
along and smash existing practice, like some Corbusier Moses.  We have
an existing system, and what the document wants to do is make a number
of reservations (effectively across the entire DNS tree) in an effort
to solve a problem that would be _already solved_ by the existing RFC,
were it implemented.  But that RFC was apparently not implemented, and
therefore I think this I-D is dangerous because it entails rules about
a certain label that extend down the tree, even though it is solving a
problem that might already have been solved if 6761 were followed.  I
don't believe we should take greater action when the previous, lesser
action has not yet been implemented.

Best regards,

A

[1] To be clear, I say this with pretty full experience of my current
employer's "enterprise network(s)".  I used to think my picture of
such networks was a nasty parody, including every bad idea I could
think of.  As it turns out, I was short on bad ideas.

-- 
Andrew Sullivan
[email-masked]

---

From: Åke Nordin <[email-masked]>
Date: Sun, 11 Feb 2018 21:30:33 +0100

> at current place of work.  And, sadly, I don't think it is especially

Not atypical at all. While URL usage isn't much anylonger
where I try navigating chaos during the days, way too many
internal applications depend on short names resolving. At
least most storage mount points are specified using FQDNs
nowadays, but those names has always been controlled by
comparatively few technicians who should have known better
from the outset.

+1 to anything I can wave with when arguing against search
lists. People doesn't seem to believe me when I use
performance arguments against it.

-- 
Åke Nordin <[email-masked]>, resident Net/Lunix/telecom geek.
Netia Data AB, Stockholm SWEDEN +46704660199

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 12 Feb 2018 12:12:01 +0100

On Sat, Feb 10, 2018 at 09:38:54PM +0000,
 Warren Kumari <[email-masked]> wrote 
 a message of 97 lines which said:

> that might be a useful thing to do -- documenting the issues caused
> by search lists [...] and that IETF technologies shouldn't rely on
> them

That's certainly a better proposal than the initial one (banning
search lists).

However, I wonder if it is really IETF business? It is a local
decision, after all.

---

From: Tony Finch <[email-masked]>
Date: Mon, 12 Feb 2018 12:03:55 +0000

> every searchlist context.

The way nss-style resolvers work is to do exact match on /etc/hosts (which
with the default contents sinks localhost lookups) then go on to the DNS
where the search list is used. So there isn't any special casing, nor is
there any complication of the search list.

For the purpose of this draft, the special-use domain names checklist
does not talk about stub resolver implementations, it talks about name
resolution APIs. So it isn't necessary to worry about the search list.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: Southwest 5 to 7, becoming cyclonic 7 to severe gale 9, perhaps
storm 10 later. Moderate, becoming rough or very rough. Squally wintry
showers. Good occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 12 Feb 2018 09:51:00 -0800

> That's certainly a better proposal than the initial one (banning

there's a huge unspecified middle and edge of dns, which is the 
presentation layer. even with RFC 1535 for "ndots", there's nothing that 
tells an endpoint how to interpret unqualified or partially qualified 
names -- or how to display them. IDN made this lack of specification 
even more obvious by not outlawing the other glyphs that look like . or 
/. BIND was certainly wrong to use RFC 952 to determine what a 
"hostname" was and to apply that restriction to A/AAAA owners and 
MX/SRV/NS targets, but there was no better specification available.

> However, I wonder if it is really IETF business? It is a local

RFC's 1535 and 2292 show that endpoint behaviour, not just signaling, 
are in-scope. the IETF needs more work of this kind, since the norms 
everybody is violating (mostly without realizing it) turn out to be 
important to interoperability. that is, partially qualified names and 
unqualified names are a layering violation, not unlike putting an RFC 
1918 address into the FTP "PORT" verb.

paul mockapetris sometimes tells the story of how auto-completion was 
the motive for writing names with most-local on the left and 
most-distant on the right. my counter-observation is that when the DNS 
consisted of a dozen large sites each full of similarly named "hosts" 
that must have made more sense. now that most of the names most of us 
look up are not local and not of "hosts", the situation has reversed: 
auto-completion of .org.redbarn.www would be far easier to implement 
than of www.redbarn.org.

ted's arguments about the insecurity of "localhost" lookups are one tiny 
corner of this land-mass sized lack of presentation-layer specification. 
it turns out you should never put an unqualified name on the wire since 
the days when your RDNS did search list processing for you are long 
gone, and it turns out that "localhost" should never have search-list 
processing applied to it. those two "turns out that"'s add up to a hard 
requirement to implement localhost-to-address and address-to-localhost 
lookups in the presentation-layer side of the stub resolver, except, we 
don't define a presentation layer, so we can't.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Mon, 12 Feb 2018 12:57:55 -0500

Of course you realize that there's a fairly obvious implication to what you
just said: "we need to write another document!!11!"

:)

On Mon, Feb 12, 2018 at 12:51 PM, Paul Vixie <[email-masked]> wrote:

> tells an endpoint how to interpret unqualified or partially qualified names
> -- or how to display them. IDN made this lack of specification even more
> obvious by not outlawing the other glyphs that look like . or /. BIND was
> certainly wrong to use RFC 952 to determine what a "hostname" was and to
> apply that restriction to A/AAAA owners and MX/SRV/NS targets, but there
> was no better specification available.
>
> RFC's 1535 and 2292 show that endpoint behaviour, not just signaling, are
> in-scope. the IETF needs more work of this kind, since the norms everybody
> is violating (mostly without realizing it) turn out to be important to
> interoperability. that is, partially qualified names and unqualified names
> are a layering violation, not unlike putting an RFC 1918 address into the
> FTP "PORT" verb.
>
> paul mockapetris sometimes tells the story of how auto-completion was the
> motive for writing names with most-local on the left and most-distant on
> the right. my counter-observation is that when the DNS consisted of a dozen
> large sites each full of similarly named "hosts" that must have made more
> sense. now that most of the names most of us look up are not local and not
> of "hosts", the situation has reversed: auto-completion of .org.redbarn.www
> would be far easier to implement than of www.redbarn.org.
>
> corner of this land-mass sized lack of presentation-layer specification. it
> turns out you should never put an unqualified name on the wire since the
> days when your RDNS did search list processing for you are long gone, and
> it turns out that "localhost" should never have search-list processing
> applied to it. those two "turns out that"'s add up to a hard requirement to
> implement localhost-to-address and address-to-localhost lookups in the
> presentation-layer side of the stub resolver, except, we don't define a
> presentation layer, so we can't.
>
> --
> P Vixie
>

---

From: Suzanne Woolf <[email-masked]>
Date: Mon, 19 Feb 2018 10:00:39 -0500

Hi all,

We’ve let the discussion continue because it’s been so active, but we also haven’t forgotten we need to review and determine next steps on this draft.

Thanks for the lively discussion, and we’ll have followup shortly.

Suzanne & Tim

> On Jan 22, 2018, at 11:18 AM, Suzanne Woolf <[email-masked]> wrote:
> 
> Hi all,
> 
> This is the opening of the Working Group Last Call for "Let 'localhost' be localhost” (https://www.ietf.org/id/draft-ietf-dnsop-let-localhost-be-localhost-02.txt).
> 
> We’ll end it in two weeks, on February 5, 2018.
> 
> Please focus feedback on: Is this draft ready to go to the IESG for approval as an RFC? If not, can you suggest specific changes it needs?
> 
> The chairs need to see both positive and negative feedback, so please speak up.
> 
> 
> Thanks,
> Suzanne & Tim
> 
>