Datenhaufen zu IT und Elektronik.

Autor: kernel-error (Seite 13 von 47)

DNS über TLS mit Stunnel und BIND9 einrichten: Anleitung für mehr Sicherheit

Ihr erinnert euch an meine Ankündigung über TLS an meinem DNS vor ein paar Tagen? RFC 7858 – DNS over Transport Layer Security

Bei mir ist inzwischen recht oft die Frage nach dem „Wie“ angekommen. Nun ich habe dafür stunnel benutzt. stunnel ist nicht speziell für DNS sondern ist ein Stück Software welches sich vor Dienste schalten lässt die keine oder eine schlechte Implementierung für SSL/TLS haben. Eine komplett stumpfe Konfiguration um zu testen würde zum Beispiel auf einem FreeBSD wie folgt aussehen:

/usr/local/etc/stunnel/conf.d/dnstls.conf

[dns4]
accept = 853
connect = 5.9.24.235:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt


[dns6]
accept = :::853 connect = 5.9.24.235:53
cert = /usr/local/etc/stunnel/ssl/dns.crt
key = /usr/local/etc/stunnel/ssl/dns.key
CAfile = /usr/local/etc/stunnel/ssl/ca.crt 

So gestartet lässt sich eine TLS Verbinung zu Port 853 aufbauen und stunnel schiebt dann alles einfach weiter an den Bind auf Port 53. Ob eine SSL/TLS Verbindung aufgebaut werden kann testet man am besten mit openSSL: openssl s_client -connect ns1.kernel-error.de:853 -showcerts Ich werfe weiter unten mal den kompletten Output in den Post…

Um eine komplette DNS Abfrage über TLS zu prüfen nutze ich gerne getdns_query. Dieses ist bereits in den FreeBSD Ports. Ein Test würde wie folgt aussehen: getdns_query @5.9.24.235 -s -a -A -l L www.kernel-error.de AAAA die Option „-l L“ weißt getdns_query dabei an es per TLS zu probieren. Auch hier werde ich den kompletten Output weiter untem im Post zeigen.

Der versprochene openSSL Output

kernel@s-meer-bsd ~> openssl s_client -connect ns1.kernel-error.de:853 -showcerts
CONNECTED(00000003)
depth=2 C = BE, O = GlobalSign nv-sa, OU = Root CA, CN = GlobalSign Root CA
verify return:1
depth=1 C = BE, O = GlobalSign nv-sa, CN = AlphaSSL CA - SHA256 - G2
verify return:1
depth=0 OU = Domain Control Validated, CN = *.kernel-error.de
verify return:1
---
Certificate chain
 0 s:/OU=Domain Control Validated/CN=*.kernel-error.de
   i:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
