Request: Reverse resolve

[gvanem]

In my project I have the need to reverse-resolve an IPv4-address into a name.
As in adig -t ptr -x 88.95.131.105 ->ti0040q160-6429.bb.online.no.

So I cooked up this function:

static bool mg_dns_send_PTR (mg_connection *c, const mg_addr *addr, uint16_t txnid)
{
  dns_pkt     pkt;
  int         i, x;
  uint8_t    *p;
  const char *arpa = "\7in-addr\4arpa";

  assert (addr->is_ip6 == false);
  memset (&pkt, '\0', sizeof(pkt));
  pkt.header.txnid = mg_htons (txnid);
  pkt.header.flags = mg_htons (0x100);
  pkt.header.num_questions = mg_htons (1);
  p = (uint8_t*) pkt.data + 0;

  for (i = 3; i >= 0; i--)
  {
    x = addr->ip [i];
    *p = (x < 10) ? 1 : (x < 100) ? 2 : 3;
    _itoa (x, p + 1, 10);
    p += *p + 1;
  }
  strcpy (p, arpa);
  p += strlen (arpa);
  memcpy (p, "\x00\x00\x0c\x00\x01", 5);  // PTR query
  p += 5;
  return mg_send (c, &pkt, p - (uint8_t*)&pkt);
}

and in my DNS-callback, I call WinDNS to parse the raw response:

static bool mg_windns_parse_ptr (const uint8_t *buf, size_t len, const mg_dns_message *_dm)
{
  DNS_MESSAGE_BUFFER dm;
  DNS_RECORDA       *dr, *dr0 = NULL;
  DNS_PTR_DATAA     *ptr;
  DNS_STATUS         rc;

  memcpy (&dm.MessageHead, buf, sizeof(mg_dns_header));
  memcpy (&dm.MessageBody, buf + sizeof(mg_dns_header), len - sizeof(mg_dns_header));

  DNS_BYTE_FLIP_HEADER_COUNTS (&dm.MessageHead);

  rc = DnsExtractRecordsFromMessage_UTF8 (&dm, len, &dr0);
  dr = dr0;
  while (dr && rc == ERROR_SUCCESS)
  {
    MG_INFO (("dr->pName: '%s', dr->wType: %u", dr->pName, dr->wType));
    if (dr->wType == DNS_TYPE_PTR)
    {
      ptr = &dr->Data.PTR;
      printf ("PTR: %s\n", ptr->pNameHost);
    }
    dr = dr->pNext;
  }

  if (dr0)
     DnsFree (dr, DnsFreeRecordList);
  return (rc == ERROR_SUCCESS);
}

static void dns_cb (mg_connection *c, int ev, void *ev_data)
{
  ...
  else if (ev == MG_EV_READ)
  {
    if (mg_dns_parse(c->recv.buf, c->recv.len, &dm) && mg_windns_parse_ptr(c->recv.buf, c->recv.len, &dm))
       g_quit = true;
  }
}

Assuming mg_dns_parse(() have to succeed in order for WinDNS to succeed. Not sure this is needed.

This program works fine. But I'd rather like Mongoose and dns.c could have such reverse-resolver functions instead.
(avoiding blocking in gethostbyaddr() etc.). The details of DNS, is too complex for me to make a PR for this,
so how about it?

[scaprile]

The current state of things is that our resolver treats IP addresses as already resolved, so besides the reverse resolution question we should also invent a non-standard URL to indicate an IP that wants to be reverse resolved. Or, provide a separate API. The latter makes more sense.
Given our current backlog and goals, unless you present a compelling application that justified moving resources into that, I don't thing it will happen. None of our paying customers require something like that, so far.

[scaprile]

I think what you're doing is fine, an UDP event handler is able to do that, and you should parse the response yourself, is not black magic, just copy what the dns_cb does, no need for Win calls

[gvanem]

just copy what the dns_cb does, ...

So I need to add a modified version of mg_dns_parse_rr()?

I was hoping Mongoose's DNS could somehow accept custom requests. Now I have to duplicate what mg_resolve() and
the whole chain of calls does. I fail to see how to "break-into" this and add my own custom DNS-callback etc. etc.

[scaprile]

No, the resolver is a resolver, it needs to isolate the caller opening a connection from all that stuff. You just need to know who someone is, so you just need to send an UDP request and expect a UDP response, then parse that response. I don't know all record types nor remember the response to the one we use, however, you just need to find where the name is, so the code in mg_dns_parse_rr() can help you.
You don't need to re-use Mongoose DNS connection, you can just start your own.
When you need to reverse resolve:

• mg_connect() to your preferred DNS
• build and send your PTR query
• in the event handler, you'll get a READ event when there's a response, parse that.

You'll need some way to communicate that back, maybe a callback passed in fn_data if that is not static.