# Dyndns & Bind reconds

## lockcole666

Hi all, 

Well im not really sure how to start this post up but ill try to post as much info as possible and what im trying to achieve with bind. In short I would like EXTREAMLY quick resolution of a dyndns record which I have the account too on a local bind server. I have no idea what would be the best approch. Ill explain. 

(im a little bit of a noob when it comes to dns, so i appericate the help)

So, I have two dsl accounts, router A and router B. A and B are joined together by a VPN. A, is a static address running an enterprise router, and B is a no name brand, running dyndns to update the IP. A has a gentoo bind server running which is uses for local and remote DNS (config to follow). Now A relies on the gentoo bind server (which is very local to router A) to provide timely responces on B current IP address, who has a dyndns address. This is a key factor in maintaining the VPN between A and B. 

Now, the issue. 

Router A sometimes downloads too much (bad router A!) Router A gets his bandwidth limited. When this happens the gentoo bind which sits behind router A cant resolve the dyndns names due to lack of bandwidth. Router A assumes gentoo bind has no idea, (within micro seconds) and asks things like the local link on IPv6 as it was the default route. 

Facts:-

router A and B bandwidth is not limited. 

I can see router A indicating in the debugging gentoo bind cant get answer due to a timeout. 

Router A declaring the record as a stale DNS and try stupid things. i.e. IPv6 locallink. 

Router B dyndns. (the little i know about it)

The TTL is set to 60sec 

So the route/switch crap (which i understand)

On router A, during phase 1 of ike/ipsec the dyndns entire for the remote peer is a dynamic hostname. There is no way around this in a DVPN. not setting a peer in some shape or form will mean in phase 3 or ike/ipsec will have one way data flow. Router A relies on a timely response from the gentoo DNS sevrer which has to get his records back over router A. The QoS on the egress for name resolution of the gentoo bind is very high, but on the ingress I have no control on a timely responce.

Questions (from my little understanding of bind)

Under normal circumstances this all works great. But when the connection on router A get shaped i get stale DNS from my local gentoo server. I know that dyndns is dynamically updated via a client. 

Is there any way to update router B dyndns record to A gentoo bind with the uname and pass, with a preempt TTL? 

Solution:-

 if A bind has the ability to sync  (guess) with the TTL of dyndns B expiry then I could maintain the VPN between A and B. The r&s i can do  :Smile: 

My router A bind config

```

acl "xfer" {

        none;

};

acl "trusted" {

        127.0.0.0/8;

        ::1/128;

        192.x.x.x/??;

        192.x.x.x/??;

        172.x.x.x/??;

};

options {

        directory "/var/bind";

        pid-file "/var/run/named/named.pid";

        //bindkeys-file "/etc/bind/bind.keys";

        listen-on-v6 { ::1; };

        listen-on { 127.0.0.1; 172.x.x.x; };

        allow-query {

                trusted;

        };

        allow-query-cache {

                trusted;

        };

        allow-recursion {

                trusted;

        };

        allow-transfer {

                none;

        };

        allow-update {

                none;

        };

        

        forward first;

        forwarders {

                9.x.x.x;        // Your ISP NS

        //      9.x.x.x;          // Your ISP NS

        //      4.2.2.1;                // Level3 Public DNS

        //      4.2.2.2;                // Level3 Public DNS

        //      8.8.8.8;                // Google Open DNS

        //      8.8.4.4;                // Google Open DNS

        };

        //dnssec-enable yes;

        //dnssec-validation yes;

        //dnssec-validation auto;

        /* if you have problems and are behind a firewall: */

        //query-source address * port 53;

};

view "internal" {

        match-clients { 172.x.x.x/??; 192.x.x.x/?; 192.x.x.x/??; localhost; };

        zone "testing.com" {

                type master;

                file "pri/testing.com.internal";

                allow-transfer { any; };

                                };

};

view "external" {

        match-clients { any; };

        zone "." IN {

                type hint;

                file "named.cache";

        };

        zone "127.in-addr.arpa" IN {                                                            type master;

                file "pri/127.zone";                                                            allow-update { none; };

                notify no;

        };

//      zone "testing.com" {

//                type master;

//                file "pri/testing.com.external";

//                allow-query { any; };

//                allow-transfer { SLAVE_DNS_SERVER; };

//        };

};

logging {

        channel default_log {

                file "/var/log/named/named.log" versions 5 size 50M;

                print-time yes;

                print-severity yes;

                print-category yes;

        };

        category default { default_log; };

        category general { default_log; };

};

include "/etc/bind/rndc.key";

controls {

        inet 127.0.0.1 port 953 allow { 127.0.0.1/32; ::1/128; } keys { "rndc-key"; };

};

/*

zone "." in {

        type hint;

        file "/var/bind/root.cache";

};

zone "localhost" IN {

        type master;

        file "pri/localhost.zone";

        notify no;

};

zone "127.in-addr.arpa" IN {

        type master;

        file "pri/127.zone";

        notify no;

};

*/

/*

 * Briefly, a zone which has been declared delegation-only will be effectively

 * limited to containing NS RRs for subdomains, but no actual data beyond its

 * own apex (for example, its SOA RR and apex NS RRset). This can be used to

 * filter out "wildcard" or "synthesized" data from NAT boxes or from

 * authoritative name servers whose undelegated (in-zone) data is of no

 * interest.

 * See http://www.isc.org/software/bind/delegation-only for more info

 */

//zone "COM" { type delegation-only; };

//zone "NET" { type delegation-only; };

//zone "YOUR-DOMAIN.TLD" {

//      type master;

//      file "/var/bind/pri/YOUR-DOMAIN.TLD.zone";

//      allow-query { any; };

//      allow-transfer { xfer; };

//};

//zone "YOUR-SLAVE.TLD" {

//      type slave;

//      file "/var/bind/sec/YOUR-SLAVE.TLD.zone";

//      masters { <MASTER>; };

        /* Anybody is allowed to query but transfer should be controlled by the master. */

//      allow-query { any; };

//      allow-transfer { none; };

        /* The master should be the only one who notifies the slaves, shouldn't it? */

//      allow-notify { <MASTER>; };

//      notify no;

//};

```

added 'code' tags for readability --cach0rr0

----------

## Mad Merlin

Two comments:

1) 60s TTL on DNS entries is crazy low, even an hour is pretty low. Lots of intermediate servers will ignore your TTL settings and cache for longer, this could be part of the issue.

2) If A is static, why don't you have B VPN into A, rather than A VPN into B? That way the IP address of B doesn't matter.

----------

## Ant P.

From what I could be bothered looking at (code in variable width font is exceptionally hard to follow, which is why we have code tags), you have allow-query on IPv4 subnets that aren't being listened on, and nothing can query via IPv6.

----------

