Solved DNS's and stuff

blind0ne

blind0ne

Hello,
How can I learn about theory behind bind, it's configuration, zones and stuff. The thing is that I've received access to few dns servers (master and slave), and would like to become really confident admin of this example.net authority. But can't find any materials behind it? How to master this DNS administration sklill? How to backup everything properly?

Thanks a lot
 
https://www.zytrax.com/books/dns/ can be heavy going but useful.

If someone who knew what they were doing put together the DNS servers, look at what they've done and see if you can understand the reasons. I think there are sample named.conf files included in the bind program. If you have a friend familiar with it, ask them for help. I remember explaining making a zone change to a co-worker and them saying that the 3 minute walk through I gave them made it simple.
Like many things, when you know how to do it it's not that hard, but learning to do it is difficult. Much of the documentation overcomplicates it.
 
I'm really frustrated with this "allow-recursion", "allow-query-cache" and "allow-query", Am I right, that the recursion option allows for subnets to get actual resolutions through my server, query one allows to get cached data pairs and what allows allow-query, just to get info about authoritative resources of server?

How to protect from ddos, recently I have been attacked on dns, proc was 100% loaded

Thanks
 
Recursion allows a query for other domains for which your DNS server isn't authoritative. In other words, a client could request www.google.com for example and your DNS will 'recurse' that by querying upstream DNS servers (root servers -> .com -> google.com, etc) and pass the results back to the client.

blind0ne said:
How to protect from ddos, recently I have been attacked on dns, proc was 100% loaded
Click to expand...
Do NOT allow recursive queries from outside. Only your local (trusted) network should be able to do recursive queries. https://www.cisa.gov/uscert/ncas/alerts/TA13-088A

If you need to host an authoritative DNS server for a domain on the internet it's probably best to use a separate DNS server for this. Or you will have to get creative with different "views" in BIND. Not impossible to do but quite tricky if you're new to this.

If you just want an 'authoritative' domain for internal use then make sure your DNS server isn't reachable from the internet at all.
 
SirDice said:
Recursion allows a query for other domains for which your DNS server isn't authoritative. In other words, a client could request www.google.com for example and your DNS will 'recurse' that by querying upstream DNS servers (root servers -> .com -> google.com, etc) and pass the results back to the client.


Do NOT allow recursive queries from outside. Only your local (trusted) network should be able to do recursive queries. https://www.cisa.gov/uscert/ncas/alerts/TA13-088A

If you need to host an authoritative DNS server for a domain on the internet it's probably best to use a separate DNS server for this. Or you will have to get creative with different "views" in BIND. Not impossible to do but quite tricky if you're new to this.

If you just want an 'authoritative' domain for internal use then make sure your DNS server isn't reachable from the internet at all.
Click to expand...
The problem is such: I'm already have 2 servers that are somewhere are pointed to as authoritative, and in the same time they are recursive and caching for internal clients, one is master and second is slave. Have no ideas how to "protect" them from ddos at all, or how to separate them to divide function groups, make authoritative just separate? I'll leve everything as is for now.
 
You might want to set up a VM for practice. Inside that VM, you can mess things up as much as you want without affecting the 'production' stuff. There's a good page that describes some basic strategies for fighting against a DDOS. There's a little bit you can do on your end of things (server-side) to mitigate the impact, but in the end, you're just a little fish out there.

Second, you might want to make sure your DNS server is set up sensibly - what queries are allowed, which ones are not. Don't worry about load balancing, your setup is most likely not that big. After that, I'd recommend tinkering with the firewall. And once again - do all that inside your own VM first until you gain confidence that your ideas will actually work.
 
you don't need views for bind only if you need to return different ips for queries from inside
otherwise just allow queries per zone and none by default (newer versions of bind do that by default)
 
Views was the easy thing to do, at least it was at the time I set this up. Granted, that was quite a while ago, there may be smarter ways of doing it nowadays. I haven't touched the configuration in quite a while because it works, it does what I want it to do for the past 15 or so years.


