Bert Hubert from PowerDNS made an interesting announcement today. Retrieving the coordinates for an IPv4 address with just a DNS query.
Hopefully the country code will also be included, but this is an interesting way of using DNS as a directory service with public data.
Big sites like GitHub or GitLab are hosting a lot of projects and have numerous of releases a day. And while you as a person can watch a repository on GitHub, you can’t filter out new releases easily. At least not easily findable in the interfaces and checking all the repositories manually because they aren’t part of a build process is too much hassle and will fail in the end. So also for me with highlight.js as it has been updated from version 9.11.0 to 9.12.0 months ago.
Looking at some solutions people were writing about on StackOverflow for example was to parse the HTML and use that as a basis for actions to be executed. A quick check and grep of the output shown that we only have links to releases, but no structured data we can easily parse.
$ curl -s https://github.com/isagalaev/highlight.js/releases | grep -i releases\/tag
If we take the same URL and add the extension .atom to it, then GitHub presents the same data in a consumable feed format. Now we have structured data with timestamps, URLs and descriptions.
$ curl -s https://github.com/isagalaev/highlight.js/releases.atom
<?xml version="1.0" encoding="UTF-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/" xml:lang="en-US">
<link type="text/html" rel="alternate" href="https://github.com/isagalaev/highlight.js/releases"/>
<link type="application/atom+xml" rel="self" href="https://github.com/isagalaev/highlight.js/releases.atom"/>
<title>Release notes from highlight.js</title>
<link rel="alternate" type="text/html" href="/isagalaev/highlight.js/releases/tag/9.12.0"/>
<content type="html"><p>Version 9.12.0</p></content>
<media:thumbnail height="30" width="30" url="https://avatars2.githubusercontent.com/u/99931?v=4&s=60"/>
This data can be used by a custom parser or RSS-readers like TT-RSS, but also used by platforms like IFTTT to trigger actions like adding it to a backlog or posting it to a Slack-channel.
With the creation of RFC 4408 also new a record type 99 for DNS was created to identify SPF Resource Records. It was advised to have both TXT and SPF records in DNS with the same content. RFC 4408 was obsoleted by RFC 7208 in 2014 with paragraph 3.1 stating the following:
SPF records MUST be published as a DNS TXT (type 16) Resource Record (RR) [RFC1035] only. The character content of the record is encoded as [US-ASCII]. Use of alternative DNS RR types was supported in SPF's experimental phase but has been discontinued.
Now that the SPF Resource Record has been discontinued for a while, the time has come to remove it from DNS (if not done already) and make sure it never comes back. Luckily most code libaries already preferred the TXT variant, but still this is one to put on the maintenance checklist to remove it for any application code and/or infrastructure.
Last month CentOS 7.4 was announced and it was time to rebuild some servers from scratch to make sure all playbooks were still correct as it is always good to know you can quickly (re)build servers when needed. For some other servers, the impact would be big due to huge amounts of data that needed to be moved around and an in-place upgrade would be sufficient.
Upgrading is very straightforward as it the same as the update option with “–obsoletes” flag set which removes obsoleted packages. So let start with CentOS 7.3.
$ cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)'
First, make sure all cached data is purged so we get the latest information. Secondly, run yum upgrade to download all required packages and install them. And thirdly, reboot your system.
$ sudo yum clean all
$ sudo yum upgrade
$ sudo systemctl reboot
When logging back into the system it presents itself as a server running CentOS 7.4.
$ cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
A side note to this procedure is not to use it on a server that has running applications and/or has users connecting to it. They may experience errors/failure during the upgrade procedure as libraries may not match what an application expects to start correctly or an essential service that is not running during the upgrade.
Emoji characters already appeared in DNS, but now also in an URL. And Google shows them perfectly what makes me wonder if all parts of their code base are ready to handle this correctly or that it is an incident.
So the big question is when marketeers and/or criminals start to use this to trick people into clicking on links. Also how do other systems like a CRM are going to handle this correctly.