Bug #113

circular dependency on time in DNS

Added by Dave Täht over 3 years ago. Updated almost 2 years ago.

Status:New Start date:05/05/2011
Priority:Normal Due date:
Assignee:- % Done:

0%

Category:- Spent time: 64.50 hours
Target version:Cerowrt-Next

Description

We need DNS to get to a time server
We need accurate time to get DNSSEC

Can we get time right and not have to restart bind?


Related issues

related to Cerowrt - Bug #382: named.montime runs forever, restarts ntp and named forever New 05/01/2012
related to Cerowrt - Bug #238: Multiple named processes running Closed 08/22/2011
related to Cerowrt - Feature #224: dnssec-tools would be a good package to make Closed 08/04/2011
duplicated by Cerowrt - Bug #205: Router clock (NTP/DNS issues) New 07/13/2011

History

Updated by Dave Täht about 3 years ago

  • Project changed from Überwrt to ISCWRT

Updated by Dave Täht about 3 years ago

  • Target version set to World IPv6 Day

Updated by Evan Hunt about 3 years ago

Various proposals with various levels of stupidity for getting around the chicken-egg problem...

- A well-known anycasted address providing a udp/37 time server: It had occurred to me that since this is to be used for bootstrapping DNSSEC, it might be a lovely idea if the root servers simply turned this feature on. I still sort of love this, but it turns out to be rather fraught for political reasons (hard to get root operators to agree on anything, and this would be "one more thing to break"). Also, udp/37 is obsolete and insecure. (Its security issues would be dead easy to fix -- simply allow the client to send a random nonce with its query, and return the nonce along with the time -- but the existence of SNTP leads me to suspect that IETF would not be receptive to any updates to RFC 868. Which leads me to...)

- A well-known anycasted address providing SNTP: SNTP should work fine over anycast as far as I know, but bringing the idea up seems to make time-conscious people gasp and say you can't anycast NTP. Anyway, it's too complicated a protocol to be served by the root servers, but if we can convince people that this is a piece of needed internet infrastructure, we may be able to leverage existing anycast networks to get this deployed.

- DNS itself providing time: A well known domain name, possibly server-provided along the lines of authors.bind/CH/TXT or id.server/CH/TXT, or possibly provided by anycasted DNS servers ("time.arpa" or similar), would respond with a 128-bit number provided as an AAAA record in a nonroutable block of IPv6 space. The bottom 64 bits of this would contain the current time (to the nearest second, with accuracy guaranteed plus or minus a minute). A DNS server could be configured to check this value at startup and, if the variance with the system clock was above a certain threshold, use it as baseline time for DNSSEC validation.

- The "screw it" option: Add a list of well-known NTP addresses (not domain names) to the standard ntp.conf. The chances of all such addresses becoming invalid within the lifetime of a router seem remote.

- Modified "screw it" option: Store a list of well-known NTP addresses separately from ntp.conf. NTP can use them if it doesn't have DNS access. When it does have DNS access, it can look up the addresses via DNS, compare them against the cached list, and if any addresses have changed, it can update its cache. On the next boot, it uses the cached list of addresses again.

- Use "dig +cd" to do queries with checking disabled. Start named, use dig +cd to look up the NTP server address(es), update ntp.conf, start NTP. (This requires adding 'dig' to the installation of course, and so do the next few options.)

- Use "dig +cd" to figure out the approximate date by looking at the SOA record of a frequently-updated zone that uses the date for its serial number. (This requires a high level of confidence that the zone will persist and continue using a date-format SOA serial number, so I don't love this. But, "dig +cd +short soa . | awk '{print $3}'" currently returns 2011073101 (today's date in human readable format), and "dig +cd +short soa com | awk '{print $3}'" currently returns 1312161951 (the current unix epoch date, as of about 45 seconds ago).

