-
|
Hi, pls see screenshot The hopefully relevant part of dwood3rc.txt: It would be nice if you could look into it or direct me to the right place to put this.
|
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
|
Works for me: This is using the default upstream servers, e.g. 9.9.9.9 and 149.112.112.112. |
Beta Was this translation helpful? Give feedback.
-
|
Works now on my system as well, didn't for at least a week. Also Deadwood appears not to cache the request, each repeated nslookup takes these ~2s time (otherwise I used Quad9 as workaround to put the record in cache)? |
Beta Was this translation helpful? Give feedback.
-
|
RN it again doesn't work and, looking at a Wireshark capture* it's clearly an issue with Deadwood as the upstream answered within 100ms (and from what I see in Wiresharks packet detail window ( * edit: exchanged the file for a test with 9.9.9.9 and 149.112.112.112 which shows the very same result
|
Beta Was this translation helpful? Give feedback.
-
|
Deadwood will not resolve answers which require DNS-over-TCP to resolve, and corner cases like this, where we can not get a meaningful packet over UDP, are not resolvable by Deadwood at this time. |
Beta Was this translation helpful? Give feedback.
-
|
Here is a verbose output of Deadwood’s log when it sees this: I will close this but will make a mental note that having some level of EDNS support so Deadwood can receive larger packets would be a nice to have feature. We can safely receive packets up to 1280 bytes in size but it’s a question of making an EDNS0 packet which only requests a larger packet and doesn’t request DNSSEC packets. |
Beta Was this translation helpful? Give feedback.
Deadwood will not resolve answers which require DNS-over-TCP to resolve, and corner cases like this, where we can not get a meaningful packet over UDP, are not resolvable by Deadwood at this time.