On Tue, Mar 7, 2023 at 7:34 PM Mark Andrews <ma...@isc.org> wrote: > > > On 8 Mar 2023, at 11:16, Evan Hunt <e...@isc.org> wrote: > > > > On Tue, Mar 07, 2023 at 11:15:55AM +0100, Peter Thomassen wrote: > >> Oops, touché! I stand corrected. Thanks, Mark. > >> > >> What I meant is rrtype 0. I used the wrong mnemonic.* > > > > IMHO, you're almost definitely correct that NULL (type 10) would be safe > to > > use for this. Type 0, thought, would not - it's used internally by name > > servers in ways that could be pretty difficult to untangle. > > NULL would also be difficult to use as they can exist in the wild. >
And they do! Don't break my zone please :-) $ dig +short null.huque.com. NULL | python -c "import sys,binascii;print(binascii.unhexlify(sys.stdin.readline().split()[-1]))" b'DNS is weird' > > I would lean toward using a newly allocated type code, though, because > I'm > > 100% sure that wouldn't cause any conflict with existing implementations > ... > Yeah, that's certainly true, and perhaps that should be our primary goal. I am partly sympathetic to Peter's view that RR type 0 would have been a natural fit for this purpose, but the key is "would have been". The concern about message size constraints is misplaced I think. (Pseudo) NXDOMAIN compact answers I just examined in a few of my zones are between 350 and 400 octets. So, we have > 1000 octets of buffer in UDP before problems. If we look to a future where online signers are double signing with a PQC algorithm, type bitmap sizes won't be a factor - and moving to alternate transports that don't have size constraints is more likely (or negotiation of algorithms). Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
