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

From: Suzanne Woolf <[email-masked]>
Date: Mon, 22 Jan 2018 11:18:08 -0500

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

---

From: Bob Harold <[email-masked]>
Date: Mon, 22 Jan 2018 12:43:21 -0500

On Mon, 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).
>
> 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?
>
I support this.
My concerns:
Do we need to make sure stub resolvers get updated before we update DNS, to
avoid breaking things?
Do we know what current stub resolvers do?

I notice that Google DNS returns NXDOMAIN, but OpenDNS returns 127.0.0.1

-- 
Bob Harold

---

From: Ted Lemon <[email-masked]>
Date: Mon, 22 Jan 2018 13:06:48 -0500

On Jan 22, 2018, at 12:43 PM, Bob Harold <[email-masked]> wrote:
> Do we need to make sure stub resolvers get updated before we update DNS, to avoid breaking things?

I support it too.   One observation, Bob—my recollection is that when we discussed this previously, we concluded that it's probably better, if a resolver is broken, for it to fail than succeed.   IOW, at the time I didn't hear a lot of voices saying "we have to hold off on deploying this."

This is not to say that it's a bad question.   Do you have any thoughts about what the answer should be?   In particular, use cases where breaking the resolver would be worse than not breaking it?   Given the way the discussion went earlier, that would probably be the thing to bring up, if you can think of a case where this is something we ought to be working hard to avoid.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 22 Jan 2018 10:36:25 -0800

as a general principle, any time you have to reach outside of a 
connectivity boundary in order to learn how to reach inside of a 
connectivity boundary, it's a sign of bad design.

needing to talk to a root name server in order to reach a cctld name 
server so that you can talk to people inside your own country, is an 
example of this -- and adding root name servers in that country, or on 
the loopback interface, is a workaround for a bad design, and does not 
make the design good.

the same is true for needing to reach outside your own virtual cloud, or 
your laptop, or your house or office or campus or enterprise, to find 
the "delegation data" that will let you talk to inside servers in order 
to get the information you need to talk to other inside servers. many of 
us use "stub zones" to work around this bad design, but DNS itself is 
crippled by many things, and this is one of them.

needing to talk to an rdns server to figure out that localhost means ::1 
(or 127.0.0.1 on the legacy internet) is also a bad design.

a hard transition, where all RDNS servers stop answering for localhost 
as soon as possible, is what would be in my opinion the best way to 
escape the long-armed clutches of bad design.

however, RDNS operators might be worried about complaints from their end 
users, and may want to either work through a gentle transition, or more 
likely, leave all the "tough love" for their successors to implement, 
and simply never remove this, because it's not causing them any 
problems, whereas removing it definitely could cause them problems.

vixie

---

From: Jeff Hodges <[email-masked]>
Date: Tue, 23 Jan 2018 20:03:25 +0000

This is great! I can't wait for it to ship.

---

From: Petr Špaček <[email-masked]>
Date: Wed, 24 Jan 2018 17:19:12 +0100

On 22.1.2018 17:18, Suzanne Woolf wrote:
> Please focus feedback on: Is this draft ready to go to the IESG for approval as an RFC?

Yes, I've reviewed version 02 and it seems ready to me.

-- 
Petr Špaček  @  CZ.NIC

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 24 Jan 2018 20:56:20 +0000

> This is great! I can't wait for it to ship.

I am not nearly so enthusiastic about an important component of
the draft.  Specifically, I'd like to suggest that while the
requirement for recursive resolvers to return NXDOMAIN for "localhost."
is well-intentioned, it will prove counter-productive to the
motivating goals of this draft.

To whit, the stated motivation is in good measure that applications
should be able to rely on getting loopback addresses in response
to user requests to access resources located at "localhost".  And
I agree that requiring stub resolvers to short-circuit "localhost"
is a positive step in that direction.  However, I'd like to suggest
that requiring recursive resolvers to return NXDOMAIN will likely
backfire.

When the C-library (or equivalent) stub resolver has not yet been
updated to short-circuit "localhost" (the only case in which the
requirement on recursive resolvers is relevant), but a spanking
new recursive resolver starts returning "NXDOMAIN" per the draft,
the user's reaction will not be an immediate rebuild of the system
library to short-circuit "localhost".  Rather, the far more likely
outcome is that users will switch to using IP addresses, which is
precisely what the draft is trying to avoid.

Therefore, I'd like to suggest that draft should require that
loopback addresses be returned as early as possible at every layer
of the stack, the application, the stub resolver, and the iterative
resolver (everybody except the root servers).

In summary, I believe that the draft's goals would be better served
by *requiring* recursive resolvers to short-circuit the request
and return the applicable requested (A or AAAA) loopback address.

-- 
	Viktor.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 24 Jan 2018 13:38:53 -0800

viktor, i don't disagree with your goals, but i have a proposal as to 
method.

no resolver should be sending single-label names in DNS requests, period.

search list processing should not be applied to the "localhost" single 
label name, ever.

operating system lookups like gethostbyname() or similar, that are 
willing to look at the /etc/hosts or local equivalent, should be willing 
to discover any entry, even single-label names such as "localhost".

if there is no /etc/hosts or similar that can contain something like the 
"localhost" name, then the operating system library (gethostbyname or 
similar) ought to translate this to ::1 (or 127.0.0.1) in hard code.

in other words there is no situation in which NXDOMAIN should be 
encountered for the "localhost" name, because no query should ever be 
sent. and that's mostly true today. localhost is getting returned due to 
search list processing, when it's returned by DNS at all.

because i don't think outlawing the name in an RDNS responder is the 
right place for this logic, nor that these responders are likely to be 
updated soon, nor that an operator of such a server will decide that 
implementing this change is in their best interests (wrt help desk calls.)

paul

---

From: Mark Andrews <[email-masked]>
Date: Thu, 25 Jan 2018 11:48:30 +1100

> On 25 Jan 2018, at 8:38 am, Paul Vixie <[email-masked]> wrote:
> 
> viktor, i don't disagree with your goals, but i have a proposal as to method.
> 

I would qualify that as gethostbyaddr / getaddrinfo etc. should not be ….

Resolvers do more than lookup host names.

> search list processing should not be applied to the "localhost" single label name, ever.
> 
> operating system lookups like gethostbyname() or similar, that are willing to look at the /etc/hosts or local equivalent, should be willing to discover any entry, even single-label names such as "localhost".
> 
> if there is no /etc/hosts or similar that can contain something like the "localhost" name, then the operating system library (gethostbyname or similar) ought to translate this to ::1 (or 127.0.0.1) in hard code.
> 
> in other words there is no situation in which NXDOMAIN should be encountered for the "localhost" name, because no query should ever be sent. and that's mostly true today. localhost is getting returned due to search list processing, when it's returned by DNS at all.
> 
> because i don't think outlawing the name in an RDNS responder is the right place for this logic, nor that these responders are likely to be updated soon, nor that an operator of such a server will decide that implementing this change is in their best interests (wrt help desk calls.)
> paul

> 
> _______________________________________________
> 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: Paul Vixie <[email-masked]>
Date: Wed, 24 Jan 2018 17:50:26 -0800

Mark Andrews wrote:
>> On 25 Jan 2018, at 8:38 am, Paul Vixie<[email-masked]>  wrote:
>>

as others pointed out off-thread, you are right, and that's what i meant.

-- 
P Vixie

---

From: Joe Abley <[email-masked]>
Date: Wed, 24 Jan 2018 21:52:05 -0500

Hey Paul,

(with the usual apologies for the MIME-crime that follows)

> On Jan 24, 2018, at 20:50, Paul Vixie <[email-masked]> wrote:
> 
> Mark Andrews wrote:

I was about to point out that in a QNAME-minimised future, every legitimate query received by a TLD nameserver has a single-label QNAME. But now I don't have to.

> as others pointed out off-thread, you are right, and that's what i meant.

