Macbook: Fixing the Wireshark Permissions bug “You don’t have permission to capture on that device”

If you see the error “The capture session could not be initiated on the device “en0″ (You don’t have permission to capture on that device)” when trying to start a pcap on wireshare you can try installing ChmodBPF; but I suspect you will need to follow the steps below:

$ whoami
superman
$ cd /dev
/dev $ sudo chown superman:admin bp*
Password:
$ ls -la | grep bp
crw-------   1 cp363412  admin     0x17000000 Jan 13 21:48 bpf0
crw-------   1 cp363412  admin     0x17000001 Jan 14 09:56 bpf1
crw-------   1 cp363412  admin     0x17000002 Jan 13 20:57 bpf2
crw-------   1 cp363412  admin     0x17000003 Jan 13 20:57 bpf3
crw-------   1 cp363412  admin     0x17000004 Jan 13 20:57 bpf4
/dev $

Macbook: Changing prompt $ information in the mac terminal window

When you open terminal you will see that it defaults the information that you see on the prompt, which can use up quite a bit of the screen real estate.

Last login: Sat Jan 14 11:13:00 on ttys000
cp363412~$ 

Customize the zsh Prompt in Terminal

Typically, the default zsh prompt carries information like the username, machine name, and location starting in the user’s home directory. These details are stored in the zsh shell’s system file at the /etc/zshrc location.

PS1="%n@%m %1~ %# "

In this string of variables:

  • %n is the username of your account. 
  • %m is the MacBook’s model name. 
  • %1~ means the current working directory path where the ~ strips the $HOME directory location. 
  • %# means that the prompt will show # if the shell is running with root (administrator) privileges, or else offers % if it doesn’t.

Below are a few other options that I have used previously:

\h   The hostname, up to the first . (e.g. andrew) 
\H   The hostname. (e.g. andrew.ninja.com)
\j   The number of jobs currently managed by the shell. 
\l   The basename of the shell's terminal device name. 
\s   The name of the shell, the basename of $0 (the portion following 
      the final slash).
\w   The current working directory. 
\W   The basename of $PWD. 
\!   The history number of this command. 
\#   The command number of this command

To change this, open Terminal, type the following command, and hit Return:

nano ~/.zshrc

Below is my favourite, which will just display your login name (use Ctrl + X to exit and save):

PROMPT='%n$ '

I prefer to see the path (less the home directory) in the prompt:

PROMPT='%n:%1~$ '

You can pick a font colour from black, white, yellow, green, red, blue, cyan, and magenta. Here’s how to use them:

PROMPT='%F{cyan}%n%f:~$ '

There are more modifications to this, but this is as far as i go 🙂

Mac OS X: Perform basic vulnerability checks with nmap vulners scripts

This is a very short post to help anyone quickly setup vulnerability checking for a site they own (and have permission to scan). I like the vulners scripts as they cover a lot of basic ground quickly with one script.

## First go to your NMAP script directory
$ cd /usr/local/share/nmap/scripts
## Now install vulners
git clone https://github.com/vulnersCom/nmap-vulners.git
## Now copy the files up a directory
$ cd nmap-vulners
$ ls
LICENSE				example.png			http-vulners-regex.json		paths_regex_example.png		vulners.nse
README.md			http-vulners-paths.txt		http-vulners-regex.nse		simple_regex_example.png
$ sudo cp *.* ..
## Now update NMAP NSE script database
$ nmap --script-updatedb
## Now run the scripts
$ nmap -sV --script vulners tesla.com
## Now do a wildcard scan
$ nmap --script "http-*" tesla.com

Mac OS X: View the details of a websites supported TLS certificates from terminal

The below script will give you basic information on a websites certificate:

$ curl --insecure -vvI https://andrewbaker.ninja 2>&1 | awk 'BEGIN { cert=0 } /^\* SSL connection/ { cert=1 } /^\*/ { if (cert) print }'
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: CN=andrewbaker.ninja
*  start date: Nov  4 23:00:13 2022 GMT
*  expire date: Feb  2 23:00:12 2023 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Mark bundle as not supporting multiuse
* Connection #0 to host andrewbaker.ninja left intact

NMAP is provides a simple way to get a list of available ciphers from a host website / server. Additionally, nmap provides a strength rating of strong, weak, or unknown for each available cipher. First, download the ssl-enum-ciphers.nse nmap script (explanation here). Then from the same directory as the script, run nmap as follows:

$ nmap --script ssl-enum-ciphers -p 443 andrewbaker.ninja
Starting Nmap 7.93 ( https://nmap.org ) at 2023-05-11 10:40 SAST
Nmap scan report for andrewbaker.ninja (13.244.140.33)
Host is up (0.051s latency).
rDNS record for 13.244.140.33: ec2-13-244-140-33.af-south-1.compute.amazonaws.com

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (secp256r1) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (secp256r1) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 2048) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 2048) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_256_CBC_SHA (dh 2048) - A
|       TLS_DHE_RSA_WITH_AES_128_CBC_SHA (dh 2048) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.3:
|     ciphers:
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (secp256r1) - A
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|     cipher preference: server
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 9.61 seconds

Next up (and probably my favourite), sslscan is a really decent tool because it tests connecting with TLS and SSL including obsolete SSL versions. It then reports about the server’s cipher suites and certificate.

$ brew install sslscan
$ sslscan andrewbaker.ninja
Version: 2.0.15
OpenSSL 3.0.7 1 Nov 2022

Connected to 13.244.140.33

Testing SSL server andrewbaker.ninja on port 443 using SNI name andrewbaker.ninja

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   enabled
TLSv1.1   enabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Secure session renegotiation supported

  TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed
