Thread Info
  • State Suggested Answer
  • +2 person also asked this people also asked this
  • Locked Locked
  • Replies 56 replies
  • Answers 1 answer
  • Subscribers 12 subscribers
  • Views 379140 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[SOLVED]DNS best practice?

tbrandl

There are two ways to configure DNS:

One way:
- Allowing DNS outgoing for your internal nameservers
- internal nameservers forwarding to ISP-DNS
- ASG pointing to internal nameservers 

Another way:
- ASG forwarding to ISP-nameservers
- "request routing" on ASG for internal domain pointing to internal nameservers
- internal nameservers forwarding to ASG
 
Which way do you use? And why? Which is "officially preferred"?
Both configurations seem working good for me, we run the first alternative on our cluster, the second in branch offices without internal dns (domain dns reachable via site2site-vpn).

Thanks for your ideas!
Thomas



BAlfson's DNS Best Practice's post has been moved to it's own highlighted thread here: https://community.sophos.com/utm-firewall/f/recommended-reads/122972/dns-best-practice
[edited by: FloSupport at 11:12 AM (GMT -7) on 18 Sep 2020]
Parents
  • 0
    Yes white lines,
    according to the help:
        Red: The packet was dropped.
        Yellow: The packet was rejected.
        Green: The packet was allowed.
        Gray: The action could not be determined.

    what the WHITE lines mean ???

    I read the link you provided , and I don't understand half of it, 
    I re-read it, and I can't , I mean , I'm not sure I can say that the UseCaseScenario applies to my case ...
    especially that I do use DNS forwarders, because mainly I think I should, ain't sure .... , 
    then for this they provide a step-by-step wich I don't understand at all , 
    1-
    I don't have a FQDN for my UTM( maybe my DynDNS name), I don't have an internal server, it's a client piece of software, 

    if  I go the other with solution 2-
    I don't have a DNAT rule for this, I can't forward a bunch of services to that device, some other devices use thoses services too, 

    I think that the solution, for now, is to put that device on another Internal interface, and DMZ it, to make it work first, then, try to think of a workaround to bring it back to my populated internal interface...

    How can I configure an internal interface to be DMZ?
Reply
  • 0
    Yes white lines,
    according to the help:
        Red: The packet was dropped.
        Yellow: The packet was rejected.
        Green: The packet was allowed.
        Gray: The action could not be determined.

    what the WHITE lines mean ???

    I read the link you provided , and I don't understand half of it, 
    I re-read it, and I can't , I mean , I'm not sure I can say that the UseCaseScenario applies to my case ...
    especially that I do use DNS forwarders, because mainly I think I should, ain't sure .... , 
    then for this they provide a step-by-step wich I don't understand at all , 
    1-
    I don't have a FQDN for my UTM( maybe my DynDNS name), I don't have an internal server, it's a client piece of software, 

    if  I go the other with solution 2-
    I don't have a DNAT rule for this, I can't forward a bunch of services to that device, some other devices use thoses services too, 

    I think that the solution, for now, is to put that device on another Internal interface, and DMZ it, to make it work first, then, try to think of a workaround to bring it back to my populated internal interface...

    How can I configure an internal interface to be DMZ?
Children
No Data
Unfiltered HTML