Re: [DNSOP] Status of "let localhost be localhost"?

In message <2ef550a8-3e55-7fa0-9e00-fdf07093b...@eff.org>, Jacob Hoffman-Andrew s writes: > On 08/02/2017 12:09 PM, Matthew Pounsett wrote: > > In the case where 'localhost' is being passed to DNS resolution > > software, a validating stub (for example inside a web browser) > Ah, this may be where

Re: [DNSOP] Status of "let localhost be localhost"?

On Wed, Aug 2, 2017 at 4:27 PM, Ted Lemon wrote: > On Aug 2, 2017, at 2:02 PM, Robert Edmonds wrote: > > draft-west-let-localhost-be-localhost-03 upgrades the requirements in > RFC 6761 §6.3 to make them much stricter, for all applications, > converting SHOULDs to MUSTs, etc. So we're not arguin

Re: [DNSOP] Status of "let localhost be localhost"?

A possibly stupid random thought: is there a strong barrier in *all* kernels which enforces 127.0.0.0/8 and ::1 to actually *have* to be local? The 240/4 problem is 5-6 lines of code in *some* UNIX. It wasn't in any sense globally applied. I suspect localhost is somewhat more strongly coded, but

Re: [DNSOP] Status of "let localhost be localhost"?

On 08/02/2017 12:09 PM, Matthew Pounsett wrote: > In the case where 'localhost' is being passed to DNS resolution > software, a validating stub (for example inside a web browser) Ah, this may be where we are finding a disconnect. I believe web browsers never operate validating stub resolvers, but g

Re: [DNSOP] Status of "let localhost be localhost"?

On Aug 2, 2017, at 2:02 PM, Robert Edmonds wrote: > draft-west-let-localhost-be-localhost-03 upgrades the requirements in > RFC 6761 §6.3 to make them much stricter, for all applications, > converting SHOULDs to MUSTs, etc. So we're not arguing about whether > localhost "should" be treated special

Re: [DNSOP] Status of "let localhost be localhost"?

On 2 August 2017 at 13:24, Jacob Hoffman-Andrews wrote: > On 08/01/2017 06:23 PM, Mark Andrews wrote: > > The query for foo.localhost doesn't need to hit-the-wire for this > > to be a issue. Ask your self why RFC 6303, Security section has > > > >As DNSSEC is deployed within the IN-ADDR.ARPA

Re: [DNSOP] Status of "let localhost be localhost"?

Ted Lemon wrote: > But we are arguing that "localhost" should be treated specially by every > piece of software that looks at it, when its default meaning is "look up > localhost in the DNS and connect to one of the addresses that you get in > response." RFC 6761 §6.3 already says that "localho

Re: [DNSOP] Status of "let localhost be localhost"?

On 08/01/2017 06:23 PM, Mark Andrews wrote: > The query for foo.localhost doesn't need to hit-the-wire for this > to be a issue. Ask your self why RFC 6303, Security section has > >As DNSSEC is deployed within the IN-ADDR.ARPA and IP6.ARPA >namespaces, the zones listed above will need to

[DNSOP] Trusting what you see - was Re: [Ext] Re: Call for Adoption: draft-wkumari-dnsop-extended-error

On 7/29/17, 06:06, "DNSOP on behalf of Shane Kerr" wrote: >... >I'm happy with error codes that are informational, but don't change client >behavior. Yes, I realize that users may be tricked, but that's also the case >today, right? If a receiver can't trust what it gets from the network, you

Re: [DNSOP] Status of "let localhost be localhost"?

william manning wrote: ... if you are concerned that completion logic is broken in resolvers and the string "localhost" is not appended to the domain, then you really are asking for the root servers to backstop the query with an entry for localhost. and for the first 20 years of the DNS, there

Re: [DNSOP] CDS/CDNSKEY RRSet authentication

Mark Andrews wrote: > > The purpose was for the CDS/CDNSKEY tools to not have to fetch the > current DNSKEY RRset to be able to validate the records provided they > have a current KSK. Oh, that's neat, thanks! Having thought about it a bit more I understand why the draft says what it does and wh

Re: [DNSOP] Status of "let localhost be localhost"?

