Re: [Sks-devel] New Server

[Jeffrey Johnson]

On Apr 28, 2012, at 10:16 AM, Kristian Fiskerstrand wrote:

>> 
>> Your remarks resemble my key servers. Can't be helped, sorry.
>> 
> 
> Aliases isn't necessarily a problem, at least, after the switch to
> using the reported Hostname of the SKS server. If there is enough
> need, I might consider creating a proper alias table, but I'd prefer
> not to have to :)
> 

Perfect: from this (and other remarks) and other comments
your definition of "proper FQDN" policy can be inferred (afaict):

        The hostname reported in sksconf needs to be a "proper FQDN".

What hasn't been clear to me is that has an implicit restriction
on how membership files SHOULD be written using only
hostnames that match some other sksconf. That is the root of my confusion
while doing "unauthorized" log scraping and reconstruction.

>>> Anyhow, since this change, your SKS server will be out of the
>>> pool until a proper FQDN (OK, technically not as there isn't a
>>> trailing dot) hostname is set in the sksconf file. This is
>>> currently set to "services" according to [1, 2], where by i'd
>>> expect it to read "keyserver.uberslacks.com"
>>> 
>> 
>> Can you state the requirements for a "proper FQDN" name in the
>> context of pool inclusion precisely?
> 
> In this scenario, any full hostname that is internet accessible. For
> the case at hand; specifying "keyserver.uberslacks.com" rather than
> "services" in sksconf [1] would be sufficient.
> 
>> 
>> Just asking for information on current implementation state:
>> Aliasing is a very hard problem to solve, particularly when IPv4
>> <-> IPv6 aliasing is also involved.
>> 
> 
> Indeed, but as long as there are enough servers in the pool to
> function properly, it shouldn't cause too much trouble.
> 
> Preferably SKS operators stick to using the primary hostname of the
> server for its membership file, but this should only affect the
> cross-peering check in the status page. As long as the server is
> accessible using the alias, it will now only read the Hostname from
> the status page and use that for the listing.
> 
> Could you elaborate a bit on the IPv4 <-> IPv6 part? I fail to see why
> this should add too much extra complexity (for the server operators at
> least).
> 

I can try (but my circumstances are likely atypical of most SKS operators).

Here are two usage cases where SKS servers acquire multiple addresses:

1) On lion server with iCloud, there are IPv6 tunnels being created
on my assigned IPv6 /64. E.g.

en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 9000
        options=2b<RXCSUM,TXCSUM,VLAN_HWTAGGING,TSO4>
        ether c8:2a:14:58:82:7c 
        inet6 fe80::ca2a:14ff:fe58:827c%en0 prefixlen 64 scopeid 0x4 
        inet 172.16.1.7 netmask 0xffffff00 broadcast 172.16.1.255
        inet6 2001:470:8:270:ca2a:14ff:fe58:827c prefixlen 64 autoconf 
        inet6 2001:470:8:270:a5ac:23ac:35df:d558 prefixlen 64 deprecated 
autoconf temporary 
        inet6 2001:470:8:270:814:b3bf:4186:15f prefixlen 64 deprecated autoconf 
temporary 
        inet6 2001:470:8:270:fddc:dd00:bfe7:56cd prefixlen 64 deprecated 
autoconf temporary 
        inet6 2001:470:8:270:188b:f949:ad87:3ea0 prefixlen 64 deprecated 
autoconf temporary 
        inet6 2001:470:8:270:e440:16aa:5901:7c64 prefixlen 64 deprecated 
autoconf temporary 
        inet6 2001:470:8:270:4c03:28b5:bb92:62f9 prefixlen 64 deprecated 
autoconf temporary 
        inet6 2001:470:8:270:a43a:5bbf:b7eb:85d0 prefixlen 64 autoconf 
temporary 
        media: 1000baseT <full-duplex>
        status: active

What is perhaps unusual here is that I am also using IPv6 to drill past a
single dynamically assigned DHCP IPv4 address because I'm a cheap bastard.

And I'm not sure I really want to know what magic lurks in Apple's iCloud
colluding with my AEBS in order to generate tunnel end-points: some networking
details I'd really rather not know about, and Apple iCloud is a "useful" 
service,
with "support" even if proprietary.

