• no (unregistered)
    But it certainly caused issues, and I do have to wonder: if you're treating 7 of 8 bits as reserved, maybe you should just have made it a flag?

    considering that DNS is a binary protocol, i was initially opposed to the idea. but now that i think about it, using a bit of the tag length for the issuer critical flag might not have been such a bad idea. still feels icky, though

    sure, you lose seven flags that could have been used in the future, but i’d bet that we ain’t ever gonna need them. with 7 bits for the tag length, they can now be only up to 127 bytes long, but even that seems way overkill, since there is a short list of valid ones and the (currently) longest is issuewild. doing it this way puts the flag in a field where getting it wrong will be immediately obvious since your tag and value lengths will be majorly messed up. plus the record is one byte shorter, if we still care about that sort of thing in the present day

  • (nodebb)

    The problem isn't, as such, people failing to distinguish between "flag in bit zero, zeroes in all other bits" versus "octet that is the whole flag".

    No, it is "bit zero is on the left (most significant bit)" versus "bit zero is on the right (least significant bit)". With a bit (sorry) of the first part mixed in. Then again, we cannot tell whether the programmer is confused on "which end is bit zero" or confused on "is it a bitflag with zero on the left or is it a whole zero/one field taking the whole octet".

    And don't forget the other two definitions of bit numbers in octets: bits are numbered 1 to 8 with 1 on the left versus 1 on the right, so there's no "bit zero" at all. In the past (much less today), all four schemes (0-7, 7-0, 1-8, 8-1) have been used, usually depending on the vendor that's providing the bitfields in question.

    I personally prefer 7-0 (0 is LSB) because 1 << bitnumber directly gives the right value, but https://datatracker.ietf.org/doc/html/rfc1035 says that for RFC purposes, it's 0-7 (0 is MSB). :(

  • no (unregistered) in reply to Steve_The_Cynic

    agreed, 7 downto 0 ftw :)

  • klinsten1 (github)

    i find this a bit confusing

  • some guy (unregistered)

    what percentage of the people using this field have actually read the RFC? Not many. Probably a number that rounds down to zero, if we're being honest.

    :pendant: depending on whether you're rounding to the nearest 100, this is probably always true.

  • tatoun (unregistered)

    remaining bits are 0/ignore as proscribed by the RFC.

    I think you mean "as prescribed"

  • (nodebb) in reply to Steve_The_Cynic

    I think I agree. This is clearly a case of the programmer seeing that you need to set bit 0 of the flags field (8 bits) and not realising that bit 0 is the most significant bit, not the least significant bit. In particular, the paragraph in RFC6844 before the quoted paragraphs says this:

    A CAA RR consists of a flags byte and a tag-value pair referred to as a property. Multiple properties MAY be associated with the same domain name by publishing multiple CAA RRs at that domain name. The following flag is defined:

    Any programmer (many of whom do understand bits, believe it or not) is going to think "bit field". But they are also going to think bit 0 is the LSB unless they are aware that things are done differently in networking.

    Note that later in the RFC in section 5.1 under "syntax" we have this:

    Note that according to the conventions set out in [RFC1035], bit 0 is the Most Significant Bit and bit 7 is the Least Significant

    If you read the whole RFC, you will get it right. However, people clearly don't read the whole RFC.

    I was going to criticise LetsEncrypt for their "work around". but what they do is safer than adhering strictly to the standard. If somebody bodges their CAA record in this way, intending it to be critical, it will still be treated as such instead of having the issuer issue a certificate it shouldn't.

  • COBOL Dilettante (unregistered)

    It would be much more effective to put the call-to-action first in that paragraph, so that readers know it describes something they have to do, and isn't just an arcane discussion of conventions.

    E.g. start with "Send a decimal value of 128, because on our conventions, bit 0 means the most significant bit..."

  • Endian (unregistered)

    The fact that little endian and big endian are different things at all depending on platform is TRWTF, but I understand it is impossible to make everyone agree on that because it is not a matter of agreement, it is a matter of different aspects of computing being developed in different silos that didn't and wouldn't necessarily be expected to collaborate back in the day

    Something something XKCD comic about standards

  • Tom (unregistered)

    How about "if you're going to reserve 7 of 8 bits, make bit 0 the bit you actually use"? So anyone treating it as a boolean will put a 1 in the field and get it right and future users can do fancier things.

  • Jonathan (unregistered)

    So there are two different ways to refer to different bits in an octet: by LSB to MSB, and by numbering.

    Oh, wait, there are three different ways, because numbering can go 0-7 or 1-8.

    If you're writing a specification that will be read by millions, clarity is achieved by specifying all three every time. E.g. "The furble bit is the MSB, bit 0 of 0-7". Irritating? Yes. But no matter which way a reader thinks about it, they will have the answer they need right in front of them, instead of having to consult RFC one thousand whatever.

  • ricecake (unregistered) in reply to some guy

    :pendant: depending on whether you're rounding to the nearest 100, this is probably always true. :pedant: unless you intended to insert a medal before your statement.

  • ricecake (unregistered)

    :pendant: depending on whether you're rounding to the nearest 100, this is probably always true. :pedant: unless you intended to insert a medal before your statement.

    Of course, I mess up the formatting when trying to be pedantic :)

  • (nodebb) in reply to Endian

    The fact that little endian and big endian are different things at all depending on platform is TRWTF

    It is, but that is of exactly no importance in this discussion, because we aren't talking about the different bytes/octets of a multi-byte(octet) value.

    The problem is like endianness, but concerns only how you name (number) the bits inside a single byte(octet). It's also worth noting that RFC 1035 (that describes, among other things, bit numbering conventions for RFCs) was written in 1987, when far more machines used 0=MSB/7=LSB bit numbering than today.

    But use of 128|1 (129) in the code sample is an example of someone actually following (the "accept" part of)(1) Postel's Law ("Be liberal in what you accept, and conservative in what you send."), first documented in https://www.rfc-editor.org/info/rfc791/ . We should applaud them.

    (1) If the code is very strict about interpreting the literal word of the RFC for CAA records, it breaks the intent of the requests for no really good reason.

  • (nodebb) in reply to ricecake

    Of course, I mess up the formatting when trying to be pedantic :)

    A secondary phenomenon that is merely an extension of Muphry's Law.

  • (nodebb)

    Assuming future extensions to the use of this bitfield assign the bits in numeric order, this workaround should work OK until 7 more bits are assigned, which may indeed be never. Also, we can hope that the future people designing the extensions will be aware of this confusion, and just avoid assigning any meaning to bit 7 -- it's effectively permanently reserved as an alternative to bit 0.

    Maybe someone should even enshrine this into the next revision of the standard. I admit this is ugly, but at least it makes everything consistent. Hopefully we won't need to assign all future bits in pairs like this.

  • (nodebb)

    If the value is set to "1"

    This is the part that ticks me off. If the value is to be set to "1", then we should be stuffing a 0x31 into that byte. (assuming ASCII encoding, which I think DNS always is).

  • (nodebb)

    From TFA:

    Now, I do like bitmasks, because I like the ability to trivially combine a bunch of values together with simple boolean operations

    Shouldn't that be "bitwise operations"? x & y and x && y do different things.

    Python, much as I dislike it, neatly disambiguates the bitwise and boolean operators by using and / or / not for boolean operations and & / | / ~ for bitwise operations.

  • asdf (unregistered)

    I think IBM are the only ones I've seen making bit 0 the MSB. I hate that convention, because the value of every bit will depend on the word width.

  • (nodebb)

    As someone who was on the PKIX standing committee for its entire existence, I can confidently say that half the Internet would break of the PKI standards were enforced as written. Or at least enforced as per the two dozen different incompatible but all arguably valid interpretations of the standards. The skill in working with PKI isn't knowing what to implement, it's knowing what to ignore, what not to implement, and what to implement differently to how several of the possible interpretations tell you.

    Addendum 2026-09-10 22:06: As for LetsEncrypt's approach, that's a good, pragmatic solution. This is how you make PKI not break. That's not "work", it's "not break".

  • (nodebb) in reply to jeremypnet

    This may have come from X.509, where the ASN.1 encoding rules reverse the order of the bits from how any sane person would expect them. So possibly whoever wrote the RFC had had too much exposure to ASN.1 DER, which then affected their mental state.

  • Officer Johnny Holzkopf (unregistered) in reply to Bim Zively

    Depending on how old you are, values "0" and "1" of bits aren't the only one: "off" and "on", "not set" (or "unset") and "set", "0" (or even "O" or "o") and "L" have been common. In my opinion, specifying somethimg like "set bit 5" could raise questions today: Set it to what? Old people(TM) would imply: Yes, of course, set bit 5, leave the others as they are (or maybe keep them unset). This is why ASCII diagrams showing bit order and numbering can be helpful when they accompany the description text. This should be a preface to the actual text, so any possible MSB/LSB and numbering confusion is solved beforehand. It is clear that we're talking about bits now and their values, not a value the bits might represent (like the bits needed to represent the value of ASCII "1" / 0x31 / 10001).

    Also: Bitte ein Bit.

  • Kotarak (unregistered)

    Lesson learned: Everything should come with an example.

    But then again we have the CAN standard, which you cannot implement correctly, because the text and the example contradict each other. One implementor follows the text, the other the example. There you go.

  • no (unregistered) in reply to Tom

    but it is bit 0, it’s just that they use a numbering that starts numbering from the MSb (:

  • (nodebb)

    I htink calling "bit 0" the MSB was the real WTF here. Every other source i've ever read had the LSB as bit 0, especially as you can then make the equality "bit number == power of two of the bit".

  • (nodebb) in reply to asdf

    @asdf I've seen situations which collectively use all four numbering schemas(1), what I called up above 0-7, 7-0, 1-8, 8-1. (Those are "MSB-LSB", mind.) But fortunately, 7-0 seems to have won out, except for RFCs...

    (1) Each situation seemed to use only one schema, thank Dog, but between them, they covered all four.

  • 516052 (unregistered)

    And that is why we need certification and licensing. A good engineer should know standards by heart. And by that I mean know that they exist and when to look them up.

  • (nodebb) in reply to 516052

    And by that I mean know that they exist and when to look them up.

    You left out "where to look them up"... (Although the accursèd Goggle will usually be a good place to start. Failing that, the Unreliable Source.)

  • (nodebb)

    The whole "is bit 0 the right-most or left-most" is like two guitar players talking to each other, one trained and the other self-taught. The trained one will say "the highest string" and they'll be talking about the string that is physically lowest on the instrument, aka closest to the ground, because it makes the highest pitch; whereas the self-taught might reasonably think that the "highest" string is the one that is physically highest on the instrument, aka closest to the sky, even though it makes the lowest pitch.

    Good times!

  • e (unregistered)

    Require bitfields to be palindromic so that endianness doesn't matter, don't care about wasting space 🤪

  • dusoft (unregistered)

    Bitmasks in RFCs in 2015+ ? Disregards user experience and so of course it confuses people. Written by academics for academics who disregard real life. And that's how it ends...

  • dusoft (unregistered)

    And I agree the real life and real life experience forces Let's encrypt to work around messy RFC. BTW, RFC is just a "request for comments".

  • (nodebb) in reply to Steve_The_Cynic

    Question: What's a platform that actually uses bit 0 as MSB?

    Honestly, I can't think about a single one (at least not one where I coded in assembler) and that includes micro controllers. Maybe IBM machines?

  • (nodebb) in reply to zomgwtf

    So possibly whoever wrote the RFC had had too much exposure to ASN.1 DER, which then affected their mental state.

    DER does stand for DERanged.

  • (nodebb) in reply to MaxiTB

    Question: What's a platform that actually uses bit 0 as MSB?

    Not much these days. Probably IBM zSeries (spiritual inheritors of the System/360), but not much else.

    And RFCs.

  • lzsiga (unregistered)

    Note: some documentations use notation 2⁰, 2¹,... 2⁷ for bits.

  • dusoft (unregistered) in reply to dkf

    Or for DERp.

  • (nodebb) in reply to Tom

    @Tom ref:

    How about "if you're going to reserve 7 of 8 bits, make bit 0 the bit you actually use"? So anyone treating it as a boolean will put a 1 in the field and get it right and future users can do fancier things.

    Nope. The problem is that when some old code writes a x01 into there it'll clobber the other 7 bits whose value and meaning now matters . If you ever intend to use reserved bits later for anything, then nobody can be allowed to write into that field except by bit operations. Good luck enforcing that.

  • (nodebb) in reply to Tom

    @Tom ref:

    How about "if you're going to reserve 7 of 8 bits, make bit 0 the bit you actually use"? So anyone treating it as a boolean will put a 1 in the field and get it right and future users can do fancier things.

    Nope. The problem is that when some old code writes a x01 into there it'll clobber the other 7 bits whose value and meaning now matters . If you ever intend to use reserved bits later for anything, then nobody can be allowed to write into that field except by bit operations. Good luck enforcing that.

    Addendum 2026-09-17 09:06: Sorry for double-post; flaky connection here.

Leave a comment on “A Bit of DNS”

Log In or post as a guest

Replying to comment #704298:

Log Out

« Return to Article