1

Our ISP is currently in the middle of a major DNS outage and as a result name resolution through the nameservers they provide is not working. I'm trying to add Google DNS servers to our Cisco 800 Series as an interim solution but DNS still doesn't appear to be working from either the Cisco itself or client machines.

Pinging an IP works fine:

#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/300/780 ms

Pinging a URL doesn't:

#ping cisco.com
Translating "cisco.com"...domain server (203.0.178.191) (203.215.29.191) (8.8.8.8) (8.8.4.4)
% Unrecognized host or address, or protocol not running.

Running config (obfuscation mine) :

Current configuration : 5060 bytes
!
! Last configuration change at 00:08:00 UTC Fri Apr 4 2014
version 15.1
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname ********
!
boot-start-marker
boot-end-marker
!
!
enable secret 5 ********
enable password ********
!
no aaa new-model
memory-size iomem 10
crypto pki token default removal timeout 0
!
********
!
!
********
        quit
ip source-route
!
!
!
ip dhcp excluded-address 192.168.90.254
ip dhcp excluded-address 192.168.90.1 192.168.90.31
!
ip dhcp pool ********
 import all
 network 192.168.90.0 255.255.255.0
 default-router 192.168.90.254
 dns-server 192.168.90.254
!
!
ip cef
ip name-server 8.8.8.8
ip name-server 8.8.4.4
ip inspect name CBAC_out tcp
ip inspect name CBAC_out udp
ip inspect name CBAC_out icmp
ip inspect name CBAC_out dns
no ipv6 cef
!
!
license udi pid CISCO887VA-M-K9 sn FGL16052611
!
!
username root privilege 15 password 0 ********
!
!
!
!
controller VDSL 0
!
!
!
!
!
!
!
!
interface Ethernet0
 no ip address
 shutdown
 no fair-queue
!
interface ATM0
 no ip address
 load-interval 30
 no atm ilmi-keepalive
!
interface ATM0.1 point-to-point
 pvc 8/35
  encapsulation aal5mux ppp dialer
  dialer pool-member 1
 !
!
interface FastEthernet0
 no ip address
!
interface FastEthernet1
 no ip address
!
interface FastEthernet2
 no ip address
!
interface FastEthernet3
 no ip address
!
interface Vlan1
 ip address 192.168.90.254 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip flow ingress
 ip nat inside
 ip virtual-reassembly in
!
interface Dialer0
 description ********
 ip address negotiated
 ip access-group out_to_in in
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1492
 ip nat outside
 ip inspect CBAC_out out
 ip virtual-reassembly in
 encapsulation ppp
 dialer pool 1
 ppp authentication pap callin
 ppp pap sent-username ********@******** password 0 ********
 ppp ipcp dns request
 ppp ipcp route default
 ppp ipcp address accept
 no cdp enable
!
interface Dialer1
 no ip address
!
ip forward-protocol nd
ip http server
ip http authentication local
ip http secure-server
ip http timeout-policy idle 600 life 86400 requests 1000
!
ip dns server
ip nat inside source list NAT interface Dialer0 overload
!
ip access-list extended NAT
 permit ip 192.168.90.0 0.0.0.255 any
ip access-list extended out_to_in
 remark Internet traffic coming in
 permit tcp any any established
 permit icmp any any echo-reply
 permit icmp any any echo
 permit udp any any eq domain
!
!
!
!
!
!
line con 0
line aux 0
line vty 0 4
 password ********
 login
 transport input all
!
end
Taz
  • 147
  • 3
  • 16
  • 2
    For what it's worth, I would probably remove the ISP's DNS and just never put them back in. I've never once regretted dumping their DNS. – Mark Henderson Apr 04 '14 at 01:32
  • 1
    Not sure, but what about adding `permit ip host 8.8.8.8 any` in your `ip access-list extended out_to_in` ? – krisFR Apr 04 '14 at 01:39
  • do you have the ability to run a packet capture on that interface by chance? – MartinC Apr 04 '14 at 01:50
  • @krisFR that worked perfectly - not sure why the catchall udp domain rule didn't work but whatever. Suggest as an answer and i'll mark it as correct. – Taz Apr 04 '14 at 02:55
  • DNS will also use TCP under certain circumstances as well. From Microsoft - "There should be consistency in DNS Zone database. To make this, DNS always transfer Zone data using TCP because TCP is reliable and make sure zone data is consistent by transferring the full zone to other DNS servers who has requested the data." – MartinC Apr 04 '14 at 11:59

1 Answers1

1

You have an access-list called out_to_in that seems to be here to filter incoming traffic from Internet.

You should try to add permit ip host 8.8.8.8 any in your access-list ip access-list extended out_to_in

krisFR
  • 13,280
  • 4
  • 36
  • 42