If I agree that this is a worthy goal (and I think I do, although I haven't thought it through in context very well) the obvious question is whether it's possible to get there and, if so, how.

There is an awful lot of entrenched practice (including every corporate environment I've ever worked) where a search list and single-label hostnames are either a convenient short-cut or an absolute requirement, like it or not. The collateral damage that would result from slamming that door in enough operating environments to make a difference is surely greater than customers, managers and shareholders would tolerate.

What am I missing?

Joe

---

From: Paul Vixie <[email-masked]>
Date: Thu, 25 Jan 2018 02:10:21 -0800

Joe Abley wrote:
> Hey Paul,
>
> There is an awful lot of entrenched practice (including every
> corporate environment I've ever worked) where a search list and
> single-label hostnames are either a convenient short-cut or an
> absolute requirement, like it or not. The collateral damage that
> would result from slamming that door in enough operating environments
> to make a difference is surely greater than customers, managers and
> shareholders would tolerate.
>
> What am I missing?

i'm not speaking against search lists for any single label string that 
is not "localhost". that's the detail you may have skimmed too quickly.

the internet draft being debated here should be recast as an update to 
RFC 1535 and should not mention on-the-wire behaviour at all.

-- 
P Vixie

---

From: Petr Špaček <[email-masked]>
Date: Thu, 25 Jan 2018 11:48:37 +0100

Oh, wait, I just realized one question:

What about reverse zones for "localhost" addresses specified in
https://tools.ietf.org/html/rfc6303#section-4.2
https://tools.ietf.org/html/rfc6303#section-4.3

It seems to me that it should be handled in similar way, i.e. answered
with NXDOMAIN.

RFC 6303 says that we should have empty domain for it, but this part is
confusing:
   The recommendation to serve an empty zone 127.IN-ADDR.ARPA is not an
   attempt to discourage any practice to provide a PTR RR for
   1.0.0.127.IN-ADDR.ARPA locally.

PTR is DNS-specific term, so I'm not sure if it is clumsy expression for
"stub should hardcode the answer" or something else.

Petr Špaček  @  CZ.NIC

---

From: Mark Andrews <[email-masked]>
Date: Fri, 26 Jan 2018 00:19:00 +1100

> On 25 Jan 2018, at 9:48 pm, Petr Špaček <[email-masked]> wrote:
> 

No. It says if there isn’t a zone configured then return NXDOMAIN rather than
recurse to the in-addr.arpa servers. That is different to always /just return
NXDOMAIN.

All the zones listed in RFC 6303 can be overridden locally. The point of RFC 6303
is to stop traffic going to the public server if the zones are not otherwise
configured locally.

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Jan 2018 15:56:47 +0000

> Do we know what current stub resolvers do?

Based on a few stats I gathered in September, stub resolvers already
handle localhost themselves. More details at
https://www.ietf.org/mail-archive/web/dnsop/current/msg20968.html

Regarding the draft, I have looked through it and I have one suggestion:

The second paragraph of section 5.2 (security considerations - localhost
labels in subdomains) should be beefed up. Localhost entries in subdomains
are risky so they should be discouraged - I wrote about why we deleted
ours at
http://news.uis.cam.ac.uk/articles/2017/09/01/deleting-localhost-entries-from-the-cam-ac-uk-dns-zone

I think it's misleading to say "could affect their resolution in
practice". It would be more accurate to say "in theory" because in
practice, localhost queries are already absorbed by /etc/hosts (or
equivalent) before the search list gets a look in.

So I suggest the following replacement for the second paragrph of section 5.2:

   In theory, the admonition against searchlist usage could affect their
   resolution, as discussed in Section 3; in practice, stub resolvers
   already handle queries for "localhost" as specified in this memo.

   Although localhost entries were encouraged by RFC 1537, that suggestion
   was removed from its successor RFC 1912. They are now discouraged
   because they can be used to subvert security restrictions such as the
   web browser same origin policy, especially on multi-user systems
   [http://seclists.org/bugtraq/2008/Jan/270].

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: Southwest veering northwest 5 to 7. Moderate or rough. Showers.
Good.

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Jan 2018 16:03:08 +0000

> motivating goals of this draft.

This is a legitimate worry, but it's based on incorrect information.

Stub resolvers already sink localhost queries themselves - they don't rely
on their recursive servers.

Recursive servers frequently do not implement the localhost requirement in
RFC 6761 - for example, BIND does not.

So in practice this draft is only a small tweak to current practice.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Portland, Plymouth, Biscay: West or southwest veering northwest, 5 to 7. Rough
or very rough. Thundery showers, squally at times. Mainly good.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Jan 2018 17:54:16 +0000

> is to stop traffic going to the public server if the zones are not otherwise

And this precisely where I take issue with the current draft.  It
mandates NXDOMAIN without admitting the possibility of a local
override.  I'm fine with recursive resolvers not *forwarding*
"localhost.", but forbidding local answers is I think taking it
too far and counter-productive.  If a resolver has a working
"localhost." zone that serves the expected loopback answers, it
should be free to reply with those.

Indeed I would go further, and recommend that resolvers add such
local overrides if not present, and answer accordingly.  Sure, it
would also be great if stub resolvers never asked, but just in case
they do, there's no need to punish them, that's rarely effective.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Jan 2018 17:58:07 +0000

> as others pointed out off-thread, you are right, and that's what i meant.

For the record, below are some TLDs that serve A/AAAA or MX records
for the single-label bare TLD.  Given search lists ndots, and so
on, these are often not resolvable, but there they are anyway:

    ai.                     A       209.59.119.34
    cm.                     A       195.24.205.60
    dk.                     A       193.163.102.58
    dk.                     AAAA    2a01:630:0:40::58
    gg.                     A       87.117.196.80
    je.                     A       87.117.196.80
    pa.                     A       168.77.8.43
    pn.                     A       80.68.93.100
    tk.                     A       217.119.57.22
    uz.                     A       91.212.89.8
    ws.                     A       64.70.19.33
    xn--l1acc.              A       180.149.98.78
    xn--l1acc.              A       202.170.80.40
    xn--l1acc.              A       218.100.84.27

    ai.                     MX      10 mail.offshore.ai.
    ax.                     MX      5 mail.aland.net.
    bh.                     MX      10 mail2.batelco.com.bh.
    cf.                     MX      0 mail.intnet.cf.
    dm.                     MX      10 mail.nic.dm.
    gp.                     MX      10 ns1.nic.gp.
    gt.                     MX      10 ASPMX.L.GOOGLE.COM.
    gt.                     MX      20 ALT1.ASPMX.L.GOOGLE.COM.
    gt.                     MX      20 ALT2.ASPMX.L.GOOGLE.COM.
    gt.                     MX      30 ASPMX2.GOOGLEMAIL.COM.
    gt.                     MX      30 ASPMX3.GOOGLEMAIL.COM.
    gt.                     MX      30 ASPMX4.GOOGLEMAIL.COM.
    gt.                     MX      30 ASPMX5.GOOGLEMAIL.COM.
    hr.                     MX      5 alpha.carnet.hr.
    kh.                     MX      10 ns1.dns.net.kh.
    km.                     MX      100 mail1.comorestelecom.km.
    lk.                     MX      10 malithi-slt.nic.lk.
    lk.                     MX      20 malithi-lc.nic.lk.
    mq.                     MX      10 mx1-mq.mediaserv.net.
    pa.                     MX      5 ns.pa.
    tt.                     MX      1 ASPMX.L.GOOGLE.COM.
    tt.                     MX      10 ALT1.ASPMX.L.GOOGLE.COM.
    ua.                     MX      10 mr.kolo.net.
    ws.                     MX      10 mail.worldsite.ws.

-- 
	Viktor.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Jan 2018 13:02:27 -0500

On Jan 25, 2018, at 12:54 PM, Viktor Dukhovni <[email-masked]> wrote:
> I'm fine with recursive resolvers not *forwarding*
> too far and counter-productive.

Can you talk about why you think this is important?

I ask because the point of forbidding local answers is that it's an attack surface we'd like to close.   If there's a reason not to close it, it would be good to understand the use case you have in mind in terms of how much value we would lose in exchange for the value we'd gain in closing that attack surface.

Also, it's worth bearing in mind that regardless of what this document says, you can always answer queries to 'localhost.'   Is there a reason why that's not enough to satisfy your use case?

---

From: 神明達哉 <[email-masked]>
Date: Thu, 25 Jan 2018 10:36:45 -0800

At Thu, 25 Jan 2018 16:03:08 +0000,

> on their recursive servers.

Could you be more specific about it?  It may be a minority
implementation, but I thought traditional stub resolver
implementations in BSD variants systems (getaddrinfo/gethostbyname
with the backend of libresolv) didn't hardocde special logic for
"localhost." yet.  It's true that such implementations refer to
/etc/hosts and it has system-installed mapping between 'localhost.'
and ::1 by default.  Do you mean (in addition to hardcoding the
special logic) this kind of combination of generic implementation with
default system configuration?  I'm asking this because I think the
difference between this and hardcoded implementation can matter in the
context of this draft.

--
JINMEI, Tatuya

---

From: 神明達哉 <[email-masked]>
Date: Thu, 25 Jan 2018 11:23:37 -0800

At Mon, 22 Jan 2018 11:18:08 -0500,

> approval as an RFC? If not, can you suggest specific changes it

I myself don't have a particular opinion on whether to send it to the
IESG, but I don't think it's ready for it based on my understanding of
the WG discussion so far.  In particular, I don't think I saw a wg
consensus about one major objection to the idea: "I'd like to keep my
right of configuring my DNS servers (authoritative or recursive) to
return whatever I want to 'localhost' queries".  Again, I personally
don't claim this right, but I see the concern.  If my observation is
correct and the WG has actually not reached a clear consensus on this,
I believe it should first achieve it.  If I miss a reached consensus,
I wouldn't oppose to it, but I believe the draft should discuss
how/why it justifies dismissing such concerns.

Some specific comments on the 02 version follow.

- (editorial) Section 1:
   This increases the likelihood
   that non-conformant stub resolvers will not go undetected.

  This is a kind of double negation ('not...undetected') and it was
  difficult to me to understand it on a first read.  I'd suggest
  revising it to, e.g:

   This increases the likelihood
   that non-conformant stub resolvers will go detected.

- Section 2

   The domain "localhost.", and any names falling within ".localhost.",
   are known as "localhost names".

  I'm afraid this definition can be a bit ambiguous.  It could read as
  if "a.localhost.example.' is a 'localhost name'.  I'd suggest:

   The domain "localhost.", and any names ending with "localhost.",
   are known as "localhost names".

- Section 3

   1.  Users are free to use localhost names as they would any other
       domain names.

  It's not clear to me what this sentence means.

- Section 3

   7.  DNS Registries/Registrars MUST NOT grant requests to register
       localhost names in the normal way to any person or entity.

  It's a bit awkward to me to use an RFC2119 keyword for what
  registries/registrars should (or should not) do.

- Section 5.1

   In this
   case, the requirement that the application resolve localhost names on
   its own may be safe to ignore, but only if all the requirements under
   point 2 of Section 3 are known to be followed by the resolver that is
   known to be present in the target environment.

  I don't understand this sentence, especially the phrase "if all the
   requirements under point 2 of Section 3 are known to be followed by
   the resolver".  Point 2 of Section 3 talks about application
   behavior (and I interpret "application" is a user of resolver, not
   resolver itself), so what does it mean by "known to be followed by
   the resolver"?

- Section 5.2

   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.".

  I suggest: 'as they do not end with "localhost.".' (see my comment on
  Section 2 above).

- Section 6.1

   Some application software differentiates between the hostname
   "localhost" and the IP address "127.0.0.1".

  You might also want to refer to ::1 here.

--
JINMEI, Tatuya

---

From: "Darcy Kevin (FCA)" <[email-masked]>
Date: Thu, 25 Jan 2018 19:32:41 +0000

Suggestion to the (first, Section 1) suggestion:

s/go detected/be detected/

							- Kevin

-----Original Message-----
From: DNSOP [mailto:[email-masked]] On Behalf Of ????
Sent: Thursday, January 25, 2018 2:24 PM
To: Suzanne Woolf <[email-masked]>
Cc: dnsop <[email-masked]>
Subject: Re: [DNSOP] WGLC for draft-ietf-dnsop-let-localhost-be-localhost-02

> approval as an RFC? If not, can you suggest specific changes it needs?

I myself don't have a particular opinion on whether to send it to the IESG, but I don't think it's ready for it based on my understanding of the WG discussion so far.  In particular, I don't think I saw a wg consensus about one major objection to the idea: "I'd like to keep my right of configuring my DNS servers (authoritative or recursive) to return whatever I want to 'localhost' queries".  Again, I personally don't claim this right, but I see the concern.  If my observation is correct and the WG has actually not reached a clear consensus on this, I believe it should first achieve it.  If I miss a reached consensus, I wouldn't oppose to it, but I believe the draft should discuss how/why it justifies dismissing such concerns.

- (editorial) Section 1:

- Section 2

- Section 3

- Section 3

- Section 5.1

   In this

- Section 5.2

- Section 6.1

--
JINMEI, Tatuya

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Jan 2018 20:22:36 +0000

> On 25 Jan 2018, at 18:36, 神明達哉 <[email-masked]> wrote:
> 
> default system configuration?

Exactly, yes.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Jan 2018 20:32:25 +0000

> on their recursive servers.

I don't see any mention of "localhost" in libresolv sources.  What
is true is that they generally append the default domain suffix to
"localhost", and some support a "no_tld_query" option that AFAIK is
off by default.

> RFC 6761 - for example, BIND does not.

That's fine, but I've configured plenty of recursive resolvers that
are authoritative for the "localhost" zone.  I don't why the draft
should forbid resolvers from serving such zones.

> So in practice this draft is only a small tweak to current practice.

To be clear, I support requiring a short-circuit in stub resolvers.

My objection is to requiring NXDOMAIN from recursive resolvers.
They should not forward "localhost." lookups, but they should be
able to serve local answers for this zone.

The motivation of the draft is to make "localhost" behave more
predictably.  Having resolvers provide the boilerplate replies as
a last resort is as much or more compatible with that goal than
mandating that they return NXDOMAIN.

Note also that there may be a "localhost" zone with other data for
sub-domains of "localhost".  I've often used for private MX records
on an MTA:

	example.com.localhost. IN MX 0 mx1.example.com.localhost.
	example.com.localhost. IN MX 0 mx2.example.com.localhost.
	mx1.example.com.localhost. IN A 192.0.2.1
	mx2.example.com.localhost. IN A 192.0.2.2

    with a transport entry:

	example.com relay:example.com.localhost

With localhost having local sub-domains, NXDomain is NOT an option,
though one might return NoData, it makes more sense to complete the
zone with:

	@ IN NS localhost.
	@ IN A 127.0.0.1
	@ IN AAAA ::1

Note, for example, that the SMTP client in the Postfix MTA performs
DNS lookups with the RES_DEFNAMES and RES_DNSRCH options unset (in
order to avoid unwanted search path application to MX hostnames
obtained from DNS).  Furthermore, for similar reasons, nexthop
resolution is by default exclusively via DNS, not getaddrinfo(3).
Consider that administrators may configure transport entries with
"localhost" as the nexthop domain, and you now get queries for
"localhost" sent to the local iterative resolver.  (Most Postfix
administrators use "smtp:[127.0.0.1]" instead).

Based on this draft, Postfix should probably special-case "localhost"
internally, but that's not currently the case, and if some users
choose to implement a localhost zone in their iterative resolver
there's nothing wrong with that.

--
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 25 Jan 2018 20:35:50 +0000

> Can you talk about why you think this is important?

In summary, existing "localhost" zones are fine and should not come
into a violation of a new RFC.  Secondly, returning the expected
address records at each opportunity to do so, without punting
the problem downstream is the most sensible way to achieve the
stated motivating goals.

> Also, it's worth bearing in mind that regardless of what this
> document says, you can always answer queries to 'localhost.'   Is
> there a reason why that's not enough to satisfy your use case?

If it is going to happen anyway, why forbid it?

-- 
	Viktor.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Jan 2018 15:48:35 -0500

> the problem downstream is the most sensible way to achieve the

With all due respect, that's your stated opinion.   I asked if you have some specific use case in mind where what the draft says will cause a problem.   It sounds like the answer is no, but if I'm mistaken I'd like to hear what's motivating this opinion.

> If it is going to happen anyway, why forbid it?

I think the answer is that the less it happens the better, and forbidding it is going to make it happen less.   If it's just your personal preference not to do this, then the working group isn't saying you can't make an informed decision to go against what the spec says.   We're just saying that the correct behavior is to not answer queries on localhost.

If you decide not to follow the working group recommendation, that would be you deciding that you do not agree with the consensus on what the correct behavior is.   It's still important for the working group to say what the correct behavior is (IMHO).

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Jan 2018 00:48:07 +0000

On Thu, Jan 25, 2018 at 03:48:35PM -0500, Ted Lemon wrote:

> With all due respect, that's your stated opinion.   I asked if you have
> some specific use case in mind where what the draft says will cause a
> problem.   It sounds like the answer is no, but if I'm mistaken I'd like
> to hear what's motivating this opinion.

See my other upstream message quoted below.  There are deployed
uses of local "localhost" zones, and a mandate to break them is
not well motivated in this draft.  It merely states a difficult to
justify assertion that returning NXDOMAIN will motivate adoption
of the recommendations in stub resolvers, but according to Tony's
data this is largely moot.

The minimally intrusive change is to require recursive resolvers
to not *forward* "localhost.", and *then* if they have no local
data to fall back on, return NXDOMAIN.  However, if they do
have a "localhost" zone (which arguably they should, but this
need not be the draft that promotes such action) they can and
should continue to serve it.

> I think the answer is that the less it happens the better, and forbidding
> it is going to make it happen less.

The evidence for that is rather scant.  Indeed most already return
NXDOMAIN (by forwarding to the roots, ... and getting NXDOMAIN from
there and caching it).  However some actually serve "localhost" and
there's nothing wrong with that.

Thus for resolvers that don't have a local "localhost" zone this
draft is a NOOP.  And for the few that do, it is asking them to
stop serving explicit locally configured data.

Bottom line, we have a either a NOOP or collateral damage, and no
real evidence that the damage has any benefit.

> If it's just your personal preference not to do this,

> then the working group isn't saying you can't make an
> informed decision to go against what the spec says.   We're just saying
> that the correct behavior is to not answer queries on localhost.

The correct behaviour is generally to not *forward* "localhost"
queries, but definitely "answer".  The question is whether that
answer is required to be NXDOMAIN or not.  And it is generally fine
answer with NXDOMAIN *unless* there's explicit local data for
"localhost".

A tricky corner case is what to do with recursive queries for
"localhost" that request DNSSEC (DO bit).  Perhaps the right answer
in that case is to forward to the root servers and cache the NSEC
records and RRSIGS for the full RRSIG lifetime (ignoring the TTL),
or just handle it like any other domain.  There won't be many
recursive queries for localhost with the DO bit set, and in any
case caching will cause only a trickle of queries upstream.

> If you decide not to follow the working group recommendation, that would
> be you deciding that you do not agree with the consensus on what the
> correct behavior is.   It's still important for the working group to say
> what the correct behavior is (IMHO).

It seems to me that my objection is not so radical, and that it is
premature to reject it out of hand.  I have operational experience
running ".localhost" zones and don't anything in the draft that
makes doing so a sin.

See below for some of my previous detailed discussion.

-- 
	Viktor.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Jan 2018 20:17:17 -0500

On Jan 25, 2018, at 7:48 PM, Viktor Dukhovni <[email-masked]> wrote:
> not well motivated in this draft.

Okay, so if I understand you correctly, you are saying that:

Rather than setting up a unique domain name to solve a problem you had with postfix, you used localhost, for convenience
You believe that this practice, or similar practices, are widespread

I think you acknowledge that you can still do this hack even if the document says you mustn't.

You also propose that recursive resolvers not forward localhost, but then there's actually no way to reply with anything other than NXDOMAIN, because a recursive resolver won't have authoritative information.   Maybe you mean a hybrid server that is recursive for domains for which it isn't authoritative?

Is there more?

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Jan 2018 01:37:26 +0000

On Thu, Jan 25, 2018 at 08:17:17PM -0500, Ted Lemon wrote:

> Rather than setting up a unique domain name to solve a problem
> you had with postfix, you used localhost, for convenience

I showed examples, of uses of "localhost".  Some use the TLD itself
for the usual local IPs, others employ subdomains of "localhost"
as a sensibly convenient place to park "for my eyes only" local
DNS data.  These examples are not exhaustive.

> the document says you mustn't.

You say that, and I don't deny that, but I am not saying it, because
there should be no need to ignore a MUST in an RFC just to do as
the administrator asks and serve locally configured data.

> You also propose that recursive resolvers not forward localhost, but then
> there's actually no way to reply with anything other than NXDOMAIN,

No, a resolver can return any locally configured "localhost" data.
Many resolvers (BIND, unbound, ...) can serve some local data on
the side.

> because a recursive resolver won't have authoritative information.

Well, it BIND the data would be authoritative, while in unbound
"local-data" can take a variety of forms.

> Maybe you mean a hybrid server that is recursive for domains for
> which it isn't authoritative?

Yes.  All the recursive servers I've used can also serve some local
data.  They should be able to continue to do that even when for
the "localhost" TLD.

I also note that the draft does not adequately discuss what to do
with queries with the DO bit set[1].  Presumably a forged NXDOMAIN
without appropriate root-zone NSEC records may not be adequate in
that case.  It probably (my opionion) makes more sense to obtain,
and cache the NSEC and RRSIG records from the root servers, than
to return a "bogus" reply.

-- 
	Viktor.

P.S.

[1] I expect such queries to be rare, many on this list may be
aware of my stated preference to see DNSSEC handled almost always
in a loopback iterative resolver, with applications relying on the
returned AD bit, rather than doing their own DNSSEC validation.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 25 Jan 2018 22:18:01 -0500

> DNS data.  These examples are not exhaustive.

That's not what I'm getting at.   What I'm getting at is that you are a consenting adult, and you are using localhost as a hack.   What you are doing is not the right way to do the hack—it's the expedient way to do the hack.   The right way to do the hack is with a real domain name.   You could for example use .homenet or something like it to address the problem.   Localhost is just a convenient top-level domain that you know you can safely use.

If it were the case that some end user who is not a consenting adult were going to have a problem as a result of this text, then I think that would be something we'd need to consider.   But in this case there's no problem.   If you want to do the hack, do the hack.   It's a hack.   It wasn't kosher to begin with, and this doesn't make it any less kosher.

> to return a "bogus" reply.

The draft already addresses the DNSSEC use case.   What is the failure mode that you are concerned about here?   What would go wrong?

---

From: "A. Schulze" <[email-masked]>
Date: Fri, 26 Jan 2018 07:14:17 +0100

> no resolver should be sending single-label names in DNS requests, period.
... if RD-bit is set. single-label queries to root-servers are the  
valid exception?

today I checked our data for queries to localhost. As expected they do  
happen but very rare.
So I wouldn't expect collateral damage if our resolver answer NXDOMAIN  
some day.

Every stub resolver should be smart enough to avoid unneeded network  
traffic + latency.

I support the draft.

Andreas

---

From: Petr Špaček <[email-masked]>
Date: Fri, 26 Jan 2018 12:47:29 +0100

> don't claim this right, but I see the concern.  If my observation is

Software is still free to provide knobs to deviate its behavior from
RFC, which is nothing unusual when it comes to DNS(SEC).

Is there a real problem to solve? My understanding is that this document
is stating what software should do by default.

DNS software has so many knobs which are either not described in any RFC
that I do not see why this document needs special treatment.

Petr Špaček  @  CZ.NIC

---

From: Lanlan Pan <[email-masked]>
Date: Fri, 26 Jan 2018 14:27:28 +0000

> Recursive DNS servers are required to return "NXDOMAIN" when queried for
localhost names

Why not just let Root return NXDOMAIN for  "localhost. / *.localhost.", but
also require this on recursive ? (anyway, recursive's data is from
authoritative, in theory)

For latency, reduce queries, or ... ?

Thanks.

Suzanne Woolf <[email-masked]>于2018年1月23日周二 上午12:18写道：

> localhost” (
> https://www.ietf.org/id/draft-ietf-dnsop-let-localhost-be-localhost-02.txt
> ).
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Jan 2018 16:19:33 +0000

On Thu, Jan 25, 2018 at 10:18:01PM -0500, Ted Lemon wrote:

> That's not what I'm getting at.   What I'm getting at is that you are a
> consenting adult, and you are using localhost as a hack.   What you are
> doing is not the right way to do the hack it's the expedient way to do
> the hack.

A rather impolite characterization of well motivated practice.
Serving local data for "localhost" is no more a hack than synthesizing
NXDOMAIN.  Indeed it builds on long-standing advice and practice
to implement an authoritative zone for "localhost" with contents
along the lines of:

    $ORIGIN localhost.
    @ IN SOA localhost. root.localhost. ( 1 3600 1200 604800 1200 )
    @ IN NS localhost.
    @ IN A 127.0.0.1
    @ IN AAAA ::1

Once one (and many others) is doing this anyway, it makes a great
deal of sense to augment this zone (visible only at a loopback
listening local resolver) with additional data that is "for my eyes
only".  Indeed no other zone (homenet as you suggest) is nearly as
natural in this case.  This is data for and about "localhost".

Yet, if one dismisses my extended use of the localhost zone for
various local DNS records, the original use of providing local
resolution of "localhost." remains (however rarely needed in
practice, e.g. some Postfix configurations), and need not be
proscribed by this specification.

The MUST NXDomain, should be changed to a:

     SHOULD NXDomain in the absence of locally configured data.
     Either way, recursive queries for the "localhost" zone SHOULD
     [generally?, see below] not be forwarded.

> The right way to do the hack is with a real domain name.

Well, this draft recognizes the long-established fact that "localhost"
*is* a real domainname, just one that has a local meaning on every
host, which makes it precisely suitable for the purpose to which
it was put.

> You could for example use .homenet or something like it to address the
> problem.   Localhost is just a convenient top-level domain that you know
> you can safely use.

No, "homenet" is not a private per-host domain, it is a private
site-local domain of recent vintage.  It does not have the
long-standing track-record of "localhost" as being a portable
single-host authoritative domain.  A machine that uses "localhost"
privately on the loopback interface might still want to access its
site's "homenet".

> If it were the case that some end user who is not a consenting adult were
> going to have a problem as a result of this text, then I think that would
> be something we'd need to consider.   But in this case there's no problem.
> If you want to do the hack, do the hack.   It's a hack.   It wasn't kosher
> to begin with, and this doesn't make it any less kosher.

I find this retort noticeably patronizing, I hope that's not
intentional.  The "hack" was a natural extension of well-founded
long-standing practice.

> > that case.  It probably (my opinion) makes more sense to obtain,
> The draft already addresses the DNSSEC use case.   What is the failure
> mode that you are concerned about here?   What would go wrong?

The draft does address DNSSEC in any detail, it just dismisses the
issue.  All it does is restate the fact that the root zone uses DNSSEC:

   The ".localhost" TLD is already assigned to IANA, as per [RFC2606],
   but does not have an entry in the root-zone.  This means that the
   root will return an NXDOMAIN response along with NSEC records
   constituting a secure denial of existence if queried.  That's
   consistent with the general principle that localhost names do not
   exist in the DNS, and the subsequent requirements to return NXDOMAIN
   that are laid out in Section 3.

And not surprisingly the change log shows:

    o  Explicitly waffling on DNSSEC.

This simply neglects to even consider what to do when the client's
recursive query sets the DO bit asking for DNSSEC-validation data
along with the recursive server's reply.

My suggestion is that given that such queries are by all accounts
going to be somewhat rare, and in the absence of local data, it
does no harm for the resolver in that case, instead of synthesizing
a "bogus" NXDOMAIN reply (sans valid NSEC records and RRSIGs) should
obtain, cache and serve the above mentioned root zone's DNSSEC-validated
NXDOMAIN response, this is basically status quo ante.  The synthesis
of NXDOMAIN would then be out of scope when the client requests a DNSSEC
validated response.

The DNSSEC-validated NXDomain could be cached for longer than the
advertised TTL, up to the expiration of the underlying NSEC RRSIGs,
but code to do may be not worth the effort.

If the group prefers that bogus NXDomain should be returned anyway
(in the absence of local data), the draft should at least say so,
noting clients may discard the "bogus" answer, and try another
server, and also repeat such queries more frequently.

What all this boils down to, is that I strongly support the draft's
recommendation to short-circuit A and AAAA lookups of "localhost"
in stub resolvers (DNS lookup libraries).  I also explain that
going further and requiring MUST NXDomain (for "localhost") in
recursive resolvers is undesirable, and by all accounts largely
unnecessary.  A more sensible prescription for recursive resolvers is:

     In the absence of locally configured data for "localhost",
     recursive queries that do not set the DO bit should not be
     forwarded, and NXDomain SHOULD be returned instead.

     When a recursive query does set the DO bit, the query should
     be forwarded and returned NSEC and RRSIG records cached and
     served in reply to future similar queries.  This avoids serving
     "bogus" replies to clients that are looking for DNSSEC-validated
     answers.

-- 
	Viktor.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 26 Jan 2018 08:22:18 -0800

At Fri, 26 Jan 2018 12:47:29 +0100,

> is stating what software should do by default.

Hmm, that's different from my interpretation of the draft.  According
to my usual interpretation of IETF docs, I would interpret these from
Section 3:

   3.  Name resolution APIs and libraries MUST recognize localhost names
       as special, and MUST always return an appropriate IP loopback
       address for IPv4 and IPv6 address queries and negative responses
       for all other query types.  Name resolution APIs MUST NOT send
       queries for localhost names to their configured recursive DNS
       server(s).

       As for application software, name resolution APIs and libraries
       MUST NOT use a searchlist to resolve a localhost name.

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

   5.  Authoritative DNS servers MUST respond to queries for localhost
       names with NXDOMAIN.

as these are requirements without a user-configurable knob.  If the
actual intent was just to specify the default behavior with a
configurable knob, I'd expect SHOULD-variants are used in cases like
these.

--
JINMEI, Tatuya

---

From: Petr Špaček <[email-masked]>
Date: Fri, 26 Jan 2018 17:32:33 +0100

> configurable knob, I'd expect SHOULD-variants are used in cases like

Oh, I can see your point. Let me rephrase what I'm trying to say:
I personally agree with the doc, it makes sense to me, and I do not
believe that its wording prevent anyone from adding knobs they want.
Software in the end will do whatever its developers wanted, which might
include knob to override any part of spec.

An example: RFC 4033 clearly states what should be done if result of
validation is "Bogus". Nonetheless, Unbound has "val-permissive-mode:
yes" which enables admin to pass bogus answers.

This is not to point finger to Unbound or anyone else! I'm just
demostrating that standard can be technically right, and still there can
be knobs allowing non-standard behavior. (Do not get me started about
stub zones, forwarding, ... and the other half of DNS :-))

I hope it clarifies the point.

-- 
Petr Špaček  @  CZ.NIC

---

From: Jaap Akkerhuis <[email-masked]>
Date: Fri, 26 Jan 2018 18:00:33 +0100

Petr Špaček writes:

 > <SNIP>
Note that the default setting is "val-permissive-mode: no".  It is
just a knob for all those people who want to shoot themselves in
the foot.

	jaap

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Jan 2018 12:06:28 -0500

"Hack" is an expression of praise where I learned it. But it implies that
you are using something outside of it's design envelope, which you are.

I don't want to get into a long back and forth on this. I think I
understand your objection. I don't think it's a valid objection. But it's
up to the chairs to call consensus, not up to you or me.

---

From: Petr Špaček <[email-masked]>
Date: Fri, 26 Jan 2018 18:07:34 +0100

> just a knob for all those people who want to shoot themselves in

Thank you, that's exactly my point. The doc says what is the right thing
to do in vast majority of cases (SERVFAIL for Bogus, NXDOMAIN for
localhost.) and those who know what they are doing will use knobs to do
whatever thay want. As usual.

In other words, please do not delay documents indefinitelly just because
they do not cover all conceivable use-cases. Weird stuff happens on
networks, and that's why we have all the knobs.

-- 
Petr Špaček  @  CZ.NIC

---

From: Tony Finch <[email-masked]>
Date: Fri, 26 Jan 2018 18:04:43 +0000

Viktor Dukhovni <[email-masked]> wrote:
>
> I don't see any mention of "localhost" in libresolv sources.

The places to look are in /etc/nsswitch.conf (hosts: files dns) and
/etc/hosts (the localhost lines).

> What is true is that they generally append the default domain suffix to
> "localhost"

In practice I don't see any queries like that on my recursive servers.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Shannon: Southwest 6 to gale 8. Rough or very rough. Occasional rain. Good,
occasionally poor.

---

From: Tony Finch <[email-masked]>
Date: Fri, 26 Jan 2018 18:15:49 +0000

I think the following should be amended:

Instead:

   5.  Authoritative DNS servers MUST respond to queries for localhost
       names with their usual response for an non-authoritative zone (e.g.
       REFUSED), except that if they are authoritative for the root zone
       they SHALL return NXDOMAIN.

Tony.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 26 Jan 2018 11:20:29 -0800

At Fri, 26 Jan 2018 17:32:33 +0100,

> yes" which enables admin to pass bogus answers.

It's true that an implementer sometimes even ignore MUSTs.  And it's
also true that we (the IETF) can't do anything to prevent that; after
all there's no protocol police.

IMO, however, that doesn't mean we can casually use the fact to
silence objections when the requirement level might actually be too
strong.  In my understanding and also according to my experiences,
MUST requirements are in fact very strong.  Even "I do whatever I want
no matter what the standard says"-kind of customers often accept that
something cannot be implemented when it's prohibited with a "MUST
NOT".  It's much more likely that implementations (especially
open-source kinds, which tend to respect standard more literally) do
not provide a knob to change a MUST behavior.  And, if you write your
own implementation that doesn't follow a MUST, the reputation risk is
much higher than when you are just against a SHOULD.

So, if we want to use the strongest requirement level, especially when
it's somewhat controversial, I believe that the onus is on the authors
(and the WG that supports them) to explain why that level is necessary
more carefully and in detail.  On the other hand, if we really mean
silencing arguments against the requirements with the existence of a
user-configurable knob, then IMO what we should actually do is to
loosen the requirement level so that it explicitly allows such a knob.
(I'm actually not sure whether those who showed support moving forward
definitely wants to keep the MUSTs or they can live with SHOULDs).

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Jan 2018 14:24:10 -0500

On Jan 26, 2018, at 2:20 PM, 神明達哉 <[email-masked]> wrote:
> MUST requirements are in fact very strong.

Can you talk about why you personally think MUST is too strong here?   It's interesting to discuss it on a meta-level, but I think we might get lost in the weeds doing that.   If you are feeling uneasy about this requirement, I suspect that there is a use case lurking down there somewhere under the discomfort.   Bringing it up to the surface might help.

---

From: 神明達哉 <[email-masked]>
Date: Fri, 26 Jan 2018 11:27:25 -0800

At Thu, 25 Jan 2018 20:22:36 +0000,

> > default system configuration?

Okay, then would such a system be deemed to conform to this part of
the draft?

   3.  Name resolution APIs and libraries MUST recognize localhost names
       as special, and MUST always return an appropriate IP loopback
       address for IPv4 and IPv6 address queries and negative responses
       for all other query types.

It's not clear to me, and either way I believe the draft should be
clearer on these points (see also my latest response to Petr.  If the
intent of the draft is to prohibit any user customization, it should
explicitly say so (with, IMO, some more explanation); if the intent is
to allow such customization, I believe we should actually loosen it to
SHOULDs).

--
JINMEI, Tatuya

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Jan 2018 14:40:43 -0500

> to allow such customization, I believe we should actually loosen it to

There was no clear intent at the beginning when this was an individual submission, but the discussion on the individual submission and on the call for adoption seemed to show a fairly strong consensus that looking up localhost using DNS is a significant security vulnerability, so MUST is the right language.   Of course, I was part of that consensus, so I may be biased!

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Jan 2018 19:54:54 +0000

> configurable knob, I'd expect SHOULD-variants are used in cases like

Exactly.  The MUST language is asking implementations to remove
support for the existing knobs, which should stay.

I just talked to Christos Zoulas of NetBSD, as he's also the current
(or at least recent) upstream maintainer of libresolv.  He not only
supports my view that the MUST is extraneous, but indeed also has
localhost (forward) and loopback (reverse) zones configured on his
own machines.  This practice is reasonably widespread.

I should also note that there is some confusion in recent messages
between what is a stub (DNS) resolver and higher-level name resolution
facilities such as getaddrinfo(3).  Yes, getaddrinfo(3) and friends
on modern Unix-like systems use nsswitch and typically consult the
/etc/hosts file before using DNS, but that's not what this draft
is about.  It specifically describes "stub-resolver" behaviour, not
getaddrinfo() behaviour.  The stub resolver is libresolv, and does
not presently special-case "localhost".

If the intent is to require special handling of "localhost" in the
platform's name to address lookup library (getaddrinfo(),
gethostbyname(), ...), then the draft should say so, instead of
talking about stub resolvers, which are only the DNS component of
the platform's hostname resolution stack.

-- 
	Viktor.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 26 Jan 2018 11:55:20 -0800

Ted Lemon wrote:
> On Jan 26, 2018, at 2:27 PM, 神明達哉 <[email-masked]
> <mailto:[email-masked]>> wrote:
> There was no clear intent at the beginning when this was an individual
> submission, but the discussion on the individual submission and on the
> call for adoption seemed to show a fairly strong consensus that looking
> up localhost using DNS is a significant security vulnerability, so MUST
> is the right language. Of course, I was part of that consensus, so I may
> be biased!

i was outside that consensus at the time, and remain so now. the 
security aspects aren't paramount and aren't clearly identified. this 
change could be made in the style of RFC 1535, referring only to the 
operating system API behaviour and not mentioning on-the-wire DNS 
protocol behaviour at all. to the extent that it does the latter it 
could be a strong recommendation ("SHOULD") and have the same impact.

many operators will ignore this advice no matter how it's phrased, and 
nothing bad will happen to them when they ignore it, and that's "not a 
MUST" by definition. reasons to ignore include: not wanting to give any 
of their customers any reason to call in and say "the internet is down".

the ietf is always at its best when its claims are of the form, "if you 
want to do _this_, here's a way to do it interoperably." can that be done?

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Fri, 26 Jan 2018 11:59:06 -0800

Viktor Dukhovni wrote:
...
> the platform's hostname resolution stack.

that's what it should say, and that's how it should say it. so, +1.

-- 
P Vixie

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Jan 2018 20:16:13 +0000

> > to allow such customization, I believe we should actually loosen it to

That's also my position.

> is the right language.

Agreed when it comes to requiring a localhost short-circuit in the
platform's (and perhaps also application's) name lookup software
(to be reworded more clearly to refer to that, and not stub
resolvers).