TLSv1.1 not vulnerable to heartbleed
TLSv1.0 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve P-256 DHE 256
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve P-256 DHE 256
Accepted  TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve P-256 DHE 256
Preferred TLSv1.2  256 bits  ECDHE-RSA-AES256-GCM-SHA384   Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-GCM-SHA256   Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.2  128 bits  ECDHE-RSA-AES128-SHA256       Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  ECDHE-RSA-AES256-SHA384       Curve P-256 DHE 256
Accepted  TLSv1.2  256 bits  AES256-GCM-SHA384
Accepted  TLSv1.2  128 bits  AES128-GCM-SHA256
Accepted  TLSv1.2  256 bits  AES256-SHA
Accepted  TLSv1.2  128 bits  AES128-SHA
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-GCM-SHA384     DHE 2048 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-GCM-SHA256     DHE 2048 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA256         DHE 2048 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA256         DHE 2048 bits
Accepted  TLSv1.2  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  TLSv1.2  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
Preferred TLSv1.1  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.1  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.1  256 bits  AES256-SHA
Accepted  TLSv1.1  128 bits  AES128-SHA
Accepted  TLSv1.1  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  TLSv1.1  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits
Preferred TLSv1.0  128 bits  ECDHE-RSA-AES128-SHA          Curve P-256 DHE 256
Accepted  TLSv1.0  256 bits  ECDHE-RSA-AES256-SHA          Curve P-256 DHE 256
Accepted  TLSv1.0  256 bits  AES256-SHA
Accepted  TLSv1.0  128 bits  AES128-SHA
Accepted  TLSv1.0  256 bits  DHE-RSA-AES256-SHA            DHE 2048 bits
Accepted  TLSv1.0  128 bits  DHE-RSA-AES128-SHA            DHE 2048 bits

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  192 bits  secp384r1 (NIST P-384)
TLSv1.3  260 bits  secp521r1 (NIST P-521)
TLSv1.2  128 bits  secp256r1 (NIST P-256)
TLSv1.2  192 bits  secp384r1 (NIST P-384)
TLSv1.2  260 bits  secp521r1 (NIST P-521)

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
RSA Key Strength:    2048

Subject:  andrewbaker.ninja
Altnames: DNS:andrewbaker.ninja, DNS:www.andrewbaker.ninja
Issuer:   Zscaler Intermediate Root CA (zscaler.net) (t)

Not valid before: May  6 06:30:35 2023 GMT
Not valid after:  May 20 06:30:35 2023 GMT

If you want a detailed dump of the certificate run (you will need openssl installed):

$ openssl s_client -connect andrewbaker.ninja:443 </dev/null 2>/dev/null | openssl x509 -inform pem -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            03:bd:20:6e:ef:67:55:93:2a:a8:90:9f:40:e4:b2:a8:c0:fe
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = US, O = Let's Encrypt, CN = R3
        Validity
            Not Before: Nov  4 23:00:13 2022 GMT
            Not After : Feb  2 23:00:12 2023 GMT
        Subject: CN = andrewbaker.ninja
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:c8:30:00:b3:f0:fb:03:10:90:57:4a:df:7f:28:
                    34:b9:2e:94:1a:28:29:41:2b:88:48:3b:c0:48:2a:
                    f0:62:3d:57:0d:32:db:30:9b:c5:98:11:b3:14:a7:
                    a8:e0:30:1d:d7:ec:cc:86:6f:d2:f1:7b:a4:70:9c:
                    98:e0:63:34:ae
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Key Identifier:
                B9:28:D2:09:38:B0:B1:03:77:DA:8F:C6:AD:2E:51:EF:0F:7F:23:4F
            X509v3 Authority Key Identifier:
                keyid:14:2E:B3:17:B7:58:56:CB:AE:50:09:40:E6:1F:AF:9D:8B:14:C2:C6

            Authority Information Access:
                OCSP - URI:http://r3.o.lencr.org
                CA Issuers - URI:http://r3.i.lencr.org/

            X509v3 Subject Alternative Name:
                DNS:andrewbaker.ninja, DNS:www.andrewbaker.ninja
            X509v3 Certificate Policies:
                Policy: 2.23.140.1.2.1
                Policy: 1.3.6.1.4.1.44947.1.1.1
                  CPS: http://cps.letsencrypt.org

            CT Precertificate SCTs:
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : B7:3E:FB:24:DF:9C:4D:BA:75:F2:39:C5:BA:58:F4:6C:
                                5D:FC:42:CF:7A:9F:35:C4:9E:1D:09:81:25:ED:B4:99
                    Timestamp : Nov  5 00:00:13.652 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:46:02:21:00:89:98:62:15:D5:40:1D:80:9D:40:4B:
                                31:B1:E3:C5:3B:65:41:11:4D:98:D2:E1:23:16:45:0D:
                                DA:08:FE:72:AB:02:21:00:A7:F0:5D:49:63:4F:91:4C:
                                CF:60:8D:FF:26:F6:0B:1B:0C:47:9C:B6:70:57:7C:68:
                                AB:F0:9B:35:48:34:08:A4
                Signed Certificate Timestamp:
                    Version   : v1 (0x0)
                    Log ID    : 7A:32:8C:54:D8:B7:2D:B6:20:EA:38:E0:52:1E:E9:84:
                                16:70:32:13:85:4D:3B:D2:2B:C1:3A:57:A3:52:EB:52
                    Timestamp : Nov  5 00:00:14.177 2022 GMT
                    Extensions: none
                    Signature : ecdsa-with-SHA256
                                30:45:02:21:00:E1:8B:7F:3F:75:05:20:8A:27:3D:30:
                                64:BB:4B:FE:EF:24:C9:7E:85:6C:6D:DF:16:ED:BE:23:
                                9C:97:67:E1:DD:02:20:60:89:B6:D9:0F:BE:C4:E0:7B:
                                05:E1:EE:6D:0B:2D:78:C9:58:AA:0F:10:C0:34:FE:79:
                                FA:63:DD:2D:50:01:5B
    Signature Algorithm: sha256WithRSAEncryption
         4a:54:e0:ec:05:b8:58:ef:44:de:a8:5f:89:fc:1d:cb:86:39:
         05:1d:d3:b2:57:73:bd:6d:11:e5:c2:fd:cd:1a:6b:ee:62:11:
         f8:94:6b:22:b9:16:d6:e3:95:ed:04:9e:7c:ba:1b:3e:5f:dc:
         4f:a0:ae:58:ec:3c:25:a0:41:a5:c8:b9:c8:7a:3c:2f:1f:17:
         60:e8:7d:f0:a2:8e:0d:45:cb:7b:b1:06:13:75:3b:b0:cb:f6:
         6e:2f:71:70:6a:55:96:34:58:db:42:06:5a:7f:78:00:8f:7d:
         e3:83:02:30:82:49:52:38:da:07:6b:c3:ba:ad:09:1e:7e:33:
         0c:f5:0b:49:33:9d:b7:4e:1a:16:c2:ef:47:6f:ec:02:03:4a:
         84:75:bb:30:6e:8a:b4:22:da:d6:ac:43:5d:9b:3c:8b:2a:13:
         af:2b:2e:ab:02:58:dd:80:73:04:8c:dc:2e:48:71:ae:57:c4:
         0e:40:8c:6d:52:b5:91:0c:6b:0d:5e:98:01:6f:09:d1:3a:1b:
         41:7c:70:cc:66:9a:89:b3:b7:27:3d:6f:62:10:66:bb:63:67:
         59:08:ed:7e:c0:c3:31:1c:89:dd:ce:f2:6f:42:fd:42:21:94:
         c3:27:6e:d9:ea:d1:5f:5a:6f:58:26:eb:3e:ba:a6:ee:ed:45:
         00:99:e3:9e
