serve the root zone with bind and utilize RPZ

Question

I have some problems with configuring BIND as my private server at root zone.

I have tried the dot "." (had read somewhere) and an empty string "" (my bad guess) as for the root zone identifier (which both have syntax errors)

zone "." { ; sorry 
    ... 
};

also

zone "" { ;sorry 
    ... 
};

Do you have any hint how to server the root zone?

(My Note: Serving the root zone might possibly be different from being a root-server!)

Update

The problem actually lies within the response policy zone at root ("."):

options {
    #response-policy {zone "com"; }; #it is OK (before commenting)
    response-policy {zone "."; }; #it makes error when loading the config
};  


zone "."{
    type master; 
    file "db/zone.root.db"; 
};

zone "com"{ #just for syntax test/check
    type master; 
    file "db/zone.root.db"; 
};

named-checkconf -zj named.conf

  zone ./IN: NS 'LOCALHOST' has no address records (A or AAAA)
  zone ./IN: not loaded due to errors.
  _default/./IN: bad zone
  zone com/IN: loaded serial 1

NOTE: In both configurations : the one that the service loads and the other that terminates, the output is the same

dig www.google.com @127.0.0.1

01     ; <<>> DiG 9.10.4-P2 <<>> www.google.com @127.0.0.1
02     ;; global options: +cmd
03     ;; Got answer:
04     ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58406
05     ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 1
06     
07     ;; OPT PSEUDOSECTION:
08     ; EDNS: version: 0, flags:; udp: 4096
09     ;; QUESTION SECTION:
10     ;www.google.com.                        IN      A
11     
12     ;; ANSWER SECTION:
13     www.google.com.         5       IN      CNAME   nosslsearch.google.com.rpz.zone.
14     nosslsearch.google.com.rpz.zone. 3600 IN A      216.239.32.20
15     
16     ;; AUTHORITY SECTION:
17     rpz.zone.               3600    IN      NS      LOCALHOST.
18     
19     ;; Query time: 44 msec
20     ;; SERVER: 127.0.0.1#53(127.0.0.1)
21     ;; WHEN: Mon Aug 01 17:07:14 Daylight Time 2016
22     ;; MSG SIZE  rcvd: 127

Note : See Line 13 and the trailing ".rpz.zone."

nslookup

01     > server 127.0.0.1
02     Default server: 127.0.0.1
03     Address: 127.0.0.1#53
04     > www.google.com
05     Server:         127.0.0.1
06     Address:        127.0.0.1#53
07     
08     Non-authoritative answer:
09     www.google.com  canonical name = nosslsearch.google.com.rpz.zone.
10     Name:   nosslsearch.google.com.rpz.zone
11     Address: 216.239.32.20

ping www.google.com -n 1

1     Pinging nosslsearch.google.com.rpz.zone [216.239.32.20] with 32 bytes of data:
2     Reply from 216.239.32.20: bytes=32 time=149ms TTL=45
3     
4     Ping statistics for 216.239.32.20:
5         Packets: Sent = 1, Received = 1, Lost = 0 (0% loss),
6     Approximate round trip times in milli-seconds:
7         Minimum = 149ms, Maximum = 149ms, Average = 149ms

Summary of above output snippets: the rpz.zone gets added everywhere, that's why I thought of moving to root area.

And this is my

zone.root.db file

01     $TTL 1H
02     @                       SOA LOCALHOST. named-mgr.example.com (1 1h 15m 30d 2h)
03                             NS  LOCALHOST.
04     
05     nosslsearch.google.com       A     216.239.32.20
06     google.com                   CNAME nosslsearch.google.com
07     www.google.com               CNAME nosslsearch.google.com
08

I just want to get rid of the rp.zone being appended to the responses!, how?