Disagreed, with respect to recursive resolvers, because the
requirement is neither necessary nor sufficient to achieve the
stated security goals, is not required for interoperability, and
is in conflict with existing uses of local data for localhost.

--
	Viktor.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Jan 2018 14:24:26 -0600

> is in conflict with existing uses of local data for localhost.

The point of the requirement is that it breaks stacks that use DNS to look up localhost.   If you think there's no risk to applications that rely on this, obviously it's not worth doing.   The reason I'm being such a stickler about this is that we have beaucoup experience over the past two decades that if there is an attack surface, somebody will come up with an attack.   It's better to fail safe than fail unsafe.   If apps are breaking all over the place because they use DNS to look up localhost, then we all win in the long run.

That said, I absolutely do not want to deprive you of the ability to do your hack.   I just don't think that the current text does that.   If the way the stack accomplishes the MUST is to have some code in nsswitch.conf that does the right thing, I think that follows the MUST.   If it were really true that that were not the case, I would agree with you.  (And as an aside, you are correct to point out the error of my statement about localhost versus home.arpa.)

The reason I drilled down into your use case is that I don't think there's ever going to be a time when Christos disables this behavior.   So I don't think this text is going to actually create an inconvenience for you.   That's not the point of writing that MUST.

Is there a way we can change what the text says so that it's sufficiently emphatic to make me happy, and sufficiently open to make you unhappy?

