RFC2136 Server Setup How-to


  • Rebel Alliance Developer Netgate

    I just added a how-to on the wiki for setting up an RFC2136 server in BIND:

    http://doc.pfsense.org/index.php/RFC2136_Dynamic_DNS

    It's actually pretty easy/straightforward and works pretty well for me on over two dozen hosts so far.

    I also plan on working on some improvements to the RFC2136 GUI as time allows.



  • What great timing.  Just set this up this afternoon using instructions found on internet; http://www.shakabuku.org/writing/dyndns.html (TSIG Signed Updates section).

    A few variations from what you have here.  Also on a chroot installation of BIND 9 so a few path and permissions differences.

    Would be interested in the significance of the differences.

    
    update-policy { grant *.dyn.example.com. self dyn.example.com. A AAAA; };
     vs. 
    allow-update { key home-dns.shakabuku.org.; };
    
    
    
    /usr/sbin/dnssec-keygen -K /etc/namedb/keys -a HMAC-MD5 -b 128 -n HOST  myhost.dyn.example.com.
    Kmyhost.dyn.example.com.+157+32768
     vs. 
    dnssec-keygen -a HMAC-MD5 -b 128 -n HOST home-dns.shakabuku.org.
    
    

  • Rebel Alliance Developer Netgate

    That tutorial is one of a few I drew on for information. I fished around for info from a number of places since several of them didn't agree and in some cases nobody mentioned important information (such as what the zone file should contain) or it wasn't suited for what I wanted to do.

    The update-policy vs allow-update differences are just a matter of preference and what you want to do. In my example I wanted to set it up to allow a lot of hosts to update themselves, rather than a single one, and I wanted to restrict them to only updating their A and AAAA records (RFC2136 does support IPv6 and it works fine, btw :-)

    The keygen line you have is equivalent the only difference there is the -K which makes it output to the given directory not the current directory. My syntax there has a focus on scripting.



  • Thanks for the additional explanations.

    Could the RFC2136 help (http://doc.pfsense.org/index.php/RFC2136_Dynamic_DNS) be added to the Dynamic DNS help table of contents and linked from there (http://doc.pfsense.org/index.php/Dynamic_DNS)?

    You mentioned doing some work on the RFC2136 GUI.  A closed loop status to determine whether or not the update was successful and retry would be nice.  Does DDNS update return any status?  If not maybe a periodic nslookup or something could be used to determine state of the DNS record.

    Nice work.  Thanks.


  • Rebel Alliance Developer Netgate

    @NOYB:

    Could the RFC2136 help (http://doc.pfsense.org/index.php/RFC2136_Dynamic_DNS) be added to the Dynamic DNS help table of contents and linked from there (http://doc.pfsense.org/index.php/Dynamic_DNS)?

    Done!

    @NOYB:

    You mentioned doing some work on the RFC2136 GUI.  A closed loop status to determine whether or not the update was successful and retry would be nice.  Does DDNS update return any status?  If not maybe a periodic nslookup or something could be used to determine state of the DNS record.

    I'm not sure what all I'm going to do, but I do want to bring it closer in-line with what is being done by the main dyndns tab. So probably things like: Option to use a public IP if WAN is private, showing the cached IP/check if it's up-to-date, adding these hostnames to the rebinding/referer check lists, and adding gateway group support.



  • (better late then never)

    Thanks for the DOC / RFC2136_Dynamic_DNS.
    Yes, I'm using pfSense as a local "keep the sheeps in and wolfs out" wall, and Yes, I do have some Linux (sorry) server somewhere on the net. Needless to say that bind (named) is resolving my domains over there.

    I already new that the Services:> Dynamic DNS clients:> RFC 2139 tab existed but these 'dyndns' and compatible are more easy to set up.
    Knowing that my Linux Debian server is running rock solid for years now, I said to myself: let's do it.
    But … making things to work was less easy - RFC2136 is more like a test for "how well do you know bind ?".

    Anyway, it works.

    It's nice to see that after an update (IP WAN change), the IP is being thrown in my zone:

    24-Sep-2013 16:02:10.955 update: client 90.60.98.149#42474: updating zone 'test-domaine.fr/IN': deleting rrset at 'brit.test-domaine.fr' A
    24-Sep-2013 16:02:10.956 update: client 90.60.98.149#42474: updating zone 'test-domaine.fr/IN': adding an RR at 'brit.test-domaine.fr' A
    
    

    brit.test-domaine.fr is my 'dynamical sub domain'.
    Right after, binds start to notify all my slave DNS:

    24-Sep-2013 16:02:11.019 notify: zone test-domaine.fr/IN: sending notifies (serial 2013092406)
    
    

    And a couple of seconds afters that, they all call in, to update their copie of the zone 'test-domaine.fr'.

    24-Sep-2013 16:02:11.039 xfer-out: client 213.186.33.199#46628: transfer of 'test-domaine.fr/IN': IXFR started
    24-Sep-2013 16:02:11.040 xfer-out: client 213.186.33.199#46628: transfer of 'test-domaine.fr/IN': IXFR ended
    24-Sep-2013 16:02:11.854 xfer-out: client 174.37.196.55#23866: transfer of 'test-domaine.fr/IN': IXFR started
    24-Sep-2013 16:02:11.854 xfer-out: client 174.37.196.55#23866: transfer of 'test-domaine.fr/IN': IXFR ended
    
    

    (the code snippets are part of the debug log of bind, running on my Linux server).

    A real surprise was the fact that bind rewrites &&reformats my zone file !!
    My private formating … gone.
    The A and AAAA of a sub domain changed, so bind actually rebuilds my zone file  :o
    It increments the SOA serial in that file - from "2013092405" to "2013092406" thus forcing the slave DNS to make a zone transfer (IXFR).

    No more need for those DynDNS, FreeDNS, OpenDNS services ….... I'm going to ditch them soon now.

    Btw: I discovered something new: in this special case, bind needs the 'rights' to WRITE into /etc/bind/ - needs the 'rights' to overwrite the concerned zone file. It even keeps some kind of journal-log file in the /etc/bind/ directory.


  • Rebel Alliance Developer Netgate

    Yes that's why in my example I used a "dyn.example.com" subdomain because it rewrites that file and needs extra permissions… Not fun when it's unexpected. I thought I noted that somewhere but I don't see it now.

    If you lock it down to just one subdomain/zone it is easier to manage, though it doesn't look quite so nice as being on the main zone.



  • Hi

    If I May,

    Can I ask for some help with this post http://forum.pfsense.org/index.php/topic,67817.0.html

    Regards
    Franck



  • Hello,

    Can anybody tell me if this solution could still apply if I wanted to create a DNS to handle an internal subdomain of a publicly hosted domain.

    Please help

    Here is a post I've opened on expert exchange  "http://www.experts-exchange.com/Networking/Protocols/DNS/Q_28268075.html#a39589557"

    Regards
    Franck



  • It sounds like this thread is more or less about what I like to do: replace DynDNS service and host it on my own pfSense box.
    However, I'm a bit confused by the how-to article https://doc.pfsense.org/index.php/RFC2136_Dynamic_DNS
    because I'm not clear what box is and what subsystem is running where and what's a server of what client…

    In short, I have a domain example.com and example.net. I want to use example.net for dynamic DNS, which allows me to point CNAME records from example.com at example.net to have in essence dynamic DNS for example.com, yet I can have the DNS servers cleanly separated.
    DNS Servers for example.com are somewhere on an OS X Server box and should not be considered.

    Then I'd like to have two pfSense units. The main unit is at a colocation service, fixed IP address, and I want that unit to host the primary DNS server for example.net, and and update the address records as needed dynamically.

    I have a second pfSense unit with DHCP assigned IP address at home, and of course a roaming laptop, etc. all of which should stop using Dyn.com's DynDNS service and use the above mentioned pfSense unit at the colocation service.

    Sorry for being a bit dense, but this is new turf for me.


  • Rebel Alliance Developer Netgate

    This is not meant to run as a server on pfSense, but on another server running BIND.

    I don't know if the new BIND package is capable of handling this task, but it's still best to run an authoritative name server on a separate box.



  • @jimp:

    This is not meant to run as a server on pfSense, but on another server running BIND.

    I don't know if the new BIND package is capable of handling this task, but it's still best to run an authoritative name server on a separate box.

    Hm, that wouldn't work for me, because my main DNS server is on the net with the dynamic IP.
    Although that seems paradox at first, this works because I have a direct assigned IP address block which is routed to the dynamic network over a quasi-permanent VPN connection between the two pfSense units. But of course exactly when the IP address changes, that also means the VPN is down until the hostname can be resolved again, so for these moments my main DNS server is inaccessible.
    That's also why I want to segment the name space cleanly into example.com and example.net, with the .net portion being hosted by the pfSense unit with a permanent, fixed IP address and located at the colocation provider.

    How does the bind package interfere with the DNS forwarder? Any known issues when installing bind?

    If what you describe would work with the bind package, I'd finally have the solution that I've been looking for for quite some time, because the various DynDNS providers get ever more expensive, their service more convoluted, and I also want to reduce the number of failure points in my setup. Simplify, simplify…



  • I just upgraded to the 2.2-RELEASE version of pfSense, and set up an RFC 2136 dynamic DNS client.  I had problems getting it to work initially, but its fine now.

    It turns out that in the "Hostname" field (with the text "Fully qualified hostname of the host to be updated"), you cannot have a trailing "." character on the DNS name.  If this is present, it silently fails without attempting to transmit a packet to the DNS server.  This, of course, discovered by running tcpdump on both ends..  Removing the trailing period character immediately had it working.


  • Rebel Alliance Developer Netgate

    Did it work with the trailing "." in 2.1.x?

    I don't recall attempting to end it with a trailing '.' before



  • Just to say that in 2.2 the validation of an FQDN now allows the trailing "." (root domain) to be specified.
    So there will be places like this where the trailing dot is now allowed by the validation, but maybe some downstream implementing code does not cope with trailing dot and needs to be enhanced.



  • Hello, I'm trying to enable RFC2136
    But I followed the tutorial and am having the following error

    Feb 25 19:56:29 ns php-fpm[72872]: /services_rfc2136_edit.php: The command '/usr/local/bin/nsupdate -k /var/etc/K0domain.net.+157+00000.key -v /var/etc/nsupdatecmds0' returned exit code '134', the output was '; Communication with 177.177.177.70#53 failed: operation canceled name.c:1014: REQUIRE((__builtin_expect(!!((source) != ((void *)0)), 1) && __builtin_expect(!!(((const isc__magic_t *)(source))->magic == ((('D') << 24 | ('N') << 16 | ('S') << 8 | ('n')))), 1))) failed, back trace #0 0xa8567f33 in ??' 
    Feb 25 19:56:29 ns kernel: pid 94766 (nsupdate), uid 0: exited on signal 6 (core dumped)
    Feb 25 19:56:29 ns php-fpm[72872]: /services_rfc2136_edit.php: phpDynDNS: ERROR while updating IP Address (A) for domain.net (177.177.177.70)
    
    

    I also tried it in another way by using a script to just update my Zone A with my external iP
    Using nsupdate however I get the declined error

    Sending update to 172.16.0.1#53
    Outgoing update query:
    ;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id:  34415
    ;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 2, ADDITIONAL: 1
    ;; ZONE SECTION:
    ;domain.net.			IN	SOA
    
    ;; UPDATE SECTION:
    domain.net.		0	ANY	A	
    domain.net.		30	IN	A	172.16.0.48
    
    ;; TSIG PSEUDOSECTION:
    172.16.0.1.		0	ANY	TSIG	hmac-md5.sig-alg.reg.int. 1488057940 300 16 lUuMfR2HVuCcC7A== 34415 NOERROR 0 
    
    Reply from update query:
    ;; ->>HEADER<<- opcode: UPDATE, status: REFUSED, id:  34415
    ;; flags: qr ra; ZONE: 1, PREREQ: 0, UPDATE: 0, ADDITIONAL: 1
    ;; ZONE SECTION:
    ;domain.net.			IN	SOA
    
    ;; TSIG PSEUDOSECTION:
    172.16.0.1.		0	ANY	TSIG	hmac-md5.sig-alg.reg.int. 1488057940 300 17g+7Cw== 34415 NOERROR 0 
    
    


  • domain.net is probably not your URL and 172.16.0.1 is a private IP (RFC1918).
    If, for whatever reason, you don't want your public URL known here then use  example.com  as placeholder. This way we know you're not putting rubbish in those fields.

    Since your public IP changes (you wouldn't use a DynDNS service otherwise) just use your current IP; alternatively use an IP from TEST-NET-2 198.51.100.0/24  (RFC5737)



  • I'm using a different DNS server that I love, but that hasn't been updated in 7 years, mydns-ng.  It has support for RFC2136, but I'm having some problems connecting pfsense to it.  A DNS request is coming into the DNS server, but it isn't what I would expect it to be.  It's just checking the SOA for the zone, but then not trying to update the A record.  I very much think it's something I'm just doing wrong by misunderstanding one of the fields.  In particular the 'key' field in pfsense.  There is no matching field in mydns that I can find, so I'm not certain what to put there.

    When I try to use nsupdate from the CLI, I get errors from the dns server that I'm not authenticated, but pfsense never goes far enough to receive that failure.  Does anyone have any insights or suggestions for me?



  • You have some logs as showed above ?