You may have come across a record type labeled "EBOT" when reviewing query statistics returned by the NS1 API. This is not a DNS record type you can configure, but rather a "virtual" record type used to provide more detailed reporting on queries for non-existent records in your zones.
EBOT stands for Exists But Other Type. Most typically, NS1 responses are counted as EBOT queries when AAAA queries are made against records in your zone that exist as A records (i.e. IPv4) but have no AAAA (IPv6) versions. In accordance with RFC 4074, when a AAAA query is made and no AAAA exists, but an A record with the same name exists, we return response code 0 (NOERROR) with an empty answer section and an authoritative SOA record. This indicates to the recursor that they should re-query the name as an A record, which will exist. We count this type of query/response as an EBOT query so we can provide more detailed reporting on how many such queries occur.
It's common behavior for recursive nameservers to first query AAAA for a domain and check the response -- even if you've only asked for the A record. If NS1 were to return an NXDOMAIN (non-existent domain) response, it would indicate that neither AAAA nor A records exist for that name. If NOERROR is returned (the EBOT situation), the recursor will issue another query to retrieve the result of the A record.
EBOT queries are not billed specially or separately from the rest of your traffic. While most DNS providers simply lump all queries related to a zone together when invoicing, NS1 breaks out EBOT queries specifically to differentiate between this common type of query and "true" NXDOMAIN traffic for domains that do not exist, so our customers can better understand the sources of their traffic.
If you are seeing unusually high EBOT traffic, you may want to check the TTL of your SOA record. Increasing this TTL affects how long recursors cache the NOERROR response returned during a AAAA lookup.