-----BEGIN CERTIFICATE-----
MIIEdTCCA12gAwIBAgISA70gbu9nVZMqqJCfQOSyqMD+MA0GCSqGSIb3DQEBCwUA
MDIxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MQswCQYDVQQD
EwJSMzAeFw0yMjExMDQyMzAwMTNaFw0yMzAyMDIyMzAwMTJaMBwxGjAYBgNVBAMT
EWFuZHJld2Jha2VyLm5pbmphMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEyDAA
s/D7AxCQV0rffyg0uS6UGigpQSuISDvASCrwYj1XDTLbMJvFmBGzFKeo4DAd1+zM
hm/S8XukcJyY4GM0rqOCAmQwggJgMA4GA1UdDwEB/wQEAwIHgDAdBgNVHSUEFjAU
BggrBgEFBQcDAQYIKwYBBQUHAwIwDAYDVR0TAQH/BAIwADAdBgNVHQ4EFgQUuSjS
CTiwsQN32o/GrS5R7w9/I08wHwYDVR0jBBgwFoAUFC6zF7dYVsuuUAlA5h+vnYsU
wsYwVQYIKwYBBQUHAQEESTBHMCEGCCsGAQUFBzABhhVodHRwOi8vcjMuby5sZW5j
ci5vcmcwIgYIKwYBBQUHMAKGFmh0dHA6Ly9yMy5pLmxlbmNyLm9yZy8wMwYDVR0R
BCwwKoIRYW5kcmV3YmFrZXIubmluamGCFXd3dy5hbmRyZXdiYWtlci5uaW5qYTBM
BgNVHSAERTBDMAgGBmeBDAECATA3BgsrBgEEAYLfEwEBATAoMCYGCCsGAQUFBwIB
FhpodHRwOi8vY3BzLmxldHNlbmNyeXB0Lm9yZzCCAQUGCisGAQQB1nkCBAIEgfYE
gfMA8QB3ALc++yTfnE26dfI5xbpY9Gxd/ELPep81xJ4dCYEl7bSZAAABhEUWgVQA
AAQDAEgwRgIhAImYYhXVQB2AnUBLMbHjxTtlQRFNmNLhIxZFDdoI/nKrAiEAp/Bd
SWNPkUzPYI3/JvYLGwxHnLZwV3xoq/CbNUg0CKQAdgB6MoxU2LcttiDqOOBSHumE
FnAyE4VNO9IrwTpXo1LrUgAAAYRFFoNhAAAEAwBHMEUCIQDhi38/dQUgiic9MGS7
S/7vJMl+hWxt3xbtviOcl2fh3QIgYIm22Q++xOB7BeHubQsteMlYqg8QwDT+efpj
3S1QAVswDQYJKoZIhvcNAQELBQADggEBAEpU4OwFuFjvRN6oX4n8HcuGOQUd07JX
c71tEeXC/c0aa+5iEfiUayK5Ftbjle0Enny6Gz5f3E+grljsPCWgQaXIuch6PC8f
F2DoffCijg1Fy3uxBhN1O7DL9m4vcXBqVZY0WNtCBlp/eACPfeODAjCCSVI42gdr
w7qtCR5+Mwz1C0kznbdOGhbC70dv7AIDSoR1uzBuirQi2tasQ12bPIsqE68rLqsC
WN2AcwSM3C5Ica5XxA5AjG1StZEMaw1emAFvCdE6G0F8cMxmmomztyc9b2IQZrtj
Z1kI7X7AwzEcid3O8m9C/UIhlMMnbtnq0V9ab1gm6z66pu7tRQCZ454=
-----END CERTIFICATE-----

Mac OS X: Using dig and whois to resolve DNS issues between your DNS server and the authoritive DNS Server

When debugging DNS issues its important to verify the local DNS response with the authoritive DNS nameserver. With dig we can directly query the authoritative name servers for a domain, these are the DNS servers that hold the authoritative records for the domains DNS zone; the source of truth. If a correct response is received from the authoritative DNS server but not when querying against your own DNS server then you should investigate why your local DNS server is not able to resolve the record.

