Skip to content
Snippets Groups Projects

www.vutbr.cz fails (again)

    • Closed Issue created by Vladimír Čunát @vcunat

    I swear it did work somewhere on vld-refactoring...

    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items ...

    • Activity

    • Vladimír Čunát
      Vladimír Čunát @vcunat ·
      Author Owner

      Bisected to e436b6d9.

    • Ondřej Surý
      Ondřej Surý @ondrej ·
      Guest

      fixed in d169055a

    • Ondřej Surý closed

      closed

    • Petr Špaček
      Petr Špaček @pspacek ·
      Contributor

      Answer from the buggy version looks like this. Please note the rcode = SERVFAIL:

      $ dig @127.0.0.1 www.vutbr.cz
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61784
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.vutbr.cz.			IN	A

;; ANSWER SECTION:
www.vutbr.cz.		300	IN	CNAME	piranha.ro.vutbr.cz.
piranha.ro.vutbr.cz.	3599	IN	A	147.229.2.90
    • Ondřej Surý
      Ondřej Surý @ondrej ·
      Guest

      @pspacek Is this the latest master (1.2.0-rc2?)

      I see this:

      ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 16234
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 4; AUTHORITY: 0; ADDITIONAL: 1

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

;; QUESTION SECTION:
;; www.vutbr.cz.       	 IN A

;; ANSWER SECTION:
www.vutbr.cz.       	300 IN CNAME piranha.ro.vutbr.cz.
www.vutbr.cz.       	300 IN RRSIG CNAME 5 3 300 20170216060902 (
				20170117060902 39756 vutbr.cz.
				9B3UC5SOEw1+yKlYlOTINEuNq0Kdglywc5IYJwze
				SzQ3ykptzZo3ABSybYhTqImVkhm/4NFM9/4HWMHP
				DzTmrWS0mCI/ljCd/oe/PxW/uESvo4P5EQzlcuH6
				xBzc1KdEFAJOSmRzFjj3vyK1QN3k/c+1y2oMFOYO
				R2oOzCw+MIE=
				)
piranha.ro.vutbr.cz.	3500 IN A 147.229.2.90
piranha.ro.vutbr.cz.	3500 IN RRSIG A 5 4 3600 20170217082024 (
				20170118082024 12150 ro.vutbr.cz.
				d+AWUSMK0IqEyzLPvhDoSK/yRerZSfLrehWzFbuL
				lHnpmbA8h1fiT6eVo+8fZ5yk2PX0PZJQMDD43/2P
				CgqmRb9gPSGZmEj5f++Y3BPZsZRXDGib0trK+dbI
				6hiso/q4MxTkV+KpQmLtGN088T6BJdij/JbyMJOW
				W905JgA+7BI=
				)

;; Received 443 B
;; Time 2017-01-20 21:05:47 CET
;; From 127.0.0.1@53(UDP) in 38.8 ms
    • Vladimír Čunát
      Vladimír Čunát @vcunat ·
      Author Owner

      No, I'm convinced this was about some of the old versions, while trying to distill the problem into a test case.

    • Petr Špaček
      Petr Špaček @pspacek ·
      Contributor

      Do not worry, it is from the d70135ea which is one commit before fix d169055a. I had to go back in time to verify that my test catches the problem.

      I prefer to have the problematic replies listed in the tickets so we can eaily see what was wrong back then.

    • Ondřej Surý
      Ondřej Surý @ondrej ·
      Guest

      @pspacek JFTR You want to record the output similar to what qry-trace (soon to be merged) branch does, so there's a record of upstream reponses. The downstream response is usually less meaningless, as you want to have test that's NOERROR (unless it's a special case that should fail - like errors in DNSSEC-validation, timing out servers, etc.)

    Please register or sign in to reply