From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id BAA82200627 for ; Sun, 17 Jul 2011 04:55:45 -0700 (PDT) Received: by iyi12 with SMTP id 12so3450447iyi.16 for ; Sun, 17 Jul 2011 05:34:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pmh1NylGFQzHPx1aXUcC2icfXRmSjg4crnrs9mpAEWw=; b=h3O4i2Nitgco276dF7eNIBnrJO9M/S343zuY7SC1bHRDh8nWD+HllvvTQ8xOE7zvxn HA+geff6ohAwL/p3APBZSrXdWS7Ii5+CYfNcb/ihyYrVNKEqUha9r2Ts+X5/eWYjk5i0 T4LJWUaXlhQFdNs+SwF7V8Q7PbO1HFkYS4+xg= MIME-Version: 1.0 Received: by 10.42.156.68 with SMTP id y4mr3017798icw.174.1310906073783; Sun, 17 Jul 2011 05:34:33 -0700 (PDT) Received: by 10.42.75.197 with HTTP; Sun, 17 Jul 2011 05:34:33 -0700 (PDT) In-Reply-To: References: <4E2226B3.3070907@hp.com> Date: Sun, 17 Jul 2011 06:34:33 -0600 Message-ID: Subject: Re: smoketest #6 of cerowrt is go for testing From: Dave Taht To: Dave Hart Content-Type: multipart/alternative; boundary=90e6ba6e8d52dc9cd704a8431a39 Cc: bismark-bootcamp@projectbismark.net, bloat-devel , Evan Hunt , bismark-devel@projectbismark.net X-BeenThere: bloat-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Developers working on AQM, device drivers, and networking stacks" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2011 11:55:46 -0000 --90e6ba6e8d52dc9cd704a8431a39 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Sat, Jul 16, 2011 at 10:35 PM, Dave Hart < davehart_gmail_exchange_tee@davehart.net> wrote: > On Sun, Jul 17, 2011 at 00:02 UTC, Rick Jones wrote: > > If you configure ntpd with bare IP addresses rather than names, will th= e > > getaddrinfo() return without attempting any DNS in the first place? > > Yes, basically. ntpd might not even call getaddrinfo() in that case > (it may use inet_pton() or similar to convert the IP address to binary > representation). At any rate, using only numeric IPv4 or IPv6 > addresses will avoid any DNS lookups. > While there is one group that is finally providing ntp time via anycast - which is a good solution to a large extent! - there is only the one (small) group doing so, rather than the needed '3'. http://news.ntppool.org/2011/03/expanding-the-anycast-dns-serv.html And I'm reluctant, given the sordid history of hard coding ntp IP addresses= , http://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse to hard code *any* until far more anycast servers are online. To take a step backwards on this, there are extensive notes on the circular dependencies between time and dnssec logged here. http://www.bufferbloat.net/issues/205 I'd implemented a hack to try to address these circular depenencies last week in the named-latest package repo, while also coping with http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2011-2464 I think I addressed the latter issue, but *good*. :) The 'fix' for the ntp/dnssec/bind/network dependencies seems to have some problems, however, notably really slow startup in general. To step further back on this: I had implemented ntp (with 7 contacted servers in the conf file!) in the first place due to the "cosmic background bufferbloat detector" idea extensively discussed on the comp.protocols.ntp newsgroup, and because I wanted to be able to compare large sample data sets against known-to-be accurate time, with a large deployment of client routers that had a configuration I could trust to be accurate, talking to a yet-to-be-deployed string of ntp servers (via hopefully a helpful operator) that could work on this with us. We had implemented dnssec in the first place because we wanted more people to be using it, and ironing out problems (among other things, I planned to use it to ensure valid updates to the routers), and because of nonsense about DNS censorship happing all over the world, such as the recent shenanagans in Australia. once all these circular dependencies are resolved on boot, which doesn't always happen and seems to take minutes, regardless, dnssec works pretty darn good. Seeing it actually work at all after a decade of discussion make= s me really, really happy, but making it work *well*, somehow, would be best. It's also my hope to implement this fix to bind, in the next rc release of cerowrt. http://www.isc.org/community/blog/201107/major-improvement-bind-9-startup-p= erformance > Cheers, > Dave Hart > --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --90e6ba6e8d52dc9cd704a8431a39 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jul 16, 2011 at 10:35 PM, Dave H= art <davehart_gmail_exchange_tee@davehart.net> wrote:
On Sun, Jul 17, 2011 at 00:02 UTC, Rick Jones <rick.jones2@hp.com> wrote:
> If you configure ntpd with bare IP addresses rather than names, will t= he
> getaddrinfo() return without attempting any DNS in the first place?
Yes, basically. =A0ntpd might not even call getaddrinfo() in that cas= e
(it may use inet_pton() or similar to convert the IP address to binary
representation). =A0At any rate, using only numeric IPv4 or IPv6
addresses will avoid any DNS lookups.

While there = is one group that is finally providing ntp time via anycast - which is a go= od solution to a large extent! - there is only the one (small) group doing = so, rather than the needed '3'.

http://news.ntppool.org/2011/03/expanding-the-anycast-dns-serv.htm= l

And I'm reluctant, given the sordid history of hard coding= ntp IP addresses,

ht= tp://en.wikipedia.org/wiki/NTP_server_misuse_and_abuse

to hard c= ode *any* until far more anycast servers are online.

To take a step = backwards on this, there are extensive notes on the circular dependencies b= etween time and dnssec logged here.

http://www.bufferbloa= t.net/issues/205

I'd implemented a hack to try to address th= ese circular depenencies last week in the named-latest package repo, while = also coping with

http://cve.mitre.org/cgi-bin/cvename.cgi?name=3DCVE-2011-2464
I think I addressed the latter issue, but *good*. :) The 'fix' for= the ntp/dnssec/bind/network dependencies seems to have some problems, howe= ver, notably really slow startup in general.


To step further back on this:

I had implemented ntp (with 7 = contacted servers in the conf file!) in the first place due to the "co= smic background bufferbloat detector" idea extensively discussed on th= e comp.protocols.ntp newsgroup, and because I wanted to be able to compare = large sample data sets against known-to-be accurate time, with a large depl= oyment of client routers that had a configuration I could trust to be accur= ate, talking to a yet-to-be-deployed string of ntp servers (via hopefully a= helpful operator) that could work on this with us.


We had implemented dnssec in the first place because we wanted more= people to be using it, and ironing out problems (among other things, I pla= nned to use it to ensure valid updates to the routers), and because of nons= ense about DNS censorship happing all over the world, such as the recent sh= enanagans in Australia.

once all these circular dependencies are resolved on boot, which doesn&= #39;t always happen and seems to take minutes, regardless, dnssec works pre= tty darn good. Seeing it actually work at all after a decade of discussion = makes me really, really happy, but making it work *well*, somehow, would be= best.

It's also my hope to implement this fix to bind, in the next rc rel= ease of cerowrt.

http://www.isc.org/community= /blog/201107/major-improvement-bind-9-startup-performance


Cheers,
Dave Hart



--
Dave T=E4ht
S= KYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com
--90e6ba6e8d52dc9cd704a8431a39--