Basic idea is/was this:
Code: 
view "internal" {
        match-clients { mynetwork; };
        allow-transfer { mynetwork; };
        recursion yes;
        
       include "...";
...
}

view "guest" {
        match-clients { guest; };
        allow-transfer { none; };
        recursion yes;
        
        include "....";
...
}
view "external" {
        match-clients { any; };
        allow-transfer { none; };
        recursion no;
    
        include "...";
...
}

mynetwork and guest are defined as acl ... { 1.1.1.1/32; }; for example. That guest network is a separate wifi network at home, you can use it to access the internet but it won't give you access to the rest of my home network.
 
acls work in individual zone blocks
zone "xxx.dom" {
type master;
allow-query { 0/0;};
file "../master/xxx.dom.db";
};
with views you (can) have separate configs for the same zone, different zone files
and you can then resolve mx.xxx.dom to 10.3.4.17 for internal network and 14.23.99.91 for the internet
by default bind will allow queries, recursion for RFC 1918 clients only but you can define any number of acls and put the global stuff in the options block
 
Hi here I spotted some trash in logs, looks like this:
22-Mar-22 20:35:42.444 resolver: notice: DNS format error from xxx.xxx.xxx.xx#53 resolving ns-open3.qq.com/AAAA for <unknown>: Name qq.com (SOA) not subdomain of zone ns-open3.qq.com -- invalid respons

What the hell is it and why there is so much of this log lines here. xxx.xxx.xxx.xx is variative (different). It is around 3 such errors in second. Server is still working, but logs become complete useless because of this request. How can I understand what the heck it is and how to fight it at all.

Thanks, its so good not to be complete alone after black screen.
 
blind0ne said:
Hi here I spotted some trash in logs, looks like this:
22-Mar-22 20:35:42.444 resolver: notice: DNS format error from xxx.xxx.xxx.xx#53 resolving ns-open3.qq.com/AAAA for <unknown>: Name qq.com (SOA) not subdomain of zone ns-open3.qq.com -- invalid respons

What the hell is it and why there is so much of this log lines here. xxx.xxx.xxx.xx is variative (different). It is around 3 such errors in second. Server is still working, but logs become complete useless because of this request. How can I understand what the heck it is and how to fight it at all.

Thanks, its so good not to be complete alone after black screen.
Click to expand...
Ummm... there are some Best Practice ideas floating around the Internet that I think you can make use of:
  • Mastery of standard text analysis tools like sed/awk/grep. Amazingly useful when going through logs.
  • Learn what should be logged, what can be ignored, etc.
  • Learn what even produces log entries like that. Just grepping for 'error' string is not enough. Even if you don't have much access right now, try to make sense of the data that you're seeing. As in, try to understand it end-to-end. You'll be surprised at the size of the list of chores just in your position.
  • Learn to correlate the theory with practice. There's a reason advice from the Internet doesn't tell you which button to push or line to add to the config file.
  • Learn to look for patterns in logs, and to correlate them with simple, concrete activity.
Once you get a handle on all that (and probably more), then you'll be ready for security/snort. OINK! ;)
 
astyle said:
Ummm... there are some Best Practice ideas floating around the Internet that I think you can make use of:
  • Mastery of standard text analysis tools like sed/awk/grep. Amazingly useful when going through logs.
  • Learn what should be logged, what can be ignored, etc.
  • Learn what even produces log entries like that. Just grepping for 'error' string is not enough. Even if you don't have much access right now, try to make sense of the data that you're seeing. As in, try to understand it end-to-end. You'll be surprised at the size of the list of chores just in your position.
  • Learn to correlate the theory with practice. There's a reason advice from the Internet doesn't tell you which button to push or line to add to the config file.
  • Learn to look for patterns in logs, and to correlate them with simple, concrete activity.
Once you get a handle on all that (and probably more), then you'll be ready for security/snort. OINK! ;)
Click to expand...
Just blocked this chinas ips
 
You must log in or register to reply here.
Back
Top