---

From: 神明達哉 <[email-masked]>
Date: Fri, 26 Jan 2018 14:13:36 -0800

At Fri, 26 Jan 2018 14:24:10 -0500,
Ted Lemon <[email-masked]> wrote:

> Can you talk about why you personally think MUST is too strong here?

I said it might be too strong, so it's more that I *wonder* whether it
might be too strong.  This impression comes from the observation that
while the draft uses a strong word several people hinted at
customization.  That looked odd to me - if they so strongly think it
must be a MUST, it would look more sensible to me if they said "it
MUST be that way, period <because XXX>".  It's true that there are
always people who still disagree with it and are willing to ignore the
MUST, but in that case we should rather call them a standard offender
instead of pretending to offer an option.  Stating a MUST on one hand
while hinting at violating it as a "customization" on the other looked
awkward to me, making me think the WG might actually feel it's too
strong.

> It's interesting to discuss it on a meta-level, but I think we might
> get lost in the weeds doing that.   If you are feeling uneasy about
> this requirement, I suspect that there is a use case lurking down
> there somewhere under the discomfort.   Bringing it up to the
> surface might help.

Personally, I don't mind the MUST (and for that matter I don't mind
either if it's a SHOULD).  But given that it will break existing
practices, I'd like the draft to explain the rationale in more detail.
And I'd like it to make it clearer that it intentionally plugs any
possibility of user customization, whether it's a protocol-violating
server option or a customized /etc/hosts entry.  And then let the
market decide whether to obey it.