-----BEGIN CERTIFICATE-----
MIIIVjCCBz6gAwIBAgIMKHSoWgqp4f0QDMWoMA0GCSqGSIb3DQEBCwUAMEwxCzAJ
BgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIwIAYDVQQDExlB
bHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcyMB4XDTE3MDMxMDEwNTI1MloXDTE4MDMx
MTEwNTI1MlowPzEhMB8GA1UECxMYRG9tYWluIENvbnRyb2wgVmFsaWRhdGVkMRow
GAYDVQQDDBEqLmtlcm5lbC1lcnJvci5kZTCCAiIwDQYJKoZIhvcNAQEBBQADggIP
ADCCAgoCggIBAMtVm/TykTvxvwZN0h6H2YeIeu4G+scVCb+kxxa8Jrua7DuLchjm
05wj6zPTe+2opDNNeZ6T5/ISSKczUQO4p+ttxFzl8OGA8FaZe4Qc9FNYdzY35w2d
oMgpTpsO+xTEdLHbXcNvEdFXg/8vyKS5y9Ddp8mSvz/Mt04rj2sjXGWwV00ImDQ1
DHBEuNuvFsnyaXQkDXeC3bA+2EkuVIcFcviQT5At88CDLkP8ygJsD3iDudnVeEJZ
N1AFnjN/qQksjKvT5V75R7GcIhA0a6lC56iBmEykht8YdPy63940hYmO4Ug17p68
7uiPZKUsFkGmYchbkiw5KLTck6VVv9b5Z+lFfIQcfBf5blmaUkQQ8CP3yXXajmfP
3KqJu5c+M3OW9evFiE+z7ihtKVtOHQS86z0ijvSNaCfj9OWQKXhBzBzdEGTogC7n
Iq8YYjveRQ+ExffM+RY3xaqMc1368tUx6ir+0LdGiqgzDC5OcWPqRTNobeTfcETz
VCxqgTfVr4tDNTk1+LmRsWKVDuBtG3p/lJEwCU1z6ZP6xmNTBZc1iOuNOJN+CmYW
ZpKaI3F6JPRK4G2Hu4fa0GWjRHSSZYFkyBl520a8fTMGIY8JlfHfx9HVK2fFJ4yP
NxKligKSydphqEG8cyEU/V3oRlgZ7en1HmrWRrIRiWcmWk3qKl/AZk97AgMBAAGj
ggRDMIIEPzAOBgNVHQ8BAf8EBAMCBaAwgYkGCCsGAQUFBwEBBH0wezBCBggrBgEF
BQcwAoY2aHR0cDovL3NlY3VyZTIuYWxwaGFzc2wuY29tL2NhY2VydC9nc2FscGhh
c2hhMmcycjEuY3J0MDUGCCsGAQUFBzABhilodHRwOi8vb2NzcDIuZ2xvYmFsc2ln
bi5jb20vZ3NhbHBoYXNoYTJnMjBXBgNVHSAEUDBOMEIGCisGAQQBoDIBCgowNDAy
BggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9y
eS8wCAYGZ4EMAQIBMAkGA1UdEwQCMAAwPgYDVR0fBDcwNTAzoDGgL4YtaHR0cDov
L2NybDIuYWxwaGFzc2wuY29tL2dzL2dzYWxwaGFzaGEyZzIuY3JsMC0GA1UdEQQm
MCSCESoua2VybmVsLWVycm9yLmRlgg9rZXJuZWwtZXJyb3IuZGUwHQYDVR0lBBYw
FAYIKwYBBQUHAwEGCCsGAQUFBwMCMB0GA1UdDgQWBBSL6GOdfjNSVXP7NNrKRfN/
ZEGEJTAfBgNVHSMEGDAWgBT1zdU8CFD5ak86t5faVoPmadJo9zCCAm0GCisGAQQB
1nkCBAIEggJdBIICWQJXAHUAu9nfvB+KcbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e
0YUAAAFat9mThAAABAMARjBEAiBA/XALdgdBZzdvL20DwfeGUAKVhFAueJG6hIWF
eooeSwIgBAMtgDdRxtSkDbKZdkuT9pul6HlZgGSKBLwHjt08rSAAdgDd6x0reg1P
piCLga2BaHB+Lo6dAdVciI09EcTNtuy+zAAAAVq32ZOaAAAEAwBHMEUCIAwdq+Ma
WZ+v8TuKuwIT9oTHT6mlOuov2brZHNa53o5MAiEAq1ZFktpd5XzJQixebUuaCNKW
dZWUF58tKuB4l7xvGOUAdgCkuQmQtBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3c
EAAAAVq32ZZ1AAAEAwBHMEUCIAUVh0ZRcb/+WRb9F+nn/Jmzvgs/bnLQNwEjBUT1
/t2aAiEAmZWAnrB3RnsCbedw8SOvJk6HsZG67T0fdI96M/Pc47kAdgBWFAaaL9fC
7NP14b1Esj7HRna5vJkRXMDvlJhV1onQ3QAAAVq32Za/AAAEAwBHMEUCIQD92ZOc
1xqff1TJ7gsw/ZGtkvzrjIW6uu/Hu7ZxBKkOgQIgRC0TkK19+m8nUN7KDCqyKsZT
DqUrKE01MuPhx1RnIPMAdgDuS723dc5guuFCaR+r4Z5mow9+X7By2IMAxHuJeqj9
ywAAAVq32ZllAAAEAwBHMEUCIQCPAWIduEfXjVVq+qKHEtoy84Nqm+PsibSk8uXq
ziMziQIgJp3NRvIM8bFtzQe/ZQYBnNv2H3MwZmldaIbV5VcbMOQwDQYJKoZIhvcN
AQELBQADggEBAKmQsE/CjF2nRuqaPZht7EFsQpHzihm+VBA48HDN0Uj9JpObHadg
kxNunKd3K+KNsZP4gwg8Z+LfNAU2smK//Ptq7S/y3ECZTniwLMNx4ogekIuQ9i6a
5zgdN3TpWMV/pu2PEguG/FhDIeIEoC5L7qYAKsSq/4VMexUeVfg3IDbdFH0FGlF7
NRAvfY8KfkvkM6c0VhkAuisnYpt+N3RoXOUlQEbv2qRPikiRnLW4hyms0Y73W5v2
GBA6H66lPIqWTzalY9d1kUVY0N+qz/ZgZhdY0LkeTHG4l+XAyKwa241LHGtDHz7m
7c9LBqS3mXSFvfCL9eU2vzDHkU6cMixjf94=
-----END CERTIFICATE-----
 1 s:/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
   i:/C=BE/O=GlobalSign nv-sa/OU=Root CA/CN=GlobalSign Root CA
