]>
Commit | Line | Data |
---|---|---|
0e2063c3 PL |
1 | Dynamic DNS Update (RFC2136) |
2 | ============================ | |
3 | ||
4 | Starting with the PowerDNS Authoritative Server 3.4.0, DNS update | |
5 | support is available. There are a number of items NOT supported: | |
6 | ||
7 | - There is no support for GSS\*TSIG and SIG (TSIG is supported); | |
8 | - WKS records are specifically mentioned in the RFC, we don't | |
9 | specifically care about WKS records; | |
10 | - Anything we forgot.... | |
11 | ||
12 | The implementation requires the backend to support a number of new | |
13 | operations. Currently, the following backends have been modified to | |
14 | support DNS update: | |
15 | ||
16 | - :doc:`gmysql <backends/generic-mysql>` | |
17 | - :doc:`gpgsql <backends/generic-postgresql>` | |
18 | - :doc:`gsqlite3 <backends/generic-sqlite3>` | |
0e2063c3 PL |
19 | - :doc:`godbc <backends/generic-odbc>` |
20 | ||
21 | .. _dnsupdate-configuration-options: | |
22 | ||
23 | Configuration options | |
24 | --------------------- | |
25 | ||
26 | There are two configuration parameters that can be used within the | |
27 | powerdns configuration file. | |
28 | ||
29 | ``dnsupdate`` | |
30 | ~~~~~~~~~~~~~ | |
31 | ||
32 | A setting to enable/disable DNS update support completely. The default | |
33 | is no, which means that DNS updates are ignored by PowerDNS (no message | |
34 | is logged about this!). Change the setting to ``dnsupdate=yes`` to | |
35 | enable DNS update support. Default is ``no``. | |
36 | ||
37 | ``allow-dnsupdate-from`` | |
38 | ~~~~~~~~~~~~~~~~~~~~~~~~ | |
39 | ||
40 | A list of IP ranges that are allowed to perform updates on any domain. | |
96c7fbd2 | 41 | The default is ``127.0.0.0/8``, which means that all loopback addresses are accepted. |
0e2063c3 PL |
42 | Multiple entries can be used on this line |
43 | (``allow-dnsupdate-from=198.51.100.0/8 203.0.113.2/32``). The option can | |
44 | be left empty to disallow everything, this then should be used in | |
45 | combination with the ``ALLOW-DNSUPDATE-FROM`` :doc:`domain metadata <domainmetadata>` setting per | |
dd1928e9 JM |
46 | zone. Setting a range here and in ``ALLOW-DNSUPDATE-FROM`` enables updates |
47 | from either address range. | |
0e2063c3 PL |
48 | |
49 | ``forward-dnsupdate`` | |
50 | ~~~~~~~~~~~~~~~~~~~~~ | |
51 | ||
52 | Tell PowerDNS to forward to the master server if the zone is configured | |
53 | as slave. Masters are determined by the masters field in the domains | |
54 | table. The default behaviour is enabled (yes), which means that it will | |
55 | try to forward. In the processing of the update packet, the | |
56 | ``allow-dnsupdate-from`` and ``TSIG-ALLOW-DNSUPDATE`` are processed | |
57 | first, so those permissions apply before the ``forward-dnsupdate`` is | |
58 | used. It will try all masters that you have configured until one is | |
59 | successful. | |
60 | ||
61 | .. _dnsupdate-lua-dnsupdate-policy-script: | |
62 | ||
63 | ``lua-dnsupdate-policy-script`` | |
64 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
65 | ||
66 | Use this Lua script containing function ``updatepolicy`` to validate | |
67 | each update. This will ``TURN OFF`` all other | |
68 | authorization methods, and you are expected to take care of everything | |
69 | yourself. See :ref:`dnsupdate-update-policy` for details and | |
70 | examples. | |
71 | ||
72 | The semantics are that first a dynamic update has to be allowed either | |
73 | by the global :ref:`setting-allow-dnsupdate-from` setting, or by a per-zone | |
74 | ``ALLOW-DNSUPDATE-FROM`` metadata setting. | |
75 | ||
76 | Secondly, if a zone has a ``TSIG-ALLOW-DNSUPDATE`` metadata setting, that | |
77 | must match too. | |
78 | ||
79 | So to only allow dynamic DNS updates to a zone based on TSIG key, and | |
80 | regardless of IP address, set :ref:`setting-allow-dnsupdate-from` to empty, set | |
81 | ``ALLOW-DNSUPDATE-FROM`` to "0.0.0.0/0" and "::/0" and set the | |
82 | ``TSIG-ALLOW-DNSUPDATE`` to the proper key name. | |
83 | ||
84 | Further information can be found :ref:`below <dnsupdate-how-it-works>`. | |
85 | ||
86 | .. _dnsupdate-metadata: | |
87 | ||
88 | Per zone settings | |
89 | ----------------- | |
90 | ||
91 | For permissions, a number of per zone settings are available via the | |
a771f67f | 92 | :doc:`domain metadata <domainmetadata>`. |
0e2063c3 | 93 | |
690bd03e PL |
94 | .. _metadata-allow-dnsupdate-from: |
95 | ||
0e2063c3 PL |
96 | ALLOW-DNSUPDATE-FROM |
97 | ~~~~~~~~~~~~~~~~~~~~ | |
98 | ||
99 | This setting has the same function as described in the configuration | |
9e461099 | 100 | options (See :ref:`above <dnsupdate-configuration-options>`). Only one item is |
0e2063c3 PL |
101 | allowed per row, but multiple rows can be added. An example: |
102 | ||
103 | :: | |
104 | ||
105 | sql> select id from domains where name='example.org'; | |
106 | 5 | |
107 | sql> insert into domainmetadata(domain_id, kind, content) values(5, ‘ALLOW-DNSUPDATE-FROM’,’198.51.100.0/8’); | |
108 | sql> insert into domainmetadata(domain_id, kind, content) values(5, ‘ALLOW-DNSUPDATE-FROM’,’203.0.113.2/32’); | |
109 | ||
110 | This will allow 198.51.100.0/8 and 203.0.113.2/32 to send DNS update | |
111 | messages for the example.org domain. | |
112 | ||
690bd03e PL |
113 | .. _metadata-tsig-allow-dnsupdate: |
114 | ||
0e2063c3 PL |
115 | TSIG-ALLOW-DNSUPDATE |
116 | ~~~~~~~~~~~~~~~~~~~~ | |
117 | ||
118 | This setting allows you to set the TSIG key required to do an DNS | |
119 | update. If you have GSS-TSIG enabled, you can use Kerberos principals | |
7e7c085a | 120 | here. An example, using :program:`pdnsutil` to create the key: |
0e2063c3 | 121 | |
633489be | 122 | .. code-block:: shell |
0e2063c3 | 123 | |
633489be | 124 | $ pdnsutil generate-tsig-key test hmac-md5 |
7e7c085a | 125 | Create new TSIG key test hmac-md5 kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys= |
633489be GD |
126 | |
127 | :: | |
128 | ||
0e2063c3 PL |
129 | sql> insert into tsigkeys (name, algorithm, secret) values ('test', 'hmac-md5', 'kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys='); |
130 | sql> select id from domains where name='example.org'; | |
131 | 5 | |
132 | sql> insert into domainmetadata (domain_id, kind, content) values (5, 'TSIG-ALLOW-DNSUPDATE', 'test'); | |
133 | ||
633489be | 134 | An example of how to use a TSIG key with the :program:`nsupdate` command:: |
0e2063c3 PL |
135 | |
136 | nsupdate <<! | |
137 | server <ip> <port> | |
138 | zone example.org | |
139 | update add test1.example.org 3600 A 203.0.113.1 | |
140 | key test kp4/24gyYsEzbuTVJRUMoqGFmN3LYgVDzJ/3oRSP7ys= | |
141 | send | |
142 | ! | |
143 | ||
144 | If a TSIG key is set for the domain, it is required to be used for the | |
7a5bad63 JM |
145 | update. The TSIG is an alternative means of securing updates, instead of using the |
146 | ``ALLOW-DNSUPDATE-FROM`` setting. If a TSIG key is set, and if ``ALLOW-DNSUPDATE-FROM`` is set, | |
147 | the IP(-range) of the updater still needs to be allowed via ``ALLOW-DNSUPDATE-FROM``. | |
0e2063c3 | 148 | |
690bd03e PL |
149 | .. _metadata-forward-dnsupdate: |
150 | ||
0e2063c3 PL |
151 | FORWARD-DNSUPDATE |
152 | ~~~~~~~~~~~~~~~~~ | |
153 | ||
4e031caf | 154 | See :ref:`Configuration options <dnsupdate-configuration-options>` for what it does, |
0e2063c3 PL |
155 | but per domain. |
156 | ||
157 | :: | |
158 | ||
159 | sql> select id from domains where name='example.org'; | |
160 | 5 | |
161 | sql> insert into domainmetadata(domain_id, kind, content) values(5, ‘FORWARD-DNSUPDATE’,’’); | |
162 | ||
163 | There is no content, the existence of the entry enables the forwarding. | |
164 | This domain-specific setting is only useful when the configuration | |
165 | option :ref:`setting-forward-dnsupdate` is set to 'no', as that will disable it | |
166 | globally. Using the domainmetadata setting than allows you to enable it | |
167 | per domain. | |
168 | ||
690bd03e PL |
169 | .. _metadata-notify-dnsupdate: |
170 | ||
0e2063c3 PL |
171 | NOTIFY-DNSUPDATE |
172 | ~~~~~~~~~~~~~~~~ | |
173 | ||
174 | Send a notification to all slave servers after every update. This will | |
175 | speed up the propagation of changes and is very useful for acme | |
176 | verification. | |
177 | ||
178 | :: | |
179 | ||
180 | sql> select id from domains where name='example.org'; | |
181 | 5 | |
182 | sql> insert into domainmetadata(domain_id, kind, content) values(5, ‘NOTIFY-DNSUPDATE’,’1’); | |
183 | ||
cd46fc6c PL |
184 | .. _metadata-soa-edit-dnsupdate: |
185 | ||
0e2063c3 PL |
186 | SOA-EDIT-DNSUPDATE |
187 | ~~~~~~~~~~~~~~~~~~ | |
188 | ||
189 | This configures how the soa serial should be updated. See | |
190 | :ref:`below <dnsupdate-soa-serial-updates>`. | |
191 | ||
192 | .. _dnsupdate-soa-serial-updates: | |
193 | ||
194 | SOA Serial Updates | |
195 | ------------------ | |
196 | ||
197 | After every update, the soa serial is updated as this is required by | |
198 | section 3.7 of :rfc:`2136`. The behaviour is configurable via domainmetadata | |
199 | with the ``SOA-EDIT-DNSUPDATE`` option. It has a number of options listed | |
200 | below. If no behaviour is specified, DEFAULT is used. | |
201 | ||
202 | :rfc:`2136, Section 3.6 <2136#section-3.6>` defines some specific behaviour for updates of SOA | |
203 | records. Whenever the SOA record is updated via the update message, the | |
204 | logic to change the SOA is not executed. | |
205 | ||
206 | .. note:: | |
207 | Powerdns will always use :ref:`metadata-soa-edit` when serving SOA | |
208 | records, thus a query for the SOA record of the recently update domain, | |
209 | might have an unexpected result due to a SOA-EDIT setting. | |
210 | ||
211 | An example: | |
212 | ||
213 | :: | |
214 | ||
215 | sql> select id from domains where name='example.org'; | |
216 | 5 | |
217 | sql> insert into domainmetadata(domain_id, kind, content) values(5, ‘SOA-EDIT-DNSUPDATE’,’INCREASE’); | |
218 | ||
219 | This will make the SOA Serial increase by one, for every successful | |
220 | update. | |
221 | ||
222 | SOA-EDIT-DNSUPDATE settings | |
223 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~ | |
224 | ||
225 | These are the settings available for **SOA-EDIT-DNSUPDATE**. | |
226 | ||
227 | - DEFAULT: Generate a soa serial of YYYYMMDD01. If the current serial | |
228 | is lower than the generated serial, use the generated serial. If the | |
229 | current serial is higher or equal to the generated serial, increase | |
230 | the current serial by 1. | |
231 | - INCREASE: Increase the current serial by 1. | |
232 | - EPOCH: Change the serial to the number of seconds since the EPOCH, | |
233 | aka unixtime. | |
234 | - SOA-EDIT: Change the serial to whatever SOA-EDIT would provide. See | |
6def4610 | 235 | :doc:`Domain metadata <domainmetadata>` |
0e2063c3 PL |
236 | - SOA-EDIT-INCREASE: Change the serial to whatever SOA-EDIT would |
237 | provide. If what SOA-EDIT provides is lower than the current serial, | |
238 | increase the current serial by 1. | |
98d7e4c8 PD |
239 | Exception: with SOA-EDIT=INCEPTION-EPOCH, the serial is bumped to at |
240 | least the current EPOCH time. | |
0e2063c3 PL |
241 | |
242 | DNS update How-to: Setup dyndns/rfc2136 with dhcpd | |
243 | -------------------------------------------------- | |
244 | ||
245 | DNS update is often used with DHCP to automatically provide a hostname | |
246 | whenever a new IP-address is assigned by the DHCP server. This section | |
247 | describes how you can setup PowerDNS to receive DNS updates from ISC's | |
248 | dhcpd (version 4.1.1-P1). | |
249 | ||
250 | Setting up dhcpd | |
251 | ~~~~~~~~~~~~~~~~ | |
252 | ||
253 | We're going to use a TSIG key for security. We're going to generate a | |
254 | key using the following command: | |
255 | ||
633489be | 256 | .. code-block:: shell |
0e2063c3 PL |
257 | |
258 | dnssec-keygen -a hmac-md5 -b 128 -n USER dhcpdupdate | |
259 | ||
260 | This generates two files (Kdhcpdupdate.*.key and | |
261 | Kdhcpdupdate.*.private). You're interested in the .key file: | |
262 | ||
633489be | 263 | .. code-block:: shell |
0e2063c3 PL |
264 | |
265 | # ls -l Kdhcp* | |
266 | -rw------- 1 root root 53 Aug 26 19:29 Kdhcpdupdate.+157+20493.key | |
267 | -rw------- 1 root root 165 Aug 26 19:29 Kdhcpdupdate.+157+20493.private | |
268 | ||
269 | # cat Kdhcpdupdate.+157+20493.key | |
270 | dhcpdupdate. IN KEY 0 3 157 FYhvwsW1ZtFZqWzsMpqhbg== | |
271 | ||
272 | The important bits are the name of the key (**dhcpdupdate**) and the | |
273 | hash of the key (**FYhvwsW1ZtFZqWzsMpqhbg==** | |
274 | ||
275 | Using the details from the key you've just generated. Add the following | |
276 | to your dhcpd.conf: | |
277 | ||
278 | :: | |
279 | ||
280 | key "dhcpdupdate" { | |
281 | algorithm hmac-md5; | |
282 | secret "FYhvwsW1ZtFZqWzsMpqhbg=="; | |
283 | }; | |
284 | ||
285 | You must also tell dhcpd that you want dynamic dns to work, add the | |
286 | following section: | |
287 | ||
288 | :: | |
289 | ||
290 | ddns-updates on; | |
291 | ddns-update-style interim; | |
292 | update-static-leases on; | |
293 | ||
294 | This tells dhcpd to: | |
295 | ||
296 | 1. Enable Dynamic DNS | |
297 | 2. Which style it must use (interim) | |
298 | 3. Update static leases as well | |
299 | ||
300 | For more information on this, consult the dhcpd.conf manual. | |
301 | ||
302 | Per subnet, you also have to tell **dhcpd** which (reverse-)domain it | |
303 | should update and on which master domain server it is running. | |
304 | ||
305 | :: | |
306 | ||
307 | ddns-domainname "example.org"; | |
308 | ddns-rev-domainname "in-addr.arpa."; | |
309 | ||
310 | zone example.org { | |
311 | primary 127.0.0.1; | |
312 | key dhcpdupdate; | |
313 | } | |
314 | ||
315 | zone 1.168.192.in-addr.arpa. { | |
316 | primary 127.0.0.1; | |
317 | key dhcpdupdate; | |
318 | } | |
319 | ||
320 | This tells **dhcpd** a number of things: | |
321 | ||
322 | 1. Which domain to use (**ddns-domainname "example.org";**) | |
323 | 2. Which reverse-domain to use (**dnssec-rev-domainname | |
324 | "in-addr.arpa.";**) | |
325 | 3. For the zones, where the primary master is located (**primary | |
326 | 127.0.0.1;**) | |
327 | 4. Which TSIG key to use (**key dhcpdupdate;**). We defined the key | |
328 | earlier. | |
329 | ||
330 | This concludes the changes that are needed to the **dhcpd** | |
331 | configuration file. | |
332 | ||
333 | Setting up PowerDNS | |
334 | ~~~~~~~~~~~~~~~~~~~ | |
335 | ||
336 | A number of small changes are needed to powerdns to make it accept | |
337 | dynamic updates from **dhcpd**. | |
338 | ||
339 | Enabled DNS update (:rfc:`2136`) support functionality in PowerDNS by adding | |
340 | the following to the PowerDNS configuration file (pdns.conf). | |
341 | ||
633489be | 342 | .. code-block:: ini |
0e2063c3 PL |
343 | |
344 | dnsupdate=yes | |
345 | allow-dnsupdate-from= | |
346 | ||
347 | This tells PowerDNS to: | |
348 | ||
349 | 1. Enable DNS update support(:ref:`setting-dnsupdate`) | |
350 | 2. Allow updates from NO ip-address (":ref:`setting-allow-dnsupdate-from`\ =") | |
351 | ||
352 | We just told powerdns (via the configuration file) that we accept | |
353 | updates from nobody via the :ref:`setting-allow-dnsupdate-from` | |
354 | parameter. That's not very useful, so we're going to give permissions | |
355 | per zone (including the appropriate reverse zone), via the | |
356 | domainmetadata table. | |
357 | ||
358 | :: | |
359 | ||
360 | sql> select id from domains where name='example.org'; | |
361 | 5 | |
362 | sql> insert into domainmetadata(domain_id, kind, content) values(5, 'ALLOW-DNSUPDATE-FROM','127.0.0.1'); | |
363 | sql> select id from domains where name='1.168.192.in-addr.arpa'; | |
364 | 6 | |
365 | sql> insert into domainmetadata(domain_id, kind, content) values(6, 'ALLOW-DNSUPDATE-FROM','127.0.0.1'); | |
366 | ||
367 | This gives the ip '127.0.0.1' access to send update messages. Make sure | |
368 | you use the ip address of the machine that runs **dhcpd**. | |
369 | ||
370 | Another thing we want to do, is add TSIG security. This can only be done | |
371 | via the domainmetadata table: | |
372 | ||
373 | :: | |
374 | ||
375 | sql> insert into tsigkeys (name, algorithm, secret) values ('dhcpdupdate', 'hmac-md5', 'FYhvwsW1ZtFZqWzsMpqhbg=='); | |
376 | sql> select id from domains where name='example.org'; | |
377 | 5 | |
378 | sql> insert into domainmetadata (domain_id, kind, content) values (5, 'TSIG-ALLOW-DNSUPDATE', 'dhcpdupdate'); | |
379 | sql> select id from domains where name='1.168.192.in-addr.arpa'; | |
380 | 6 | |
381 | sql> insert into domainmetadata (domain_id, kind, content) values (6, 'TSIG-ALLOW-DNSUPDATE', 'dhcpdupdate'); | |
382 | ||
383 | This will: | |
384 | ||
385 | 1. Add the 'dhcpdupdate' key to our PowerDNSinstallation | |
386 | 2. Associate the domains with the given TSIG key | |
387 | ||
388 | Restart PowerDNS and you should be ready to go! | |
389 | ||
390 | .. _dnsupdate-how-it-works: | |
391 | ||
392 | How it works | |
393 | ------------ | |
394 | ||
395 | This is a short description of how DNS update messages are processed by | |
396 | PowerDNS. | |
397 | ||
398 | 1. The DNS update message is received. If it is TSIG signed, the TSIG | |
399 | is validated against the tsigkeys table. If it is not valid, Refused | |
400 | is returned to the requestor. | |
401 | 2. A check is performed on the zone to see if it is a valid zone. | |
402 | ServFail is returned when not valid. | |
403 | 3. The **dnsupdate** setting is checked. Refused is returned when the | |
404 | setting is 'no'. | |
7faba4b6 | 405 | 4. If update policy Lua script is provided then skip up to 7. |
0e2063c3 PL |
406 | 5. If the **ALLOW-DNSUPDATE-FROM** has a value (from both |
407 | domainmetadata and the configuration file), a check on the value is | |
408 | performed. If the requestor (sender of the update message) does not | |
409 | match the values in **ALLOW-DNSUPDATE-FROM**, Refused is returned. | |
410 | 6. If the message is TSIG signed, the TSIG keyname is compared with the | |
411 | TSIG keyname in domainmetadata. If they do not match, a Refused is | |
412 | send. The TSIG-ALLOW-DNSUPDATE domainmetadata setting is used to | |
413 | find which key belongs to the domain. | |
414 | 7. The backends are queried to find the backend for the given domain. | |
415 | 8. If the domain is a slave domain, the **forward-dnsupdate** option | |
416 | and domainmetadata settings are checked. If forwarding to a master | |
417 | is enabled, the message is forward to the master. If that fails, the | |
418 | next master is tried until all masters are tried. If all masters | |
419 | fail, ServFail is returned. If a master succeeds, the result from | |
420 | that master is returned. | |
421 | 9. A check is performed to make sure all updates/prerequisites are for | |
422 | the given zone. NotZone is returned if this is not the case. | |
423 | 10. The transaction with the backend is started. | |
424 | 11. The prerequisite checks are performed (section 3.2 of :rfc:`2136 <2136#section-3.2>`). If a | |
425 | check fails, the corresponding RCode is returned. No further | |
426 | processing will happen. | |
427 | 12. Per record in the update message, a the prescan checks are | |
428 | performed. If the prescan fails, the corresponding RCode is | |
429 | returned. If the prescan for the record is correct, the actual | |
430 | update/delete/modify of the record is performed. If the update fails | |
431 | (for whatever reason), ServFail is returned. After changes to the | |
432 | records have been applied, the ordername and auth flag are set to | |
433 | make sure DNSSEC remains working. The cache for that record is | |
434 | purged. | |
435 | 13. If there are records updated and the SOA record was not modified, | |
436 | the SOA serial is updated. See :ref:`dnsupdate-soa-serial-updates`. The cache for this record is | |
437 | purged. | |
438 | 14. The transaction with the backend is committed. If this fails, | |
439 | ServFail is returned. | |
440 | 15. NoError is returned. | |
441 | ||
442 | .. _dnsupdate-update-policy: | |
443 | ||
444 | Update policy | |
445 | ------------- | |
446 | ||
447 | .. versionadded:: 4.1.0 | |
448 | ||
449 | You can define a Lua script to handle DNS UPDATE message | |
450 | authorization. The Lua script is to contain at least function called | |
451 | ``updatepolicy`` which accepts one parameter. This parameter is an | |
452 | object, containing all the information for the request. To permit | |
453 | change, return true, otherwise return false. The script is called for | |
454 | each record at a time and you can approve or reject any or all. | |
455 | ||
456 | The object has following methods available: | |
457 | ||
a771f67f | 458 | - ``DNSName getQName()`` - name to update |
f9c60de1 | 459 | - ``DNSName getZoneName()`` - zone name |
a771f67f GD |
460 | - ``int getQType()`` - record type, it can be 255(ANY) for delete. |
461 | - ``ComboAddress getLocal()`` - local socket address | |
462 | - ``ComboAddress getRemote()`` - remote socket address | |
463 | - ``Netmask getRealRemote()`` - real remote address (or netmask if EDNS Subnet is used) | |
464 | - ``DNSName getTsigName()`` - TSIG **key** name (you can assume it is validated here) | |
465 | - ``string getPeerPrincipal()`` - Return peer principal name (``user@DOMAIN``, | |
466 | ``service/machine.name@DOMAIN``, ``host/MACHINE$@DOMAIN``) | |
0e2063c3 PL |
467 | |
468 | There are many same things available as in recursor Lua scripts, but | |
a771f67f | 469 | there is also ``resolve(qname, qtype)`` which returns array of records. |
0e2063c3 PL |
470 | Example: |
471 | ||
633489be | 472 | .. code-block:: lua |
0e2063c3 PL |
473 | |
474 | resolve("www.google.com", pdns.A) | |
475 | ||
476 | You can use this to perform DNS lookups. If your resolver cannot find | |
477 | your local records, then this will not find them either. In other words, | |
478 | resolve does not perform local lookup. | |
479 | ||
480 | Simple example script: | |
481 | ||
633489be | 482 | .. code-block:: lua |
0e2063c3 PL |
483 | |
484 | --- This script is not suitable for production use | |
485 | ||
486 | function strpos (haystack, needle, offset) | |
487 | local pattern = string.format("(%s)", needle) | |
488 | local i = string.find (haystack, pattern, (offset or 0)) | |
489 | return (i ~= nil and i or false) | |
490 | end | |
491 | ||
492 | function updatepolicy(input) | |
493 | princ = input:getPeerPrincipal() | |
494 | ||
495 | if princ == "" | |
496 | then | |
497 | return false | |
498 | end | |
499 | ||
500 | if princ == "admin@DOMAIN" or input:getRemote():toString() == "192.168.1.1" | |
501 | then | |
502 | return true | |
503 | end | |
504 | ||
505 | if (input:getQType() == pdns.A or input:getQType() == pdns.AAAA) and princ:sub(5,5) == '/' and strpos(princ, "@", 0) ~= false | |
506 | then | |
507 | i = strpos(princ, "@", 0) | |
508 | if princ:sub(i) ~= "@DOMAIN" | |
509 | then | |
510 | return false | |
511 | end | |
512 | hostname = princ:sub(6, i-1) | |
513 | if input:getQName():toString() == hostname .. "." or input:getQName():toString() == hostname .. "." .. input:getZoneName():toString() | |
514 | then | |
515 | return true | |
516 | end | |
517 | end | |
518 | ||
519 | return false | |
520 | end |