As for specific use case, I don't have one for myself as such.  But
the discussion so far (not only in this thread but also in the past WG
discussions, which actually are the base of my own response to the LC)
seems to suggest that a non-negligible number of deployments exist.
And I just thought the current content of the draft isn't clear enough
as a message for those with the existing deployments.

BTW: in case you think if I personally don't mind I should shut up: I
observed this oddity as a weakness of the document that could make it
less convincing and more likely to be ignored.  I believe pointing it
out and possibly improving it are completely valid feedback for a
WGLC, regardless of my own personal position on the content.  Of
course, whether and how to address the feedback is up to the WG; I'm
not intending to be a blocker but are just trying to help it.

--
JINMEI, Tatuya

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 26 Jan 2018 23:03:43 +0000

On Fri, Jan 26, 2018 at 02:24:26PM -0600, Ted Lemon wrote:

> The point of the requirement is that it breaks stacks that use DNS to look
> up localhost.

Multiple participants in this discussion have pointed out that such
queries are rare.  And, we must not forget that, absent local
overrides, the iterative resolvers are *already* returning NXDomain,
because the authoritative data from the root returns NXDomain.

So what you seem to be asking for is to *require* implementations
that currently serve local data with the expected loopback addresses
(and don't forward towards the root) to stop doing as configured and
return NXDomain.  Despite the explicitly configured "knobs" that turn
on this non-default behaviour.

I claim that this is too big a hammer for too small a nail.  There
is simply no need to do this.  A clear requirement to short-circuit
localhost name -> address resolution *before* it gets to the resolver
is quite sufficient.  I'm breathlessly enthusiastic for this part
of the draft. :-)