-----BEGIN CERTIFICATE-----
MIIETTCCAzWgAwIBAgILBAAAAAABRE7wNjEwDQYJKoZIhvcNAQELBQAwVzELMAkG
A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv
b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw0xNDAyMjAxMDAw
MDBaFw0yNDAyMjAxMDAwMDBaMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i
YWxTaWduIG52LXNhMSIwIAYDVQQDExlBbHBoYVNTTCBDQSAtIFNIQTI1NiAtIEcy
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2gHs5OxzYPt+j2q3xhfj
kmQy1KwA2aIPue3ua4qGypJn2XTXXUcCPI9A1p5tFM3D2ik5pw8FCmiiZhoexLKL
dljlq10dj0CzOYvvHoN9ItDjqQAu7FPPYhmFRChMwCfLew7sEGQAEKQFzKByvkFs
MVtI5LHsuSPrVU3QfWJKpbSlpFmFxSWRpv6mCZ8GEG2PgQxkQF5zAJrgLmWYVBAA
cJjI4e00X9icxw3A1iNZRfz+VXqG7pRgIvGu0eZVRvaZxRsIdF+ssGSEj4k4HKGn
kCFPAm694GFn1PhChw8K98kEbSqpL+9Cpd/do1PbmB6B+Zpye1reTz5/olig4het
ZwIDAQABo4IBIzCCAR8wDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C
AQAwHQYDVR0OBBYEFPXN1TwIUPlqTzq3l9pWg+Zp0mj3MEUGA1UdIAQ+MDwwOgYE
VR0gADAyMDAGCCsGAQUFBwIBFiRodHRwczovL3d3dy5hbHBoYXNzbC5jb20vcmVw
b3NpdG9yeS8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWdu
Lm5ldC9yb290LmNybDA9BggrBgEFBQcBAQQxMC8wLQYIKwYBBQUHMAGGIWh0dHA6
Ly9vY3NwLmdsb2JhbHNpZ24uY29tL3Jvb3RyMTAfBgNVHSMEGDAWgBRge2YaRQ2X
yolQL30EzTSo//z9SzANBgkqhkiG9w0BAQsFAAOCAQEAYEBoFkfnFo3bXKFWKsv0
XJuwHqJL9csCP/gLofKnQtS3TOvjZoDzJUN4LhsXVgdSGMvRqOzm+3M+pGKMgLTS
xRJzo9P6Aji+Yz2EuJnB8br3n8NA0VgYU8Fi3a8YQn80TsVD1XGwMADH45CuP1eG
l87qDBKOInDjZqdUfy4oy9RU0LMeYmcI+Sfhy+NmuCQbiWqJRGXy2UzSWByMTsCV
odTvZy84IOgu/5ZR8LrYPZJwR2UcnnNytGAMXOLRc3bgr07i5TelRS+KIz6HxzDm
MTh89N1SyvNTBCVXVmaU6Avu5gMUTu79bZRknl7OedSyps9AsUSoPocZXun4IRZZ
Uw==
-----END CERTIFICATE-----
---
Server certificate
subject=/OU=Domain Control Validated/CN=*.kernel-error.de
issuer=/C=BE/O=GlobalSign nv-sa/CN=AlphaSSL CA - SHA256 - G2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: ECDH, P-256, 256 bits
---
SSL handshake has read 4014 bytes and written 433 bytes
---
New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-GCM-SHA384
Server public key is 4096 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Session-ID: B1956B432DABE228C78E756329A796FA56C9646BE64326F8F96782BD946CCA82
    Session-ID-ctx: 
    Master-Key: 10329FBAE32471FC56D45E0AA0971CF5EB7977F7569AE4079219D9438E7A0F9DA8EC4150D9A074FC0AD8E63E00849047
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1513937385
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

