• 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.

Leave a comment on “A Bit of DNS”

Log In or post as a guest

Replying to comment #704209:

Log Out

« Return to Article