q: fallback flag not respected in case of overflowing header size

[JeremyRand]

I'm running a DNS server and am trying to query it with q. (The server is ncdns if that helps reproducing the issue.) The following works:

$ ./q -tcp -port 5391 @127.0.0.1 TLSA _443._tcp.prism-break.bit
;; opcode: QUERY, status: NOERROR, id: 59147
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;_443._tcp.prism-break.bit.	IN	 TLSA

;; ANSWER SECTION:
_443._tcp.prism-break.bit.	600	IN	TLSA	3 0 0 308201cb30820172a003020102021315e794c838a346fadea4d0935cb9bf9545320b300a06082a8648ce3d040302303d311830160603550403130f707269736d2d627265616b2e6269743121301f060355040513184e616d65636f696e20544c53204365727469666963617465301e170d3138313230393233333530305a170d3139313230393233333530305a303d311830160603550403130f707269736d2d627265616b2e6269743121301f060355040513184e616d65636f696e20544c532043657274696669636174653059301306072a8648ce3d020106082a8648ce3d03010703420004a812b65d69fd9a0ee653db354a716f053f6cb95ca53dd82a1dd58e8693a1d7342649ca0c902cf66f2b05e1f5b20dc927c001139cfb9352be84a105aecfdd4393a351304f300e0603551d0f0101ff04040302078030130603551d25040c300a06082b06010505070301300c0603551d130101ff04023000301a0603551d1104133011820f707269736d2d627265616b2e626974300a06082a8648ce3d0403020347003044022010a31cb8ee04d0a4edc375da181428f160616e73ae77161b6098124d5767c7c2022072cb72281b1869505267d9bedea64981367f0de5da9960774b088886562c450c

;; query time: 529 µs, server: 127.0.0.1:5391(tcp), size: 547 bytes

However, the following does not work:

$ ./q -fallback -port 5391 @127.0.0.1 TLSA _443._tcp.prism-break.bit
;; dns: overflowing header size

I would expect the -fallback flag to automatically retry with TCP in this situation, but it seems that it doesn't. I'm not certain if this is a bug in the server or in q. Any idea what's wrong?

(Note that I'm using the latest version of exdns and all of its dependencies except for dns, which is still at v1.0.15 due to #17 .)

[miekg]

Don't have time to look into this.

…

On Fri, 21 Dec 2018, 08:44 JeremyRand ***@***.*** wrote: I'm running a DNS server and am trying to query it with q. (The server is ncdns <https://github.com/namecoin/ncdns> if that helps reproducing the issue.) The following works: $ ./q -tcp -port 5391 @127.0.0.1 TLSA _443._tcp.prism-break.bit ;; opcode: QUERY, status: NOERROR, id: 59147 ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;_443._tcp.prism-break.bit. IN TLSA ;; ANSWER SECTION: _443._tcp.prism-break.bit. 600 IN TLSA 3 0 0 308201cb30820172a003020102021315e794c838a346fadea4d0935cb9bf9545320b300a06082a8648ce3d040302303d311830160603550403130f707269736d2d627265616b2e6269743121301f060355040513184e616d65636f696e20544c53204365727469666963617465301e170d3138313230393233333530305a170d3139313230393233333530305a303d311830160603550403130f707269736d2d627265616b2e6269743121301f060355040513184e616d65636f696e20544c532043657274696669636174653059301306072a8648ce3d020106082a8648ce3d03010703420004a812b65d69fd9a0ee653db354a716f053f6cb95ca53dd82a1dd58e8693a1d7342649ca0c902cf66f2b05e1f5b20dc927c001139cfb9352be84a105aecfdd4393a351304f300e0603551d0f0101ff04040302078030130603551d25040c300a06082b06010505070301300c0603551d130101ff04023000301a0603551d1104133011820f707269736d2d627265616b2e626974300a06082a8648ce3d0403020347003044022010a31cb8ee04d0a4edc375da181428f160616e73ae77161b6098124d5767c7c2022072cb72281b1869505267d9bedea64981367f0de5da9960774b088886562c450c ;; query time: 529 µs, server: 127.0.0.1:5391(tcp), size: 547 bytes However, the following does not work: $ ./q -fallback -port 5391 @127.0.0.1 TLSA _443._tcp.prism-break.bit ;; dns: overflowing header size I would expect the -fallback flag to automatically retry with TCP in this situation, but it seems that it doesn't. I'm not certain if this is a bug in the server or in q. Any idea what's wrong? (Note that I'm using the latest version of exdns and all of its dependencies except for dns, which is still at v1.0.15 due to #17 <#17> .) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#19>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAVkW2FxHAaPNQKAtUZOmzAMEQdhCGP5ks5u7J9ugaJpZM4ZdmOn> .