Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
Ondřej Surý wrote: > I am 99% sure the fpdns is wrong and this is not djbdns. The fpdns relies on > subtle differences between various DNS implementations and is often wrong > because there’s either not enough data or just not enough differences. That’s > what I’ve seen when we started with Knot DNS - the quality implementations > just > didn’t had enough differences between than because they adhered to standards > that fpdns just could not tell the difference. If you run fpdns with "-d" it will print out the queries/responses, and fpdns does observe some stereotypical (but maybe not exclusively?) djbdns behavior like dropping queries that aren't for domains the server is configured to be authoritative for. "a.ns", "b.ns" etc. is a nameserver-naming pattern used in the tinydns documentation. For the djbdns suite, tinydns only serves UDP traffic and you have to install an extra daemon called axfrdns to handle TCP queries and AXFR traffic. If you request an AXFR for a zone that axfrdns is authoritative for but your source IP isn't on its allowlist, axfrdns _exit()'s without sending anything, which is consistent with: $ dig +tries=1 +tcp +norec @e.ns.email.sonyentertainmentnetwork.com -t AXFR email.sonyentertainmentnetwork.com ;; communications error to 207.251.96.133#53: end of file Regarding the truncation behavior, the djbdns documentation states: "dnscache ends the packet before all records." It doesn't say how tinydns behaves but it looks like the code is the same. The answer count in the header is not updated, which seems to be what is upsetting the various message parsers. According to the CHANGES file: 2210 internal: response_tc() reduces len, simplifying udprespond(). ui: response_tc() now truncates immediately after query. this should work around the Squid parsing bug reported by Stuart Henderson. So I'm inclined to think they probably actually are using djbdns, or maybe a load balancer in front of djbdns. At least I don't see anything inconsistent with this being a djbdns deployment. You are right about high quality implementations not having enough subtle idiosyncratic differences to reliably distinguish between them, though. -- Robert Edmonds ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
On Sat, Jul 30, 2022 at 11:14 AM Ondřej Surý wrote: > I am 99% sure the fpdns is wrong and this is not djbdns. The fpdns relies > on subtle differences between various DNS implementations and is often > wrong because there’s either not enough data or just not enough > differences. That’s what I’ve seen when we started with Knot DNS - the > quality implementations just didn’t had enough differences between than > because they adhered to standards that fpdns just could not tell the > difference. > If there are SUBTLE differences between DJB DNS and anything else, I would die of shock. I will offer a beer to anyone who shows me anything even remotely close to as broken as that POS. (The DNS community should maybe start offering rewards for replacing it, to anyone running djbdns, in real currency, just to purge it from the internet.) Brian > > Cheers, > -- > Ondřej Surý (He/Him) > > On 30. 7. 2022, at 19:37, Puneet Sood wrote: > > > > > On Sat, Jul 30, 2022 at 10:26 AM Dave Lawrence wrote: > >> Greg Choules via dns-operations writes: >> > I am including in this mail the RNAME from the SOA (same for both >> > zones) in the hope that someone who is responsible for DNS at Sony >> > entertainment will see this and take note. >> >> And tell us what in the world DNS software they're running, and why >> they chose it. >> > > Jaap up-thread used fpdns to figure out the first question. > > fpdns e.ns.email.sonyentertainmentnetwork.com > fingerprint (e.ns.email.sonyentertainmentnetwork.com, 207.251.96.133): DJ > Bernstein TinyDNS 1.05 [Old Rules] > >> ___ >> dns-operations mailing list >> dns-operations@lists.dns-oarc.net >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations >> > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
I am 99% sure the fpdns is wrong and this is not djbdns. The fpdns relies on subtle differences between various DNS implementations and is often wrong because there’s either not enough data or just not enough differences. That’s what I’ve seen when we started with Knot DNS - the quality implementations just didn’t had enough differences between than because they adhered to standards that fpdns just could not tell the difference. Cheers, -- Ondřej Surý (He/Him) > On 30. 7. 2022, at 19:37, Puneet Sood wrote: > > > > >> On Sat, Jul 30, 2022 at 10:26 AM Dave Lawrence wrote: >> Greg Choules via dns-operations writes: >> > I am including in this mail the RNAME from the SOA (same for both >> > zones) in the hope that someone who is responsible for DNS at Sony >> > entertainment will see this and take note. >> >> And tell us what in the world DNS software they're running, and why >> they chose it. > > Jaap up-thread used fpdns to figure out the first question. > > fpdns e.ns.email.sonyentertainmentnetwork.com > fingerprint (e.ns.email.sonyentertainmentnetwork.com, 207.251.96.133): DJ > Bernstein TinyDNS 1.05 [Old Rules] >> ___ >> dns-operations mailing list >> dns-operations@lists.dns-oarc.net >> https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
Puneet Sood writes: > Jaap up-thread used fpdns to figure out the first question. > fingerprint (e.ns.email.sonyentertainmentnetwork.com, 207.251.96.133): DJ > Bernstein TinyDNS 1.05 [Old Rules] Subtle correction: to figure out one possible answer to the first question. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
--- Begin Message --- On Sat, Jul 30, 2022 at 10:26 AM Dave Lawrence wrote: > Greg Choules via dns-operations writes: > > I am including in this mail the RNAME from the SOA (same for both > > zones) in the hope that someone who is responsible for DNS at Sony > > entertainment will see this and take note. > > And tell us what in the world DNS software they're running, and why > they chose it. > Jaap up-thread used fpdns to figure out the first question. fpdns e.ns.email.sonyentertainmentnetwork.com fingerprint (e.ns.email.sonyentertainmentnetwork.com, 207.251.96.133): DJ Bernstein TinyDNS 1.05 [Old Rules] > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
I am betting on “load balancers”… -- Ondřej Surý (He/Him) > On 30. 7. 2022, at 16:39, Dave Lawrence wrote: > > Greg Choules via dns-operations writes: >> I am including in this mail the RNAME from the SOA (same for both >> zones) in the hope that someone who is responsible for DNS at Sony >> entertainment will see this and take note. > > And tell us what in the world DNS software they're running, and why > they chose it. > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
Greg Choules via dns-operations writes: > I am including in this mail the RNAME from the SOA (same for both > zones) in the hope that someone who is responsible for DNS at Sony > entertainment will see this and take note. And tell us what in the world DNS software they're running, and why they chose it. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
Puneet Sood via dns-operations writes: > While the affected operators are spread around the world, the similarity of > the bad response across operators appears to suggest the DNS software may > be from the same or closely related source. These servers do not respond to > a version.bind query. > > Have you seen similar bad responses? Do you have an idea of the provenance > of this software? Fingerprinting with fpdns gives: fpdns e.ns.email.sonyentertainmentnetwork.com fingerprint (e.ns.email.sonyentertainmentnetwork.com, 207.251.96.133): DJ Bernstein TinyDNS 1.05 [Old Rules] jaap ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
--- Begin Message --- This looks very broken. Here are checks of the "m.email..." and "email..." domains - both exhibit many protocol errors: https://ednscomp.isc.org/ednscomp/7225e09225 https://ednscomp.isc.org/ednscomp/e9310fc22b I am including in this mail the RNAME from the SOA (same for both zones) in the hope that someone who is responsible for DNS at Sony entertainment will see this and take note. Cheers, Greg On Fri, 29 Jul 2022 at 22:09, Puneet Sood via dns-operations < dns-operati...@dns-oarc.net> wrote: > > > > -- Forwarded message -- > From: Puneet Sood > To: dns-operations > Cc: > Bcc: > Date: Fri, 29 Jul 2022 17:04:28 -0400 > Subject: Name servers returning incorrectly truncated UDP responses > Hello, > > While making our DNS response validation stricter, we have noticed that a > number of name servers return badly truncated UDP responses. This sometimes > happens with incorrect Answer section RR count. > > $ dig m.email.sonyentertainmentnetwork.com. TXT @ > e.ns.email.sonyentertainmentnetwork.com > ;; Warning: Message parser reports malformed message packet. > ;; Truncated, retrying in TCP mode. > > ; <<>> DiG 9.18.3-1+build1-Debian <<>> > m.email.sonyentertainmentnetwork.com. TXT @ > e.ns.email.sonyentertainmentnetwork.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24446 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;m.email.sonyentertainmentnetwork.com. IN TXT > > ;; ANSWER SECTION: > m.email.sonyentertainmentnetwork.com. 3600 IN TXT "v=spf1 a mx ip4: > 63.236.31.220/31 ip4:8.30.201.100/31 ip4:63.236.84.160 ip4:8.30.201.16 > ip4:4.22.42.19 ip4:4.22.42.20/30 ip4:4.2" "2.42.24/31 ip4:4.22.42.26 ip4: > 72.166.182.10/31 ip4:72.166.182.12/31 ip4:72.166.182.18/31 ip4: > 72.166.182.20/30 ip4:207.251.96.0/" "24 ip4:65.125.54.0/24 ip4: > 63.232.57.0/24 ip4:208.49.63.128/28 ip4:63.211.90.16/29 ip4:8.7.42.16/29 > ip4:8.7.43.16/29 ip4:63.232." "236.144/29 ip4:8.7.44.144/29 ip4: > 63.236.31.128/26 ip4:63.236.76.0/23 ip4:8.30.201.0/26 ~all" > > ;; Query time: 4 msec > ;; SERVER: 207.251.96.133#53(e.ns.email.sonyentertainmentnetwork.com) > (TCP) > ;; WHEN: Fri Jul 29 16:57:51 EDT 2022 > ;; MSG SIZE rcvd: 542 > > > While the affected operators are spread around the world, the similarity > of the bad response across operators appears to suggest the DNS software > may be from the same or closely related source. These servers do not > respond to a version.bind query. > > Have you seen similar bad responses? Do you have an idea of the provenance > of this software? > > Thanks, > Puneet > > > > > -- Forwarded message -- > From: Puneet Sood via dns-operations > To: dns-operations > Cc: > Bcc: > Date: Fri, 29 Jul 2022 17:04:28 -0400 > Subject: [dns-operations] Name servers returning incorrectly truncated UDP > responses > ___ > dns-operations mailing list > dns-operations@lists.dns-oarc.net > https://lists.dns-oarc.net/mailman/listinfo/dns-operations > --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Name servers returning incorrectly truncated UDP responses
On Fri, Jul 29, 2022 at 05:04:28PM -0400, Puneet Sood via dns-operations wrote:
> $ dig m.email.sonyentertainmentnetwork.com. TXT
> @e.ns.email.sonyentertainmentnetwork.com
> ;; Warning: Message parser reports malformed message packet.
> ;; Truncated, retrying in TCP mode.
Indeed this response is truncated to just the question without adjusting
the answer count accordingly (tshark decode):
Domain Name System (response)
Transaction ID: 0x7189
Flags: 0x8600 Standard query response, No error
1... = Response: Message is a response
.000 0... = Opcode: Standard query (0)
.1.. = Authoritative: Server is an authority for
domain
..1. = Truncated: Message is truncated
...0 = Recursion desired: Don't do query recursively
0... = Recursion available: Server can't do
recursive queries
.0.. = Z: reserved (0)
..0. = Answer authenticated: Answer/authority
portion was not authenticated by the server
...0 = Non-authenticated data: Unacceptable
= Reply code: No error (0)
Questions: 1
Answer RRs: 1
Authority RRs: 0
Additional RRs: 0
Queries
m.email.sonyentertainmentnetwork.com: type TXT, class IN
Name: m.email.sonyentertainmentnetwork.com
[Name Length: 36]
[Label Count: 4]
Type: TXT (Text strings) (16)
Class: IN (0x0001)
[Malformed Packet: DNS]
[Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
[Malformed Packet (Exception occurred)]
[Severity level: Error]
[Group: Malformed]
002071 89 86 00 00 01 q.
0030 00 01 00 00 00 00 01 6d 05 65 6d 61 69 6c 18 73 ...m.email.s
0040 6f 6e 79 65 6e 74 65 72 74 61 69 6e 6d 65 6e 74 onyentertainment
0050 6e 65 74 77 6f 72 6b 03 63 6f 6d 00 00 10 00 01 network.com.
Another interesting factor is that the nameserver responded to an EDNS0
query without either returning FORMERR or returning an OPT pseudo-RR.
EDNS0 is also ignored over TCP, only this time the response is not
truncated:
$ dig +nocmd +vc +norecur m.email.sonyentertainmentnetwork.com. TXT
@e.ns.email.sonyentertainmentnetwork.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12793
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;m.email.sonyentertainmentnetwork.com. IN TXT
;; ANSWER SECTION:
m.email.sonyentertainmentnetwork.com. 3600 IN TXT "v=spf1 a mx ... ~all"
;; Query time: 7 msec
;; SERVER: 207.251.96.133#53(207.251.96.133)
;; WHEN: Fri Jul 29 17:35:05 EDT 2022
;; MSG SIZE rcvd: 542
That said, an earlier case observed internally today trucated to 512
bytes in the middle of an RR, but did adjust the counts, so that
response had extra bytes at the end of the packet, while this one is
missing a promised RR.
So perhaps there's more than one problem implementation, though both
simply ignore EDNS and respond sans FORMERR or OPT.
It is looking like truncation is implemented poorly more often than one
might like...
--
Viktor.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
[dns-operations] Name servers returning incorrectly truncated UDP responses
--- Begin Message --- Hello, While making our DNS response validation stricter, we have noticed that a number of name servers return badly truncated UDP responses. This sometimes happens with incorrect Answer section RR count. $ dig m.email.sonyentertainmentnetwork.com. TXT @ e.ns.email.sonyentertainmentnetwork.com ;; Warning: Message parser reports malformed message packet. ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.18.3-1+build1-Debian <<>> m.email.sonyentertainmentnetwork.com. TXT @e.ns.email.sonyentertainmentnetwork.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24446 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;m.email.sonyentertainmentnetwork.com. IN TXT ;; ANSWER SECTION: m.email.sonyentertainmentnetwork.com. 3600 IN TXT "v=spf1 a mx ip4: 63.236.31.220/31 ip4:8.30.201.100/31 ip4:63.236.84.160 ip4:8.30.201.16 ip4:4.22.42.19 ip4:4.22.42.20/30 ip4:4.2" "2.42.24/31 ip4:4.22.42.26 ip4: 72.166.182.10/31 ip4:72.166.182.12/31 ip4:72.166.182.18/31 ip4: 72.166.182.20/30 ip4:207.251.96.0/" "24 ip4:65.125.54.0/24 ip4: 63.232.57.0/24 ip4:208.49.63.128/28 ip4:63.211.90.16/29 ip4:8.7.42.16/29 ip4:8.7.43.16/29 ip4:63.232." "236.144/29 ip4:8.7.44.144/29 ip4: 63.236.31.128/26 ip4:63.236.76.0/23 ip4:8.30.201.0/26 ~all" ;; Query time: 4 msec ;; SERVER: 207.251.96.133#53(e.ns.email.sonyentertainmentnetwork.com) (TCP) ;; WHEN: Fri Jul 29 16:57:51 EDT 2022 ;; MSG SIZE rcvd: 542 While the affected operators are spread around the world, the similarity of the bad response across operators appears to suggest the DNS software may be from the same or closely related source. These servers do not respond to a version.bind query. Have you seen similar bad responses? Do you have an idea of the provenance of this software? Thanks, Puneet --- End Message --- ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