Lets first see where our DNS traffic is going:

$ scutil --dns | grep 'nameserver\[[0-9]*\]'
  nameserver[0] : 100.64.0.1
  nameserver[0] : 192.168.0.
  nameserver[0] : 192.168.0.1

The first DNS server in the list – at 100.64.0.1 will need to accept TCP and UDP traffic over port 53 from our client/server. A port scanner such as the nmap tool can be used to confirm if the DNS server is available on port 53 as shown below.

# First check UDP

$ nmap -sU -p 53 100.64.0.1
Starting Nmap 7.93 ( https://nmap.org ) at 2022-11-21 22:04 SAST
Nmap scan report for 100.64.0.1
Host is up.

PORT   STATE         SERVICE
53/udp open|filtered domain

Nmap done: 1 IP address (1 host up) scanned in 2.08 seconds

## Next check TCP

$ nmap -sT -p 53 100.64.0.1
Starting Nmap 7.93 ( https://nmap.org ) at 2022-11-21 22:07 SAST
Nmap scan report for 100.64.0.1
Host is up (0.00059s latency).

PORT   STATE SERVICE
53/tcp open  domain

Nmap done: 1 IP address (1 host up) scanned in 0.15 seconds

It’s worth noting that scanning UDP with nmap is not reliable due to the nature of UDP, this is why the state is listed as open or filtered. We can clearly see that TCP 53 is definitely open and responding which is a good sign, if the state was reported as filtered the next thing to investigate would be the connectivity to the DNS server, in particular any firewall running on the DNS server would need to be configured to allow TCP and UDP port 53 traffic in.

We can also run tcpdump to watch the traffic going to our local DNS server:

$ sudo tcpdump -n host 100.64.0.1
tcpdump: data link type PKTAP
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on pktap, link-type PKTAP (Apple DLT_PKTAP), snapshot length 524288 bytes
23:17:39.411500 IP 100.64.0.1.58169 > 100.64.0.1.53: 50915+ A? logs.af-south-1.amazonaws.com. (47)
23:17:39.411594 IP 100.64.0.1.58169 > 100.64.0.1.53: 50915+ A? logs.af-south-1.amazonaws.com. (47)
23:17:39.411703 IP 100.64.0.1.53 > 100.64.0.1.58169: 50915 1/0/0 A 100.64.1.18 (63)
23:17:39.411734 IP 100.64.0.1.53 > 100.64.0.1.58169: 50915 1/0/0 A 100.64.1.18 (63)
23:17:39.412167 IP 100.64.0.1.57548 > 100.64.1.18.443: Flags [SEW], seq 630452899, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 542272848 ecr 0,sackOK,eol], length 0
23:17:39.412204 IP 100.64.1.18.57548 > 100.64.0.1.9010: Flags [SEW], seq 630452899, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 542272848 ecr 0,sackOK,eol], length 0
23:17:39.412302 IP 100.64.0.1.9010 > 100.64.1.18.57548: Flags [S.E], seq 2920832254, ack 630452900, win 65535, options [mss 1360,nop,wscale 6,nop,nop,TS val 974661492 ecr 542272848,sackOK,eol], length 0

Next up, query the local DNS response (and you will note that the A record is missing):

$ dig andrewbaker.ninja
; <<>> DiG 9.10.6 <<>> andrewbaker.ninja
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 35921
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;andrewbaker.ninja.		IN	A

;; Query time: 1348 msec
;; SERVER: 100.64.0.1#53(100.64.0.1)
;; WHEN: Mon Nov 21 19:44:32 SAST 2022
;; MSG SIZE  rcvd: 46

Next, to get the authoritive name servers of a domain we can use the ‘whois’ command as shown below.

$ whois andrewbaker.ninja | grep -i "name server"
Name Server: ns-983.awsdns-58.net
Name Server: ns-462.awsdns-57.co
Name Server: ns-1745.awsdns-26.co.uk
Name Server: ns-1363.awsdns-42.org
Name Server: NS-1363.AWSDNS-42.ORG
Name Server: NS-462.AWSDNS-57.COM
Name Server: NS-1745.AWSDNS-26.CO.UK
Name Server: NS-983.AWSDNS-58.NET

As shown andrewbaker.ninja currently has 8 authoritative name servers. If we run a dig directly against any of these we should receive an authoritative response, that is an up to date and non cached response straight from the source rather than from our local DNS server. In the below example we have run our query against @ns-983.awsdns-58.net

$ dig @ns-983.awsdns-58.net andrewbaker.ninja

; <<>> DiG 9.10.6 <<>> @ns-983.awsdns-58.net andrewbaker.ninja
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64987
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 8, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;andrewbaker.ninja.		IN	A

;; ANSWER SECTION:
andrewbaker.ninja.	300	IN	A	13.244.140.33

;; AUTHORITY SECTION:
andrewbaker.ninja.	172800	IN	NS	ns-1254.awsdns-28.org.
andrewbaker.ninja.	172800	IN	NS	ns-1514.awsdns-61.org.
andrewbaker.ninja.	172800	IN	NS	ns-1728.awsdns-24.co.uk.
andrewbaker.ninja.	172800	IN	NS	ns-1875.awsdns-42.co.uk.
andrewbaker.ninja.	172800	IN	NS	ns-491.awsdns-61.com.
andrewbaker.ninja.	172800	IN	NS	ns-496.awsdns-62.com.
andrewbaker.ninja.	172800	IN	NS	ns-533.awsdns-02.net.
andrewbaker.ninja.	172800	IN	NS	ns-931.awsdns-52.net.

;; Query time: 20 msec