Der versprochene getdns_query Output:

kernel@s-meer-bsd ~> getdns_query @5.9.24.235 -s -a -A -l L www.kernel-error.de AAAA
{
  "answer_type": GETDNS_NAMETYPE_DNS,
  "canonical_name": <bindata for www.kernel-error.de.>,
  "just_address_answers":
  [
    {
      "address_data": <bindata for 2a01:4f8:161:3ec::443>,
      "address_type": <bindata of "IPv6">
    },
    {
      "address_data": <bindata for 5.9.24.250>,
      "address_type": <bindata of "IPv4">
    }
  ],
  "replies_full":
  [
     <bindata of 0xd3578500000100010003000703777777...>,
     <bindata of 0xe9288500000100010003000703777777...>
  ],
  "replies_tree":
  [
    {
      "additional":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv4_address": <bindata for 5.9.24.235>,
            "rdata_raw": <bindata of 0x050918eb>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv4_address": <bindata for 176.9.109.53>,
            "rdata_raw": <bindata of 0xb0096d35>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv4_address": <bindata for 203.137.119.119>,
            "rdata_raw": <bindata of 0xcb897777>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:161:3ec::53>,
            "rdata_raw": <bindata of 0x2a0104f8016103ec0000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:150:1095::53>,
            "rdata_raw": <bindata of 0x2a0104f8015010950000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2001:310:6000:f::1fc7:1>,
            "rdata_raw": <bindata of 0x200103106000000f000000001fc70001>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "do": 0,
          "extended_rcode": 0,
          "rdata":
          {
            "rdata_raw": <bindata of 0x>
          },
          "type": GETDNS_RRTYPE_OPT,
          "udp_payload_size": 4096,
          "version": 0,
          "z": 0
        }
      ],
      "answer":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for www.kernel-error.de.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:161:3ec::443>,
            "rdata_raw": <bindata of 0x2a0104f8016103ec0000000000000443>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        }
      ],
      "answer_type": GETDNS_NAMETYPE_DNS,
      "authority":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns2.kernel-error.org.>,
            "rdata_raw": <bindata for ns2.kernel-error.org.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns1.kernel-error.de.>,
            "rdata_raw": <bindata of 0x036e7331c010>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns3.kernel-error.com.>,
            "rdata_raw": <bindata for ns3.kernel-error.com.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        }
      ],
      "canonical_name": <bindata for www.kernel-error.de.>,
      "header":
      {
        "aa": 1,
        "ad": 0,
        "ancount": 1,
        "arcount": 7,
        "cd": 0,
        "id": 54103,
        "nscount": 3,
        "opcode": GETDNS_OPCODE_QUERY,
        "qdcount": 1,
        "qr": 1,
        "ra": 0,
        "rcode": GETDNS_RCODE_NOERROR,
        "rd": 1,
        "tc": 0,
        "z": 0
      },
      "question":
      {
        "qclass": GETDNS_RRCLASS_IN,
        "qname": <bindata for www.kernel-error.de.>,
        "qtype": GETDNS_RRTYPE_AAAA
      }
    },
    {
      "additional":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv4_address": <bindata for 5.9.24.235>,
            "rdata_raw": <bindata of 0x050918eb>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv4_address": <bindata for 176.9.109.53>,
            "rdata_raw": <bindata of 0xb0096d35>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv4_address": <bindata for 203.137.119.119>,
            "rdata_raw": <bindata of 0xcb897777>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns1.kernel-error.de.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:161:3ec::53>,
            "rdata_raw": <bindata of 0x2a0104f8016103ec0000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns2.kernel-error.org.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2a01:4f8:150:1095::53>,
            "rdata_raw": <bindata of 0x2a0104f8015010950000000000000053>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for ns3.kernel-error.com.>,
          "rdata":
          {
            "ipv6_address": <bindata for 2001:310:6000:f::1fc7:1>,
            "rdata_raw": <bindata of 0x200103106000000f000000001fc70001>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_AAAA
        },
        {
          "do": 0,
          "extended_rcode": 0,
          "rdata":
          {
            "rdata_raw": <bindata of 0x>
          },
          "type": GETDNS_RRTYPE_OPT,
          "udp_payload_size": 4096,
          "version": 0,
          "z": 0
        }
      ],
      "answer":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for www.kernel-error.de.>,
          "rdata":
          {
            "ipv4_address": <bindata for 5.9.24.250>,
            "rdata_raw": <bindata of 0x050918fa>
          },
          "ttl": 300,
          "type": GETDNS_RRTYPE_A
        }
      ],
      "answer_type": GETDNS_NAMETYPE_DNS,
      "authority":
      [
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns2.kernel-error.org.>,
            "rdata_raw": <bindata for ns2.kernel-error.org.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns1.kernel-error.de.>,
            "rdata_raw": <bindata of 0x036e7331c010>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        },
        {
          "class": GETDNS_RRCLASS_IN,
          "name": <bindata for kernel-error.de.>,
          "rdata":
          {
            "nsdname": <bindata for ns3.kernel-error.com.>,
            "rdata_raw": <bindata for ns3.kernel-error.com.>
          },
          "ttl": 86400,
          "type": GETDNS_RRTYPE_NS
        }
      ],
      "canonical_name": <bindata for www.kernel-error.de.>,
      "header":
      {
        "aa": 1,
        "ad": 0,
        "ancount": 1,
        "arcount": 7,
        "cd": 0,
        "id": 59688,
        "nscount": 3,
        "opcode": GETDNS_OPCODE_QUERY,
        "qdcount": 1,
        "qr": 1,
        "ra": 0,
        "rcode": GETDNS_RCODE_NOERROR,
        "rd": 1,
        "tc": 0,
        "z": 0
      },
      "question":
      {
        "qclass": GETDNS_RRCLASS_IN,
        "qname": <bindata for www.kernel-error.de.>,
        "qtype": GETDNS_RRTYPE_A
      }
    }
  ],
  "status": GETDNS_RESPSTATUS_GOOD
}

