[Dnssec-deployment] secspider

[Richard Lamb]

How bout and update of this:

http://secspider.cs.ucla.edu/images/growth.png



> -----Original Message-----
> From: dnssec-deployment-bounces at dnssec-deployment.org [mailto:dnssec-deployment-bounces at dnssec-
> deployment.org] On Behalf Of Osterweil, Eric
> Sent: Monday, April 25, 2011 8:17 AM
> To: Patrik Fältström
> Cc: Lixia Zhang; Eric Osterweil; DNSSEC Deployment
> Subject: Re: [Dnssec-deployment] secspider
> 
> 
> 
> 
> On 4/25/11 11:00 AM, "Patrik Fältström" <patrik at frobbit.se> wrote:
> 
> > On 25 apr 2011, at 16.39, Osterweil, Eric wrote:
> >
> >> On 4/25/11 3:34 AM, "Patrik Fältström" <patrik at frobbit.se> wrote:
> >>
> >>> A. That there are PMTU problems.
> >>>
> >>> From poller #  PMTU problem for DNSKEYs?  Packet size that worked
> >>> 0              No                         Any
> >>> :
> >>> 8              Yes                        3
> >>>
> >>> I have tried to look at the documentation and also this presentation:
> >>>
> >>> http://www.ietf.org/proceedings/75/slides/dnsext-3.pdf
> >>>
> >>> ...and do not understand. I.e. if the PMTU is small, the IP packets will be
> >>> fragmented, so is the error that fragments are dropped?
> >>
> >> Yes.  Without trying to determine who dropped the fragments, and where, we
> >> simply report that there is no reassembled message received at that poller.
> >>
> >> You could also try our RIPE presentation (it was more verbose):
> >>    http://irl.cs.ucla.edu/talks/2009-05-RIPE-PMTU.pptx
> >
> > I am still confused as that presentation also, according to my read, claim
> > that the data size that of course should be smaller than announced EDNS0 size
> > must also be smaller than PMTU. To me that is not correct, as if the UDP
> > packet is larger than PMTU will result in fragmented UDP packets. Which are
> > fine.
> 
> It's only fine if the fragments actually get delivered and reassembled.
> What the evidence shows is that one cannot rely on this.  It "should" work,
> but it doesn't always work from every vantage point.
> 
> >
> > So we have three different sizes to talk about, and not only two:
> >
> > - Announced max reassembly size (announced in EDNS0)
> > If the amount of data sent is larger than this, TC bit is set
> >
> > - The actual size of the data sent
> >
> > - PMTU
> 
> Yes, but I don't see your point?  One would like to expect fragment
> reassembly to work, but the measurements show this is not always the case.
> 
> >
> >> Or our IMC 2008 paper where we presented a closed form to evaluate the PMTU
> >> problem:
> >>    http://irl.cs.ucla.edu/papers/imc71-osterweil.pdf
> >> Though this one might be a longer read. :)
> >>
> >>> I.e. I do not see any problems with EDNS0 size be larger than PMTU.
> >>
> >> I am not sure I understand, but this says that no matter what you set the
> >> buffer size to, the messages don't fit.  Either you get a TC bit, or you get
> >> a silent drop.
> >
> > No, you get a fragmented UDP packet.
> 
> But that does not mean the fragments are reassembled and delivered.  There
> can be many reasons for this, but the most obvious is middleboxes that are
> acting improperly.
> 
> >
> > You only get a drop if you do not receive the UDP fragments.
> 
> Well, I can speculate as to why one does get drops, but that would just be
> my speculation.  What I can say empirically is that some pollers reliably
> get drops even when all fragments are transmitted by name servers.  Thus, it
> is worth worrying about as a zone admin.
> 
> >
> >>> B. In the list of nameservers, I see two nameservers listed twice, with
> >>> different result ;-)
> >>
> >> Right, because one poller (1/9) cannot fetch the DNSKEYs (due to the PMTU
> >> problem), and this constitutes a different "view" of the name server... :)
> >
> > But what is the problem?
> 
> Unavailable DNSKEYs.  "Problem" might be overly strong (though some might
> think it is appropriate).  Thus, you can see the zone is considered to have
> deployed DNSSEC.  Just one vantage point is having trouble with that (re:
> the PMTU problem).  I think our contention is that if one poller is having
> this trouble, there may be many resolvers in similar types of networks
> experiencing the problem as well...  I.e. This is evidence of a general
> problem.
> 
> >>> In one of the instances for the same nameservers, it is said that "DNSSEC
> >>> Deployed:" is "No".
> >>
> >> Yup.
> >>
> >>> Does anyone know what "DNSSEC Deployed" means?
> >>
> >> http://secspider.cs.ucla.edu/about.html
> >
> > The word "deployed" does not exist on that page. I did look at it :-)
> 
> Yes, that's old text, sorry (I thought you just wanted to understand the
> checking process).  The discussion on the "about" page doesn't mention that
> label, but that is what it is referring to.  Mia culpa. :)
> 
> >
> >> It means that not all of our checks were passed.
> >
> > But wait, have a look at this page again:
> >
> > http://secspider.cs.ucla.edu/frobbit-se--zone.html
> >
> > Note that two of the nameservers are listed twice.
> >
> > In one of the cases for each one of them, the result is "DNSSEC is not
> > deployed". In the other it is.
> 
> That's not what I see.  I see " ns1.frobbit.se." -> DNSSEC deployed = No and
> "ns.cafax.se." -> DNSSEC deployed = NO, but the other views of these NSes
> show DNSSEC enabled = Yes.  Can you double check?
> 
> >
> > First I do not understand why the same nameserver is listed twice, and
> > secondly how the two instances can have different result.
> 
> It's not a great interface... It hasn't kept up (though v3 will be much
> better).  However, what it is _trying_ to show is that some vantage points
> see fully DNSSEC enabled and available nameservers.  In your case, one
> vantage point does not see this.  Thus, the less-than-great presentation
> shows each unique view of the name servers.
> 
> Eric
> 
> >
> >> In this case, the PMTU
> >> failure is causing that view's problem .  I do apologize for the old
> >> interface, but the new one is almost ready and provides a lot more
> >> transparency about this.
> >
> > Good!
> >
> >    Patrik
> >