What problem are you trying to solve by having a root zone? They were previously used as a poor man's [tag:dns-firewall], but RPZ is a better solution for that in modern versions of BIND. There are a few advanced use cases where they are still applicable but few for inexperienced admins. — Andrew B, Jul 27 '16 at 06:53
The first zone declaration does work (provided it's put in a valid location and the bit you replaced with `...` is valid). What specifically is the error? — Håkan Lindqvist, Jul 27 '16 at 07:16
Well, I guess I should say, provided the `; sorry` bit is not actually there. `;` is not the comment character in the config file. — Håkan Lindqvist, Jul 27 '16 at 07:29
@AndrewB : Well, yes, I wanted it to work in conjunction with RPZ. So that I could manage the policies in a single file. And of course without an 'rpz.zone' being added to responses (only just a dot, by being at root) — F.I.V, Aug 01 '16 at 10:34
@HåkanLindqvist: Well, I was sure that it should work (as I mentioned, I have read it also on other pages....), So, I am going to retry to see if there was other issues in the configuration preventing this "." zone to load. — F.I.V, Aug 01 '16 at 10:36
@F.I.V You may want to include log output or `named-checkconf -zj` output — Håkan Lindqvist, Aug 01 '16 at 10:52
@HåkanLindqvist: You are absolutely right, I updated to add the tested configuration. The zone "." works, but referencing it from the response-policy section makes the trouble (The service crashes at startup). The output of checkconf is the same in case of both configuration files — F.I.V, Aug 01 '16 at 11:59
@F.I.V Why would you name an RPZ zone "."? The RPZ zone name is not really relevant to its operation (it's not a normal zone anyway, it being a zone at all is just a way of taking advantage of existing mechanisms for how to load/sync the RPZ data, the special RPZ semantics make it behave differently anyway). — Håkan Lindqvist, Aug 01 '16 at 12:04
@HåkanLindqvist : The problem is that it gets added to the policy-overrriden-response. for example if I choose zone "rpz.zone" in both the policy and zone sections, then the overridden IP for host1.example.com works but it is replied with host1.example.com.rpz.zone! — F.I.V, Aug 01 '16 at 12:25
@F.i.V Just to confirm, what you just described as "I tried it this way and it didn't work" is the expected setup. — Håkan Lindqvist, Aug 01 '16 at 12:40
Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/43300/discussion-between-f-i-v-and-hakan-lindqvist). — F.I.V, Aug 01 '16 at 12:52

score 2 · Accepted Answer · answered Aug 01 '16 at 13:16

RPZ zones have special semantics defined, such that the name of the zone is not actually relevant to its operation.
In fact, the name should be chosen not to conflict with actual zones. RPZ data being loaded from a zone at all is just a way to make use of existing zone loading/synchronization mechanisms.

So you would not want to name the RPZ zone . or com or anything like that. However, as it is loaded as a zone, the regular master file specs do apply to how the contents are interpreted.

eg for a zone named example, the following

www.google.com CNAME nosslsearch.google.com

means

www.google.com.example. CNAME nosslsearch.google.com.example.

(unless explicitly overriding $ORIGIN)

While RPZ defines the owner name (left-most column) in a way so that when matching by query-name it auto-appends the RPZ zone name,

QNAME

QNAME policy records are triggered by query names of requests and targets of CNAME records resolved to generate the response. The owner name of a QNAME policy record is the query name relativized to the policy zone.

the CNAME record data (right-hand-side) is used as-is for cases where you are supplying local data. (Ie, when the CNAME data is not one of the special cases cases defined in RPZ, such as rpz-drop., ., *., etc)

Local Data

A set of ordinary DNS records can be used to answer queries. Queries for record types not the set are answered with NODATA.

A special form of local data is a CNAME whose target is a wildcard such as *.example.com. It is used as if were an ordinary CNAME after the astrisk (*) has been replaced with the query name. The purpose for this special form is query logging in the walled garden's authority DNS server.

Long story short, you would want something like this instead:

www.google.com CNAME nosslsearch.google.com.

Thanks a lot for the full explanations . And the last line was the cure. Adding the trailing dot "." did the magic! — F.I.V, Aug 01 '16 at 13:23

serve the root zone with bind and utilize RPZ

1 Answers1