Oh und weil ich gerade dabei war… Ich habe direkt ns2.kernel-error.org mit einem gültigen Zertifikat ausgestattet.

Fragen? Dann fragen 🙂

Arbeit im Kindergarten

Au man ich arbeite im Kindergarten. Die Kaffeemaschine ist abgeschaltet worden, weil eine unserer Küchen nicht ordentlich gehalten wurde O_o Man sollte doch wohl in der Lage sein, das schmutzige Geschirr in die Spülmaschine zu stellen und nicht einfach irgendwo in die Küche. Kollektivstrafe „kein Kaffee mehr für den Tag“ geht auch irgendwie nicht. Ich bin hier echt im Kindergarten *kopfschüttel*

Meine Kollegen sind lustig…

In einer der Küchen meines Brötchengebers steht seit ein paar Tagen ein Tiefer Teller gefüllt mit Zucker in der Nähe der Kaffeemaschine. Warum auch immer dieses so ist; keine Ahnung. Heute hat jemand ein Bild hinter diesen Teller gestellt und joar das bringt mich zum Lachen.

Nur damit nicht gemotzt wird: Dorgen sind böse!

Kaltgang im DataCenter

Ich habe vor kurzem in einem DataCenter gestanden und mir einen „neuen“ Kaltgang angeschaut bei dem mir wirklich alles aus dem Gesicht gefallen ist. Der Betreiber dieses DataCenters ist groß, international tätig, nennt eine größere zweistellige Zahl an DataCentern sein eigen und ist doch recht namhaft… Dieser Versuche von einem Kaltgang ist dabei von eben diesem Betreiber gebaut worden. Nicht für einen vermieteten Cage sondern ganz trocken für vermietete Rackreihen…. Rackreihen bei denen sie penibel darauf achten dass dort ganz sicher auch die einzelnen HE Blenden eingesetzt werden, damit ein korrekter Luftstrom garantiert ist. Das meinen die wirklich ernst! *kopfschüttel*

