This is the Internet Measurement and Anti-Abuse Laboratory (IMAAL) in the Computer Science Department at Brigham Young University. Lab research is directed under Dr. Casey Deccio, an assistant professor in the department.
As part of our research we are engaged in activities involving both passive and active Internet measurements, with the goal of assessing and improving the Internet's health, efficiency, and resiliency to attack and failure.
If you've observed anomalous Internet traffic associated with our address space, we list below more information on research we're conducting, what you might expect to see, and how to opt out.
We are conducting a measurement study that uses SYN packets (and their corresponding SYNACKs) to 1) identify OS and 2) determine whether or not SYN cookies are in use. We believe that our findings, in aggregate, will help us get a picture of security and stability of the Internet, as indicated by servers experiencing high volume or SYN floods over time.
We are conducting an experiment to learn whether networks are susceptible to reverse spoofing, the idea that internal address space is reachable through by spoofing that IP address as the source in packets. We are using DNS queries to known resolvers as a means to test this.
We are conducting experiments related to validation of SPF and DMARC, as part of our research on SMTP anti-abuse. The suffix for any sender email corresponds to a domain with a specific configuration testing a given characteristic of SPF and/or DMARC. We observe the traffic at our authoritative DNS servers to learn more about the state of SPF and DMARC deployment.
We know that people hate spam, so we have tried several ways to reduce, if not eliminate, the amount of unsolicited email reaching someone's inbox as part of our experiment. First, with one methodology we employ, we simply disconnect from the SMTP server after DATA is issued (but before any content is sent). We have and are using that methodology. However, we have learned that many servers begin SPF validation by the point at which we disconnect, but some servers (e.g., gmail) won't validate unless they get some content. Of those, many (e.g., gmail) would immediately dismiss a blank email message, even though they still validate. So we additionally using this methodology. We recognize that there are some servers that don't error out, but we make note of those to not hit them twice---to minimize annoyance and perceived abuse. We also use an invalid SPF and strict DMARC reject policy, so servers adhering to SPF and DMARC should reject our message, but we understand that not all are validating.
We are conducting experiments to characterize DNS server behavior, particularly with respect to open resolver behavior. The custom queries we issue to a resolver supporting recursive DNS queries from our address space force it to in turn issue queries to the servers authoritative for dns-lab.org, which are under our control.
We are also conducting experiments related to DNS-over-TLS, so you might see connection attempts to port 853, which is associated with DNS-over-TLS.
We are conducting experiments to understand the handling of negative DNS responses by DNS authoritative servers, which requires us to issue queries to servers for names or types that don't exist within the DNS zone for which the servers are authoritative.
We are conducting experiments to characterize resolver behavior with respect to DNS authoritative server selection. The custom queries we issue to the resolver force it to in turn issue queries to the servers authoritative for resolver-select.dns-lab.org, which are specially configured and under our control.
We are conducting experiments to characterize resolver behavior with respect to DNS authoritative server selection and proximity to resolvers. Issuing queries for DNS records that don't exist help us to better understand that behavior.