> If you think there's no risk to applications that rely on
> this, obviously it's not worth doing.   The reason I'm being such a stickler
> about this is that we have beaucoup experience over the past two decades
> that if there is an attack surface, somebody will come up with an attack.
> It's better to fail safe than fail unsafe.   If apps are breaking all over
> the place because they use DNS to look up localhost, then we all win in
> the long run.

Reports from the field seem to indicate that this is largely a
non-problem, and perhaps the maintainers of glibc and the like will
pay attention to this specification and ensure correct localhost
resolution without asking even the (e.g. glibc) DNS stub resolver,
let alone an upstream recursive resolver.

> That said, I absolutely do not want to deprive you of the ability to do
> your hack.   I just don't think that the current text does that.

The MUST says otherwise, and if we don't mean that, then we should
not say so.

> If the way the stack accomplishes the MUST is to have some code in
> nsswitch.conf that does the right thing, I think that follows the MUST.

It follows the MUST for the part I am breathlessly enthusiastic about,
the requirements on the hostname -> address resolution library.  No
problems with that at all.  My objection all along is with the MUST
at the recursive resolver.

> The reason I drilled down into your use case is that I don't think there's
> ever going to be a time when Christos disables this behavior.   So I don't
> think this text is going to actually create an inconvenience for you.

I'm fine with MUST NOT FORWARD, except when the DO bit is set in
the query, in which case I'm inclined to say that a validated
NXDomain from the root is better than a bogus NXDomain, and
is still (or more) secure.

> Is there a way we can change what the text says so that it's sufficiently
> emphatic to make me happy, and sufficiently open to make you [not] unhappy?

Yes.  Keep the MUST for the platform library.  Downgrade the MUST for
the iterative resolver to a SHOULD (absent local data), and either
exempt DNSSEC or explain why "bogus" local NXDomain is better than
a cacheable validated NXDomain from the roots.

-- 
	Viktor.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 26 Jan 2018 18:02:00 -0600

On Jan 26, 2018, at 5:03 PM, Viktor Dukhovni <[email-masked]> wrote:
> queries are rare.

Sigh.   Yes, such queries are rare.   The things that make those queries are the things that are vulnerable.   That such queries are rare is further evidence that responding to them when they come with NXDOMAIN is a safe choice to make.

> And, we must not forget that, absent local

That's a good point, of course.   However, I think we heard in the discussion prior to adoption that this is not in fact the default behavior for all recursive resolvers.

> a cacheable validated NXDomain from the roots.

How about if it says "SHOULD" but explains what the exception is, and strongly advocates the position that only when that exception is applicable should this be treated as optional behavior.

I would say that the exception is "when answering queries for the local host" or something, but I don't understand the intricacies of your use case sufficiently to know what would satisfy it.   I thought I understood your use case to be the case where the stub resolver is on the same host as the recursive resolver, but I may have misunderstood.

The case I'm trying to exclude is the one where the recursive resolver is answering queries for hosts other than, well, localhost.

---

From: Warren Kumari <[email-masked]>
Date: Sat, 27 Jan 2018 12:56:23 -0500

> Multiple participants in this discussion have pointed out that such

<no hats>