Oh und nein… ich werde jetzt nicht sagen wer der Betreiber ist.

IPv6 Traffic hat sich verdoppelt

Wenn ich meine Graphen so verfolge sehe ich eine Verdopplung des IPv6 Traffics seit dem Anfang diesen Jahres beim HTTPS Traffic. SMTP ist es nur knapp 50% mehr. Ich würde nun jetzt einfach mal behaupten dass inzwischen viel mehr Enduser mit einer IPv6 Adresse unterwegs sind und Mailserverbetreiber so schnell nicht „nachziehen“.

Mich überrascht dieser starke Anstieg in 2017 etwas daher habe ich nun mal alles gegen meinen IPv4 Traffic gehalten.

Insg. habe ich von meinen Systemen ausgehend 12,5% mehr IPv6 Traffic als IPv4 Traffic. Eingehend habe ich tatsächlich 6% mehr IPv6 Traffic als IPv4 Traffic 🙂 OK OK jetzt bin ich dabei sicher nicht repräsentativ… Nur ist in 2017 das Verhältnis zumindest bei mir von IPv4 zu IPv6 gekippt. Jetzt sind alle Systeme bei mir durchgängig IPv6 fähig und alles bewegt sich sicher sehr in seiner eigenen Blase, nicht zu viel herein steigern…

Gab es da nicht vor Kurzem eine Heise Meldung?

https://www.heise.de/newsticker/meldung/IPv4-Adressen-immer-knapper-Adressklau-sogar-mit-gefaelschter-Sterbeurkunde-3872129.html

Schaue ich mir die großen an sieht man das es mehr wird und vor allem auch bei uns in Deutschland:

https://www.google.de/ipv6/statistics.html

https://stats.labs.apnic.net/ipv6

Mit einigen Bekannten habe ich ebenfalls gesprochen, hier zeigt sich ein sehr ähnliches Bild. Wir bleiben nur immer in der gleichen „Blase“. Mein Brötchengeber wäre noch ein ganz guter und sicher schon ein repräsentativ Statistikgeber, nur leider ist es hier produktiv noch extrem dunkel wenn es um IPv6 geht. 🙁 Hier gibt es gerade andere Baustellen.

Wie ist es denn bei euch? Jemand ein paar Zahlen oder Links für mich?

Update

Na schau an, eine erste Anregung habe ich schon mal. Mobile Endgeräte... Wenn man nicht gerade bei der Telekom ist sind viele noch mit ihren Smartphones auf IPv4 festgebunden. Statistiken von google/facebook/twitter usw. wird dieses sicher stark verfälschen. Wobei *grübel* verfälschen? Ist „das Internet“ (ich denke gerade an The IT Crowd) nicht inzwischen eher Smartphone? Benutzer mit einem Smartphone werden meine Webseite kaum anschauen, denn sie sieht mit so einem Gerät noch viel schlimmer aus als sie es bereits mit einem normalen Browser tut.

