mr-karan / doggo

:dog: Command-line DNS Client for Humans. Written in Golang
https://doggo.mrkaran.dev/
GNU General Public License v3.0
2.83k stars 100 forks source link

Doggo Support for RFC9460 #140

Open tristanpipo opened 1 month ago

tristanpipo commented 1 month ago

Been playing with Doggo since I like a great deal of the features. But one use case I have come across is support for type 65 lookups used by currently Draft RFC 9460 (https://datatracker.ietf.org/doc/rfc9460/)

I see that doggo has support for -t or --type queries but when attempting 65.

doggo @192.168.100.219 login.microsoftonline.com -t=65 doggo @192.168.100.219 login.microsoftonline.com -t=TYPE65

A packet capture shows this as "type Unused,"

Queries login.microsoftonline.com: type Unused, class IN Name: login.microsoftonline.com [Name Length: 25] [Label Count: 3] Type: Unused (0) Class: IN (0x0001)

I get the following errors back on the CLI.

$ doggo @192.168.100.219 login.microsoftonline.com -t=TYPE65

time=2024-07-10T14:13:44.364-07:00 level=ERROR msg="Error looking up DNS records" error="context deadline exceeded"
$ doggo @192.168.100.219 login.microsoftonline.com -t=65

time=2024-07-10T14:13:55.153-07:00 level=ERROR msg="error in lookup" error="read udp 192.168.100.6:42976->192.168.100.219:53: i/o timeout"
time=2024-07-10T14:13:55.153-07:00 level=ERROR msg="Error looking up DNS records" error="context deadline exceeded"

When performing this via dig it appears to work accordingly.

dig -t TYPE65 @192.168.100.219 login.microsoftonline.com

Queries login.microsoftonline.com: type HTTPS, class IN Name: login.microsoftonline.com [Name Length: 25] [Label Count: 3] Type: HTTPS (65) (HTTPS Specific Service Endpoints) Class: IN (0x0001)```

Output from the dig command

; <<>> DiG 9.18.24-0ubuntu5-Ubuntu <<>> -t TYPE65 @192.168.100.219 login.microsoftonline.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61501
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;login.microsoftonline.com.     IN      HTTPS

;; ANSWER SECTION:
login.microsoftonline.com. 8471 IN      CNAME   login.mso.msidentity.com.
login.mso.msidentity.com. 111   IN      CNAME   ak.privatelink.msidentity.com.
ak.privatelink.msidentity.com. 111 IN   CNAME   www.tm.ak.prd.aadg.akadns.net.

;; AUTHORITY SECTION:
akadns.net.             177     IN      SOA     internal.akadns.net. hostmaster.akamai.com. 1712104200 90000 90000 90000 180

;; Query time: 0 msec
;; SERVER: 192.168.100.219#53(192.168.100.219) (UDP)
;; WHEN: Wed Jul 10 14:13:34 PDT 2024
;; MSG SIZE  rcvd: 224

Since this isn't for DoH using @https://x.x.x.x lookups but a record type wasn't sure if this would apply either way. Would just be helpful to have this functionality for future usage scenario testing. Since it's a current draft RFC at this time I understand if this isn't on the current roadmap.