<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Sinodun Internet Technologies</title>
    <link>https://sinodun.com/</link>
    <description>Recent content on Sinodun Internet Technologies</description>
    <generator>Hugo</generator>
    <language>en</language>
    <copyright>Copyright 2026 Sinodun IT</copyright>
    <lastBuildDate>Fri, 07 Feb 2025 15:00:48 +0000</lastBuildDate>
    <atom:link href="https://sinodun.com/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Using the Fediverse to Add Comments to a Static Website</title>
      <link>https://sinodun.com/post/using-the-fediverse-to-add-comments-to-a-static-website/</link>
      <pubDate>Fri, 24 Jan 2025 14:06:30 +0000</pubDate>
      <guid>https://sinodun.com/post/using-the-fediverse-to-add-comments-to-a-static-website/</guid>
      <description>&lt;p&gt;Since I migrated this website to &lt;a href=&#34;https://gohugo.io&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;HUGO&lt;/a&gt; I have been searching for an elegant way to allow comments on our blog posts. I looked at most solutions given in the &lt;a href=&#34;https://gohugo.io/content-management/comments/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Hugo Documentation&lt;/a&gt;. They all seemed overly complex and involved third party services. So I started thinking if it would be possible to use statuses on Mastodon. It turns out I was not alone and this has been done before several times. I went with a system described by &lt;a href=&#34;https://danielpecos.com/2022/12/25/mastodon-as-comment-system-for-your-static-blog/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Daniel Pecos Martínez&lt;/a&gt;.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Happy 15th Birthday Sinodun!</title>
      <link>https://sinodun.com/post/15years/</link>
      <pubDate>Wed, 15 Jan 2025 11:52:49 +0000</pubDate>
      <guid>https://sinodun.com/post/15years/</guid>
      <description>&lt;p&gt;Today in 2010 we incorporated Sinodun Internet Technologies. It has been a fantastic 15 years with many exciting, enjoyable and interesting projects to work on. We would like to thank all of our customers who have supported us, and also all the grant awarding organisations that have funded our work over the years. It has been a pleasure and privilege to be part of the DNS and standards community during this time. We look forward to continuing to work with the community over the years to come!&lt;/p&gt;</description>
    </item>
    <item>
      <title>New Website</title>
      <link>https://sinodun.com/post/new-website/</link>
      <pubDate>Mon, 14 Oct 2024 12:59:28 +0100</pubDate>
      <guid>https://sinodun.com/post/new-website/</guid>
      <description>&lt;p&gt;Welcome to our new website. As a side project over the last few months we have migrated from Wordpress to a static Hugo website. It is based on the &lt;a href=&#34;https://themes.gohugo.io/themes/hugo-bootstrap-theme/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;hugo-bootstrap&lt;/a&gt; theme. Anecdotal evidence suggests it is much faster. We use no cookies or any kind of tracking and nothing about our users is recorded unless we need to troubleshoot a problem. See our &lt;a href=&#34;https://sinodun.com/privacy-policy/&#34;&gt;privacy policy&lt;/a&gt;.&#xA;Since this site is now static, we will post links to all new content on&#xA;&lt;div class=&#34;col-lg-2&#34;&gt;&#xA;&lt;figure&gt;&lt;a href=&#34;https://fosstodon.org/@sinodun&#34; target=&#34;_blank&#34;&gt;&lt;img src=&#34;https://sinodun.com/logo-black.svg&#34; height=&#34;36px&#34;&gt;&lt;/a&gt;&#xA;         &lt;/figure&gt;&#xA;&#xA;&lt;/div&gt;&#xA;and encourage any discussion there.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Internet Engineering Services</title>
      <link>https://sinodun.com/services/</link>
      <pubDate>Thu, 01 Aug 2024 13:09:10 +0100</pubDate>
      <guid>https://sinodun.com/services/</guid>
      <description>&lt;p&gt;Along with our network of associates we can provide a variety of Research and Development services including&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;DNS research and development.&lt;/li&gt;&#xA;&lt;li&gt;DNS Protocol specification and prototyping.&lt;/li&gt;&#xA;&lt;li&gt;DNS and DNSSEC consulting.&lt;/li&gt;&#xA;&lt;li&gt;DNS Privacy expertise and advice.&lt;/li&gt;&#xA;&lt;li&gt;DNS Training.&lt;/li&gt;&#xA;&lt;li&gt;Upgrade or migration of business critical DNS infrastructure.&lt;/li&gt;&#xA;&lt;li&gt;HSM expertise.&lt;/li&gt;&#xA;&lt;li&gt;Software development.&lt;/li&gt;&#xA;&lt;li&gt;Project management.&lt;/li&gt;&#xA;&lt;li&gt;Unix systems administration (FreeBSD, GNU/Linux).&lt;/li&gt;&#xA;&lt;/ul&gt;</description>
    </item>
    <item>
      <title>DNS Work and Consultancy</title>
      <link>https://sinodun.com/dnswork/</link>
      <pubDate>Wed, 31 Jul 2024 15:31:02 +0100</pubDate>
      <guid>https://sinodun.com/dnswork/</guid>
      <description>&lt;p&gt;We have a range of experience in DNS protocol development, prototyping and deployment, and also in DNS operations (primarily of TLD services). We are members of DNS-OARC.&lt;/p&gt;&#xA;&lt;h1 id=&#34;dns-stats&#34;&gt;DNS-STATS&lt;/h1&gt;&#xA;&lt;p&gt;We have worked on the development of &lt;a href=&#34;http://dns-stats.org&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;DNS-STATS&lt;/a&gt; (in collaboration with ICANN), an Open Source suite of tools for DNS traffic capture and visualization.&lt;/p&gt;&#xA;&lt;p&gt;ICANN use this software, including for the public front-end, for their &lt;a href=&#34;https://stats.dns.icann.org/stats/d/wom-ext-main/traffic-menu?orgId=1&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;IMRS statistics dashboard&lt;/a&gt;. Data is collected in C-DNS format (a compact DNS specific capture format defined in &lt;a href=&#34;https://datatracker.ietf.org/doc/rfc8618&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC 8618&lt;/a&gt; using our implementation called the &lt;a href=&#34;https://github.com/dns-stats/compactor&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;DNS-STATS Compactor&lt;/a&gt;. It is then stored in a Clickhouse database and visualized with a custom Grafana front end. An open source version of the &lt;a href=&#34;https://github.com/dns-stats/visualizer/wiki&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;DNS-STATs visualizer&lt;/a&gt; is available.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Wiki Js and Katex</title>
      <link>https://sinodun.com/post/wiki-js/</link>
      <pubDate>Wed, 08 Jun 2022 00:00:00 +0100</pubDate>
      <guid>https://sinodun.com/post/wiki-js/</guid>
      <description>&lt;p&gt;I have been playing with &lt;a href=&#34;https://js.wiki/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Wiki.js&lt;/a&gt;, I happened to notice that some math was not getting rendered correctly. Wiki.js uses &lt;a href=&#34;https://katex.org/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Katex&lt;/a&gt; to render Latex (like) math expressions. I wanted to produce an unordered list of equations like this,&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;\(\braket{v_i|v_i} = 1\) because we are dealing with a unit vector&lt;/li&gt;&#xA;&lt;li&gt;\(\braket{v_1|v_2}=\braket{v_2^*|v_1^*}\)&lt;/li&gt;&#xA;&lt;li&gt;\(\braket{v_1\vert(a\vert v_2}+b\ket{v_3})=a\braket{v_1\vert v_2}+b\braket{v_1\vert v_3}\)&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;p&gt;The markdown to do this looks like&lt;/p&gt;&#xA;&lt;p&gt;* $\braket{v_i|v_i} = 1$ because we are dealing with a unit vector&lt;/p&gt;</description>
    </item>
    <item>
      <title>Working with Materialized View tables in ClickHouse</title>
      <link>https://sinodun.com/post/clickhouse-matviews/</link>
      <pubDate>Tue, 21 Jan 2020 00:00:00 +0000</pubDate>
      <guid>https://sinodun.com/post/clickhouse-matviews/</guid>
      <description>&lt;p&gt;There must be something about January which makes John prod me into a blog post about something I&amp;rsquo;ve just teased out. So here we are, it&amp;rsquo;s 2020, it&amp;rsquo;s January, and what is fast (OK, not so fast) becoming an annual tradition.&lt;/p&gt;&#xA;&lt;p&gt;Today&amp;rsquo;s post is a selection on snippets on Materialized Views. Materialized Views, if you haven&amp;rsquo;t met them, are tables automatically populated when data is inserted into some other table.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Junos DHCPv6 DNS Search List</title>
      <link>https://sinodun.com/post/junos-dhcpv6/</link>
      <pubDate>Fri, 01 Mar 2019 00:00:00 +0000</pubDate>
      <guid>https://sinodun.com/post/junos-dhcpv6/</guid>
      <description>&lt;p&gt;I have been looking at the DHCPv6 server in JUNOS 15.1X49-D160.2. It is easy enough to setup Note: Step 5 is wrong, the first two instructions should have dhcpv6 as the last argument e.g.&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services dhcpv6&#xA;&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;It would be nice to configure the DNS Search List option. The option code for this is 24. So I tried this&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;set access address-assignment pool my-pool family inet6 dhcp-attributes option 24 array string [ &amp;#34;sinodun.com&amp;#34; &amp;#34;ipv4.sinodun.com&amp;#34; ]&#xA;&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;but it didn’t work. There appears to be no examples of how to do this correctly so after reading RFC3315 section 8 and RFC1035 section 3.1 I realised it had to be in uncompressed wire format like this&lt;/p&gt;</description>
    </item>
    <item>
      <title>Executable External Dictionaries in Clickhouse</title>
      <link>https://sinodun.com/post/clickhouse-exe-dicts/</link>
      <pubDate>Mon, 28 Jan 2019 00:00:00 +0000</pubDate>
      <guid>https://sinodun.com/post/clickhouse-exe-dicts/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://clickhouse.yandex/docs/en/query_language/dicts/external_dicts/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;External dictionaries&lt;/a&gt;, a dictionary populated by an external source, are a rather useful way to make data external to &lt;a href=&#34;http://clickhouse.com/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;ClickHouse&lt;/a&gt; accessible when working in ClickHouse. One option for the source of the external data is an executable. I found, though, that the documentation doesn’t clearly tell you how to use this, so here I’m trying to rectify this.&lt;/p&gt;&#xA;&lt;p&gt;There are two basic types of executable external dictionary, which I’ll call whole file and lookup dictionaries. Let’s look at each in turn. Oh, and I’m using ClickHouse version 18.5.1 for these examples.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Using OpenSSL from inside a chroot</title>
      <link>https://sinodun.com/post/openssl-chroot/</link>
      <pubDate>Mon, 29 Jan 2018 00:00:00 +0000</pubDate>
      <guid>https://sinodun.com/post/openssl-chroot/</guid>
      <description>&lt;p&gt;A little something we tripped over this week. We’re providing an experimental DNS-over-TLS server that supports TLS v1.3. Right now TLS v1.3 is still an Internet Draft; in other words, it’s not a finished standard, though close to it. The latest version of the draft is draft 23, support for which was merged into the OpenSSL master branch yesterday, January 25th. Yup, we’re living on the bleeding edge.&lt;/p&gt;&#xA;&lt;p&gt;Support for the final standard TLS v1.3 will be in the next OpenSSL release, v1.1.1.&lt;/p&gt;</description>
    </item>
    <item>
      <title>More on Debian Jessie/Ubuntu Trusty packet capture woes</title>
      <link>https://sinodun.com/post/more-pcap/</link>
      <pubDate>Tue, 27 Jun 2017 00:00:00 +0100</pubDate>
      <guid>https://sinodun.com/post/more-pcap/</guid>
      <description>&lt;p&gt;Back in September I wrote about a problem we’d come across when capturing traffic with &lt;code&gt;pcap_dispatch()&lt;/code&gt; or &lt;code&gt;pcap_next_ex()&lt;/code&gt; on Ubuntu Trusty or Debian Jessie. When the traffic was slow, we saw packets not being captured.&lt;/p&gt;&#xA;&lt;p&gt;We’ve since done a bit more digging. The problem, we think, is a bug in the Linux kernel &lt;code&gt;select()&lt;/code&gt; system call. With both &lt;code&gt;pcap_dispatch()&lt;/code&gt; and&#xA;&lt;code&gt;pcap_next_ex()&lt;/code&gt; we’re using a central loop that is basically:&lt;/p&gt;&#xA;&lt;pre tabindex=&#34;0&#34;&gt;&lt;code&gt;pcap_dispatch();&#xA;select(pcapfd, timeout);&#xA;&lt;/code&gt;&lt;/pre&gt;&lt;p&gt;The length of timeout in the select() call shouldn’t matter. But it does. In our test scenario, set it to 1ms and every packet in a ping to an otherwise idle network connection will be captured. Set it to 2s and most or all will be missed.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Compressing pcap files</title>
      <link>https://sinodun.com/post/compress-pcap/</link>
      <pubDate>Thu, 08 Jun 2017 00:00:00 +0100</pubDate>
      <guid>https://sinodun.com/post/compress-pcap/</guid>
      <description>&lt;p&gt;Here at Sinodun Towers, we’re often dealing with &lt;code&gt;pcap&lt;/code&gt; DNS traffic capture files created on a far distant server. These files need to be compressed, both to save space on the server, and also to speed transfer to our machines.&lt;/p&gt;&#xA;&lt;p&gt;Traditionally we’ve used &lt;code&gt;gzip&lt;/code&gt; for quick but basic compression, and &lt;code&gt;xz&lt;/code&gt; when space was more important than CPU and we really needed the best compression we could get. At a recent conference, though, an enthusiastic Facebook employee suggested we take a look at &lt;code&gt;zstd&lt;/code&gt;. We’d looked at it quite some time ago, but our contact said it has improved considerably recently. So we thought we’d compare the latest &lt;code&gt;zstd (1.2.0)&lt;/code&gt; with current &lt;code&gt;gzip (1.8)&lt;/code&gt; and &lt;code&gt;xz (5.2.3)&lt;/code&gt; and see how they stack up when you’re dealing with pcap DNS traffic captures.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Packet capture woes with libpcap on Ubuntu Trusty and Debian Jessie</title>
      <link>https://sinodun.com/post/packet-capture/</link>
      <pubDate>Thu, 29 Sep 2016 00:00:00 +0100</pubDate>
      <guid>https://sinodun.com/post/packet-capture/</guid>
      <description>&lt;p&gt;Usually when you’re using libpcap to capture network traffic, your chief worry will be whether or not your application will keep up with the flow of traffic.&lt;/p&gt;&#xA;&lt;p&gt;Today, though, I’ve stubbed my toe on a problem with traffic that’s too slow. It happens with both Ubuntu Trusty and Debian Jessie. If there’s a gap between packets of more than about 50 milliseconds, the first packet to arrive after the gap will be dropped and you’ll never see it. I was capturing DNS queries and responses, and found that with a query rate of under 20 queries per second you start dropping queries. By the time you’re down to 15 queries per second, nearly every query is dropped.&lt;/p&gt;</description>
    </item>
    <item>
      <title>Juniper SRX mucking with DNS</title>
      <link>https://sinodun.com/post/junos-dns/</link>
      <pubDate>Mon, 25 Mar 2013 00:00:00 +0000</pubDate>
      <guid>https://sinodun.com/post/junos-dns/</guid>
      <description>&lt;p&gt;I was getting some strange DNS answers on the servers in a trust zone on my SRX. All the servers are statically NAT’d to external IP’s and run their own caching resolvers but when I tried to query for the servers A RR I kept getting the internal IP address. No name server either internal or external was serving that A RR. Eventually I realised that it was the SRX changing the answer section of the DNS response. I don’t know if it is on by default, or if I switched it on by mistake but it was the DNS Application Layer Gateway (ALG) trying to help by making use of what it knew about the static NATs. Switching DNS ALG off solved the issue. For a detailed description of what the ALG does see the Junos OS Security Configuration Guide.&lt;/p&gt;</description>
    </item>
    <item>
      <title>About Sinodun IT</title>
      <link>https://sinodun.com/about/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://sinodun.com/about/</guid>
      <description>&lt;p&gt;Sinodun was co-founded in 2010 by John and Sara Dickinson. The company name comes from the &lt;a href=&#34;http://en.wikipedia.org/wiki/Wittenham_Clumps&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Sinodun Hills&lt;/a&gt; (also known as Wittenham Clumps), two wooded chalk hills that are a local landmark near our original office in Oxfordshire. The word Sinodun derives from Celtic for Old Fort.&lt;/p&gt;&#xA;&lt;p&gt;Sinodun IT is an Internet Engineering company. We work with customers around the world to help them create and implement Internet Protocols.&lt;/p&gt;&#xA;&lt;hr/&gt;&#xA;&lt;h2 id=&#34;meet-the-team&#34;&gt;Meet the Team&lt;/h2&gt;&#xA;&lt;div class=&#34;row justify-content-center text-center mt-lg-3&#34;&gt;&#xA;    &lt;div class=&#34;card text-center border-0 shadow col-lg-4 mt-3&#34;&gt;&#xA;        &lt;img src=&#34;https://sinodun.com/authors/sara-dickinson/sara.jpg&#34; class=&#34;card-img-top mx-auto d-block&#34; alt=&#34;Sara Dickinson&#34; style=&#34;width: 150px&#34;&gt;&#xA;        &lt;div class=&#34;card-body&#34;&gt;&#xA;            &lt;h2 class=&#34;card-title&#34;&gt;Sara Dickinson&lt;/h2&gt;&#xA;            &lt;p class=&#34;card-text&#34;&gt;Director of Software Development&lt;/p&gt;</description>
    </item>
    <item>
      <title>Open Standards</title>
      <link>https://sinodun.com/open-standards/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://sinodun.com/open-standards/</guid>
      <description>&lt;p&gt;We have contributed to several Internet Drafts and RFCs at the IETF.&lt;/p&gt;&#xA;&lt;h2 id=&#34;rfcs&#34;&gt;RFCs&lt;/h2&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc9250/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC9250&lt;/a&gt; DNS over Dedicated QUIC Connections&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc9103/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC9103&lt;/a&gt; DNS Zone Transfer over TLS&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc8901/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC8901&lt;/a&gt; Multi-Signer DNSSEC Models&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc8932/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC8932 (BCP232)&lt;/a&gt; Recommendations for DNS Privacy Service Operators – Describes operational, policy and security considerations for DNS operators who choose to offer DNS Privacy services&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc8618&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC 8618&lt;/a&gt; Compacted-DNS (C-DNS): A Format for DNS Packet Capture – A DNS specific format for efficient capture of DNS traffic.&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc8490&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC8490&lt;/a&gt; DNS Stateful Operations – Internet Draft proposing a new mechanism for per-session DNS signalling&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc8310&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC8310&lt;/a&gt; Usage Profiles for DNS over TLS and DNS over DTLS – describes how DNS Privacy clients can authenticate DNS Privacy servers&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc7858&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC7858&lt;/a&gt; Specification for DNS over TLS (contributing author)&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc7828&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC7828&lt;/a&gt; The edns-tcp-keepalive EDNS0 Option – defines an EDNS0 option to enable idle timeout management of DNS-over-TCP sessions.&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc7766&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC7766&lt;/a&gt; DNS Transport over TCP – Implementation Requirements – a bis version of RFC5966, (DNS Transport over TCP – Implementation Requirements)&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/rfc7583&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;RFC7583&lt;/a&gt; DNSSEC Key Rollover Timing Considerations – a detailed analysis of the timings involved when performing key rollover in DNSSEC.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h2 id=&#34;internet-drafts&#34;&gt;Internet Drafts&lt;/h2&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/draft-daley-dnsxml/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;dnsxml&lt;/a&gt; – A standard XML representation of DNS data – a syntax for encoding DNS Resource Records in XML&lt;/li&gt;&#xA;&lt;li&gt;&lt;a href=&#34;https://datatracker.ietf.org/doc/draft-dickinson-dnsop-nameserver-control/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;A name server Data Model&lt;/a&gt; –  Nameserver control protocol (NSCP): a common control protocol for managing name servers.&lt;/li&gt;&#xA;&lt;/ul&gt;</description>
    </item>
    <item>
      <title>Privacy Policy</title>
      <link>https://sinodun.com/privacy-policy/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      <guid>https://sinodun.com/privacy-policy/</guid>
      <description>&lt;h1 id=&#34;sinodun-internet-technologies-ltd-privacy-policy&#34;&gt;Sinodun Internet Technologies Ltd Privacy Policy&lt;/h1&gt;&#xA;&lt;h2 id=&#34;summary&#34;&gt;Summary&lt;/h2&gt;&#xA;&lt;p&gt;We do not use cookies and we do not collect any personal data unless troubleshooting issues with the site.&lt;/p&gt;&#xA;&lt;ul&gt;&#xA;&lt;li&gt;No personal information is collected unless troubleshooting issues with the site (see below).&lt;/li&gt;&#xA;&lt;li&gt;No information is stored in the browser.&lt;/li&gt;&#xA;&lt;li&gt;No information is shared with, sent to or sold to third-parties.&lt;/li&gt;&#xA;&lt;li&gt;No information is shared with advertising companies.&lt;/li&gt;&#xA;&lt;li&gt;No information is mined and harvested for personal and behavioural trends.&lt;/li&gt;&#xA;&lt;li&gt;No information is monetized.&lt;/li&gt;&#xA;&lt;/ul&gt;&#xA;&lt;h2 id=&#34;detailed-privacy-policy&#34;&gt;Detailed Privacy Policy&lt;/h2&gt;&#xA;&lt;p&gt;This privacy notice tells you what to expect us to do with your personal information.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
