FORMERR does not trigger EDNS fallback

added bug label

Cc @sbalazik This is potentially interesting for !1030 (merged) .

Workaround in configuration file:

policy.add(policy.suffix(policy.FLAGS({'SAFEMODE'}), {todname('spam.molax.co.kr.')}))

pcap confirms that the issue really is not disabling EDNS after FORMERR.

Interestingly the server responds with FORMERR only to the first query and then is silent. This can be reproduced manually by running dig @211.105.253.20 molax.co.kr. NS. It seems like heavy rate limiting or blacklist triggered by repeated FORMERRs.

In the current implementation the first step is to turn off QNAME minimization and after FORMERR with that it goes to SAFEMODE (no EDNS or 0x20).

This domain is probably hopeless, two consecutive queries fail if the first leads to FORMERR:

~$ dig @211.105.253.20 molax.co.kr. NS

; <<>> DiG 9.16.8 <<>> @211.105.253.20 molax.co.kr. NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 62226
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d8c56da2d6d03f35 (echoed)
;; QUESTION SECTION:
;molax.co.kr.			IN	NS

;; Query time: 346 msec
;; SERVER: 211.105.253.20#53(211.105.253.20)
;; WHEN: Čt lis 19 08:51:27 CET 2020
;; MSG SIZE  rcvd: 52

~$ dig +noedns @211.105.253.20 molax.co.kr. NS

; <<>> DiG 9.16.8 <<>> +noedns @211.105.253.20 molax.co.kr. NS
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

At least we can think about some optimization, possibly as part of !1030 (merged) . @sbalazik Please have a look at the PCAP, it has very wild retransmits in it (times in the table are relative to the previous row):

No.	Time	Destination	Info
1	0.000000	2001:500:2d::d	Standard query 0x938b DNSKEY OPT
3	0.022948	2001:500:12::d0d	Standard query 0x0135 NS KR OPT
5	0.049220	210.101.61.1	Standard query 0x52c4 DNSKEY KR OPT
6	0.200603	210.101.60.1	Standard query 0x52c4 DNSKEY KR OPT
8	0.072595	2001:dcc:4::1	Standard query 0xeecc NS Co.KR OPT
9	0.200791	203.83.159.1	Standard query 0xeecc NS Co.KR OPT
12	0.082542	203.83.159.1	Standard query 0x8e30 DS co.kr OPT
13	0.093460	2001:dcc:4::1	Standard query 0x8e30 DS co.kr OPT
14	0.093435	2001:dcc:6::1	Standard query 0x8e30 DS co.kr OPT
16	0.093445	210.101.62.1	Standard query 0x8e30 DS co.kr OPT
18	0.040571	2001:dcc:6::1	Standard query 0x7788 DNSKEY cO.Kr OPT
21	0.200703	210.101.62.1	Standard query 0x7788 DNSKEY cO.Kr OPT
24	0.088222	210.101.60.1	Standard query 0x9172 NS MoLAx.Co.kR OPT
25	0.083688	2001:dcc:5::100	Standard query 0x9172 NS MoLAx.Co.kR OPT
26	0.083638	202.30.124.100	Standard query 0x9172 NS MoLAx.Co.kR OPT
28	0.083411	210.101.60.1	Standard query 0x9172 NS MoLAx.Co.kR OPT
30	0.057553	211.105.253.20	Standard query 0xd6e6 A sPAM.moLax.Co.KR OPT
33	0.200740	211.105.253.20	Standard query 0xd6e6 A sPAM.moLax.Co.KR OPT
36	0.133419	211.105.253.20	Standard query 0x807d A SPAM.MOLAX.Co.Kr OPT
37	0.200451	211.105.253.20	Standard query 0x807d A SPAM.MOLAX.Co.Kr OPT
38	0.200463	211.105.253.20	Standard query 0x807d A SPAM.MOLAX.Co.Kr OPT
39	0.000108	211.105.253.20	Standard query 0x807d A SPAM.MOLAX.Co.Kr OPT
43	1.719547	211.105.253.20	Standard query 0xdabd A sPaM.mOLax.co.KR OPT

investigate why test https://gitlab.nic.cz/knot/deckard/-/blob/master/sets/resolver/iter_formerr.rpl did not detect this and fix it!

The test is kind of dumb. It requires any kind of requery and there is no check for EDNS.

marked this issue as related to #640 (closed)

Solved in kresd.

The test can't be fixed easily for now; see deckard#43 (comment 194974)

closed

In what version of kresd is this supposed to be fixed? I am seeing what looks like the same behaviour described here against domain nextwebhosting.com on 5.4.1. The delegated servers reply FORMERR to EDNS0 queries. kresd tries both delegated servers once, with EDNS0, receives FORMERR for both queries, and then sends SERVFAIL to the client. The trace does indicate that kresd detects FORMERR_EDNS, but doesn't seem to act on it.

The workaround policy.add(policy.suffix(policy.FLAGS({'NO_EDNS'}), {todname('nextwebhosting.com.')})) works.

@ktims: nextwebhosting.com seems clearly wrong here, I'm sorry. FORMERR is only standardized to indicate non-support of EDNS0 if the reply does not contain EDNS0 section (i.e. the OPT record). That is not the case:

$ kdig @216.19.65.2 nextwebhosting.com +edns
;; ->>HEADER<<- opcode: QUERY; status: FORMERR; id: 8102
;; Flags: qr rd; QUERY: 1; ANSWER: 0; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 4096 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; nextwebhosting.com.          IN      A

;; Received 47 B
;; Time 2021-10-11 13:02:33 CEST
;; From 216.19.65.2@53(UDP) in 118.4 ms

You can also inspect analyses from third parties:

DNS flag day 2019 was focused exactly on these kinds of issues, so you can find more related information on its page: https://dnsflagday.net/2019/

FORMERR does not trigger EDNS fallback

Child items ...

Activity

Admin message

FORMERR does not trigger EDNS fallback

Activity