Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Bill, At IETF 96 in Berlin, Warren gave a presentation discussing how Google is using this in their recursive servers. Here's the link to the recorded video for the whole dnsop session: http://recs.conf.meetecho.com/Playout/watch.jsp?recording=IETF96_DNSOP=chapter_1 For me the most interesting

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Moin! On 17 Dec 2016, at 20:25, David Conrad wrote: I presume NSEC Aggressive Use will significantly reduce the amount of crap hitting the root servers. There are other ways of reducing the crap to the root servers (RFC 7706). I don't think NSEC Agressive use will reduce crap a lot as if I

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

David, it would seem that fact-driven processes might serve the operational ecosystem better than SWAG, don't you agree? Warren, do you have, even antecdotal data on the impact of aggressive NSEC and traffic to the roots, that would inform this discussion (maybe). At least it would give the root

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Bill, On Dec 17, 2016, at 11:36 AM, william manning wrote: > Is there any public data to support the presumptions of excess capacity at > the roots and the impact of NSEC aggressive use on the DNS? Warren provided some interesting anecdotes at the last IEPG, but I'm

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Is there any public data to support the presumptions of excess capacity at the roots and the impact of NSEC aggressive use on the DNS? I know that in the previous century, punting on operational impact by guessing about outcomes was common. I thought the IETF had moved away from SWAG and was

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

I presume NSEC Aggressive Use will significantly reduce the amount of crap hitting the root servers. Given how much capacity the root servers already have to provision to deal with that crap, I don't think a massive increase in legitimate (NSEC Aggressive Use-implementing) resolvers will move

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Billions and billions of them? How often do they query the root, do you think, compared to a stub resolver that did recursion itself? On Thu, Dec 15, 2016 at 3:57 PM, John R Levine wrote: > Putting an iterative resolver in a stub resolver is an attack on the DNS >>>

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Putting an iterative resolver in a stub resolver is an attack on the DNS infrastructure. Ted might want to alert all of the BSD and linux distros that default to running a copy of bind or unbound answering queries on 127.0.0.1. Regards, John Levine, jo...@taugh.com, Taughannock Networks,

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

In message <4195dba6-6eae-45ce-ad61-9236c6212...@google.com>, james woodyatt wr ites: > > On Dec 15, 2016, at 06:35, Ted Lemon wrote: > > [Mark Andrews wrote:] > > Why shouldn't a iterative resolver work if we can make it work? > > > > Putting an iterative

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

In message

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

> > Why shouldn't a iterative resolver work if we can make it work? > Putting an iterative resolver in a stub resolver is an attack on the DNS infrastructure. If you are doing it because you are testing some theory in an experimental jig, that's perfectly fine; in that case, you are a

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

> So far so good. The problem is a (largely hypothetical at this point) > stub resolver that wants to do DNSSEC verification of the results the > router gives it. Yes, I'm following this discussion with interest. The only bit I object to is bringing .onion into the discussion -- .homenet is

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

In message , "John R Levine" writes: > > I was under the impression that .homenet is handled entirely within the > > DNS resolver of the Homenet router, which combines: > > > > - an authoritative DNS server for .homenet; > > - a hybrid mDNS proxy; > >

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

In message

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

In message

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

A stub resolver is expected to query a caching resolver, not the root. So all that is required for this to work is that the resolver advertised on the homenet claim authority for the zone, and that there be an unsecured delegation that validates that the homenet resolver can give to the stub

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

I was under the impression that .homenet is handled entirely within the DNS resolver of the Homenet router, which combines: - an authoritative DNS server for .homenet; - a hybrid mDNS proxy; - a recursive DNS resolver for the rest of the namespace. So far so good. The problem is a (largely

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

> On the computers I know, the stub resolver is in one shared library and > the SOCKS proxy is in another. What's the difference? The SOCKS library uses a completely different data transport (one that is circuit-switched and layered over TCP), with very different capabilities from the usual

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Brian, there's no need for the complexity you are describing. The unsecured delegation of .homenet would just point to AS112. Any trust anchor bootstrapping would not involve the root at all. ___ DNSOP mailing list DNSOP@ietf.org

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

You would need a special resolver to _validate_ .homenet automatically using a trust anchor published by the home network. You do not need a special resolver to look up names in the homenet without validation, if there is an unsecured delegation at the root. If there is a secure denial of

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

On Wed, Dec 14, 2016 at 5:18 PM, Mark Andrews wrote: > > In message

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

>RFC 7686 updates every single DNS-using application protocol, even if it >has nothing to do with tor. Now go and fix the FTP client you wrote in >1984, it violates RFC 7686. My applications call res_query() to look up and A records, so they don't work with .home, either. That horse left

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

>Now, granted, .local and .homenet require special casing in shared parts >of the protocol stack (.local in the stub resolver, .homenet in the >Homenet router's resolver), but this needs to be done just once in the >protocol stack, not in every single application. Completely unlike .onion. I

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

> requires special-case code in every single freaking DNS-speaking > application. Yeah, I'm still pissed off.) Since people seem puzzled about my rant, here's the relevant quotation from RFC 7686: Applications that do not implement the Tor protocol SHOULD generate an error upon the use

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

> This brings us to one of the knottiest parts of special use names, which > is that they're all handled differently. For .onion, it's generally > handled in a SOCKS proxy in the application, for .local it's handled by > mDNS, and for .localhost it's special cased in the stub client library.

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

On Wed, 14 Dec 2016, Ted Lemon wrote: That is precisely why we need an unsecured delegation. Except that as the [etc] said, it doesn't really solve the problem. It solves the problem of not repudiating names in the homenet. You have to have a special resolver to be able to validate them.

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

In message

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

Two conversations in one thread is confusing. There is a part which is about the name as a label. in the root? not in the root? under .arpa? which process? why? -Thats mired. I'm trying not to re-ignite flames having covered myself in petrol some time ago. There is a part which is 'can we do

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

It solves the problem of not repudiating names in the homenet. You have to have a special resolver to be able to validate them. On Wed, Dec 14, 2016 at 7:48 PM, John R Levine wrote: > But it's worse than that -- if your client software does DNSSEC >>> validation it needs to

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

But it's worse than that -- if your client software does DNSSEC validation it needs to understand that homenet is a special case and it's OK not to validate. [etc] That is precisely why we need an unsecured delegation. Except that as the [etc] said, it doesn't really solve the problem.

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

application, for .local it's handled by mDNS, and for .localhost it's special cased in the stub client library. But it isn't. Go read the library code. There isn't magic for localhost in there. The code looks in /etc/hosts before looking in the DNS (normally) if there is a

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon wrote: > On Dec 14, 2016, at 5:04 PM, John Levine wrote: > > But it's worse than that -- if your client software does DNSSEC > validation it needs to understand that homenet is a special case and > it's OK not to

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

On Dec 14, 2016, at 5:04 PM, John Levine wrote: > But it's worse than that -- if your client software does DNSSEC > validation it needs to understand that homenet is a special case and > it's OK not to validate. > [etc] That is precisely why we need an unsecured delegation.

Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

In message <20161214220428.1688.qm...@ary.lan>, "John Levine" writes: > >Here's the reasoning: Either your home router understands .homenet or > >it doesn't. If it doesn't, then your homenet shouldn't be using > >.homenet and any .homenet lookups to the real world should fail. If it >