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=chapter_1
For me the most inter
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
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 o
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 unaware of
any formal model
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
wo
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 t
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
>>> infrastructure.
>>>
>>
> Te
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, Tru
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 resolver in a stub resolver is an atta
In message
, Ted Lemon writes:
> --001a11411ef6886b910543b361bc
> Content-Type: text/plain; charset=UTF-8
>
> >
> > 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 doi
>
> 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
consenting
> 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 noth
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;
> > - a recursive DNS resolver for the rest of
In message
, Ted Lemon writes:
>
> 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 th
In message
, Brian Dickson writes:
>
> On Wed, Dec 14, 2016 at 6:37 PM, Ted Lemon wrote:
>
> > 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
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
reso
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
> 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 packe
On Wed, Dec 14, 2016 at 6:37 PM, Ted Lemon wrote:
> 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.
>
Is the intent just to have a global NXDOMA
In message
, Brian Dickson writes:
>
> On Wed, Dec 14, 2016 at 5:18 PM, Mark Andrews wrote:
>
> >
> > In message > gmail.com>
> > , Brian Dickson writes:
> > >
> > > On Wed, Dec 14, 2016 at 4:09 PM, Ted Lemon wrote:
> > >
> > > > On Dec 14, 2016, at 5:04 PM, John Levine wrote:
> > > >
> > >
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
https://www.ietf.org/
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 exist
On Wed, Dec 14, 2016 at 5:18 PM, Mark Andrews wrote:
>
> In message gmail.com>
> , Brian Dickson writes:
> >
> > 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 DNSS
>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 th
>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 thin
> 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 o
> 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.
Let'
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.
In message
, Brian Dickson writes:
>
> 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
> > i
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 DNSS
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 understand that hom
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.
Regard
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 gethostbyname/getadd
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 validate.
>
> [etc]
>
>
> That is precis
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.
_
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
> >does
36 matches
Mail list logo