2) WIth VM hosting and an IPv6-aware provider, I find a need for multiple IPv6 
/64's
being assigned to interfaces so that the VM's are part of both my providers and
my own IPv6 address spaces.

> Speaking based on my own keyservers, the DNS entries simply lists;
> 
> ## keys.kfwebs.net: IPv4 && IPv6 ##
> keys.kfwebs.net.        49497   IN      A       213.161.224.2
> keys.kfwebs.net.        49497   IN      AAAA    2001:16d8:ee30::4
> 
> ## keys2.kfwebs.net: IPv4 && IPv6 ##
> keys2.kfwebs.net.       32283   IN      A       84.215.6.5
> keys2.kfwebs.net.       22683   IN      AAAA
> 2001:16d8:ee3d:ee30:215:5dff:fe00:120d
> 
> ## keys3.kfwebs.net: IPv6 only ##
> keys3.kfwebs.net.       22672   IN      AAAA
> 2001:16d8:ee3d:ee30:215:5dff:fe00:1203
> 

MY DNS is a bit more complex because I tend to have 3
different POV for DNS:

        1) externally accessible IPv6 for each machine
        2) one "public" IPv4/IPv6
        3) a private DNS with both IPv4/IPv6 address

Anyways what I needed to know is the definition of "proper FQDN"
that you were expecting with sks-keyserver.net pool's.

If you are consistently using the reported host name as an identifier,
I can figure out the rest. What is/was confusing me was seeing
nick-names and aliases in the meta pages.

73 de Jeff
> [1] http://keyserver.uberslacks.com:11371/pks/lookup?op=stats
> 
> - -- 
> - ----------------------------
> Kristian Fiskerstrand
> http://www.sumptuouscapital.com
> Twitter: @krifisk
> - ----------------------------
> Corruptissima re publica plurimæ leges
> The greater the degeneration of the republic, the more of its laws
> - ----------------------------
> This email was digitally signed using the OpenPGP
> standard. If you want to read more about this
> The book: Sending Emails - The Safe Way: An
> introduction to OpenPGP security is now
> available in both Amazon Kindle and Paperback
> format at
> http://www.amazon.com/dp/B006RSG1S4/
> - ----------------------------
> Public PGP key 0xE3EDFAE3 at http://www.sumptuouscapital.com/pgp/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQIcBAEBCAAGBQJPm/umAAoJEBbgz41rC5UI/bwP/0KNBH7pkx4mGQORqpe5m8EG
> Kdwzl6el5MPaAcuaFIstLk1JQrAv7RjE/JaQwIo6ftt47GTdFhDcn8f2APDe6bAx
> 3/T3V1zTbnXLcMU1OlLCjRj/G9gUQYu/mpJ1nS7BAqMz8Vzfl3iftwcsx7AK0AEs
> wFfHKNiNjGKkH3KaWu7X8GW51yHdGBjYmcgZbiNuKrzDDF6eCSic4jwj0VmQU3TW
> GyyI8vcE+JxNCQuSlhmiXzYd9HXWCXUqyHryzzAusvLGyjN1F8Sl0ffCmhdNZ1za
> OW59JSW0fahXvbet6hf5s0DequJLMuNUEOZvEazyZ76TK4DXVSCcfXSsM5ezdL7a
> WOy1XwlFs5iCqLmLIy5G57Jla+sGs1RYLth+CT+EBE/ehHCcZ/BanpDFNH/SrdRC
> aEwP4uxqAtMMIH9BJz0uMrppz/BcAhiyXLfRle2g1PBJm+aVfA2D6YeLS0/8HHdH
> 16N//+TxHBg7gFfXVr+tV8w6lBO4W7/fjEeUPE9y1Rz9GuRx3MQPC3LPdy4TYWIw
> sBwicYPdGhlfbgcInRB71h2eMQ683Umhf8vKy3ykc+s0IDYZrn+Uyx1dx0bQdcnw
> v6bbRTArT/vBNNqPwPjTgwDFAw4p1Q73XI3pD2GsjRDifSYRz2YUpdNmaTbeW3zH
> Tru37cWxC4psx4kW6ItN
> =ISRH
> -----END PGP SIGNATURE-----
> 
> 
> _______________________________________________
> Sks-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/sks-devel