On Thu 2017-04-27 11:28:15 +0100, Tony Finch wrote: > Section 3.2.2 HTTP/1 > > Is there a SP missing between the request-target and the HTTP-version in > the diagram of the shortest possible request?
whoops, i can't believe i missed that. thanks! fixed in git:
https://gitlab.com/dkg/hddemux/commit/bc88fd5dd65cded1c20a61e55d1e747bba769c1c
> Section 4.3 Opcode / 4.6 ANCOUNT NSCOUNT
>
> Do you want to support UPDATE? If not it should probably be ruled out up
> front, since it changes some of the analysis
hm, i don't want to rule out UPDATE, i just hadn't thought about it. --
i can imagine someone wanting to make use of UPDATE over this mechanism,
so it'd be nice to keep it.
I've opened a ticket to track that concern:
https://gitlab.com/dkg/hddemux/issues/1
> (though not the result, since octet 5 will be zero for DNS).
Is that guaranteed? It seems likely in practice, but RFC 2136 says:
RCODE Response code - this four bit field is undefined in requests
and set in responses.
So it seems conceivable that some client fiddles with these undefined
bits somehow -- they're not required to be zeros, the way the Z section
is :/
the way i'm reading RFC 2136, though, the formats of the four sections
remain the same, so the "Combinations of octets" calculation seems to
still hold, which means the "Proof" section should still hold too, i
think. Or am i missing something there?
--dkg
signature.asc
Description: PGP signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
