Live data from Hacker News

DNS-Persist-01: A New Model for DNS-Based Challenge Validation

letsencrypt.org

161–164 of 164 posts

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#161

Earlier quoted context omitted.

Abolition of the Leap Second is basically a done deal. So, the differences caused by leap seconds will become frozen as arbitrary offsets, GPS time versus UTC for example. Basically when it was invented leap seconds seemed like a good idea because we assumed the inconvenience versus value was a good trade, but in practice we've discovered the value is negligible and the inconvenience more than we expected, so, bye by…

Which is how we get the October revolution in November.

The October Revolution being in November is because of a different drift problem. The Calendar drifts because the Earth's orbit isn't a whole number of days, so any attempt to have fixed length years drifts noticeably over just a few decades, the initial fix ("Julian" calendars) had the compensation factor wrong, and countries adopted an improved calendar ("Gregorian" calendars) at different points leading to that offset between Old and New dates.

The leap second is because the Earth's spin varies. The orbit isn't varying significantly, it's just not a whole number of day-night cycles which is inconvenient for us, but the spin actually varies. To "fix" this variation we have leap seconds. But unlike the very noticeable October versus November difference, a century of missed leap seconds adds up to much less than a minute of difference between solar time and civil time, and that's not something you'll actually notice.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#162

Earlier quoted context omitted.

Which is how we get the October revolution in November.

The October Revolution being in November is because of a different drift problem. The Calendar drifts because the Earth's orbit isn't a whole number of days, so any attempt to have fixed length years drifts noticeably over just a few decades, the initial fix ("Julian" calendars) had the compensation factor wrong, and countries adopted an improved calendar ("Gregorian" calendars) at different points leading to that of…

I'm aware of the different periods involved (I have a degree in astronomy), my point is that because the Russian Empire put off the switch for so long the difference became a historical joke. Similarly, I would suggest that it is generally best practice to make small changes quickly rather than large changes slowly. So why is it in the case of leap seconds (given we can and do perform measurements below the second scale to take account in variations in local and global gravity) are we seemingly unable to handle something so trivial?

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#163
post #129

I'm one of the draft authors. Several questions here touch real design tradeoffs — addressing the main threads: Why account URI instead of a public key in the record? (micw, 9dev, csense) Three reasons: 1. Key rotation without DNS changes. dns-persist-01 exists because DNS updates are expensive. Embedding a public key forces a DNS update on every key rotation — the exact problem this method solves. The account URI su…

This is excellent. I’m looking forward to use this instead of DNS-01.

Re: DNS-Persist-01: A New Model for DNS-Based Challenge Validation

#164

Earlier quoted context omitted.

The October Revolution being in November is because of a different drift problem. The Calendar drifts because the Earth's orbit isn't a whole number of days, so any attempt to have fixed length years drifts noticeably over just a few decades, the initial fix ("Julian" calendars) had the compensation factor wrong, and countries adopted an improved calendar ("Gregorian" calendars) at different points leading to that of…

I'm aware of the different periods involved (I have a degree in astronomy), my point is that because the Russian Empire put off the switch for so long the difference became a historical joke. Similarly, I would suggest that it is generally best practice to make small changes quickly rather than large changes slowly. So why is it in the case of leap seconds (given we can and do perform measurements below the second sc…

But it isn't trivial, as I explained the leap days inserted to fix the calendar are entirely predictable. In 1752 when my country adopted this system they already knew that 1800 and 1900 would not have such a day but 2000 would. They had no idea what the year 2000 would be like but their calendar already told them it has an extra day.

In contrast leap seconds are not predictable because they're trying to smooth out spin variation and the planet's spin is affected by natural processes. The IERS measures UT1 and we add (or remove) leap seconds to make UTC try to approximate UT1, we get a few months warning at most that a new insertion or removal is needed.

And despite being very difficult all of this is also pointless because we don't care. As an astronomer you know you don't try to use a wristwatch to figure out the Earth's rotation, you can just look that up online and use your exact position. But for any other purpose except astronomy we don't need this angle information, we want a nice regular time and the atomic time, TAI, already provides that without this nonsense about leap seconds.

Post reply on HN