What Port Is Associated With The Dns Service

8.x Domain Proper noun System (DNS)

DNS is a distributed database system that translates hostnames to IP addresses and IP addresses to hostnames (e.m., it translates hostname miles.somewhere.net to IP address 192.168.244.34). DNS is as well the standard Cyberspace mechanism for storing and accessing several other kinds of data nigh hosts; it provides data virtually a particular host to the globe at large. For example, if a host cannot receive mail service directly, only another machine will receive mail for it and pass it on, that information is communicated with an MX record in DNS.

DNS clients include any plan that needs to practise any of the following:

Interpret a hostname to an IP address
Interpret an IP address to a hostname
Obtain other published data virtually a host (such as its MX record)

Fundamentally, whatsoever program that uses hostnames can be a DNS client. This includes essentially every programme that has annihilation to do with networking, including both customer and server programs for Telnet, SMTP, FTP, and almost whatsoever other network service. DNS is thus a fundamental networking service, upon which other network services rely.

Other protocols may be used to provide this kind of information. For example, NIS/YP is used to provide host data inside a network. Nonetheless, DNS is the service used for this purpose across the Cyberspace, and clients that need to admission Internet hosts will have to utilize DNS, directly or indirectly. On networks that use NIS/YP or other methods internally, the server for the other protocol normally acts as a DNS proxy for the client. Many clients can also be configured to use multiple services, so that if a host lookup fails, it will retry using another method. Thus, it might start past looking in NIS/YP, which will show merely local hosts, but try DNS if that fails, or it might outset by looking in DNS, and and so try a file on its own deejay if that fails (so that y'all can put in personal favorite names, for example).

In UNIX, DNS is implemented past the Berkeley Cyberspace Proper name Domain (BIND). On the customer side is the resolver, a library of routines called by network processes. On the server side is a daemon called named (also known as in.named on some systems).

DNS is designed to frontwards queries and responses betwixt clients and servers, so that servers may act on behalf of clients or other servers. This capability is very of import to your ability to build a firewall that handles DNS services securely.

How does DNS work? Substantially, when a client needs a particular piece of information (e.g., the IP address of host ftp.somewhere.net), information technology asks its local DNS server for that information. The local DNS server outset examines its own enshroud to see if it already knows the answer to the customer's query. If not, the local DNS server asks other DNS servers, in turn, to discover the reply to the client's query. When the local DNS server gets the answer (or decides that it can't for some reason), it caches any data it got[34] and answers the customer. For example, to find the IP address for ftp.somewhere.net, the local DNS server first asks ane of the public root nameservers which machines are nameservers for the net domain. Information technology and so asks 1 of those cyberspace nameservers which machines are nameservers for the somewhere.net domain, and then information technology asks i of those nameservers for the IP accost of ftp.somewhere.internet.

[34] Some servers will cache the fact that the query failed, on some types of failures; others cache only information retrieved on a successful query.

This request and answering is all transparent to the client. Every bit far as the client is concerned, it has communicated only with the local server. Information technology doesn't know or care that the local server may accept contacted several other servers in the procedure of answering the original question.

eight.10.one Bundle Filtering Characteristics of DNS

There are two types of DNS network activities: lookups and zone transfers. Lookups occur when a DNS customer (or a DNS server acting on behalf of a customer) queries a DNS server for information, e.g., the IP accost for a given hostname, the hostname for a given IP accost, the name server for a given domain, or the mail exchanger for a given host. Zone transfers occur when a DNS server (the secondary server) requests from another DNS server (the primary server) everything the main server knows nearly a given slice of the DNS naming tree (the zone). Zone transfers happen only among servers that are supposed to be providing the aforementioned information; a server won't try to do a zone transfer from a random other server nether normal circumstances. People occasionally do zone transfers in order to gather information (this is OK when they're calculating what the most popular hostname on the Internet is, but bad when they're trying to detect out what hosts to attack at your site).

For performance reasons, DNS lookups are commonly executed using UDP. If some of the data is lost in transit by UDP (call back that UDP doesn't guarantee commitment), the lookup will be redone using TCP. In that location may be other exceptions. Figure 8.thirteen shows a DNS proper name lookup.

Effigy 8.13: DNS proper noun lookup

Figure 8.13

A DNS server uses well-known port 53 for all its UDP activities and as its server port for TCP. It uses a random port above 1023 for TCP requests. A DNS client uses a random port above 1023 for both UDP and TCP. You can thus differentiate between the following:

A client-to-server query - source port is above 1023, destination port is 53.
A server-to-client response - source port is 53, destination port is above 1023.
A server-to-server query or response - at least with UDP, where both source and destination port are 53; with TCP, the requesting server will use a port in a higher place 1023.

DNS zone transfers are performed using TCP. The connection is initiated from a random port above 1023 on the secondary server (which requests the data) to port 53 on the main server (which sends the data requested by the secondary). A secondary server must also do a regular DNS query of a primary server to decide when to do a zone transfer. Figure viii.14 shows a DNS zone transfer.

Direc-	Source	Dest.	Pro-	Source	Dest.	ACK
tion	Addr.	Addr.	tocol	Port	Port	Ready	Notes
In	Ext	Int	UDP	>1023	53	[35]	Incoming query via UDP, client to server
Out	Int	Ext	UDP	53	>1023	[35]	Reply to incoming UDP query, server to customer
In	Ext	Int	TCP	>1023	53	[36]	Incoming query via TCP, customer to server
Out	Int	Ext	TCP	53	>1023	Aye	Reply to incoming TCP query, server to customer
Out	Int	Ext	UDP	>1023	53	[35]	Outgoing query via UDP, client to server
In	Ext	Int	UDP	53	>1023	[35]	Answer to outgoing UDP query, server to client
Out	Int	Ext	TCP	>1023	53	[36]	Outgoing query via TCP, client to server
In	Ext	Int	TCP	53	>1023	Yes	Answer to approachable TCP query, server to customer
In	Ext	Int	UDP	53	53	[35]	Query or response between two servers via UDP
Out	Int	Ext	UDP	53	53	[35]	Query or response between 2 servers via UDP
In	Ext	Int	TCP	>1023	53	[36]	Query from external server to internal server via TCP; also zone transfer request from external secondary server via TCP
Out	Int	Ext	TCP	53	>1023	Yes	Reply from internal server to external server via TCP; also zone transfer response to external secondary server via TCP
Out	Int	Ext	TCP	>1023	53	[36]	Query from internal server to external server via TCP
In	Ext	Int	TCP	53	>1023	Yes	Respond from external server to internal server via TCP

[35] UDP packets do not have ACK bits.

[36] ACK is non attack the first parcel of this blazon (establishing connectedness) only will be set on the balance.

Figure 8.14: DNS zone transfer

Figure 8.14

8.10.2 Proxying Characteristics of DNS

DNS is structured so that servers always deed as proxies for clients. It's also possible to utilize a DNS feature chosen forwarding then that a DNS server is effectively a proxy for another server. The rest of this DNS discussion describes the use of these built-in proxying features of DNS.

In most implementations, it would be possible to modify the DNS libraries to use a modified-client proxy. On machines that practise non support dynamic linking, using a modified-customer proxy for DNS would require recompiling every network-aware program. Because users don't directly specify server information for DNS, modified-procedure proxies seem nearly impossible.

8.10.3 DNS Data

The DNS is a tree-structured database, with servers for various subtrees scattered throughout the Internet. There are a number of defined record types in the tree, including:[37]

[37] For detailed information nigh DNS tape types, what they mean, and how to use them, run across DNS and Demark , referenced earlier in this chapter.

Record Type	Usage
A	Translates hostname to IP address
PTR	Translates IP address to hostname
CNAME	Translates host alias to hostname ("canonical" name)
HINFO	Gives hardware/software information about a host
NS	Delegates a zone of the DNS tree to some other server
SOA	Denotes start of authority for a zone of the DNS tree
TXT	Unstructured text records

In fact, there are two split DNS data trees: one for obtaining information by hostname (such as the IP address, CNAME tape, HINFO tape, or TXT record that corresponds to a given hostname), and ane for obtaining information by IP address (the hostname for a given accost).

For example, here is a sample of the DNS data for a fake domain somebody.net:

somebody.cyberspace. IN SOA tiger.somebody.internet. root.tiger.somebody.net. (                         1001      ; series number                         36000       ; refresh (10 hr)                         3600        ; retry (i hr)                         3600000     ; expire (thou hr)                         36000       ; default ttl (10 hr)                         )                IN  NS       tiger.somebody.internet.                IN  NS       lion.somebody.net. tiger          IN  A        192.168.2.34                IN  MX       five tiger.somebody.cyberspace.                IN  MX       ten panthera leo.somebody.net.                IN  HINFO    INTEL-486 BSDI ftp            IN  CNAME    tiger.somebody.net. panthera leo           IN  A        192.168.2.35                IN  MX       5 lion.somebody.cyberspace.                IN  MX       10 tiger.somebody.net.                IN  HINFO    Sun-3 SUNOS world wide web            IN  CNAME    king of beasts.somebody.cyberspace. wais           IN  CNAME    panthera leo.somebody.cyberspace. alaska         IN  NS       carry.alaska.somebody.net. bear.alaska    IN  A        192.168.ii.81

This domain would also need a corresponding ready of PTR records to map IP addresses back to hostnames. To translate an IP address to a hostname, yous reverse the components of the IP address, append .IN-ADDR.ARPA, and look up the DNS PTR tape for that name. For example, to translate IP address 1.2.3.4, you would look upward the PTR record for iv.3.2.one.IN-ADDR.ARPA.

2.168.192.IN-ADDR.ARPA. IN  SOA tiger.somebody.net.root.tiger.somebody.net. (                                   1001     ; series number                                  36000    ; refresh (10 hr)                                  3600     ; retry (1 hr)                                  3600000  ; expire (thou 60 minutes)                                  36000    ; default ttl (x hr)                                   )                          IN  NS  tiger.somebody.internet.                          IN  NS  king of beasts.somebody.internet. 34                       IN  PTR tiger.somebody.net. 35                       IN  PTR lion.somebody.net. 81                       IN  PTR bear.alaska.somebody.net.

8.x.4 DNS Security Bug

There are some security issues with DNS that are described beneath.

eight.10.4.one Bogus answers to DNS queries

The first security trouble with DNS is that many DNS servers and clients tin be tricked by an attacker into assertive artificial information. Many clients and servers don't check to see whether all the answers they get relate to questions they actually asked, or whether the answers they become are coming from the server they asked. Servers, in detail, may cache these "extra" answers without actually thinking well-nigh it, and answer later queries with this bogus cached data. This lack of checking can let an attacker to give false data to your clients and servers. For case, an attacker could use this capability to load your server's cache with information that says that his IP accost maps to the hostname of a host you trust for countersign-less access via rlogin. (This is only one of several reasons you lot shouldn't let the BSD "r" commands across your firewall; see the full discussion of these commands before in this affiliate.)

Annotation: Afterwards versions of DNS for UNIX (Demark iv.9 and later) cheque for artificial answers and are less susceptible to these problems. Earlier versions, and DNS clients and servers for other platforms, may however be susceptible.

viii.ten.4.2 Mismatched data between the hostname and IP accost DNS trees

The attack described in the previous section points out the trouble of mismatched information between the hostname and IP address trees in the DNS. In a example like the one nosotros've described, if you wait upward the hostname corresponding to the attacker'due south IP address (this is chosen a opposite lookup), you get back the proper noun of a host you trust. If y'all and so look up the IP address of this hostname (which is called a double-opposite lookup), you should meet that the IP address doesn't match the ane the attacker is using. This should alarm y'all that something suspicious is going on. Reverse and double-opposite lookups are described in more item in the section called "Prepare up a `simulated' DNS server on the breastwork host for the outside world to use" later in this DNS discussion.

Any program that makes authentication or dominance decisions based on the hostname information it gets from DNS should be very conscientious to validate the data with this reverse lookup/double-reverse lookup method. In some operating systems (for case, SunOS iv.x and later), this cheque is automatically done for you by the gethostbyaddr() library part. In nigh other operating systems, y'all take to do the check yourself. Brand sure that you know which approach your own operating system takes and make sure that the daemons that are making such decisions in your organization practice the appropriate validation. (And be sure you're preserving this functionality if you lot modify or supercede the vendor's libc.) Better yet, don't exercise whatever authentication or dominance based solely on hostname or fifty-fifty on IP accost; at that place is no fashion to exist sure that a packet comes from the IP accost it claims to come from, unless there is some kind of cryptographic hallmark within the parcel that simply the true source could have generated.

Some implementations of double-reverse lookup neglect on hosts with multiple addresses, e.one thousand., dual-homed hosts used for proxying. If both addresses are registered at the same name, a DNS lookup by proper name will return both of them, but many programs volition read simply the first. If the connectedness happened to come from the 2d address, the double-opposite will incorrectly neglect fifty-fifty though the host is correctly registered. Although you should avoid using double-reverse implementations that have this flaw, you may too want to ensure that on your externally visible multi-homed hosts, lookup by address returns a different name for each accost, and that those names have only ane address returned when it is looked up. For example, for a host named "foo" with two interfaces named "e0" and "e1", accept lookups of "foo" return both addresses, lookups of "foo-e0" and "foo-e1" return but the accost of that interface, and lookups by IP accost return "foo-e0" or "foo-e1" (simply not just "foo") as appropriate.

Annotation: For internal multi-homed hosts, you probably don't want to set things upwards in the way we've described; if y'all do, you lot may finish upward needing to list them by multiple names anywhere y'all want to give them permissions, such as in /etc/exports files.

8.ten.4.3 Revealing likewise much information to attackers

Another problem you lot may meet when supporting DNS with a firewall is that it may reveal information that you lot don't want revealed. Some organizations view internal hostnames (besides equally other data about internal hosts) equally confidential data. They want to protect these host names much as they do their internal phone directories. They're nervous because internal hostnames may reveal project names or other product intelligence, or because these names may reveal the blazon of the hosts (which may make an attack easier). For example, it'due south piece of cake to guess what kind of arrangement something is if its name is "lab-sun" or "cisco-gw".

Even the simplest hostname information can be helpful to an attacker who wants to barefaced his style into your site, physically or electronically. Using information in this way is an example of what is ordinarily called a social engineering attack. The attacker beginning examines the DNS information to make up one's mind the name of a key host or hosts at your site. Such hosts volition often exist listed as DNS servers for the domain, or equally MX gateways for lots of other hosts. Next, the assaulter calls or visits your site, posing as a service technician, and says he needs to piece of work on these hosts. He'll ask for the passwords for the hosts (if he calls on the telephone), or ask to be shown to the car room (if he visits the site). Considering the attacker seems legitimate, and seems to have inside information about the site - later on all, he knows the names of your central hosts - he'll oft gain access. Social engineering attacks similar this takes a lot of brazenness on the role of the aggressor, particularly if he really visits your site, but yous'd be amazed at how oftentimes such attacks succeed.

Besides internal hostnames, other information is often placed inside the DNS; information which is useful locally, but which you lot'd really rather an attacker not accept access to. DNS HINFO and TXT resource records are particularly revealing:

HINFO: Host data records: These name the hardware and operating system release that a machine is running: it's very useful data for system and network administrators, but also tells an attacker exactly which list of bugs to endeavour on that machine.
TXT: Textual information records: These are essentially short unformatted text records used by a variety of different services to provide various information. For case, some versions of Kerberos and related tools employ these records to store information that, at some other site, might be handled by NIS/YP.

Attackers will ofttimes obtain DNS information about your site wholesale by contacting your DNS server and asking for a zone transfer, as if they were a secondary server for your site. You can either prevent this with packet filtering (by blocking TCP-based DNS queries, which volition unfortunately block more than just zone transfers) or through the xfernets directive of current implementations of Demark (come across the Bind documentation for more information).

The question to keep in mind when because what DNS data to reveal is, "Why give attackers any more than data than necessary?" The following sections provide some suggestions to aid you reveal only the data you want people to have.

8.ten.5 Setting Up DNS to Hibernate Information

We've mentioned that DNS has a query-forwarding capability.[38] By taking reward of this capability, y'all tin can give internal hosts an unrestricted view of both internal and external DNS data, while restricting external hosts to a very limited ("sanitized") view of internal DNS information. Y'all might desire to do this for such reasons as:

[38] Cricket Liu has pointed out that the strategies described in this section practice not piece of work for subdomains. If you are using subdomains, refer to http://www.greatcircle.com/firewalls-book/errata.html or to the second edition of DNS and Demark .

Because your internal DNS information is too sensitive to evidence to everybody.
Considering you know that your internal DNS servers don't all work perfectly and you want a better-maintained view for the outside world.
Because y'all desire to give certain information to external hosts and dissimilar information to internal hosts (for example, you want internal hosts to send mail directly to internal machines, simply external hosts to run across an MX record directing the postal service to a bastion host).

Figure 8.15 shows how to ready DNS to hibernate information; the following sections describe all the details.

Figure 8.15: A firewall tin can be used to hide DNS data

Figure 8.15

8.10.5.one Set up upward a `fake' DNS server on the bastion host for the outside world to utilise

The first step in hiding DNS data from the external world is to set up a fake DNS server on a bastion host. This server claims to exist authoritative for your domain. Go far the server for your domain that is named by the Name Server records maintained by your parent domain. If you accept multiple such servers for the exterior world to talk to (which you should - some or all of the rest may belong to your service provider), brand your false server the primary server of the set of administrative servers; make the others secondaries of this master server.

As far as this fake server on the bastion host is aware, it knows everything about your domain. In fact, though, all information technology knows about is whatever information you want revealed to the outside world. This information typically includes only basic hostname and IP accost information near the following hosts:

The machines on your perimeter network (i.e., the machines that make up your firewall).
Any machines that somebody in the exterior globe needs to be able to contact directly. I example of such a machine is an internal Usenet news (NNTP) server that is reachable from your service provider. (Come across the department on NNTP elsewhere in this chapter for an example of why you might want to allow this.) Another example is any host reachable over the Internet from trusted affiliates. External machines need an externally visible name for such an internal machine; it need not be the internal machine'due south real name, even so, if you feel that the existent name is somehow sensitive information, or you lot just want to exist able to change it on a whim.

In addition, you'll demand to publish MX records for whatsoever host or domain names that are used as office of email addresses in email letters and Usenet news postings, so that people can respond to these messages. Continue in heed that people may answer to messages days, weeks, months, or fifty-fifty years after they were sent. If a given host or domain name has been widely used as part of an email accost, you may need to preserve an MX record for that host or domain forever, or at to the lowest degree until well later on it's dead and gone, so that people can all the same reply to old messages. If information technology has appeared in impress, "forever" may exist all also accurate; sites all the same receive electronic mail for machines decommissioned five and x years ago.

You will also need to publish faux information for whatever machines that tin contact the outside earth straight. Many servers on the Cyberspace (for example, most major anonymous FTP servers) insist on knowing the hostname (non merely the IP address) of whatsoever machines that contact them, fifty-fifty if they do nothing with the hostname but log it. In the DNS resource records, A (name-to-address mapping) records and PTR (address-to-proper name mapping) records handle lookups for names and addresses.

Every bit we've mentioned earlier, machines that have IP addresses and need hostnames do reverse lookups. With a contrary lookup, the server starts with the remote IP address of the incoming connexion, and looks up the hostname that the connection is coming from. It takes the IP address (for example, 172.sixteen.19.67), permutes it in a particular style (reverses the parts and adds .IN-ADDR.ARPA to become 67.19.16.172.IN-ADDR.ARPA, and looks up a PTR tape for that name. The PTR tape should return the hostname for the host with that address (e.k., mycroft.somewhere.internet), which the server so uses for its logs or whatever.

How tin you deal with these reverse lookups? If all these servers wanted was a name to log, you could just create a wildcard PTR record. That tape would indicate that a whole range of addresses belongs to an unknown host in a particular domain. For example, y'all might have a lookup for *.19.16.172.IN-ADDR.ARPA return unknown.somewhere.net). Returning this information would be fairly helpful; it would at least tell the server administrator whose machine it was (somewhere.net'due south). Anyone who had a problem with the automobile could pursue it through the published contacts for the somewhere.internet domain.

There is a trouble with doing merely this, nevertheless. In an effort to validate the data returned past the DNS, more than and more servers (specially anonymous FTP servers) are now doing a double-reverse lookup, and won't talk to you unless the double-reverse lookup succeeds. This is the same kind of lookup we mentioned to a higher place; it's certainly necessary for people who provide a service where they demand any degree of authentication of the requesting host. Whether or not anonymous FTP is such a service is another question. Some people believe that one time y'all put a file up for anonymous FTP, you no longer take reason to try to cosign hosts; after all, you're trying to give information away. People running anonymous FTP servers that do double-reverse lookup argue that people who want services have a responsibility to exist members of the network community and that requires being identifiable. Whichever side of the argument you're on, it is certainly truthful that the maintainers of several of the largest and best-known anonymous FTP servers are on the side that favors double-reverse lookup, and will not provide service to you unless double-opposite lookup succeeds.

In a double-reverse lookup, a DNS client:

Performs a reverse lookup to translate an IP address to a hostname.
Does a regular lookup on that hostname to determine its nominal IP address.
Compares this nominal IP address to the original IP address.

Your false server needs to provide consistent false data for all hosts in your domain whose IP addresses are going to be seen by the outside world. For every IP accost you own, the simulated server must publish a PTR record with a fake hostname, as well as a respective A record that maps the false hostname back to the IP accost. For example, for address 172.16.i.2, you might publish a PTR record with the name host-172-16-one-2.somewhere.net and a corresponding A tape which maps host-172-16-ane-2.somewhere.net back to the corresponding IP address (172.sixteen.ane.2). When you connect to some remote system that attempts to practise a contrary lookup of your IP address (e.g., 172.16.1.ii) to determine your hostname, that organization will get dorsum the fake hostname (due east.1000., host-172-16-1-2). If the system then attempts to do a double-contrary lookup to translate that hostname to an IP address, information technology will become back 172.sixteen.1.2, which matches the original IP accost and satisfies the consistency check.

If you are strictly using proxying to connect internal hosts to the external world, y'all don't need to prepare the fake information for your internal hosts; you simply need to put up information for the host or hosts running the proxy server. The external world will come across only the proxy server'southward address. For a large network, this by itself may make using proxy service for FTP worthwhile.

eight.10.five.2 Gear up upwards a real DNS server on an internal system for internal hosts to apply

Your internal machines need to use the real DNS information about your hosts, not the fake data presented to the outside world. You do this through a standard DNS server setup on some internal system. Your internal machines may too want to find out near external machines, though, e.thousand., to translate the hostname of a remote anonymous FTP site to an IP address.

I way to achieve this is to provide admission to external DNS information by configuring your internal DNS server to query remote DNS servers directly, equally appropriate, to resolve queries from internal clients about external hosts. Such a configuration, however, would crave opening your bundle filtering to let your internal DNS server to talk to these remote DNS servers (which might exist on any host on the Internet). This is a problem considering DNS is UDP-based, and as nosotros talk over in Affiliate half-dozen, you need to block UDP birthday in order to block outside access to vulnerable RPC-based services like NFS and NIS/YP.

Fortunately, the near common DNS server (the UNIX named program) provides a solution to this dilemma: the forwarders directive in the /etc/named.boot server configuration file. The forwarders directive tells the server that, if it doesn't know the data itself already (either from its own zone information or from its cache), information technology should frontwards the query to a specific server and let this other server effigy out the respond, rather than attempt to contact servers all over the Internet in an attempt to determine the answer itself. In the /etc/named.kicking configuration file, you fix up the forwarders line to bespeak to the false server on the breastwork host; the file also needs to incorporate a "slave" line, to tell information technology to only apply the servers on the forwarders line, even if the forwarders are irksome in answering.

The use of the forwarders mechanism doesn't actually have annihilation to do with hiding the information in the internal DNS server; it has everything to practise with making the packet filtering every bit strict as possible (i.e., applying the principle of least privilege), by making information technology so that the internal DNS server demand only be able to talk to the bastion host DNS server, not to DNS servers throughout the whole Internet.

If internal hosts can't contact external hosts, you may not want to bother setting things up so that they can resolve external host names. SOCKS proxy clients can be gear up upwards to use the external name server directly. This simplifies your name service configuration somewhat, but information technology complicates your proxying configuration, and some users may desire to resolve hostnames even though they can't achieve them (for example, they may be interested in knowing whether the hostname in an email address is valid).

Figure 8.sixteen shows how DNS works with forwarding; Figure 8.17 shows how it works without forwarding.

Figure 8.16: DNS with forwarding

Figure 8.16

Effigy viii.17: DNS without forwarding

Figure 8.17

viii.10.5.3 Internal DNS clients query the internal server

The next step is to configure your internal DNS clients to ask all their queries of the internal server. On UNIX systems, you do this through the /etc/resolv.conf file. There are two cases:

When the internal server receives a query about an internal system, or about an external arrangement which is in its cache, it answers directly and immediately because information technology already knows the answers to such queries.
When the internal server receives a query well-nigh an external organization that isn't in its enshroud, the internal server forrad this query to the bastion host server (considering of the forwarders line described above). The breastwork host server obtains the respond from the appropriate DNS servers on the Internet and relays the respond back to the internal server. The internal server and so answers the original client and caches the answer.

In either example, as far as the client is concerned, it asked a question of the internal server and got an answer from the internal server. The client doesn't know whether the internal server already knew the answer or had to obtain the answer from other servers (indirectly, via the breastwork server). Therefore, the /etc/resolv.conf file will look perfectly standard on internal clients.

8.10.5.4 Bastion DNS clients too query the internal server

The key to this whole information-hiding configuration is that DNS clients on the bastion host must query the internal server for information, not the server on the breastwork host. This way, DNS clients on the bastion host (such as Sendmail, for case) can use the real hostnames and so on for internal hosts, but clients in the outside world can't access the internal data.

DNS server and client configurations are completely carve up. Many people assume that they must accept configuration files in common, that the clients will automatically know near the local server, and that pointing them elsewhere will also bespeak the server elsewhere. In fact, there is no overlap. Clients never read /etc/named.boot, which tells the server what to practice, and the server never reads /etc/resolv.conf, which tells the clients what to practice.

Again, there are two cases:

When a DNS client on the breastwork host asks nearly an internal system, it gets the real answer directly from the internal server.
When a DNS customer on the bastion host asks about an external organisation, the internal DNS server forwards the query to the bastion DNS server. The bastion server obtains the answer from the appropriate DNS servers on the Internet, and so relays the answer back to the internal server. The internal server, in turn, answers the original customer on the bastion host.

DNS clients on the bastion host could obtain information well-nigh external hosts more directly by asking the DNS server on the breastwork host instead of the i on the internal host. However, if they did that, they'd be unable to get the "existent" internal information, which only the server on the internal host has. They're going to need that information, because they're talking to the internal hosts likewise equally the external hosts.

eight.x.5.v What your packet filtering system needs to allow

In society for this DNS forwarding scheme to work, whatever packet filtering organisation between the bastion host and the internal systems has to allow all of the following (see the table below for details):

DNS queries from the internal server to the bastion host server: UDP packets from port 53 on the internal server to port 53 on the bastion host (rule A), and TCP packets from ports above 1023 on the internal server to port 53 on the bastion host (rule B).
Responses to those queries from the breastwork host to the internal server: UDP packets from port 53 on the bastion host to port 53 on the internal server (rule C), and TCP packets with the ACK bit gear up from port 53 on the bastion host to ports above 1023 on the internal server (rule D).
DNS queries from the breastwork host DNS clients to the internal server: UDP and TCP packets from ports above 1023 on the bastion host to port 53 on the internal server (rules Due east and F).
Responses from the internal server to those bastion host DNS clients: UDP packets and TCP packets with the ACK bit set from port 53 on the internal server to ports above 1023 on the bastion host (Rules Grand and H).

	Direc-	Source	Dest.	Pro-	Source	Dest.	ACK
Rule	tion	Addr.	Addr.	tocol	Port	Port	Set	Activity
A	Out	Internal Server	Bastion Host	UDP	53	53	[39]	Permit
B	Out	Internal Server	Bastion Host	TCP	>1023	53	Any	Permit
C	In	Bastion Host	Internal Server	UDP	53	53	[39]	Permit
D	In	Bastion Host	Internal Server	TCP	53	>1023	Aye	Permit
E	In	Bastion Host	Internal Server	UDP	>1023	53	[39]	Permit
F	In	Bastion Host	Internal Server	TCP	>1023	53	Any	Permit
G	Out	Internal Server	Bastion Host	UDP	53	>1023	[39]	Permit
H	Out	Internal Server	Bastion Host	TCP	53	>1023	Yes	Permit

[39] UDP packets do non have ACK $.25.

eight.10.half dozen Setting up DNS Without Hiding Information

The arroyo we've described above is not the only option. Suppose that yous don't feel it'due south necessary to hide your internal DNS data from the globe. In this case, your DNS configuration is similar to the one we've described to a higher place, but it'due south somewhat simpler. Effigy 8.18 shows how DNS works without information hiding.

Figure 8.18: DNS without information hiding

Figure 8.18

With this alternate arroyo, you should still take a bastion host DNS server and an internal DNS server; however, one of these tin can be a secondary server of the other. Generally, it's easier to make the bastion DNS server a secondary of the internal DNS server, and to maintain your DNS data on the internal server. You should still configure the internal DNS server to forrard queries to the bastion host DNS server, but the bastion host DNS clients can be configured to query the bastion host server instead of the internal server.

You need to configure any packet filtering system betwixt the bastion host and the internal server to allow the following (meet the table beneath for details):

DNS queries from the internal DNS server to the bastion DNS server: UDP packets from port 53 on the internal server to port 53 on the bastion host (rule A) and TCP packets from ports above 1023 on the internal server to port 53 on the breastwork host (rule B).
Responses from the bastion DNS server to the internal DNS server: UDP packets from port 53 on the breastwork host to port 53 on the internal server (dominion C) and TCP packets with the ACK bit ready from port 53 on the bastion host to ports above 1023 on the internal server (rule D).

If the breastwork host is also a DNS secondary server and the internal host is the corresponding DNS primary server, you lot also accept to permit the following:

DNS queries from the breastwork host DNS server to the internal DNS server: UDP packets from port 53 on the breastwork host to port 53 on the internal server (note that this is the aforementioned as rule C), and TCP packets from ports above 1023 on the bastion host to port 53 on the internal server (rule E).
Responses from the internal DNS server back to the bastion DNS server: UDP packets from port 53 on the internal server to port 53 on the breastwork host (note that this is the same every bit rule A), and TCP packets with the ACK bit fix from port 53 on the internal server to ports above 1023 on the breastwork host (dominion F).
DNS zone transfer requests from the bastion host to the internal server: TCP packets from ports to a higher place 1023 on the breastwork host to port 53 on the internal server (note that this is the aforementioned every bit rule E).
DNS zone transfer responses from the internal server to the breastwork host: TCP packets with the ACK scrap set up from port 53 on the internal server to ports above 1023 on the bastion host (note that this is the aforementioned as rule F).

	Direc-	Source	Dest.	Pro-	Source	Dest.	ACK
Rule	tion	Addr.	Addr.	tocol	Port	Port	Set	Action
A	Out	Internal Server	Bastion Host	UDP	53	53	[xl]	Permit
B	Out	Internal Server	Breastwork Host	TCP	>1023	53	Whatsoever	Permit
C	In	Bastion Host	Internal Server	UDP	53	53	[40]	Permit
D	In	Bastion Host	Internal Server	TCP	53	>1023	Yep	Allow
Due east	In	Bastion Host	Internal Server	TCP	>1023	53	Whatsoever	Permit
F	Out	Internal Server	Bastion Host	TCP	53	>1023	Yes	Let

[forty] UDP packets do not have ACK bits.

8.10.vii Summary of DNS Recommendations

Prepare an external DNS server on a bastion host for the exterior world to access.
Do not brand HINFO records visible to the outside earth; either don't use them, or configure DNS for information hiding as described to a higher place.
Use an up-to-engagement Demark implementation and double-reverse lookups to avoid spoofing.
Consider hiding all internal DNS data and using forwarding and fake records; this doesn't make sense for all sites, only information technology might for yours.
Disable zone transfers to anyone but your secondaries, using bundle filtering or the xfernets directive. Even if you've chosen non to hibernate your DNS data, there'due south probably no valid reason for anyone but your secondaries to do a zone transfer, and disallowing zone transfers makes life a bit harder for attackers.