I've somewhat lost track of which exactly "such queries" are
('localhost', '*.localhost', with or without DO bit, etc), and what we
are considering as "rare", but, as mentioned in
https://mailarchive.ietf.org/arch/msg/dnsop/k9Rec7WuLCLjLBb5hI7kynAxf3U
:
'Around 0.3% of responses from Google Public DNS are for "localhost".'

If I opened a packet of M&Ms[0] and <0.3% of them were green I'd call
green M&Ms rare, but if 0.3% of people who went swimming got eaten by
sharks I'd likely not call shark attacks rare :-p

> because the authoritative data from the root returns NXDomain.

... do they?

Google Public DNS:
$ dig  +dnssec localhost @8.8.8.8
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62555
;; AUTHORITY SECTION:
. 64929 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018012700
1800 900 604800 86400
. 64929 IN RRSIG SOA 8 0 86400 20180209050000 20180127040000 41824 .
i1JPur/fqut5...==

Verisign Public DNS:
$ dig +dnssec localhost @64.6.64.6
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8025
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
localhost. 10687 IN A 127.0.0.1

Quad9:
$ dig +dnssec localhost @9.9.9.9
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22677
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
localhost. 86170 IN A 127.0.0.1

OpenDNS:
dig +dnssec localhost @208.67.222.222
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14156
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; ANSWER SECTION:
localhost. 604800 IN A 127.0.0.1

My local BIND instance:
# dig +dnssec localhost @127.0.0.1
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62183
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;localhost.                     IN      A

;; AUTHORITY SECTION:
.                       10800   IN      SOA     a.root-servers.net.
nstld.verisign-grs.com. 2018012700 1800 900 604800 86400
.                       10800   IN      RRSIG   SOA 8 0 86400
20180209050000 20180127040000 41824 . i1JPur/fqut5jJ...

(above examples edited for readability. No queries were harmed in the
making of this).

I'm not really sure anymore who's point I'm making here, but I
disagree that localhost queries hitting the DNS is rare, and that
iterative resolvers already return NXD - some do, and some don't.

W
</no hats>

[0]: For non-Americans, M&Ms are kind of like Rowntree (now Nestlé)
Smarties[0], but much less tasty.
[1]: For American readers, Rowntree Smarties are like much much better
M&M's, and *nothing* like the US Smarties (which are mainly sugar,
citric acid and calcium stearate, but always taste like chalk to
me...).
We'll be in London soon, you should really give them a try...

-- 
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: Mark Andrews <[email-masked]>
Date: Mon, 29 Jan 2018 09:26:44 +1100

> On 27 Jan 2018, at 11:02 am, Ted Lemon <[email-masked]> wrote:
> 

Actually NXDOMAIN is the WRONG choice to make.  NXDOMAIN is driven by not
wanting to engage with ICANN and sort out the fact that the TLD is scoped for
local use and to deal with all the side effects of that come with that especially
when DNSSEC is in use.

10.IN-ADDR.ARPA is scoped for local use and a insecure delegation to a otherwise
empty zone works fine for it.  This is NO TECHNICAL REASON TO RETURN NXDOMAIN!

> That's a good point, of course.   However, I think we heard in the discussion prior to adoption that this is not in fact the default behavior for all recursive resolvers.

Local resolvers can return NODATA just as easily as NXDOMAIN by default and
that with a insecure delegation is perfectly fine.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 28 Jan 2018 22:37:39 +0000

On Fri, Jan 26, 2018 at 06:02:00PM -0600, Ted Lemon wrote:

> Sigh.   Yes, such queries are rare.   The things that make those queries
> are the things that are vulnerable.   That such queries are rare is further
> evidence that responding to them when they come with NXDOMAIN is a safe
> choice to make.

Protecting the residual cases is already covered by the draft's
requirement on the platform's resolution library to short-circuit
"localhost".  There is no need to impose a mandate to break these
cases on the recursive resolver.

> That's a good point, of course.   However, I think we heard in the
> discussion prior to adoption that this is not in fact the default behavior
> for all recursive resolvers.

Once more, *absent local overrides*, all resolvers are already
returning NXDomain.  Many resolvers don't have local overrides,
some do.

> How about if it says "SHOULD" but explains what the exception is, and
> strongly advocates the position that only when that exception is applicable
> should this be treated as optional behavior.

Sure.  The main exception is when the resolver is serving only
loopback clients.  And I am not opposed to text that discourages
"shared" recursive resolvers from serving local data for "localhost".

What remains then beyond recommending NXDomain for non-DNSSEC queries,
is a well-reasoned recommendation for what to do with DNSSEC queries
(DO bit).  My recommendation, as mentioned a few times upthread, is
to cache and serve the root zone's validated NXDomain.

> I would say that the exception is "when answering queries for the local
> host" or something, but I don't understand the intricacies of your use
> case sufficiently to know what would satisfy it.   I thought I understood
> your use case to be the case where the stub resolver is on the same host
> as the recursive resolver, but I may have misunderstood.

"Whitelisting" loopback resolvers is largely sufficient, provided that
the language is changed from MUST to SHOULD.

> > because the authoritative data from the root returns NXDomain.

Definitely, *absent local overrides"*.

> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 62555

Google has no such overrides.  And yet, localhost queries continue,
so NXDomain responses are not proving to be an effective motivation
to short-circuit the issue upstream.

> localhost. 604800 IN A 127.0.0.1

Verisign, Quad9 and OpenDNS do have the traditional "local overrides".

Perhaps when they become aware of this draft, they'll drop the
override zone, or perhaps they'll leave the short-circuit decision
to the platform library maintainers.  Time will tell.

In summary I see the following actions to move this forward:

    - Encourage (SHOULD) recursive resolvers to not serve local
      data for localhost, except perhaps when the resolver is a
      loopback only resolver.

    - Encourage (SHOULD) recursive resolvers that don't have local
      data for localhost to short-circuit insecure (no DO bit) localhost
      A/AAAA queries with NXDomain without forwarding these upstream
      to the roots.

    - Suggest that rather than returning "bogus" NXDomain responses,
      secure (DO bit set) queries should get secure NXDomain
      responses (thus forwarded to the root servers and cached).

-- 
	Viktor.

---

From: Petr Špaček <[email-masked]>
Date: Mon, 29 Jan 2018 12:45:59 +0100

> . 64929 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2018012700

To add more to this, Unbound by default returns 127.0.0.1, and so does
Knot Resolver, because both decided to respect
https://tools.ietf.org/html/rfc6761#section-6.3

This is a security hole, and again, purpose of NXDOMAIN is to make it
fail safe instead of keeping insecure stub implementations doing what
they did up until now.

So again, I support documents in its current form.

Petr Špaček  @  CZ.NIC

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Jan 2018 10:51:12 -0500

Dear colleagues,

> 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).

I have read this document.

Let me begin by saying that I am sympathetic to what the document
wants to do and why it wants to do it.  I nevertheless think the
proposal here is incorrect, and that it has bad consequences for the
DNS and for the RFC 6761 special-use registries.

I am at least a little troubled by the assertion, early in the
document, that RFC 6761 empowers anything to send queries anywhere.
This is the text in RFC 6761:

   3.  Name resolution APIs and libraries SHOULD recognize localhost
       names as special and SHOULD always return the IP loopback address
       for address queries and negative responses for all other query
       types.  Name resolution APIs SHOULD NOT send queries for
       localhost names to their configured caching DNS server(s).

That does not sound to me like "empowering" clients to send queries to
a resolver.  It sounds to me like something being advised against, and
strongly.  In RFC 2119, "SHOULD" does not mean, "This is mostly
preferable."  It means you ought to do it unless there "exist valid
reasons in particular circumstances to ignore" that constraint.

Nevertheless, people sometimes misread the SHOULD.  Perhaps the
section of RFC 6761 dealing with localhost could use the following
clarification:

   3.  Name resolution APIs and libraries SHOULD recognize localhost
       names as special and SHOULD always return the IP loopback
       address for address queries and negative responses for all
       other query types.  Name resolution APIs SHOULD NOT send
       queries for localhost names to their configured caching DNS
       server(s).  The only exception to this stricture is in the case
       where a node is known not to have a loopback interface
       configured and the local network is known to provide some
       replacement service.  For practical purposes, libraries will
       never use such functionality, and resolution API and library
       programmers are encouraged to treat these requirements and
       mandatory behaviour.

I'd even be prepared to countenance an argument that the SHOULDs
really ought to be MUSTs in this item.

I am really very troubled by the idea that any DNS server should
return RCODE 3 to a query for "localhost".  (This is items 4 and 5 in
section 3.)  This is not even wrong: the name _does_ exist, and indeed
any server on the Internet would know that (since it would itself
serve the answer _to_ itself of what localhost means; whether it
should serve it to anyone else might be a different question, but it
certainly should not respond with RCODE 3).

The draft's IANA considerations are wrong, I think, because it does
not make clear that this reservation is of the label "localhost"
anywhere in the DNS at all.  That is the consequence of item 2 under
section 3: since the bare label localhost, which is a relative name,
is treated as root-relative under all circumstances.  I am pretty sure
this is an update to STD13: I can't think of any case where relative
qualification is treated so strangely (if example.com does not get
resolution as example.com., then the fallback to the search list
happens, but not before).  This seems to be in tension with section
5.2.  I understand the goal, but I don't think it is possible to
achieve it in the DNS.