Ted Lemon wrote: > > And you don't want to put link-local addresses in DNS, even if > it made sense to do so, so what is one to do? As far as I know it isn't even possible :-) (Some time ago I investigated support for link-local addresses in stub resolvers, and I found that it was usually broken

Re: [DNSOP] Call for Adoption: draft-wkumari-dnsop-extended-error

Viktor Dukhovni wrote: > On Mon, Jul 31, 2017 at 05:11:07PM +, Evan Hunt wrote: > > > Are there applications specifically trusting AD=1 and behaving differently > > than with AD=0? > > On Mon, Jul 31, 2017 at 02:16:37PM -0400, Paul Wouters wrote: > > > Postfix is one but last I knew only when

Re: [DNSOP] Status of "let localhost be localhost"?

On Wed, Aug 2, 2017 at 9:18 AM, Richard Barnes wrote: > > > On Wed, Aug 2, 2017 at 9:10 AM, Ted Lemon wrote: > >> On Aug 2, 2017, at 9:02 AM, Richard Barnes wrote: >> >> But of course having IP addresses in URLs is both a PITA for developers >> and an anti-pattern more generally. >> >> >> While

Re: [DNSOP] Status of "let localhost be localhost"?

Wow. That was horribly-formatted. Apologies for the iPad MIME-crime. > On Aug 2, 2017, at 14:34, Joe Abley wrote: > > Hi Mike, > > On Aug 2, 2017, at 09:54, Mike West wrote: > > What would you like to see in the document in order to address this concern? > A requirement that a `localhost` zo

Re: [DNSOP] Status of "let localhost be localhost"?

On Wed, Aug 2, 2017 at 9:34 AM, Joe Abley wrote: > Hi Mike, > > On Aug 2, 2017, at 09:54, Mike West wrote: > > What would you like to see in the document in order to address this > concern? A requirement that a `localhost` zone be created and delegated as > an insecure delegation, using some of

Re: [DNSOP] Status of "let localhost be localhost"?

Hi Mike, On Aug 2, 2017, at 09:54, Mike West wrote: > What would you like to see in the document in order to address this concern? > A requirement that a `localhost` zone be created and delegated as an insecure > delegation, using some of the language from the draft above (e.g. "This > delega

Re: [DNSOP] Status of "let localhost be localhost"?

On Wed, Aug 2, 2017 at 9:10 AM, Ted Lemon wrote: > On Aug 2, 2017, at 9:02 AM, Richard Barnes wrote: > > But of course having IP addresses in URLs is both a PITA for developers > and an anti-pattern more generally. > > > While true, I would argue that this is actually a problem. E.g., I > actu

Re: [DNSOP] Status of "let localhost be localhost"?

On Aug 2, 2017, at 9:07 AM, Mike West wrote: > I was typing basically this when Richard's message came in. So I'll simply > add that Problem 8 in > https://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-09#section-5 >

Re: [DNSOP] Status of "let localhost be localhost"?

On Aug 2, 2017, at 9:02 AM, Richard Barnes wrote: > But of course having IP addresses in URLs is both a PITA for developers and > an anti-pattern more generally. While true, I would argue that this is actually a problem. E.g., I actually literally cannot surf to a link-local URL without havin

Re: [DNSOP] Status of "let localhost be localhost"?

On Wed, Aug 2, 2017 at 8:48 AM, Ted Lemon wrote: > On Aug 2, 2017, at 8:40 AM, Richard Barnes wrote: > > The underlying need here is that application software would like to make > use of the fact that it is connecting to "localhost" (vs. other domain > names) to make security decisions based on

Re: [DNSOP] Status of "let localhost be localhost"?

On Aug 2, 2017, at 8:40 AM, Richard Barnes wrote: > The underlying need here is that application software would like to make use > of the fact that it is connecting to "localhost" (vs. other domain names) to > make security decisions based on whether traffic is going to leave the host. > So if

Re: [DNSOP] Status of "let localhost be localhost"?

On Wed, Aug 2, 2017 at 6:39 AM, william manning wrote: > localhost is just a string, like www or mail or supralingua. A DNS > operator may > chose to map any given string to any given IP address. restricting ::1 > so that it never leaves > the host is pretty straight forward. if I map localh

Re: [DNSOP] Status of "let localhost be localhost"?

localhost is just a string, like www or mail or supralingua. A DNS operator may chose to map any given string to any given IP address. restricting ::1 so that it never leaves the host is pretty straight forward. if I map localhost to 3ffe::53:dead:beef and NOT ::1 in my systems, why should you