Thursday, March 19, 2020
Still another issue with DoH, yet this time it isn't my fault
So I'm reading this comment on Hacker News and none of the links are working. Odd, because I have had no problems since Debtember with my current implementation of DoH. The broken links in question all have the hostname ending with a period. While unusual, the trailing dot on a hostname makes is a “fully qualified domain name.” I won't go into the full details of a “fully qualified domain name” (that's beyond the scope of this post) but suffice to say, it should be supported.
Okay, fine. I start looking at my script and … well … there's no reason for it to fail. I mean, I did find two bugs (one typo and one logic bug in handling an error) but they were unrelated to not resolving a fully qualified domain name. Down the rabbit hole I go.
What do I find once I hit bottom? Not Alice, but I do think I found a bug in Firefox. And I think it's a similar cause as before—a different codepath.
When I force Firefox to use DNS,
both boston.conman.org and boston.conman.org.
(note the trailing dot)
produce the following DNS request:
00000000: 00 00 01 00 00 01 00 00 00 00 00 01 06 62 6F 73 .............bos 00000010: 74 6F 6E 06 63 6F 6E 6D 61 6E 03 6F 72 67 00 00 ton.conman.org.. 00000020: 01 00 01 00 00 29 10 00 00 00 00 00 00 08 00 08 .....).......... 00000030: 00 04 00 01 00 00 ......
When I switch back to DoH however,
boston.conman.org.
(note the fully qualified domain name) generates this:
00000000: 00 00 01 00 00 01 00 00 00 00 00 01 06 62 6F 73 .............bos 00000010: 74 6F 6E 06 63 6F 6E 6D 61 6E 03 6F 72 67 00 00 ton.conman.org.. 00000020: 00 01 00 01 00 00 29 10 00 00 00 00 00 00 08 00 ......)......... 00000030: 08 00 04 00 01 00 00 .......
There's an extra NUL byte after the domain name,
and I suspect what's happening is that the extra “.” at the end is being encoded instead of being ignored.
I've created a bug report so we'll see how this goes.
Update on Friday, March 27TH, 2020
The bug has been fixed..