The advocacy in section 5.1, that applications should do the work
themselves, seems to me to be leading in the opposite direction to an
ostensible goal of the document.  In section 1 we see a note that
applications have hard-coded loopback addresses.  But the complexities
of resolution are such that any application in the future that is
supposed to do its own resolution might just wire up a shortcut to a
loopback addresses, thereby enshrining the very "hard coding" into
protocol-specified behaviour for applications.

I am sorry that cannot support advancing the draft in its current
state.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 29 Jan 2018 16:27:53 +0000

> fail safe instead of keeping insecure stub implementations doing what

By short-circuiting the lookup as early as possible these resovers
avoid sending the query upstream.  Thus eliminating part of the
security exposure further upstream away from the user's device.

Serving local data for "localhost" is NOT the security hole, it is
an incomplete fix, and a secure one when the resolver is responding
to loopback clients.  The hole is in the platform's libraries, and
that is the proper primary focus of the draft, not recursive
resolvers, nor even stub resolvers (the DNS portion of the platform
name resolution libraries).

If you want to remove the band-aid, that is properly a SHOULD, not
a MUST.  It is not required for interoperability, nor does it
address the security issue, [e.g. the next resolver in the forwarding
chain may still return 127.0.0.1,  or as likely or more the user
will just stop using "localhost", and hard-code IPv4: 127.0.0.1].

-- 
	Viktor.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Jan 2018 12:14:50 -0500

> include knob to override any part of spec.

The purpose of RFC 2119 language is not to make people feel better or
to provide the imaginary benefit of a stick with which to beat people
for non-conformance.  The purpose is to maximise reliable
interoperation, where "reliable" is interpreted generously to include
concern for security and privacy, and "interoperation" is interpreted
generously to include avoidance of anti-patterns in design and
deployment choices.

So the problem here is that, if people start adding local
configurations to override the proposed update to "MUST", the goals of
the document won't be realised anyway.  If on the other hand we
understand 2119 language correctly and apply it rigorously, the
failure to capture localhost at the local boundary will already be
understood as a problem (regardless of what the mechanism is by which
one gets there -- the BSD approach would be as good as any other).

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Paul Vixie <[email-masked]>
Date: Mon, 29 Jan 2018 09:42:09 -0800

chiming in for the hum:

> I am sorry that cannot support advancing the draft in its current

likewise. i'd prefer this to be crafted as operating system api 
guidance, along the lines of RFC 1535. i can't agree to on-the-wire 
changes along the lines described here.

-- 
P Vixie

---

From: Bob Harold <[email-masked]>
Date: Tue, 30 Jan 2018 10:44:37 -0500

On Mon, Jan 29, 2018 at 12:42 PM, Paul Vixie <[email-masked]> wrote:

>>> 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).
>>>
>>>
> likewise. i'd prefer this to be crafted as operating system api guidance,
> along the lines of RFC 1535. i can't agree to on-the-wire changes along the
> lines described here.
>
> --
> P Vixie
>
>
The document recommends "defense in depth" or multiple layers - asking both
applications and the operating system to return the correct answer (the IP
Address in IPv4, IPv6, and any future).  I think that should be extended to
DNS Resolvers, at a minimum.

I would prefer to extend that to the root, and have a DNSSEC signed answer,
although I realize that is difficult, and would accept the draft without
it.  But we should give some guidance for DNSSEC queries - do we give a
bogus response with the IP's, or a validated answer of NXDOMAIN ?

-- 
Bob Harold

---

From: Ted Lemon <[email-masked]>
Date: Tue, 30 Jan 2018 11:39:31 -0600

On Jan 30, 2018, at 9:44 AM, Bob Harold <[email-masked]> wrote:
> I would prefer to extend that to the root, and have a DNSSEC signed answer, although I realize that is difficult, and would accept the draft without it.  But we should give some guidance for DNSSEC queries - do we give a bogus response with the IP's, or a validated answer of NXDOMAIN ?

It is possible to produce a signed answer, because the domain doesn't exist: if you query the root and ask for a signed response, you should get one.   This response can be cached locally and returned to stub resolvers that ask for a signed response.

cavall% dig @a.root-servers.net localhost

; <<>> DiG 9.10.1b1 <<>> @a.root-servers.net localhost
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 19121
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;localhost.			IN	A

;; AUTHORITY SECTION:
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2018013001 1800 900 604800 86400

;; Query time: 1539 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Tue Jan 30 11:37:13 CST 2018
;; MSG SIZE  rcvd: 113

versus:

cavall% dig +dnssec @a.root-servers.net localhost

; <<>> DiG 9.10.1b1 <<>> +dnssec @a.root-servers.net localhost
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 29683
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1472
;; QUESTION SECTION:
;localhost.			IN	A

;; AUTHORITY SECTION:
loans.			86400	IN	NSEC	locker. NS DS RRSIG NSEC
loans.			86400	IN	RRSIG	NSEC 8 1 86400 20180212150000 20180130140000 41824 . UZH9Nl/4FLq3t5xOJvrFQzaBf5sktHJHTyHzfTCQSHGR8/0ViSlZ1FGB eac/wM4QXmDtuHaLI89zTHzsp6Bv2vVz09y/tUVgBfU4UcvkNOnSuToW fXQaB6MPlqktp9lw0ZHAk4dyOyeBz6MhI+S6BCsY978Yk5kySi/S8kuz 0p5Bc1qUWJYi3xkFUMB1PQe3OCS031ZnM1de+tjcma2EJQgNFScdJbfH 68adi2BQvdhHz0wMTjpItTWTPIEwv11KKi19SzZKEBxQPHRlNC2fVSlV bwg863ubm4lxmPEH6bdpsspKJObWYU8qC3E3KSXK6+ooBzyAVzI5ERRc yoz9zA==
.			86400	IN	NSEC	aaa. NS SOA RRSIG NSEC DNSKEY
.			86400	IN	RRSIG	NSEC 8 0 86400 20180212150000 20180130140000 41824 . e/KqZevslC6QTFyDkwWKN5XUAgTLdUiJcoQhuDKcm1H7jgXOb+FMfvbM /TrFMT+AheiN0pjN3evOrY9H0NN/4SBdrnEtPt1JV37GaQXwK3jEbB48 fLq/zKhmA1vvZY4lalToPYB1R7V4CHW7UIPbMX5HWeP178xmR0Dtc5y/ XI9gNpErCI4MkPoWEpMg4kOyBUtvOT02epRUbTrWovEM5TZkUiMLqGR1 lN09u5ARSOd06jTEhP4PtFvnzqbFMMlYWDl8P5wLzkUEDptsP2GZbFj0 kYEwvjVtihY9lwlY9Hl9r7xy4ucBNqVcZFnrnjEWxuo1vdUd0+3EjujR BplRcw==
.			86400	IN	SOA	a.root-servers.net. nstld.verisign-grs.com. 2018013001 1800 900 604800 86400
.			86400	IN	RRSIG	SOA 8 0 86400 20180212150000 20180130140000 41824 . cQULD+MOdwm2zcCes3LXD6buPnAZpfJZRU7zT7GtM4XWx+uQjfWAotkt gG6CuTzp2UvL2tqKcbHsNg7KjXycYv20OK6IBmu0/QGsSsw7hSmqUZar B1OR5oQEGJ7v+uH326YIhPyjdqJiTiZ8ka/1tVdt2vYKOSg8qVGkvSgM 72LjFAKKHVYr9GHIAqIo4ZhcnjOpP+ql33Q7MgzkS/rYhPMCmaS4TvOu ClF/YF+QxhcxSuyZLNH3TtRi+wGQpxu9bEHCd1qnuOnWNO1Kkh69zhNi NIrqkS2NE/vRkRn5QLeFKe8UCr2u4UM1tmAk9xmVtZu01M01/+WIm0tf WIt3UA==

;; Query time: 80 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Tue Jan 30 11:38:00 CST 2018
;; MSG SIZE  rcvd: 1030

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 30 Jan 2018 13:59:19 -0500

On Tue, Jan 30, 2018 at 11:39:31AM -0600, Ted Lemon wrote:
> 
> It is possible to produce a signed answer, because the domain doesn't exist

I think I was arguing yesterday that that is in fact not true.  The
domain (name) does exist, and it is defined in RFC 6761 precisely to
be special.  In addition,

> ;; WARNING: recursion requested but not available

That answer from the root is contrary to RFC 6761 section 6.3 item 5
and maybe 6.  

Because of that same section, also, signing the answer should also not
be controversial because the answer is static.  My preference,
however, would be for the root servers to REFUSE to answer such
queries.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Wed, 31 Jan 2018 10:04:03 +0000

> however, would be for the root servers to REFUSE to answer such

Won't that cause the resolver to cycle through every root server letter
hoping for one that doesn't give that answer?

Ray

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 31 Jan 2018 16:15:07 +0000

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

Yes, most likely.  I am not fond of that option.  Continuing to
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.

-- 
	Viktor.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 31 Jan 2018 11:28:04 -0800

> 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.

-- 
P Vixie