You can now see the A record is returned. Also note that in this dig response we now have the “aa” flag in the header which represents that this is an authoritative answer and is not a cached response (note: qr = query response and rd = recursion desired). If we run this same dig command again, the 300 second TTL that was returned in the answer section will continually state that the TTL is 300 seconds as the response is authoritative.

However if we were to run this dig without specifying @ns-983.awsdns-58.net we would be querying our local DNS server which is not authoritative for the andrewbaker.ninja domain, after the first result the record will be cached locally. This can be confirmed by running the dig command again, as the TTL value will drop down until it reaches 0 and is removed from the cache completely.

By querying the authoritative name server directly we ensure that we are getting the most up to date response rather than a potential old cached response from our own local DNS server or local DNS cache.

Linux: Find the maximum packet size (MTU) between two hosts (using do not fragment flag)


If you have ever tried to use jumbo packets, or trace a weird slowness on the network – one of the things that frequently comes up is packet fragmentation. This is basically where a source machine is sending bigger packets than can be consumed along its pathway to a destination machine. This means the packets will need to be split up. This causes a host of performance issues.

So how do you diagnose this? Well Ping is your friend. It allows you to flag packets to not be fragmented and specify a minimum and maximum packet size. The example below sends a 1460 byte do not fragment packet from the host to example.com:

$ ping -M do -s 1460 example.com 
PING example.com (93.184.216.34) 1460(1488) bytes of data. 
1468 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=1 ttl=45 time=223 ms
1468 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=2 ttl=45 time=223 ms 1468 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=3 ttl=45 time=223 ms

Taking the example above and running on a Macbook/OSX:

$ ping -D -s 1460 example.com
PING example.com (93.184.216.34): 1460 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4

The maximum packet size over the internet is 1500 bytes. So 1490 should be fine, right?

$ ping -M do -s 1490 example.com 
PING example.com (93.184.216.34) 1490(1518) bytes of data. 
ping: local error: Message too long, mtu=1500 ping: local error: Message too long, mtu=1500

The same test on Macbook/OSX:

$ ping -D -s 1490 example.com
PING example.com (93.184.216.34): 1460 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4

As you can see, this breaks beneath the expected 1500 byte packet size. Running “ping -M do -s 1490 example.com” says that the ICMP data size is 1490 bytes and fragmentation is not allowed. But remember the size of ICMP data, ICMP size (i.e., header + data) will be 1498 bytes. Next you need to add the IP header and so the new frame size becomes 1518 bytes. The frame size can’t exceed MTU size of the interface and you can see this in the error message (MTU for the interface is 1500 bytes). Without fragmentation, this message can’t be sent. Since fragmentation is not allowed, ping fails saying message is too long.

Ok, so what if I do this?

$ ping -M want -s 1490 example.com 
PING example.com (93.184.216.34) 1490(1518) bytes of data. 
1498 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=1 ttl=45 time=223 ms
1498 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=2 ttl=45 time=223 ms
1498 bytes from 93.184.216.34 (93.184.216.34): icmp_seq=3 ttl=45 time=223 ms

Ok, why did this work? Well -M want will allow local fragmentation.

Mac OS X: Find the maximum unfragmented packet size (MTU) to reach a host

If you have ever tried to use jumbo packets, or trace a weird slowness on the network – one of the things that frequently comes up is packet fragmentation. This is basically where a source machine is sending bigger packets than can be consumed along its pathway to a destination machine. This means the packets will need to be split and essentially causes a host of performance issues.

So how do you diagnose this? Well Ping is your friend. It allows you to flag packets to not be fragmented and specify a minimum and maximum packet size. Using this you can simply loop through test packet sizes until a packet fails and then you have your MTU.

The command below sends packets from 1350 to 1520 and increases the packet size by 10 bytes each time.

ping -g 1350 -G 1520 -h 10 -D andrewbaker.ninja

Mac OS X: Using nmap or sslscan to review the ciphers supported by a website

To retrieve a list of the SSL/TLS cipher suites a particular website offers you can either use sslscan or nmap

brew install sslscan
sslscan andrewbaker.ninja
Version: 2.0.15
OpenSSL 3.0.7 1 Nov 2022

Connected to 13.244.140.33

Testing SSL server andrewbaker.ninja on port 443 using SNI name andrewbaker.ninja

  SSL/TLS Protocols:
SSLv2     disabled
SSLv3     disabled
TLSv1.0   enabled
TLSv1.1   enabled
TLSv1.2   enabled
TLSv1.3   enabled

  TLS Fallback SCSV:
Server supports TLS Fallback SCSV

  TLS renegotiation:
Secure session renegotiation supported

  TLS Compression:
OpenSSL version does not support compression
Rebuild with zlib1g-dev package for zlib support

  Heartbleed:
TLSv1.3 not vulnerable to heartbleed
TLSv1.2 not vulnerable to heartbleed
TLSv1.1 not vulnerable to heartbleed
TLSv1.0 not vulnerable to heartbleed

  Supported Server Cipher(s):
Preferred TLSv1.3  256 bits  TLS_AES_256_GCM_SHA384        Curve 25519 DHE 253
Accepted  TLSv1.3  256 bits  TLS_CHACHA20_POLY1305_SHA256  Curve 25519 DHE 253
Accepted  TLSv1.3  128 bits  TLS_AES_128_GCM_SHA256        Curve 25519 DHE 253
Preferred TLSv1.2  256 bits  ECDHE-ECDSA-AES256-GCM-SHA384 Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-GCM-SHA256 Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA384     Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-CAMELLIA256-SHA384 Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA256     Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-CAMELLIA128-SHA256 Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-CHACHA20-POLY1305 Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-CCM8       Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-CCM        Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-ARIA256-GCM-SHA384 Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-CCM8       Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-CCM        Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-ARIA128-GCM-SHA256 Curve 25519 DHE 253
Accepted  TLSv1.2  256 bits  ECDHE-ECDSA-AES256-SHA        Curve 25519 DHE 253
Accepted  TLSv1.2  128 bits  ECDHE-ECDSA-AES128-SHA        Curve 25519 DHE 253
Preferred TLSv1.1  256 bits  ECDHE-ECDSA-AES256-SHA        Curve 25519 DHE 253
Accepted  TLSv1.1  128 bits  ECDHE-ECDSA-AES128-SHA        Curve 25519 DHE 253
Preferred TLSv1.0  256 bits  ECDHE-ECDSA-AES256-SHA        Curve 25519 DHE 253
Accepted  TLSv1.0  128 bits  ECDHE-ECDSA-AES128-SHA        Curve 25519 DHE 253

  Server Key Exchange Group(s):
