The third returns whether the database knows about a given zone and the fourth returns the actual IP for any lookup that isn't for types MX or SOA.
The next is the database connection string (host, username, password). The first indicates the database type and the number of concurrent connections to keep open (4). There are, at a minimum, four lines that need to be included. You can modify these if you like but it's much easier to use what's provided. If you read the bind-dlz configuration page you'll find a set of database queries that get inserted into nf. The bind-dlz sourceforge page lists several more columns but those are only necessary for a full DLZ deployment, where the DNS server is authoritative for a domain, not for a purely recursive caching server. The data, type, host and ttl fields can have size restrictions put in place and you can drop the id field altogether.
DNS BLACKHOLE HOW TO
I like to use a schema that reflects the type of data the column holds so I'll use the following create statement:Ĭreate index zone_idx on dns_records(zone) Ĭreate index host_idx on dns_records(host) Ĭreate index type_idx on dns_records(type) John Wagnon discusses how to manage DNS requests with a solution to blackhole malicious requests or remediate them on BIG-IP.Link to Blackhole DNS iRule: htt. The database schema is pretty flexible there are no required column names or types, as long as queries return the correct type of data.
0 kommentar(er)
