Skip to main content
MrSinners
MrSinners
New Member
March 16, 2018
Solved

DNS server on loopback not working after upgrade to 5.6.3

  • March 16, 2018
  • 3 replies
  • 21531 views

Hello,

 

After upgrading from 5.4.5 to 5.6.3, the DNS service on a loopback interface is not working anymore. The traffic is arriving on the VDOM and the debug flow shows the traffic is accepted and sent to the loopback. However the DNS service itself does not reply. A wireshark shows exactly the same behavior, the packet is incoming on the VDOM, but there's no reply back. DNSproxy debugging shows:

 

udp_receive_request()-2065: vd=8, intf=39, len=32, alen=16, 10.1.0.47:42857=>172.16.10.13 handle_dns_request()-1395: id:0xabb5 pktlen=32, qr=0 req_type=3 get_intf_policy()-876: ifindex=39

A config compare between 5.4.5 and 5.6.3 shows no modified configuration whatsoever related to DNS or the loopback interface. Running the DNS service on a physical interface does seems to be working.

 

Has anyone by chance run into this before? It seems like a bug or behavior change.

    Best answer by MrSinners

    Hi Emnoc,

     

    For this issue I made a Fortinet ticket. As it turns out, there was a change of behavior in 5.6. There was a security flaw related to DNS in 5.4 which has been fixed. The consequence of this fix is that the DNS service has to be enabled also on the source interface receiving the DNS traffic. This is also why reproducing the issue at home was not successful for me, as DNS was enabled on my LAN also so I couldn't break it. After removing DNS on my local LAN, the DNS service on the Loopback interface indeed stopped responding. It still doesn't make that much sense to enable DNS as a service on the receiving interface, but it is the solution. Thanks for your help :)

    3 replies

    emnoc
    emnoc
    New Member
    March 16, 2018

    Yes we had the same issue. Did you reapply the cfg ?  And  issues the  fwpolicy is allowing the traffic ( I know you said yes above )

     

    Ken

    MrSinners
    MrSinnersAuthor
    New Member
    March 16, 2018

    Hi Ken,

     

    Thanks for your response!

     

    The config has not been reapplied, at least not that im aware off. The FG has been recently added to FMG and had its first install. Should the config be reapplied? How did you manage to solve this? The policy is allowing traffic, but does not show up in the debug flow trace (Allowed by policy-X) as its a local interface.

    emnoc
    emnoc
    New Member
    March 17, 2018

    I don't know what else to suggest outside re-apply the cfg and make sure  the status is enable. We have ipv6/ipv4 bound on the  loopback and it works 100%

     

    e.g 

     

    AUN1LSE01:~ root# host -6  -T -t  a www.1plus1eq2.com  '2001:db8:101::1'

    Using domain server:

    Name: 2001:db8:101::1

    Address: 2001:db8:101::1#53

    Aliases: 

     

    www.1plus1eq2.com has address 1.1.1.1

     

     

    AUN1LSE01:~ root# host -t a www.1plus1eq2.com 192.168.1.1

    Using domain server:

    Name: 192.168.1.1

    Address: 192.168.1.1#53

    Aliases: 

     

    www.1plus1eq2.com has address 1.1.1.1

     

    config system interface

        edit "loop0"

            set vdom "mgmt"

            set ip 128.0.0.1 255.0.0.0

            set allowaccess ping https ssh

            set type loopback

            set snmp-index 9

            config ipv6

                set ip6-address 2001:db8:101::1/128

                set ip6-allowaccess ping ssh

            end

        next

    end

     

     

    config system dns-database

        edit "1plus1eq2.com"

            set status enable

            set domain "1plus1eq2.com"

            set type master

            set view public

            set ttl 300

            set authoritative enable

            unset forwarder

            set source-ip 0.0.0.0

            config dns-entry

                edit 1

                    set status enable

                    set type A

                    set ttl 30

                    set hostname "www.1plus1eq2.com"

                    set ip 1.1.1.1

                next

                edit 2

                    set status enable

                    set type MX

                    set ttl 7

                    set hostname "mail.1plus1eq2.com"

                    set preference 1000

     

    This an authoritative  DNS for a single zone btw

     v5.6.3 FGT90D

     

    Ken

     

    Leenchen
    Leenchen
    New Member
    February 18, 2022

    Confirmed this is still behavior in 7.0.2
    The solution for me was to enable dns on the incoming interface as well.

    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    February 19, 2022

    As stated in one of the first posts, "it's not a but, it's a feature!".

    @FTNT: maybe there should be a hint added to the regular documentation (i.e. the Handbook) in the chapter on DNS servers. This would spare users, and eventually FTNT customer support, a lot of troubleshooting.

    Terms & ConditionsAccessibility statement