TLSv1.3  128 bits  secp256r1 (NIST P-256)
TLSv1.3  192 bits  secp384r1 (NIST P-384)
TLSv1.3  260 bits  secp521r1 (NIST P-521)
TLSv1.3  128 bits  x25519
TLSv1.3  224 bits  x448
TLSv1.2  128 bits  secp256r1 (NIST P-256)

  SSL Certificate:
Signature Algorithm: sha256WithRSAEncryption
ECC Curve Name:      prime256v1
ECC Key Strength:    128

Subject:  andrewbaker.ninja
Altnames: DNS:andrewbaker.ninja, DNS:www.andrewbaker.ninja
Issuer:   R3

Not valid before: Nov  4 23:00:13 2022 GMT
Not valid after:  Feb  2 23:00:12 2023 GMT

alternatively you can just use nmap (note: i use “-e en0” to bypass zscaler):

% brew install nmap
% nmap --script ssl-enum-ciphers -p 443 andrewbaker.ninja -e en0
Starting Nmap 7.93 ( https://nmap.org ) at 2022-11-19 22:30 SAST
Nmap scan report for andrewbaker.ninja (13.244.140.33)
Host is up (0.014s latency).
rDNS record for 13.244.140.33: ec2-13-244-140-33.af-south-1.compute.amazonaws.com

PORT    STATE SERVICE
443/tcp open  https
| ssl-enum-ciphers:
|   TLSv1.0:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.1:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.2:
|     ciphers:
|       TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CCM_8 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CCM (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_ARIA_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CCM (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_ARIA_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|     compressors:
|       NULL
|     cipher preference: server
|   TLSv1.3:
|     ciphers:
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: A

Nmap done: 1 IP address (1 host up) scanned in 1.52 seconds

Another variant (including cert dates, again “-e en0” is used to bypass zscaler):

$ nmap -e en0 --script ssl-cert -p 443 andrewbaker.ninja
Starting Nmap 7.93 ( https://nmap.org ) at 2023-06-23 18:41 SAST
Nmap scan report for andrewbaker.ninja (13.244.140.33)
Host is up (0.019s latency).
rDNS record for 13.244.140.33: ec2-13-244-140-33.af-south-1.compute.amazonaws.com

PORT    STATE SERVICE
443/tcp open  https
| ssl-cert: Subject: commonName=andrewbaker.ninja
| Subject Alternative Name: DNS:andrewbaker.ninja, DNS:www.andrewbaker.ninja
| Issuer: commonName=Zscaler Intermediate Root CA (zscaler.net) (t) /organizationName=Zscaler Inc./stateOrProvinceName=California/countryName=US
| Public Key type: rsa
| Public Key bits: 2048
| Signature Algorithm: sha256WithRSAEncryption
| Not valid before: 2023-06-17T02:07:23
| Not valid after:  2023-07-01T02:07:23
| MD5:   a20b5ae2900569601de116b49b7a29bd
|_SHA-1: 27d681607f0ccffbec6e303d14d6d41fd24c0851

Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds

Mac OS X or Linux: Use terminal to get http/https response headers of a url using the curl command

Web devs need to know the http headers their apps/webpages. This can be easily achieved using a browser plugin for Chrome or Firefox. But I prefer to use the command terminal, and curl makes this really easy.

curl -I andrewbaker.ninja
HTTP/1.1 302 Found
Date: Thu, 17 Nov 2022 14:01:53 GMT
Server: Apache
X-Frame-Options: SAMEORIGIN
Location: https://andrewbaker.ninja/
Connection: close
Content-Type: text/html; charset=iso-8859-1

## Alternative
url --head https://andrewbaker.ninja
HTTP/1.1 200 OK
Date: Thu, 17 Nov 2022 14:08:36 GMT
Server: Apache
X-Powered-By: PHP/7.3.18
Link: <https://andrewbaker.ninja/wp-json/>; rel="https://api.w.org/", <https://andrewbaker.ninja/wp-json/wp/v2/pages/78>; rel="alternate"; type="application/json", <https://andrewbaker.ninja/>; rel=shortlink
X-Frame-Options: SAMEORIGIN
Cache-Control: max-age=0, no-cache
Connection: close
Content-Type: text/html; charset=UTF-8

Macbook: Exploring DNS using DIG (Domain Information Groper)

DIG is an awesome command line utility to explore DNS. Below is a quick guide to get you started.

Query Specific Name Server

By default, if no name server is specified, dig will use the servers listed in /etc/resolv.conf file. To view the default server use:

% cat /etc/resolv.conf
#
# macOS Notice
#
# This file is not consulted for DNS hostname resolution, address
# resolution, or the DNS query routing mechanism used by most
# processes on this system.
#
# To view the DNS configuration used by this system, use:
#   scutil --dns
#
# SEE ALSO
#   dns-sd(1), scutil(8)
#
# This file is automatically generated.
#
nameserver 100.64.0.1

You can override the name server against which the query will be executed, use the @ (at) symbol followed by the name server IP address or hostname.

For example, to query the Google name server (8.8.8.8) for information about andrewbaker.ninja you would use:

% dig andrewbaker.ninja @8.8.8.8

; <<>> DiG 9.10.6 <<>> andrewbaker.ninja @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33993
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;andrewbaker.ninja.		IN	A

;; ANSWER SECTION:
andrewbaker.ninja.	300	IN	A	13.244.140.33

;; Query time: 1099 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Thu Nov 17 11:26:55 SAST 2022
;; MSG SIZE  rcvd: 62

Get a Short Answer

To get a short answer to your query, use the +short option:

% dig andrewbaker.ninja +short
13.244.140.33

Query a Record Type

Dig allows you to perform any valid DNS query by appending the record type to the end of the query. In the following section, we will show you examples of how to search for the most common records, such as A (the IP address), CNAME (canonical name), TXT (text record), MX (mail exchanger), and NS (name servers).

Querying A records

To get a list of all the address(es) for a domain name, use the a option:

% dig +nocmd andrewbaker.ninja a +noall +answer
andrewbaker.ninja.	156	IN	A	13.244.140.33

Querying CNAME records

To find the alias domain name use the cname option:

dig +nocmd mail.google.com cname +noall +answer
mail.google.com.	553482	IN	CNAME	googlemail.l.google.com.

Querying TXT records

Use the txt option to retrieve all the TXT records for a specific domain:

% dig +nocmd google.com txt +noall +answer
google.com.		3600	IN	TXT	"globalsign-smime-dv=CDYX+XFHUw2wml6/Gb8+59BsH31KzUr6c1l2BPvqKX8="
google.com.		3600	IN	TXT	"MS=E4A68B9AB2BB9670BCE15412F62916164C0B20BB"
google.com.		3600	IN	TXT	"docusign=1b0a6754-49b1-4db5-8540-d2c12664b289"
google.com.		3600	IN	TXT	"onetrust-domain-verification=de01ed21f2fa4d8781cbc3ffb89cf4ef"
google.com.		3600	IN	TXT	"apple-domain-verification=30afIBcvSuDV2PLX"
google.com.		3600	IN	TXT	"google-site-verification=TV9-DBe4R80X4v0M4U_bd_J9cpOJM0nikft0jAgjmsQ"
google.com.		3600	IN	TXT	"facebook-domain-verification=22rm551cu4k0ab0bxsw536tlds4h95"
google.com.		3600	IN	TXT	"webexdomainverification.8YX6G=6e6922db-e3e6-4a36-904e-a805c28087fa"
google.com.		3600	IN	TXT	"docusign=05958488-4752-4ef2-95eb-aa7ba8a3bd0e"
google.com.		3600	IN	TXT	"v=spf1 include:_spf.google.com ~all"
google.com.		3600	IN	TXT	"atlassian-domain-verification=5YjTmWmjI92ewqkx2oXmBaD60Td9zWon9r6eakvHX6B77zzkFQto8PQ9QsKnbf4I"
google.com.		3600	IN	TXT	"google-site-verification=wD8N7i1JTNTkezJ49swvWW48f8_9xveREV4oB-0Hf5o"

Querying MX records

To get a list of all the mail servers for a specific domain using the mx option:

% dig +nocmd google.com mx +noall +answer
google.com.		48	IN	MX	10 smtp.google.com.

Querying All Records

Use the any option to get a list of all DNS records for a specific domain:

dig +nocmd andrewbaker.ninja any +noall +answer
andrewbaker.ninja.	300	IN	A	13.244.140.33
andrewbaker.ninja.	21600	IN	NS	ns-1254.awsdns-28.org.
andrewbaker.ninja.	21600	IN	NS	ns-1514.awsdns-61.org.
andrewbaker.ninja.	21600	IN	NS	ns-1728.awsdns-24.co.uk.
andrewbaker.ninja.	21600	IN	NS	ns-1875.awsdns-42.co.uk.
andrewbaker.ninja.	21600	IN	NS	ns-491.awsdns-61.com.
andrewbaker.ninja.	21600	IN	NS	ns-496.awsdns-62.com.
andrewbaker.ninja.	21600	IN	NS	ns-533.awsdns-02.net.
andrewbaker.ninja.	21600	IN	NS	ns-931.awsdns-52.net.
andrewbaker.ninja.	900	IN	SOA	ns-1363.awsdns-42.org. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Tracing DNS Resolution

DNS query resolution follows a simple recursive process outlined below:

  1. You as the DNS client (or stub resolver) query your recursive resolver for www.example.com.
  2. Your recursive resolver queries the root name server for www.example.com.
  3. The root name server refers your recursive resolver to the .com Top-Level Domain (TLD) authoritative server.
  4. Your recursive resolver queries the .com TLD authoritative server for www.example.com.
  5. The .com TLD authoritative server refers your recursive server to the authoritative servers for example.com.
  6. Your recursive resolver queries the authoritative servers for www.example.com, and receives 1.2.3.4 as the answer.
  7. Your recursive resolver caches the answer for the duration of the time to live (TTL) specified on the record, and returns it to you.

Below is an example trace:

% dig +trace andrewbaker.ninja

; <<>> DiG 9.10.6 <<>> +trace andrewbaker.ninja
;; global options: +cmd
.			62163	IN	NS	g.root-servers.net.
.			62163	IN	NS	j.root-servers.net.
.			62163	IN	NS	e.root-servers.net.
.			62163	IN	NS	l.root-servers.net.
.			62163	IN	NS	d.root-servers.net.
.			62163	IN	NS	a.root-servers.net.
.			62163	IN	NS	b.root-servers.net.
.			62163	IN	NS	i.root-servers.net.
.			62163	IN	NS	m.root-servers.net.
.			62163	IN	NS	h.root-servers.net.
.			62163	IN	NS	c.root-servers.net.
.			62163	IN	NS	k.root-servers.net.
.			62163	IN	NS	f.root-servers.net.
.			62163	IN	RRSIG	NS 8 0 518400 20221129170000 20221116160000 18733 . MbE0OpdxRbInDK0olZm8n585L4oPq3q8iVbn/O0S7bfelS9wauhHQnnY Ifuj3D6Owp6R7H2Om6utfeB2kjrocJG9ZQPy0UQhWvgcFp9I4KnWRr1L H/yvmSM2EejR7kQHp4OBrb55RBsX4tojvr1UU+fWRuy988prwBVBdKj6 EElNwteQCosJHxVzqP0z6UpP9i5rUkRNGOD7OvdwF8ynBV93F4FpOI9r yuKzz0hdE3YAQJztOY84VuLkXM2DPs51LR6ftibxswUwoeUg04QUS7py gzn1z9en99oUgX+Lic6fLKc5Q0LpeZGhW0qBCY2CB9KEaRth+ZCD6WEU tjOBCw==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 249 ms

ninja.			172800	IN	NS	v0n2.nic.ninja.
ninja.			172800	IN	NS	v2n1.nic.ninja.
ninja.			172800	IN	NS	v0n0.nic.ninja.
ninja.			172800	IN	NS	v0n1.nic.ninja.
ninja.			172800	IN	NS	v2n0.nic.ninja.
ninja.			172800	IN	NS	v0n3.nic.ninja.
ninja.			86400	IN	DS	46082 8 2 C8F816A7A575BDB2F997F682AAB2653BA2CB5EDDB69B036A30742A33 BEFAF141
ninja.			86400	IN	RRSIG	DS 8 1 86400 20221130050000 20221117040000 18733 . xoEolCAm4d+f6LxulPa/lnCwKuwWLPI8LzlgmOVvMNL7z8J/21FqTWBu 4tZT8KZTciAvcTcRo3TDAg0Qr48QvJI30ld4yYa81HGHpVKVuTSoNCtn FnxvCuZmqDY+aFM/zn9jSTdCcT8EhwLJrsHq/zj/iasymLZ/UvanJo8j X/PRSorGfWJjUeDSSjCOpOITjRLqzHeBcY9+Qpf7O5fDguqtkhzc/8pS qKmjUh2B+yJA4QgDSaoxdv9LRQIvdSL1Iwq9eAXnl9azJy3GbVIUVZCw bA8ZsFYhw9sQbk39ZDi3K4pS717uymh4RBlk4r/5EuqdKBpWFYdOW4ZC EGDBcg==
;; Received 763 bytes from 198.41.0.4#53(a.root-servers.net) in 285 ms

andrewbaker.ninja.	3600	IN	NS	ns-1363.awsdns-42.org.
andrewbaker.ninja.	3600	IN	NS	ns-1745.awsdns-26.co.uk.
andrewbaker.ninja.	3600	IN	NS	ns-462.awsdns-57.com.
andrewbaker.ninja.	3600	IN	NS	ns-983.awsdns-58.net.
4vnuq0b3phnjevus6h4meuj446b44iqj.ninja.	3600 IN	NSEC3 1 1 10 332539EE7F95C32A 4VVVNRI7K3EH48N753IKM6TUI5G921J7  NS SOA RRSIG DNSKEY NSEC3PARAM
4vnuq0b3phnjevus6h4meuj446b44iqj.ninja.	3600 IN	RRSIG NSEC3 8 2 3600 20221208121502 20221117111502 22878 ninja. RIuQHRcUrHqMNg1lab6s/oRNmflV4e+8r2553miiZdlGqCl8Q05+e1f5 /AY0enkAaG4DvoXCAlwroL7B7iYgivgrmPXklPTEahnzdeZV76UWimRs 2WjKLI9DSUsSl5yPZBDloqYBxhQlHwY7RPcKxELX2wO7ld8Dk+cSpQIu CQQ=
dg8umbqgrvdemk76n4dtbddckfghtloo.ninja.	3600 IN	NSEC3 1 1 10 332539EE7F95C32A DGG261SH46I7K27S1MPEID8CER0BFH07  NS DS RRSIG
dg8umbqgrvdemk76n4dtbddckfghtloo.ninja.	3600 IN	RRSIG NSEC3 8 2 3600 20221130155636 20221109145636 22878 ninja. b3g1om7FYmaboSk49ZuQC/wiyuZ0zQXOs/HbfrtDP1wUGyvXMAG1ofik //wSTVEvi7bufrbKUCSkBrxiBweSkRIKokaB/5j90Izpb9znaN0MWmOQ gywML7TQ3etOWb9s8L/oUmiBUUUtBtPGAy/e4hsbuYKQt+awJZVhR4G/ GBM=
;; Received 691 bytes from 65.22.21.4#53(v0n1.nic.ninja) in 892 ms

andrewbaker.ninja.	300	IN	A	13.244.140.33
andrewbaker.ninja.	172800	IN	NS	ns-1254.awsdns-28.org.
andrewbaker.ninja.	172800	IN	NS	ns-1514.awsdns-61.org.
andrewbaker.ninja.	172800	IN	NS	ns-1728.awsdns-24.co.uk.
andrewbaker.ninja.	172800	IN	NS	ns-1875.awsdns-42.co.uk.
andrewbaker.ninja.	172800	IN	NS	ns-491.awsdns-61.com.
andrewbaker.ninja.	172800	IN	NS	ns-496.awsdns-62.com.
andrewbaker.ninja.	172800	IN	NS	ns-533.awsdns-02.net.
andrewbaker.ninja.	172800	IN	NS	ns-931.awsdns-52.net.
;; Received 328 bytes from 205.251.195.215#53(ns-983.awsdns-58.net) in 53 ms

As you can see above, the first set of results are the NS (nameservers) for the root domain (.), followed by the NS for .ninja, then finally the NS for andrewbaker.ninja (hosted in AWS).