- Use "dig +cd" to figure out the approximate date by looking at inception and expiration dates on current RRSIG records. This has a pretty poor accuracy level, but currently "dig +cd +short rrsig . | awk '$1 == "SOA" {print $6}'" gives you 20110730230000 (which is yesterday).

- Compile NTP with libval from SPARTA (dnssec-tools.org) and use val_getaddrinfo() instead of getaddrinfo().

- Write code to use in NTP when getaddrinfo() doesn't work, using the standard resolver library. Something like this ought to work (totally untested, use it as a starting place only):

     #include <sys/types.h>
     #include <netinet/in.h>
     #include <arpa/nameser.h>
     #include <resolv.h>

     unsigned char qbuffer[NS_PACKETSZ + 1];
     unsigned char rbuffer[NS_PACKETSZ + 1];
     int qlen, rlen;
     ns_message handle;

     /* ipv4 address query, ns_t_a -- need to do this again for ns_t_aaaa */
     qlen = res_mkquery(QUERY, "servername", C_IN, ns_t_a, NULL, 0, NULL, 
                        qbuffer, NS_PACKETSZ);

     /* set the CD bit in the query message */
     qbuffer[3] = 0x10U;

     /* send the query */
     rlen = res_send(qbuffer, qlen, rbuffer, NS_PACKETSZ);

     /* parse the response */
     if (ns_initparse(rbuffer, rlen, &handle) < 0)
         return (ERROR);

     for (i = 0; i < ns_msg_count(handle, ns_s_an); i++) {
         ns_rr rr;
         sockaddr_in addr4;
         sockaddr_in6 addr6;
         if (ns_parserr(&handle, ns_s_an, i, &rr) == 0)
             return (ERROR);
         if (ns_rr_type(rr) == ns_t_a) {
             addr4.sin_family = AF_INET;
             memcpy(addr4.sin_addr, ns_rr_rdata(rr), NS_INADDRSZ);
             /* cache address for use by NTP */
         } else if (ns_rr_type(rr) == ns_t_aaaa) {
             addr6.sin6_family = AF_INET6;
             memcpy(addr6.sin6_addr, ns_rr_rdata(rr), NS_IN6ADDRSZ);
             /* cache address for use by NTP */
         }
     }

Updated by Evan Hunt about 3 years ago

I've just had a serious headdesk moment. There's a feature in rndc that I have somehow managed to go multiple years without ever noticing:

rndc validation off
ntpd
sleep 1
rndc validation on

Problem solved.

(Is that how you were already doing it? I had the impression you were modifying the config file and running "rndc reconfig", which is obviously much more cumbersome than this method.)

Updated by Dave Täht about 3 years ago

it takes considerably longer than 1 second for dns to come up. For example, I've seen it take minutes to merely get an IP address from the external router/cable modem, etc.

I also took a look at the ntp code, because I wanted to implement dnssec-free lookups when the -g option was specified, and rapidly got bogged down in that to where I waved hands and said to self - self - convince a ntp code-base expert to do this patch. Don't know any except hal and dave hart.

Updated by Dave Täht almost 3 years ago

  • Target version changed from World IPv6 Day to 14

I have found the dns circular dependency problem annoying enough to want to hack ntp up to DO THE RIGHT THING myself.

but I keep hoping someone with familiarity with the ntp codebase will take a stab at it. I looked, and the 'right thing' is to revalidate after you get enough time servers to get time so dnssec can validate....

Updated by Jim Gettys almost 3 years ago

  • Project changed from ISCWRT to Cerowrt

Updated by David Taht almost 3 years ago

Ya know, that's pretty clever. 8.8.8.8 is blocked in some places, as is ntp,
but, yea...

(cc-ing the bug)

On Fri, Dec 9, 2011 at 9:02 AM, Ross Boswell <> wrote:

Dear Jim and Dave

I read with interest your Cerowrt document from the 25 Oct meeting.

I wonder about this:

Headache: no TOY (time of year) clock in home routers: how do you get approximate time to bring up DNSsec? You can't do DNS lookups until DNSsec is running, and you need to do DNS lookups to get the time...

