DNSServer message header format

[gustavofbreunig]

I'm working with the DNSServer library located in https://github.com/esp8266/Arduino/blob/esp8266/hardware/esp8266com/esp8266/libraries/DNSServer/src/DNSServer.h

There is a struct called DNSHeader, It reflects the UDP DNS packet header:

struct DNSHeader
{
  uint16_t ID;               // identification number
  unsigned char RD : 1;      // recursion desired
  unsigned char TC : 1;      // truncated message
  unsigned char AA : 1;      // authoritive answer
  unsigned char OPCode : 4;  // message_type
  unsigned char QR : 1;      // query/response flag
  unsigned char RCode : 4;   // response code
  unsigned char Z : 3;       // its z! reserved
  unsigned char RA : 1;      // recursion available
  uint16_t QDCount;          // number of question entries
  uint16_t ANCount;          // number of answer entries
  uint16_t NSCount;          // number of authority entries
  uint16_t ARCount;          // number of resource entries
};

I'm looking in various places and the fields are different, every documentation says something like:

source: http://www.tcpipguide.com/free/t_DNSMessageHeaderandQuestionSectionFormat.htm

I'm not a C++ expert, but looks like the struct isn't in the correct order (right after the ID, the correct is QR Flag, not the RD), but the library works great, so I'm missing something?

[Links2004]

for my understanding of the compiler it is looking good.
it shut be interpreted like this:

  uint16_t ID;               // 2 byte
{
  unsigned char RD : 1;      // 24
  unsigned char TC : 1;      // 23
  unsigned char AA : 1;      // 22
  unsigned char OPCode : 4;  // 18 19 20 21
  unsigned char QR : 1;      // 17
}// 1 byte

{

  unsigned char RCode : 4;   // 29 30 31 21
  unsigned char Z : 3;       // 26 27 28
  unsigned char RA : 1;      // 25
}// 1 byte


  uint16_t QDCount;          // 2 byte
  uint16_t ANCount;          // 2 byte
  uint16_t NSCount;          // 2 byte
  uint16_t ARCount;          // 2 byte

[gustavofbreunig]

OK I will take a look on this, it seems the compiler uses little endian.

This issue can be closed.