[tz] [Tzdist-bis] [calsify] tzdist and IANA -- estimating the operational parameters

Lord Buddha lord.buddha at gmail.com
Fri Aug 23 04:46:59 UTC 2019


Have long thought there would be merit for some sort of on demand
updates.   This could be implemented in a system more similar to/if not
DNS.  If you need the rules for a location/zone/city/place you would query
for that and in the first place, the DNS servers provided by your ISP or
company and if they have that info you get it from them if not they request
off the next level up and so on and so on.

In DNS the rules could be published in TXT records in much the same way as
Google publishes all its net-blocks in DNS so that anybody can query what
public addresses they use.   Google publish a TXT record with the names of
other TXT records which list the netblocks they use (wish Amazon and MS
Azure were so internet application friendly).    For a time zone, a TXT
record could be published giving the number of records (lines) for that
zone and then TXT records published with an index suffix on the zone.

IANA could maintain these TXT records under their domain with maybe a
subdomain per time zone (OMG in a zone file),  OR, they could actually
delegate this out to designated authorities for geo-political areas.... OK,
yep, that would be a political quagmire for some regions of the world so
perhaps not.

All of this could be done within the existing internet infrastructure and
without it impacting IANA systems.   The starting point being an RFC to
describe it all including the format meanings of the rules themselves.
That format would likely need to be less dependent on the definition of and
interpretation of white-space; some sort of single delimiter would be
nice.   "|" would be a candidate.   The records would be free of the
commentary, that would remain in the current full download from IANA.

DNSSEC....   Definitely.  Much mischief possible without.

Oh and Java / JodaTime, which I have just patched for the Norfolk Island
and Fiji changes not yet released by IANA on a couple of hundred JVMs.
Neither Java nor JodaTime would need to embed their timezone info any more
(when updated to just use DNS) which would save me from that chore.

Wishful thinking ?   Must have been suggested before.

David Wade

*Traversing Googles cloud netblocks (thanks Google).*

waded at darkhorse:~$ dig +short TXT _cloud-netblocks.googleusercontent.com
"v=spf1 include:_cloud-netblocks1.googleusercontent.com include:_
cloud-netblocks2.googleusercontent.com include:_
cloud-netblocks3.googleusercontent.com include:_
cloud-netblocks4.googleusercontent.com include:_
cloud-netblocks5.googleusercontent.com ?all"
waded at darkhorse:~$ dig +short TXT _cloud-netblocks1.googleusercontent.com
"v=spf1 include:_cloud-netblocks6.googleusercontent.com include:_
cloud-netblocks7.googleusercontent.com ip4:8.34.208.0/20 ip4:8.35.192.0/21
ip4:8.35.200.0/23 ip4:108.59.80.0/20 ip4:108.170.192.0/20 ip4:
108.170.208.0/21 ?all"
waded at darkhorse:~$ dig +short TXT _cloud-netblocks1.googleusercontent.com
"v=spf1 include:_cloud-netblocks6.googleusercontent.com include:_
cloud-netblocks7.googleusercontent.com ip4:8.34.208.0/20 ip4:8.35.192.0/21
ip4:8.35.200.0/23 ip4:108.59.80.0/20 ip4:108.170.192.0/20 ip4:
108.170.208.0/21 ?all"
waded at darkhorse:~$ dig +short TXT _cloud-netblocks2.googleusercontent.com
"v=spf1 ip4:162.216.148.0/22 ip4:162.222.176.0/21 ip4:173.255.112.0/20 ip4:
192.158.28.0/22 ip4:199.192.112.0/22 ip4:199.223.232.0/22 ip4:
199.223.236.0/23 ip4:23.236.48.0/20 ip4:23.251.128.0/19 ip4:35.204.0.0/14
ip4:35.208.0.0/13 ?all"
waded at darkhorse:~$ dig +short TXT _cloud-netblocks3.googleusercontent.com
"v=spf1 ip4:107.167.160.0/19 ip4:107.178.192.0/18 ip4:146.148.2.0/23 ip4:
146.148.4.0/22 ip4:146.148.8.0/21 ip4:146.148.16.0/20 ip4:146.148.32.0/19
ip4:146.148.64.0/18 ip4:34.104.0.0/22 ?all"
waded at darkhorse:~$ dig +short TXT _cloud-netblocks4.googleusercontent.com
"v=spf1 ip4:130.211.8.0/21 ip4:130.211.16.0/20 ip4:130.211.32.0/19 ip4:
130.211.64.0/18 ip4:130.211.128.0/17 ip4:104.154.0.0/15 ip4:104.196.0.0/14
ip4:208.68.108.0/23 ip4:35.184.0.0/14 ip4:35.188.0.0/15 ip4:35.216.0.0/15
?all"
waded at darkhorse:~$ dig +short TXT _cloud-netblocks5.googleusercontent.com
"v=spf1 ip4:35.190.0.0/17 ip4:35.190.128.0/18 ip4:35.190.192.0/19 ip4:
35.235.224.0/20 ip4:35.192.0.0/14 ip4:35.196.0.0/15 ip4:35.198.0.0/16 ip4:
35.199.0.0/17 ip4:35.199.128.0/18 ip4:35.200.0.0/14 ip4:35.235.216.0/21
ip6:2600:1900::/35 ?all"
waded at darkhorse:~$ dig +short TXT _cloud-netblocks6.googleusercontent.com
"v=spf1 ip4:35.190.224.0/20 ip4:35.232.0.0/15 ip4:35.234.0.0/16 ip4:
35.235.0.0/17 ip4:35.235.192.0/20 ip4:35.236.0.0/14 ip4:35.240.0.0/15 ip4:
35.203.232.0/21 ip4:130.211.4.0/22 ip4:35.220.0.0/14 ip4:35.242.0.0/15 ip4:
35.244.0.0/14 ?all"
waded at darkhorse:~$ dig +short TXT _cloud-netblocks7.googleusercontent.com
"v=spf1 ip4:34.64.0.0/11 ip4:34.96.0.0/14 ip4:34.100.0.0/16 ip4:
34.102.0.0/15 ip4:108.170.216.0/22 ip4:108.170.220.0/23 ip4:108.170.222.0/24
ip4:35.224.0.0/13 ip4:35.190.240.0/22 ip4:35.190.242.0/23 ip4:35.206.0.0/15
?all"



On Fri, 19 Jul 2019 at 08:53, Steve Crocker <steve at shinkuro.com> wrote:

> :)
>
> Sent from my iPhone
>
> > On Jul 18, 2019, at 4:51 PM, Paul Eggert <eggert at cs.ucla.edu> wrote:
> >
> > Steve Crocker wrote:
> >> It doesn’t seem to me the legal verbiage would be part of the regular
> download, so that would reduce the payload a bit.
> >
> > Sorry, I shouldn't have distracted the performance discussion by
> mentioning that verbiage. It's so small that eliminating it isn't worth the
> effort unless one is trying to win a compression contest. Here's a complete
> copy of the verbiage:
> >
> > # This zic input file is in the public domain.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/tz/attachments/20190823/f6251869/attachment.html>


More information about the tz mailing list