shivankaul / draft-ssahib-xot-padding Goto Github PK

"Do they send records in a fixed or random order - would this allow anything about the zone contents to be inferred by watching different message sizes over time if they are not all padded to the same size"

not sure this actually matters since an observer can only see a stream of packets which might contain one or more DNS messages

We currently specify that XFR responses should be padded according to the Block-Length Padding strategy recommended in [RFC8467]. We should also specify that the requests should be padded so as to protect the domain name.

"How do most open source implementations split up AXFR responses? A fixed number of records per response or as many as they can fit in a TCP message length of 65535 bytes? (Note RFC5936 talks about supporting old clients that expect one record per response!)."

Will need to set up NSD and Knot Auth primaries to test this...

Does name compression practically limit the size of the real DNS payload (i.e. excluding padding) to 16kb?
I think Mark Andrews pointed out that with ‘smart’ compression the packet could still be 64kB with pointers pointing back to the preceding 16kb but not sure any implementation does this..