The following works to set the initial time on a ubuntu box for me:

root@nomad:~#ntpdate-debian `dig @8.8.8.8 +short nist1-ny.ustiming.org nist1-jy.ustiming.org`

8.8.8.8 is of course Google's open-access nameserver and it seems very reliable. I use the NIST timeservers but you can put any string of timeserver names here -- ntp uses the first it can get a response from.

Is this a feasible solution for you?

Cheers -- Ross
Ross Boswell 148 Quay St Auckland 1010 New Zealand phone  +64 9 368 1195 mobile +64 21 402 142

Updated by Evan Hunt almost 3 years ago

Leave 8.8.8.8 out of it -- you've got a resolver, it's just not validating because the time isn't set. "dig +short +cd <NTP server>" will get you an address. (I think I already suggested this workaround, though I didn't think of using it as an argument to ntpdate, which is quite clever. My suggestion was to write the address into an ntp.conf file; this is better.)

Updated by David Taht almost 3 years ago

PROGRESS!!!!!!!

-------- Original Message --------
Subject: Re: [DNSSEC-Tools] #145: ntp could use patches to use dnssec-tools
Date: Wed, 14 Dec 2011 11:16:39 -0000
From: DNSSEC-Tools <>
Reply-To:
CC:

#145: ntp could use patches to use dnssec-tools
---------------------------+----------------------
Reporter: dave.taht@… | Owner: hserus
Type: enhancement | Status: assigned
Priority: major | Milestone:
Component: dnssec-tools | Version:
Resolution: | Keywords:
---------------------------+----------------------

Comment (by hserus):

We submitted a patch a week or so ago, but there hasn't been any feedback
from the ntp folks yet. In the meantime you could grab the patch from
http://bugs.ntp.org. search for bug 2077
It will need an updated version of libval though, currently available
through svn but will be in a release soon.

Updated by Dave Täht almost 3 years ago

From my admittedly sketchy review of the patch, while it enables dnssec
validation, and shows how to do it - for which I'm grateful! - it doesn't
appear to solve the bootstrapping problem that I described - if you have
invalid time in the first place, on starting ntp with -g it should turn
off validation until it gets valid time, then it can turn it on again.

I will apply it and fiddle with it next week, but if you could
confirm/deny my reading it would cheer me up.

(posted same message to dnssec-tools bugtracker)

Updated by Dave Täht over 2 years ago

I FINALLLY.... got ntpd + libval to NOT validate, and thus let me get valid time.

opkg install dnsval

change /etc/dnssec-tools/dnsval.conf to:

: clock-skew
. -1

and maybe

mta clock-skew
. -1
;

I'm too tired to confirm this really did the trick or not, and the version of ntpd that I built for 3.3.0-1 and later has another select problem, but I did
see it skew the darn time...

but it was possible that dnssec validation disable got turned on in the interim.

Updated by Dave Täht over 2 years ago

made it install dnsval by default and have it ignore time slew by default in the configuration. This is actually not what you want if more stuff was linked to this library, but as ntp is our only problem child here...

Updated by Dave Täht over 2 years ago

I think this fix was an illusion. It takes many minutes, if ever for named to work. Kicking it manually and watching the time slew does work, but that's unacceptable.

I am pulling both ntp and bind from the default installed packages, until this solution or something better can be made to work on x86, first, then embedded.

I will keep building them, but there is no point in shipping them at present and I have other crash bugs to resolve. I give up on fixing it myself.

Updated by Dave Täht over 2 years ago

  • Target version changed from 14 to Cerowrt-Next

Updated by Mario Lopez almost 2 years ago

I keep hoping someone with familiarity with the ntp codebase will take a stab at it. I looked, and the 'right thing' is to revalidate after you get enough time servers to get time so dnssec can validate
http://speed-up-pc.org

Also available in: Atom PDF