Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Doggo Support for RFC9460 #140

Open
tristanpipo opened this issue Jul 10, 2024 · 0 comments
Open

Doggo Support for RFC9460 #140

tristanpipo opened this issue Jul 10, 2024 · 0 comments

Comments

@tristanpipo
Copy link

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@tristanpipo