2

Just want to double check my work here, but the domain port is supposed to be specified with the actual DNS server, correct? I want to only allow the VLAN 5.5.5.0/24 to communicate with this server for DNS. For example, if my DNS server is 1.1.1.1, the ACLs would look like this:

ip access-list DNS-IN
permit udp 5.5.5.0/24 1.1.1.1/32 eq domain

ip access-list DNS-OUT
permit udp 1.1.1.1/32 eq domain 5.5.5.0/24

int vlan 10
ip access-group DNS-IN in
ip access-group DNS-OUT out

VLAN 10 is the 5.5.5.0/24 network. I'm getting confused as to where to place the eq domain command. I'm assuming you place the domain command on the actual DNS server 1.1.1.1. By the way, the /24 notation is accepted on Cisco NX-OS and the addresses are not literal. Can someone confirm that the syntax command is correct? Thanks.

  • Is VLAN 10 the 5.5.5.0/24 network? – Ron Maupin Dec 6 '17 at 22:35
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin Feb 21 '18 at 18:26
1

You are on the right way but is convenient to add the sequence number at the first place i.e:

ip access-list DNS-IN
 10 permit udp 5.5.5.0/24 1.1.1.1/32 eq domain

You could add the "log" command at the end in order to see the hits of the rule if you have doubts ie:

10 permit udp 5.5.5.0/24 1.1.1.1/32 eq domain log
0

One thing to think about with the outbound ACL is that you probably want to apply it as close to the source as possible, as an inbound ACL. That prevents you from unnecessarily routing traffic that is destined to be dropped. Filtering traffic inbound where possible saves routing resources.

Also, for your outbound ACL, you put the eq domain at then end of the ACL entry.

Another thing is that the ACLs have an implicit deny ip any any as the last ACL entry, so you probably need a permit ip any any as the last ACL entry.

  • 1
    Wouldn't eq domain on the end of the second rule mean the destination port 53? Surely the source port must be 53 for the reply. – Zac67 May 6 '18 at 8:16
0

Your ACL is correct for udp/53, which is the port that most DNS resolution occurs on.

While DNS queries normally run over UDP/53, they can also run over TCP/53. If a DNS A-record has over (approximately) 17 IP addresses, it will exceed the size of one DNS UDP packet and normal DNS resolution will use tcp/53. This is a rare case, and most network administrators avoid putting so many A-records in their entries. But to be correct, to enable DNS resolution, you need to allow your clients to reach your DNS server on both udp and tcp port 53.

I don't have operational DNSSEC experience but internet searches seem to indicate that it also uses tcp/53. If true that's another reason to permit tcp 53.

DNS zone transfers use tcp/53. Make sure your DNS servers are configured to only allow zone transfers to specific servers you allow. That protection belongs in your DNS server configuration, not ACL configuration. Test it by trying to zone transfer from an "unauthorized" host!

Enough discussion about the need for tcp/53 and zone transfer security. The way to avoid confusion is to understand that tcp/udp sockets have 5 components:

IP protocol (tcp/6 or udp/17)
source ip
source port
destination ip
destination port

In addition tcp sockets can have "flags". The most useful one for ACLs is the "established" flag, which is included in tcp responses.

Here are the 4 sockets you are dealing with:

socket 1: UDP from client to server:
protocol UDP
source ip: 5.5.5.x
source port: "random high" port (1024-65535)
destination ip: 1.1.1.1
destination port: 53

socket 2: UDP reply from server to client:
protocol UDP
source ip: 1.1.1.1
source port: 53
destination ip: 5.5.5.x
destination port: "random high" port (1024-65535)

socket 3: tcp case from client to server
protocol TCP
source ip: 5.5.5.x
source port: "random high" port (1024-65535)
destination ip: 1.1.1.1
destination port: 53

socket 4: tcp reply from server to client
protocol TCP
source ip: 1.1.1.1
source port: 53
destination ip: 5.5.5.x
destination port: "random high" port (1024-65535)
flags: established

Here's the (correct) ACL line you had for client to server UDP case (socket #1)

permit udp 5.5.5.0/24 1.1.1.1/32 eq domain

Format is as follows:

ACTION PROTOCOL SOURCE-IP {SOURCE-PORT} DESTINATION-IP {DESTINATION-PORT}

if source-port is not listed, then source port is any. That is what you want since the actual source port ranges from 1024-65535. For performance reasons its best to avoid port "range" commands in ACLs.

Here's your reply ACL line for socket #2:

permit udp 1.1.1.1/32 eq domain 5.5.5.0/24

That's also correct for socket 2, which has source port 53 and destination port 1024-65535 (so you use the implicit any destination port).

Adding in the TCP cases:

ip access-list DNS-IN
permit udp 5.5.5.0/24 1.1.1.1/32 eq domain     ! socket #1
permit tcp 5.5.5.0/24 1.1.1.1/32 eq domain     ! socket #3

ip access-list DNS-OUT
permit udp 1.1.1.1/32 eq domain 5.5.5.0/24      ! socket #2
permit tcp 1.1.1.1/32 eq domain 5.5.5.0/24 established   ! socket #4

int vlan 10
ip access-group DNS-IN in
ip access-group DNS-OUT out

Of course, if you actually apply that acl, everything else will break on that vlan because of the implicit "deny ip any any" at the end.

I personally use "permit tcp any any established" in most of my ACLs, which eliminates your socket #4 line. I put that first in the ACL for performance reasons.

Adding in the TCP case:

ip access-list DNS-IN
permit udp 5.5.5.0/24 1.1.1.1/32 eq domain  ! socket 1
permit tcp 5.5.5.0/24 1.1.1.1/32 eq domain  ! socket 3

ip access-list DNS-OUT
permit tcp any any established     ! permits socket 4 plus more
permit udp 1.1.1.1/32 eq domain 5.5.5.0/24    ! socket 2

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.