RFC 7858 – DNS over Transport Layer Security

Ich habe in den letzten Tagen etwas mit dem RFC 7858 (https://tools.ietf.org/html/rfc7858) herumgespielt. Meine Zonen und auch Dienste sind per DNSsec, HSTS, Pinning usw. usw. abgesichert. Warum also noch DNS per TLS? Nun ja… Sinn macht es sicher keinen, bei mir ist nichts spannendes zu finden und kaum ein Besucher wird mit Problemen rechnen müssen wenn er hier ist. Für mich sollte Kryptographie nicht die Ausnahme sondern der Normalzustand sein. RFC 7858 ist da nur ein weiteres Detail. In einer DNS Abfrage finden sich selten geheime Daten. Klar wäre es schlecht wenn diese verändert würden um diese zu verhindern reicht eine Signatur. Das mitlesen der DNS Abfragen würde einer dritten Person so aber offenlegen wo man surft und welche Dienste man nutzt. Sind diese Abfragen per TLS verschlüsselt bleibt dieses geheim. Daher macht es wohl am meisten Sinn es für seinen lokalen DNS Resolver zu nutzen oder es auf großen DNS Servern zu aktivieren. DNS Servern welche sich um viele Zonen kümmern….

Um irgendwo zu starten und selbst einen Eindruck davon zu bekommen habe ich es auf meinen DNS Servern für meine Zonen aktiviert. Bis auf ns2.kernel-error.org haben die Server gültige Zertifikate. Bei ns2.kernel-error.org muss ich mal schauen wie es sich entwickelt.

Als Test:

$ getdns_query -s www.kernel-error.de a @176.9.109.53 -l L

Viel Spaß

Sanftanlauf für Elektromotoren: Softstart und Anlaufstrombegrenzer im Detail

In meiner Werkstatt habe ich ein paar Elektrogeräte für welche ich gerne einen Sanftanlauf hätte. Einmal um den „Druck“ den hohen Anlaufstrom etwas von den ~Sicherungen~ zu nehmen und dann natürlich um die Geräte an sich etwas zu schonen, denn ein schlagartig anlaufender Elektromotor haut schon ganz schön rein 🙂

Natürlich gibt es viele schöne Dinge, die man einfach kaufen und zwischen stecken/einbauen kann aber ich wollte selbst einmal überlegen wie ich es realisieren kann und vor allem mit dem Zeug aus meiner „Restekiste“. So bin ich auf folgende Schaltung für meine Absauganlage gekommen. Die Anlage bekommt nur Strom, wenn ein anders Elektrogerät eingeschaltet wird und schaltet mit einem gewissen Nachlauf selbst ab (diese Schaltung führe ich vielleicht auch mal irgendwann auf). Es funktioniert also nicht diese einfach immer unter Strom zwischen zu stecken! Oh und natürlich sind Arbeiten am Strom sehr gefährlich und dürfen nur von Menschen ausgeführt werden, welche dieses dürfen 🙂 Diese Beschreibung also nicht nachmachen!

Schaltplan für einen 240V Sanftanlauf für Elektromotoren.

C1 und R1 arbeiten in der Schaltung als eine Art Kondensatornetzteil. D1 – D4 übernehmen die Aufgabe des Gleichrichters. R2 sorgt dafür, dass beim Abschalten die Schaltung möglichst schnell spannungsfrei ist (die Kondensatoren also entladen werden). C2 glättet die Spannung aus dem Gleichrichter, D5 nagelt die Spannung in der Schaltung auf ca. 18V fest. Über R3 wird C3 langsam geladen. R4 sorgt wieder für schnelles Entladen von C3. D6 schützt Q1 vor der Spule in K1, R5 ist die eigentliche „Handbremse“ für den nachgeschalteten Elektromotor. Er lässt, bis zum anziehen des Relais weniger durch und der Motor kann nicht mit voller Power loslegen.

Kommt also Spannung auf die Schaltung wird diese so lang über R5 zum Motor geleitet, bis C3 geladen ist. Denn wenn C3 voll ist, schaltet Q1 durch und somit zieht K1 an und überbrückt so R5.

R5 muss daher auf den nach gelagerten Elektromotor abgestimmt sein, sonst platzt R5 ggf. einfach. Die Größe von C3 bestimmt hierbei die Länge der Verzögerung von K1. 220μF war dabei für mich etwas zu klein. 440μF ist die perfekte Zeit

Die Platine selbst sieht nun so aus.

Selbstgebaute Platine für einen 240V Sanftanlauf für Elektromotoren.

Oh, die Absauganlage besteht aus einem Nassauger von Kärcher hinter einem selbstgebauten Zyklonabscheider.

Fragen? Dann fragen 🙂

Read- und Write-Latency mit ioping messen: So geht’s

Um die Performance von irgendwelchen Datenträgern / Netzlaufwerken usw. zu messen gibt es sehr viele verschiedene Tools. bonnie++ ist hier ein gutes Beispiel. Möchte man nur „mal schnell“ die read-/write latency messen und ein paar grobe Infos zu den IOPs haben kann ich hier ioping empfehlen.

Ein Beispiel zum messen der read latency:

➜  ~ ioping -s 256k -T 120 -D -c 20 ./
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=1 time=16.0 us (warmup)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=2 time=35.7 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=3 time=45.8 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=4 time=46.3 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=5 time=43.4 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=6 time=46.8 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=7 time=41.2 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=8 time=41.7 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=9 time=47.7 us (slow)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=10 time=42.4 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=11 time=41.8 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=12 time=41.1 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=13 time=48.8 us (slow)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=14 time=47.1 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=15 time=42.8 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=16 time=47.9 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=17 time=50.5 us (slow)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=18 time=52.8 us (slow)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=19 time=44.6 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=20 time=45.3 us

--- ./ (zfs tanksmeer/usr/home) ioping statistics ---
19 requests completed in 853.7 us, 4.75 MiB read, 22.3 k iops, 5.43 GiB/s
generated 20 requests in 19.0 s, 5 MiB, 1 iops, 269.2 KiB/s
min/avg/max/mdev = 35.7 us / 44.9 us / 52.8 us / 3.85 us

ioping liest hier jeweils 256k (-s 256k), ignoriert alles was länger brauch als die angegebene Zeit (-T 120), macht es als direct IO ohne cache (-D), dieses insg. 20 mal in Folge (-c 20) und einfach im aktuellen Pfad (./).

Die Zusammenfassung ist ähnlich wie bei ping 🙂

Ein Beispiel zum messen der write latency:

➜  ~ ioping -s 256k -T 120 -D -W -c 20 ./
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=1 time=27.0 us (warmup)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=2 time=54.4 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=3 time=60.6 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=4 time=65.5 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=5 time=57.8 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=6 time=74.0 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=7 time=65.5 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=8 time=65.3 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=9 time=70.9 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=10 time=70.7 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=11 time=2.65 ms (slow)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=12 time=71.8 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=13 time=64.5 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=14 time=77.0 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=15 time=63.3 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=16 time=67.4 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=17 time=51.6 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=18 time=82.9 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=19 time=81.5 us (fast)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=20 time=56.2 us (fast)

--- ./ (zfs tanksmeer/usr/home) ioping statistics ---
19 requests completed in 3.86 ms, 4.75 MiB written, 4.93 k iops, 1.20 GiB/s
generated 20 requests in 19.0 s, 5 MiB, 1 iops, 269.5 KiB/s
min/avg/max/mdev = 51.6 us / 202.9 us / 2.65 ms / 577.9 us

Richtig… Hier ist nur ein -W dazu gekommen!

So lässt sich schnell und einfach ein Eindruck über die aktuelle Performance von einem „Filesystem“ erlangen. Einfach um zu sehen ob es sich unter Last anders verhält oder ähnliches.

Viel Spaß und bei Fragen, einfach fragen.

« Ältere Beiträge Neuere Beiträge »

© 2025 -=Kernel-Error=-

Theme von Anders NorénHoch ↑