Re: caching does not seem to be working for internal view

[Robert Moskowitz]

This is boarderline not thinking on my part.

OF COURSE those FQDNs resolve fast; they are in local ZOne files. No 
lookup needed.


Sheesh.

"Slow down, you move to fast.  Got to make the Mornin' last!"  :)

On 8/3/22 14:43, Robert Moskowitz wrote:
Perhaps this is only caching the zones in the Internal View, not all 
public stuff looked up by internal clients?


I say this because I get fast responses to internal servers, but slow 
if at all to external ones.


Grasping here because my search foo is weak and I can't find where it 
is defined exactly what IS cached.


On 8/3/22 10:52, Robert Moskowitz via bind-users wrote:
thanks Greg.  Yes I need to figure out how to troubleshoot this.  But 
here is some stuff:


# cat resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 2600:1700:9120:4330::1

My server is 23.123.122.146.  That IPv6 addr is my ATT router.

# cat named.conf
    include "/etc/named/named.acl";

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    use-v4-udp-ports { range 10240 65535; };
    use-v6-udp-ports { range 10240 65535; };
    directory     "/var/named";
    dump-file     "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query { localhost; };

    dnssec-enable no;
    dnssec-validation no;
    bindkeys-file "/etc/named.iscdlv.key";
    managed-keys-directory "/var/named/dynamic";
    pid-file "/run/named/named.pid";
    session-keyfile "/run/named/session.key";
};

logging {    channel default_debug {
    file "data/named.run";
    severity dynamic;    };};

view "internal"
{    include "/etc/named/named.internal";};

view    "external"
{    include "/etc/named/named.external";};

include "/etc/named/rndc.key";
include "/etc/named.root.key";

# cat named.acl
acl "httslaves"  {
//    address of NSs
    208.83.69.35;    // ns1.mudkips.net
    208.83.66.130;    // ns2.mudkips.net
    63.68.132.50;    // ns1.icsl.net
    2607:f4b8:2600:1::1;    // ns1.mudkips.net
    2607:f4b8:2600:6::1;    // ns2.mudkips.net
};

acl "httnets" {
    127.0.0.1;
    23.123.122.144/28;
    192.168.32.0/24;
    192.168.64.0/24;
    192.168.96.0/24;
    192.168.160.0/23;
    192.168.128.0/23;
    192.168.192.0/22;
    192.168.224.0/24;
    ::1;
    2600:1700:9120:4330::/64;
};


# cat named.internal

    match-clients        { httnets; };
    match-destinations    { httnets; };
    allow-query        { httnets; };
    allow-query-cache    { httnets; };
    allow-recursion        { any; };
    recursion yes;
    empty-zones-enable yes;

    zone "." IN {
    type hint;
    file "named.ca";    };

    include "/etc/named.rfc1912.zones";

    zone "htt-consult.com" {
    type master;
    file "httin-consult.com.zone";    };

    zone "labs.htt-consult.com" {
    type master;
    file "labs.htt-consult.com.hosts";    };
    zone "intelcon.htt-consult.com" {
    type master;
    file "intelcon.htt-consult.com.hosts";    };
    zone "mobile.htt-consult.com" {
    type master;
    file "mobile.htt-consult.com.hosts";    };
    zone "test.htt-consult.com" {
    type master;
    file "test.httin-consult.com.hosts";    };
    zone "128.168.192.in-addr.arpa" {
    type master;
    file "128.168.192.in-addr.arpa.zone";  };
    zone "0-24.128.168.192.in-addr.arpa" {
    type master;
    file "0-24.128.168.192.in-addr.arpa.zone";    };
    zone "htt" {
    type master;
    file "htt.zone";  };
    zone "home.htt" {
    type master;
    file "home.htt.zone";    };


Do you also want my named.external?


On 8/3/22 09:39, Greg Choules wrote:

Hi Robert.
May we see the file /etc/resolv.conf and your BIND configuration? 
It's difficult to guess what might be going on with only a small 
snippet of information.
If you "ping somewhere" (or "ssh a-server", or whatever) the OS will 
consult resolv.conf to determine where to send DNS queries. If 
that's not your local instance of BIND then you could be looking for 
trouble in the wrong place.


If you *do* have an address of the local machine as the first 
'nameserver' entry in resolv.conf you will need to know what that 
query looks like to determine how BIND is going to handle it.
You also need to know what BIND will try and do when it does receive 
queries

Re: caching does not seem to be working for internal view

[Robert Moskowitz]

Perhaps this is only caching the zones in the Internal View, not all 
public stuff looked up by internal clients?


I say this because I get fast responses to internal servers, but slow if 
at all to external ones.


Grasping here because my search foo is weak and I can't find where it is 
defined exactly what IS cached.


On 8/3/22 10:52, Robert Moskowitz via bind-users wrote:
thanks Greg.  Yes I need to figure out how to troubleshoot this. But 
here is some stuff:


# cat resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 2600:1700:9120:4330::1

My server is 23.123.122.146.  That IPv6 addr is my ATT router.

# cat named.conf
    include "/etc/named/named.acl";

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    use-v4-udp-ports { range 10240 65535; };
    use-v6-udp-ports { range 10240 65535; };
    directory     "/var/named";
    dump-file     "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query { localhost; };

    dnssec-enable no;
    dnssec-validation no;
    bindkeys-file "/etc/named.iscdlv.key";
    managed-keys-directory "/var/named/dynamic";
    pid-file "/run/named/named.pid";
    session-keyfile "/run/named/session.key";
};

logging {    channel default_debug {
    file "data/named.run";
    severity dynamic;    };};

view "internal"
{    include "/etc/named/named.internal";};

view    "external"
{    include "/etc/named/named.external";};

include "/etc/named/rndc.key";
include "/etc/named.root.key";

# cat named.acl
acl "httslaves"  {
//    address of NSs
    208.83.69.35;    // ns1.mudkips.net
    208.83.66.130;    // ns2.mudkips.net
    63.68.132.50;    // ns1.icsl.net
    2607:f4b8:2600:1::1;    // ns1.mudkips.net
    2607:f4b8:2600:6::1;    // ns2.mudkips.net
};

acl "httnets" {
    127.0.0.1;
    23.123.122.144/28;
    192.168.32.0/24;
    192.168.64.0/24;
    192.168.96.0/24;
    192.168.160.0/23;
    192.168.128.0/23;
    192.168.192.0/22;
    192.168.224.0/24;
    ::1;
    2600:1700:9120:4330::/64;
};


# cat named.internal

    match-clients        { httnets; };
    match-destinations    { httnets; };
    allow-query        { httnets; };
    allow-query-cache    { httnets; };
    allow-recursion        { any; };
    recursion yes;
    empty-zones-enable yes;

    zone "." IN {
    type hint;
    file "named.ca";    };

    include "/etc/named.rfc1912.zones";

    zone "htt-consult.com" {
    type master;
    file "httin-consult.com.zone";    };

    zone "labs.htt-consult.com" {
    type master;
    file "labs.htt-consult.com.hosts";    };
    zone "intelcon.htt-consult.com" {
    type master;
    file "intelcon.htt-consult.com.hosts";    };
    zone "mobile.htt-consult.com" {
    type master;
    file "mobile.htt-consult.com.hosts";    };
    zone "test.htt-consult.com" {
    type master;
    file "test.httin-consult.com.hosts";    };
    zone "128.168.192.in-addr.arpa" {
    type master;
    file "128.168.192.in-addr.arpa.zone";  };
    zone "0-24.128.168.192.in-addr.arpa" {
    type master;
    file "0-24.128.168.192.in-addr.arpa.zone";    };
    zone "htt" {
    type master;
    file "htt.zone";  };
    zone "home.htt" {
    type master;
    file "home.htt.zone";    };


Do you also want my named.external?


On 8/3/22 09:39, Greg Choules wrote:

Hi Robert.
May we see the file /etc/resolv.conf and your BIND configuration? 
It's difficult to guess what might be going on with only a small 
snippet of information.
If you "ping somewhere" (or "ssh a-server", or whatever) the OS will 
consult resolv.conf to determine where to send DNS queries. If that's 
not your local instance of BIND then you could be looking for trouble 
in the wrong place.


If you *do* have an address of the local machine as the first 
'nameserver' entry in resolv.conf you will need to know what that 
query looks like to determine how BIND is going to handle it.
You also need to know what BIND will try and do when it does receive 
queries.


Packet captures are your friend here, using tcpdump (to disk, not to 
screen). Gather evidence first, then make theories.


Cheers, Greg

On Wed, 3 Aug 2022 at 14:29, Robert Moskowitz  
wrote:


Part of my problem is that caching does not

Re: ,Re: caching does not seem to be working for internal view

[Robert Moskowitz]

On 8/3/22 12:59, Timothe Litt wrote:


Try

echo -e "[main]\ndns=none" > /etc/NetworkManager/conf.d/no-dns.conf
systemctl restart NetworkManager.service



Same content in resolv.conf.  BTW this is on Centos7.


Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.
On 03-Aug-22 12:36, Robert Moskowitz wrote:



On 8/3/22 11:35, Timothe Litt wrote:

On 03-Aug-22 10:53, bind-users-requ...@lists.isc.org wrote:

# cat resolv.conf

My server is 23.123.122.146.  That IPv6 addr is my ATT router.



You don't want to do that.  The ATT router will not know how to 
resolve internal names.  There is no guarantee that your client 
resolver will try nameservers in order.  If you want a backup, run a 
second instance of named.


As for the intermittent issues with resolving external names, that's 
frequently a case of hitting different nameservers.  Or a firewall.


Get rid of the ATT router first.  Then as suggested, a packet trace 
will show what happens (if it still does - it could be that the ATT 
router's resolver is at fault).




Thank you for your advice.  my ifcfg-eth0 has:

DEVICE="eth0"
BOOTPROTO=none
ONBOOT="yes"
TYPE="Ethernet"
NAME="eth0"
MACADDR=02:67:15:00:00:02
MTU=1500
DNS1=23.123.122.146
GATEWAY="23.123.122.158"
IPADDR="23.123.122.146"
NETMASK="255.255.255.240"
IPV6INIT="yes"

And I am ASSuMEing that it is that IPV6INIT that is providing that 
IPv6 addr in resolv.cat.  So I added:


DNS2=192.168.224.2

And now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1

ARGH!

I want the IPv6 addr from my firewall/gateway.  But I don't want that 
IPv6 nameserver!


So I added the IPv6 address for my server.  I had not done this as 
ATT has said there is no assurance with the IPv6 addresses may 
change.  So I added:


DNS3=2600:1700:9120:4330::49

and now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2600:1700:9120:4330::49

Sigh.  I have to take that dynamic IPv6 assignment.  But I want to 
stop it pushing into my resolv.conf.






--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ,Re: caching does not seem to be working for internal view

[Robert Moskowitz]

On 8/3/22 13:10, Anand Buddhdev wrote:

On 03/08/2022 18:36, Robert Moskowitz wrote:

Hi Robert,

[snip]


ARGH!

I want the IPv6 addr from my firewall/gateway.  But I don't want that 
IPv6 nameserver!


Calm down. Just add "PEERDNS=no" in your ifcfg-eth0 file. This way, 
the resolv.conf file will only contain your specified DNS servers, and 
nothing else.


I was excited to see this simple approach.  did systemctl restart 
NetworkManager.service


And no change.  :(

I will try Timothe's recommendation next.

BTW, it seems on top of everything else my fiber connect was going south 
to the point that firefox browsing was interspersed by the ATT firewall 
with a message to reset my fiber broadband router! That has helped.  Some.


Multiple failings which is often the case.


--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: ,Re: caching does not seem to be working for internal view

[Robert Moskowitz]

On 8/3/22 11:35, Timothe Litt wrote:

On 03-Aug-22 10:53, bind-users-requ...@lists.isc.org wrote:

# cat resolv.conf

My server is 23.123.122.146.  That IPv6 addr is my ATT router.



You don't want to do that.  The ATT router will not know how to 
resolve internal names.  There is no guarantee that your client 
resolver will try nameservers in order.  If you want a backup, run a 
second instance of named.


As for the intermittent issues with resolving external names, that's 
frequently a case of hitting different nameservers.  Or a firewall.


Get rid of the ATT router first.  Then as suggested, a packet trace 
will show what happens (if it still does - it could be that the ATT 
router's resolver is at fault).




Thank you for your advice.  my ifcfg-eth0 has:

DEVICE="eth0"
BOOTPROTO=none
ONBOOT="yes"
TYPE="Ethernet"
NAME="eth0"
MACADDR=02:67:15:00:00:02
MTU=1500
DNS1=23.123.122.146
GATEWAY="23.123.122.158"
IPADDR="23.123.122.146"
NETMASK="255.255.255.240"
IPV6INIT="yes"

And I am ASSuMEing that it is that IPV6INIT that is providing that IPv6 
addr in resolv.cat.  So I added:


DNS2=192.168.224.2

And now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1

ARGH!

I want the IPv6 addr from my firewall/gateway.  But I don't want that 
IPv6 nameserver!


So I added the IPv6 address for my server.  I had not done this as ATT 
has said there is no assurance with the IPv6 addresses may change.  So I 
added:


DNS3=2600:1700:9120:4330::49

and now:

# cat /etc/resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 192.168.224.2
nameserver 2600:1700:9120:4330::1
# NOTE: the libc resolver may not support more than 3 nameservers.
# The nameservers listed below may not be recognized.
nameserver 2600:1700:9120:4330::49

Sigh.  I have to take that dynamic IPv6 assignment.  But I want to stop 
it pushing into my resolv.conf.



--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: caching does not seem to be working for internal view

[Robert Moskowitz via bind-users]

thanks Greg.  Yes I need to figure out how to troubleshoot this. But 
here is some stuff:


# cat resolv.conf
# Generated by NetworkManager
search attlocal.net htt-consult.com
nameserver 23.123.122.146
nameserver 2600:1700:9120:4330::1

My server is 23.123.122.146.  That IPv6 addr is my ATT router.

# cat named.conf
    include "/etc/named/named.acl";

options {
    listen-on port 53 { any; };
    listen-on-v6 port 53 { any; };
    use-v4-udp-ports { range 10240 65535; };
    use-v6-udp-ports { range 10240 65535; };
    directory     "/var/named";
    dump-file     "/var/named/data/cache_dump.db";
    statistics-file "/var/named/data/named_stats.txt";
    memstatistics-file "/var/named/data/named_mem_stats.txt";
    allow-query { localhost; };

    dnssec-enable no;
    dnssec-validation no;
    bindkeys-file "/etc/named.iscdlv.key";
    managed-keys-directory "/var/named/dynamic";
    pid-file "/run/named/named.pid";
    session-keyfile "/run/named/session.key";
};

logging {    channel default_debug {
    file "data/named.run";
    severity dynamic;    };};

view "internal"
{    include "/etc/named/named.internal";};

view    "external"
{    include "/etc/named/named.external";};

include "/etc/named/rndc.key";
include "/etc/named.root.key";

# cat named.acl
acl "httslaves"  {
//    address of NSs
    208.83.69.35;    // ns1.mudkips.net
    208.83.66.130;    // ns2.mudkips.net
    63.68.132.50;    // ns1.icsl.net
    2607:f4b8:2600:1::1;    // ns1.mudkips.net
    2607:f4b8:2600:6::1;    // ns2.mudkips.net
};

acl "httnets" {
    127.0.0.1;
    23.123.122.144/28;
    192.168.32.0/24;
    192.168.64.0/24;
    192.168.96.0/24;
    192.168.160.0/23;
    192.168.128.0/23;
    192.168.192.0/22;
    192.168.224.0/24;
    ::1;
    2600:1700:9120:4330::/64;
};


# cat named.internal

    match-clients        { httnets; };
    match-destinations    { httnets; };
    allow-query        { httnets; };
    allow-query-cache    { httnets; };
    allow-recursion        { any; };
    recursion yes;
    empty-zones-enable yes;

    zone "." IN {
    type hint;
    file "named.ca";    };

    include "/etc/named.rfc1912.zones";

    zone "htt-consult.com" {
    type master;
    file "httin-consult.com.zone";    };

    zone "labs.htt-consult.com" {
    type master;
    file "labs.htt-consult.com.hosts";    };
    zone "intelcon.htt-consult.com" {
    type master;
    file "intelcon.htt-consult.com.hosts";    };
    zone "mobile.htt-consult.com" {
    type master;
    file "mobile.htt-consult.com.hosts";    };
    zone "test.htt-consult.com" {
    type master;
    file "test.httin-consult.com.hosts";    };
    zone "128.168.192.in-addr.arpa" {
    type master;
    file "128.168.192.in-addr.arpa.zone";  };
    zone "0-24.128.168.192.in-addr.arpa" {
    type master;
    file "0-24.128.168.192.in-addr.arpa.zone";    };
    zone "htt" {
    type master;
    file "htt.zone";  };
    zone "home.htt" {
    type master;
    file "home.htt.zone";    };


Do you also want my named.external?


On 8/3/22 09:39, Greg Choules wrote:

Hi Robert.
May we see the file /etc/resolv.conf and your BIND configuration? It's 
difficult to guess what might be going on with only a small snippet of 
information.
If you "ping somewhere" (or "ssh a-server", or whatever) the OS will 
consult resolv.conf to determine where to send DNS queries. If that's 
not your local instance of BIND then you could be looking for trouble 
in the wrong place.


If you *do* have an address of the local machine as the first 
'nameserver' entry in resolv.conf you will need to know what that 
query looks like to determine how BIND is going to handle it.
You also need to know what BIND will try and do when it does receive 
queries.


Packet captures are your friend here, using tcpdump (to disk, not to 
screen). Gather evidence first, then make theories.


Cheers, Greg

On Wed, 3 Aug 2022 at 14:29, Robert Moskowitz  wrote:

Part of my problem is that caching does not seem to be working in my
internal view.

Something is happening such that my internal systems AND the server
itself cannot resolve names and looses it even 5 min later,
indicating
not caching.

I read https://kb.isc.org/docs/aa-00851

In my include for the internal view (named.internal) I have:

 match-clients        { httnets; };
     match-destinat

Re: Stopping ddos

[Robert Moskowitz]

Thanks.  I will look into this.

On 8/3/22 07:47, Victor Johansson via bind-users wrote:


Hey,

I just want to add that there is a better way to do this in iptables 
with hashlimit. The normal rate limit in iptables is too crude.


Below is an example from the rate-limit-chain, to which you simply 
send all port 53 traffic from the INPUT chain (make sure to exclude 
127.0.0.1/127.0.0.53 though :) ).



-A INPUT -p udp -m udp --dport 53 -j DNS-RATE-LIMIT
-A INPUT -p tcp -m tcp --dport 53 -j DNS-RATE-LIMIT

-A DNS-RATE-LIMIT -s 127.0.0.1/32 -m comment --comment "Dont 
rate-limit localhost" -j RETURN
-A DNS-RATE-LIMIT -m hashlimit --hashlimit-upto 100/sec 
--hashlimit-burst 300 --hashlimit-mode srcip --hashlimit-name DNS-drop 
--hashlimit-htable-expire 2000 -j ALLOW

-A DNS-RATE-LIMIT -m limit --limit 1/sec -j LOG --log-prefix "DNS-drop: "
-A DNS-RATE-LIMIT -m comment --comment "ansible[dns rate limiting]" -j 
DROP



//Victor


On 8/2/22 23:16, Michael De Roover wrote:
For my servers I'm using iptables rules to achieve ratelimiting. They 
look as follows:
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent 
--update --seconds 600 --hitcount 4 --name DEFAULT --mask 
255.255.255.255 --rsource -j DROP
-A INPUT -p tcp -m tcp --dport 25 -m state --state NEW -m recent 
--set --name DEFAULT --mask 255.255.255.255 --rsource


It should be fairly trivial to convert these to use UDP 53, and tweak 
the timings you want. These rules are intended to allow 4 connections 
(which normally should be entire SMTP transactions) every 10 minutes. 
Since I have 2 edge nodes with these rules, that is doubled to 8 
connections total. If you're an authoritative name server only, 
realistically mostly recursors / caching servers would query your 
servers and not too often. You can easily restrict traffic here. If 
you're a recursor too, this becomes a bit more complicated.


Regarding the legitimate queries, it would be prudent to allow common 
recursors (Google, Cloudflare, Quad9 etc) to have exceptions to this 
rule. Just allow their IP addresses to send traffic either 
unrestricted, or using a more relaxed version of the above.


HTH,
Michael

On Tue, 2022-08-02 at 16:02 -0400, Robert Moskowitz wrote:
Recently I have been having problems with my server not responding 
to my
requests.  I thought it was all sorts of issues, but I finally 
looked at

the logs and:

Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 114.29.194.4#11205
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
114.29.216.196#64956 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
64.68.114.141#39466

(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
209.197.198.45#13280 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80
114.29.202.117#41955 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 62.109.204.22#4406
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:49 onlo named[6155]: client @0xa9420720 64.68.104.9#38518
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:50 onlo named[6155]: client @0xaa882dc8 
114.29.202.117#9584

(.): view external: query (cache) './A/IN' denied

grep -c denied messages
45868

And that is just since Jul 31 3am.

This is fairly recent so I never looked into what I might do to protect
against this.  I am the master for my domain, so I do need to allow for
legitimate queries.

Any best practices on this?

I am running bind 9.11.4

thanks





-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

caching does not seem to be working for internal view

[Robert Moskowitz]

Part of my problem is that caching does not seem to be working in my 
internal view.


Something is happening such that my internal systems AND the server 
itself cannot resolve names and looses it even 5 min later, indicating 
not caching.


I read https://kb.isc.org/docs/aa-00851

In my include for the internal view (named.internal) I have:

    match-clients        { httnets; };
    match-destinations    { httnets; };
    allow-query        { httnets; };
    allow-query-cache    { httnets; };
    allow-recursion        { any; };
    recursion yes;
    empty-zones-enable yes;

Yet I get on my DNS server:

ping www.google.com
ping: www.google.com: Name or service not known

Then later it works.

Then later it doesn't again.

Sigh.  If at least caching was working for internal use, I would be able 
to work more smoothy?





--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Stopping ddos

[Robert Moskowitz via bind-users]

On 8/2/22 17:30, Nathan Ollerenshaw via bind-users wrote:

On 8/2/22 1:02 PM, Robert Moskowitz wrote:
Recently I have been having problems with my server not responding to 
my requests.  I thought it was all sorts of issues, but I finally 
looked at the logs and:


You're being used as an unwilling participant in a DNS amplification 
attack.


Reconfigure your server to not be a public recursive DNS server. Only 
respond to requests for your zones.


If you are also providing caching DNS for clients, use views to only 
allow those clients to use the server for recursive lookups.



My clients use my internal view.  My external view has:

    match-clients        { any; };
    match-destinations    { any; };
    allow-query        { any; };
    allow-query-cache    { localhost; };
    recursion no;

I am way behind the times, as I really have not made any significant 
changes to my config for a couple years.  Things have been stable.


And I am running CentOS7-arm which only has 9.11.4...

BTW, I am in the market for a 'affordable' DNS box to run here and get 
out of the business of maintaining my own software.  I am approaching 
72, and not something I want to do anymore.  And I have not see a 
service provider that would let me really config my own zone files...


--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Stopping ddos

[Robert Moskowitz]

Recently I have been having problems with my server not responding to my 
requests.  I thought it was all sorts of issues, but I finally looked at 
the logs and:


Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 114.29.194.4#11205 
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
114.29.216.196#64956 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 64.68.114.141#39466 
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
209.197.198.45#13280 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 
114.29.202.117#41955 (.): view external: query (cache) './A/IN' denied
Aug  2 15:47:19 onlo named[6155]: client @0xaa3cad80 62.109.204.22#4406 
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:49 onlo named[6155]: client @0xa9420720 64.68.104.9#38518 
(.): view external: query (cache) './A/IN' denied
Aug  2 15:47:50 onlo named[6155]: client @0xaa882dc8 114.29.202.117#9584 
(.): view external: query (cache) './A/IN' denied


grep -c denied messages
45868

And that is just since Jul 31 3am.

This is fairly recent so I never looked into what I might do to protect 
against this.  I am the master for my domain, so I do need to allow for 
legitimate queries.


Any best practices on this?

I am running bind 9.11.4

thanks

--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Providing GeoIP information for servers

[Robert Moskowitz]

On 05/11/2017 10:46 AM, Timothe Litt wrote:

On 10-May-17 17:50, John W. Blue wrote:

>From the it-could-be-worse department:

https://arstechnica.com/tech-policy/2016/08/kansas-couple-sues-ip-mapping-firm-for-turning-their-life-into-a-digital-hell/

I am more a fan of continental geolocation accuracy when it comes to IP 
addresses.

John
If your static IP address has a reverse name in DNS, it's a short hop 
through whois to your actual location.


Well, usually. It is possible that none of the contact addresses are 
where the IP address is located - especially for large organizations. 
And there are the whois proxies that obscures your physical location.


My whois information is there, if someone wanted to know.

But I was thinking to get the LOC for city hall and use that. 
Police/fire are right next door.  :)


We don't have any above-ground water to use for the GPS LOC  ;)

Afterall, my desire is to show that my servers are in Oak Park, not 
Plymouth MI.




Still, it's pretty hard to hide.  (Even in a Kansas lake.)

Depending on your situation, you may wish to have different accuracy 
and/or precision in internal and external LOC records.


But on the original topic:  Contact Maxmind and see if they'll fix 
your address. 
https://support.maxmind.com/geoip-data-correction-request/ They may 
require evidence that Comcast has delegated the address to you.


Worth doing.  I have the contract for the static address assignment.



Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.



From: bind-users  on behalf of Mark 
Andrews


AFAIK Maxmind et al don't lookup LOC records.  That being said if
enough people published LOC records they might start.

For Google you can update the location using a app which uses the
phone's GPS.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET:ma...@isc.org





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Providing GeoIP information for servers

[Robert Moskowitz]

On 05/10/2017 05:41 PM, Mark Andrews wrote:

In message , Robert Mosko
witz writes:

I am kind of tired in my systems being reported as being in Plymouth MI
instead of Oak Park MI.  That is the best Comcast seems to be willing to
do for where my IP addresses (which are static) reside.

Is there anyway to provide location information for a server via DNS
that would feed into GeoIP?  For example, do LOC records work for this?

thanks

AFAIK Maxmind et al don't lookup LOC records.  That being said if
enough people published LOC records they might start.

For Google you can update the location using a app which uses the
phone's GPS.


I hate things that insist that I leave GPS on.  I only turn it on when I 
need it for directions or for exercise mapping (same thing). The UofMich 
weather app does not work without GPS on.  I really need to complain to 
them about that...


I will publish LOC records and see what happens

thanks Mark

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Providing GeoIP information for servers

[Robert Moskowitz]

I am kind of tired in my systems being reported as being in Plymouth MI 
instead of Oak Park MI.  That is the best Comcast seems to be willing to 
do for where my IP addresses (which are static) reside.


Is there anyway to provide location information for a server via DNS 
that would feed into GeoIP?  For example, do LOC records work for this?


thanks

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

SOLVED - Re: Bind failing to start on new 9.9.4 server

[Robert Moskowitz]

File permission problems.

On 02/09/2017 10:38 AM, Ray Bellis wrote:

On 09/02/2017 15:32, Robert Moskowitz wrote:


Now doing it 'right' and seeing:

09-Feb-2017 09:59:52.191 could not open file '/run/named/named.pid':
Permission denied
09-Feb-2017 09:59:52.192 generating session key for dynamic DNS
09-Feb-2017 09:59:52.192 could not open file '/run/named/session.key':
Permission denied
09-Feb-2017 09:59:52.193 could not create /run/named/session.key
09-Feb-2017 09:59:52.193 failed to generate session key for dynamic DNS:
permission denied
09-Feb-2017 09:59:52.193 sizing zone task pool based on 21 zones

so perhaps some permissions problems?  I am su as root.

Are you specifying the '-u ' flag to named, and does that user
have read / write permissions to /run/named ?

[ also, does the config specify use of chroot? ]


then after all the auto zones:

...

Now why am I getting network unreachable?  I can ping out to a lot of
addrs.




When I rsynced all my backed up zone files, I then had to chown in 
/var/named.


Well, I set /var/named/data to root:named, this made named create

/var/named/data/named.run as root:named, which then named could not 
write to!


did a chown to named:named, rm the bad named.run, restarted named, and 
all is working.


nits

They get you every time.

Thanks for the help.


Bob


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind failing to start on new 9.9.4 server

[Robert Moskowitz]

Strange..

On 02/09/2017 09:31 AM, Ray Bellis wrote:

On 09/02/2017 14:28, Robert Moskowitz wrote:

I am migrating to Centos7 from Centos6.  Going from Bind 9.8.2 to 9.9.4,
I am building this on a new server.  I currently do not have DNSSEC
enabled, and not enabling it for the initial migration work.

I have looked over changes in named.conf and believe I have made the
necessary changes.  My named.conf is  loading as are the zone files.
This is what 'systemctl -l status named' shows:

I'd suggest that you try starting named manually with the '-g' flag so
that it sends all output to stderr without forking.

This should hopefully reveal why it's failing to start.


Now doing it 'right' and seeing:

09-Feb-2017 09:59:52.191 could not open file '/run/named/named.pid': 
Permission denied

09-Feb-2017 09:59:52.192 generating session key for dynamic DNS
09-Feb-2017 09:59:52.192 could not open file '/run/named/session.key': 
Permission denied

09-Feb-2017 09:59:52.193 could not create /run/named/session.key
09-Feb-2017 09:59:52.193 failed to generate session key for dynamic DNS: 
permission denied

09-Feb-2017 09:59:52.193 sizing zone task pool based on 21 zones

so perhaps some permissions problems?  I am su as root.

then after all the auto zones:

09-Feb-2017 09:59:53.682 all zones loaded
09-Feb-2017 09:59:53.690 running
09-Feb-2017 09:59:53.691 zone 128.168.192.in-addr.arpa/IN/internal: 
sending notifies (serial 2009031701)
09-Feb-2017 09:59:53.692 zone labs.htt-consult.com/IN/internal: sending 
notifies (serial 2015031801)
09-Feb-2017 09:59:53.695 zone home.htt/IN/internal: sending notifies 
(serial 2013041501)
09-Feb-2017 09:59:53.719 zone labs.htt-consult.com/IN/external: sending 
notifies (serial 2015031801)
09-Feb-2017 09:59:53.726 zone htt-consult.com/IN/external: sending 
notifies (serial 2015123001)
09-Feb-2017 09:59:53.732 error (network unreachable) resolving 
'ns1.icsl.net/A/IN': 2001:503:c27::2:30#53
09-Feb-2017 09:59:53.734 error (network unreachable) resolving 
'./DNSKEY/IN': 2001:503:c27::2:30#53
09-Feb-2017 09:59:53.735 error (network unreachable) resolving 
'ns1.icsl.net//IN': 2001:503:c27::2:30#53
09-Feb-2017 09:59:53.736 error (network unreachable) resolving 
'./NS/IN': 2001:503:c27::2:30#53
09-Feb-2017 09:59:53.818 error (unexpected RCODE REFUSED) resolving 
'ns1.icsl.net/A/IN': 12.36.173.2#53
09-Feb-2017 09:59:53.820 error (unexpected RCODE REFUSED) resolving 
'ns1.icsl.net//IN': 12.36.173.2#53
09-Feb-2017 09:59:53.822 error (unexpected RCODE REFUSED) resolving 
'ns2.icsl.net/A/IN': 12.36.173.2#53
09-Feb-2017 09:59:53.843 error (unexpected RCODE REFUSED) resolving 
'ns2.icsl.net//IN': 12.36.173.2#53
09-Feb-2017 09:59:53.918 error (network unreachable) resolving 
'ns1.mudkips.net/A/IN': 2607:f4b8:2600:6::1#53


Now why am I getting network unreachable?  I can ping out to a lot of addrs.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind failing to start on new 9.9.4 server

[Robert Moskowitz]

On 02/09/2017 09:55 AM, Alan Clegg wrote:

On 2/9/17 8:53 AM, Robert Moskowitz wrote:


On 02/09/2017 09:31 AM, Ray Bellis wrote:

On 09/02/2017 14:28, Robert Moskowitz wrote:

I am migrating to Centos7 from Centos6.  Going from Bind 9.8.2 to 9.9.4,
I am building this on a new server.  I currently do not have DNSSEC
enabled, and not enabling it for the initial migration work.

I have looked over changes in named.conf and believe I have made the
necessary changes.  My named.conf is  loading as are the zone files.
This is what 'systemctl -l status named' shows:

I'd suggest that you try starting named manually with the '-g' flag so
that it sends all output to stderr without forking.

This should hopefully reveal why it's failing to start.


'-g' is not a valid option.

"named -g" isn't valid?

Wow, they really HAVE changed the code.


Careless me.

I tried 'bind -g' rather than 'named -g'

Problem when a major service, bind, is the same as a program function.

ARGH!!!   :)

Making some headway.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind failing to start on new 9.9.4 server

[Robert Moskowitz]

On 02/09/2017 09:31 AM, Ray Bellis wrote:

On 09/02/2017 14:28, Robert Moskowitz wrote:

I am migrating to Centos7 from Centos6.  Going from Bind 9.8.2 to 9.9.4,
I am building this on a new server.  I currently do not have DNSSEC
enabled, and not enabling it for the initial migration work.

I have looked over changes in named.conf and believe I have made the
necessary changes.  My named.conf is  loading as are the zone files.
This is what 'systemctl -l status named' shows:

I'd suggest that you try starting named manually with the '-g' flag so
that it sends all output to stderr without forking.

This should hopefully reveal why it's failing to start.


'-g' is not a valid option.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind failing to start on new 9.9.4 server

[Robert Moskowitz]

On 02/09/2017 09:31 AM, Ray Bellis wrote:

On 09/02/2017 14:28, Robert Moskowitz wrote:

I am migrating to Centos7 from Centos6.  Going from Bind 9.8.2 to 9.9.4,
I am building this on a new server.  I currently do not have DNSSEC
enabled, and not enabling it for the initial migration work.

I have looked over changes in named.conf and believe I have made the
necessary changes.  My named.conf is  loading as are the zone files.
This is what 'systemctl -l status named' shows:

I'd suggest that you try starting named manually with the '-g' flag so
that it sends all output to stderr without forking.

This should hopefully reveal why it's failing to start.


Since I use systemctl to start the service, I would have to do some 
digging to figure out something like this that i haven't done in a 
couple decades.  :)



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Bind failing to start on new 9.9.4 server

[Robert Moskowitz]

I am migrating to Centos7 from Centos6.  Going from Bind 9.8.2 to 9.9.4, 
I am building this on a new server.  I currently do not have DNSSEC 
enabled, and not enabling it for the initial migration work.


I have looked over changes in named.conf and believe I have made the 
necessary changes.  My named.conf is  loading as are the zone files.  
This is what 'systemctl -l status named' shows:


● named.service - Berkeley Internet Name Domain (DNS)
   Loaded: loaded (/usr/lib/systemd/system/named.service; enabled; 
vendor preset: disabled)
   Active: failed (Result: exit-code) since Thu 2017-02-09 09:08:25 
EST; 14min ago
  Process: 1851 ExecStart=/usr/sbin/named -u named $OPTIONS 
(code=exited, status=1/FAILURE)
  Process: 1847 ExecStartPre=/bin/bash -c if [ ! 
"$DISABLE_ZONE_CHECKING" == "yes" ]; then /usr/sbin/named-checkconf -z 
/etc/named.conf; else echo "Checking of zone files is disabled"; fi 
(code=exited, status=0/SUCCESS)


Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: 
view internal: 74.100.IN-ADDR.ARPA
Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: 
view internal: 75.100.IN-ADDR.ARPA
Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: 
view internal: 76.100.IN-ADDR.ARPA
Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: 
view internal: 77.100.IN-ADDR.ARPA
Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: 
view internal: 78.100.IN-ADDR.ARPA
Feb 09 09:08:25 onlo.htt-consult.com named[1855]: automatic empty zone: 
view internal: 79.100.IN-ADDR.ARPA
Feb 09 09:08:25 onlo.htt-consult.com systemd[1]: named.service: control 
process exited, code=exited status=1
Feb 09 09:08:25 onlo.htt-consult.com systemd[1]: Failed to start 
Berkeley Internet Name Domain (DNS).
Feb 09 09:08:25 onlo.htt-consult.com systemd[1]: Unit named.service 
entered failed state.

Feb 09 09:08:25 onlo.htt-consult.com systemd[1]: named.service failed.

Not very informative with all those auto empty zone messages.  Is there 
a way to suppress those messages, or is this part of the problem?


I worked at viewing /var/log/messages, digging through all those auto 
empty zone messages and found the following:


Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
101.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
102.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
103.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
104.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
105.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
106.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
107.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
108.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
109.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo systemd: named.service: control process exited, 
code=exited

 status=1
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
110.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo systemd: Failed to start Berkeley Internet Name 
Domain (DNS

).
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
111.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo systemd: Unit named.service entered failed state.
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
112.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo systemd: named.service failed.
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
113.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
114.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
115.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
116.100.I

N-ADDR.ARPA
Feb  9 09:08:25 onlo named[1855]: automatic empty zone: view internal: 
117.100.I




named enters failed state and no reason why is given.  Perhaps it is the 
number of empty zones generated?


Thank you for your help on this.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

SOLVED - Re: Secondarying DLZ zones

[Robert Moskowitz]

At least the 'right' way with turning down the SOA TTL for the zone.

This is one of the set it and forget it items (at least for me), and 
once I started reading finding enough articles on secondaries it was an 
oh yeah moment.


On 09/07/2015 04:09 PM, Robert Moskowitz wrote:
On the Samba list, I was told that it is working (bug from2 years ago, 
still open, was fixed):


https://bugzilla.samba.org/show_bug.cgi?id=9634

But Notify does not work:

"yes it does work. But the DLZ bind will not notify any slaves, when 
the repository changes. This can be painful, especially for longer TTL 
values."


Is there some way to get the secondary to check frequently, like once 
an hour?


On 09/07/2015 03:12 PM, Robert Moskowitz wrote:

It seems I have this working, but...

I have a regular Centos7 Bind 9.9 server that I want to secondary a 
Samba AD (Also Centos7) DLZ zone.


On the DNS server (192.168.192.5) I have:

zone "home.htt" {
type slave;
file "slaves/bak.home.htt";
masters {192.168.192.2; };
};

On the Samba AD I have:

dlz "AD DNS Zone" {
# For BIND 9.9.x
 database "dlopen /usr/lib/samba/bind9/dlz_bind9_9.so";
};

And it seems works.

On 192.168.192.2 I saw:

Sep  7 14:00:05 homebase named[1133]: client 192.168.192.5#51888 
(home.htt): transfer of 'home.htt/IN': AXFR started
Sep  7 14:00:05 homebase named[1133]: client 192.168.192.5#51888 
(home.htt): transfer of 'home.htt/IN': AXFR ended



On the DNS server, 192.168.192.5, I can resolve hosts in the home.htt 
zone.


But there is no slaves/bak.home.htt file.  Perhaps my notes are old 
from when I did this some years back (and static master zone), but I 
would think that there should be the slaves/bak.home.htt file?


I also need to implement Notify for changes to the home.htt zone.

thanks


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Secondarying DLZ zones

[Robert Moskowitz]

On the Samba list, I was told that it is working (bug from2 years ago, 
still open, was fixed):


https://bugzilla.samba.org/show_bug.cgi?id=9634

But Notify does not work:

"yes it does work. But the DLZ bind will not notify any slaves, when the 
repository changes. This can be painful, especially for longer TTL values."


Is there some way to get the secondary to check frequently, like once an 
hour?


On 09/07/2015 03:12 PM, Robert Moskowitz wrote:

It seems I have this working, but...

I have a regular Centos7 Bind 9.9 server that I want to secondary a 
Samba AD (Also Centos7) DLZ zone.


On the DNS server (192.168.192.5) I have:

zone "home.htt" {
type slave;
file "slaves/bak.home.htt";
masters {192.168.192.2; };
};

On the Samba AD I have:

dlz "AD DNS Zone" {
# For BIND 9.9.x
 database "dlopen /usr/lib/samba/bind9/dlz_bind9_9.so";
};

And it seems works.

On 192.168.192.2 I saw:

Sep  7 14:00:05 homebase named[1133]: client 192.168.192.5#51888 
(home.htt): transfer of 'home.htt/IN': AXFR started
Sep  7 14:00:05 homebase named[1133]: client 192.168.192.5#51888 
(home.htt): transfer of 'home.htt/IN': AXFR ended



On the DNS server, 192.168.192.5, I can resolve hosts in the home.htt 
zone.


But there is no slaves/bak.home.htt file.  Perhaps my notes are old 
from when I did this some years back (and static master zone), but I 
would think that there should be the slaves/bak.home.htt file?


I also need to implement Notify for changes to the home.htt zone.

thanks


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Secondarying DLZ zones

[Robert Moskowitz]

It seems I have this working, but...

I have a regular Centos7 Bind 9.9 server that I want to secondary a 
Samba AD (Also Centos7) DLZ zone.


On the DNS server (192.168.192.5) I have:

zone "home.htt" {
type slave;
file "slaves/bak.home.htt";
masters {192.168.192.2; };
};

On the Samba AD I have:

dlz "AD DNS Zone" {
# For BIND 9.9.x
 database "dlopen /usr/lib/samba/bind9/dlz_bind9_9.so";
};

And it seems works.

On 192.168.192.2 I saw:

Sep  7 14:00:05 homebase named[1133]: client 192.168.192.5#51888 
(home.htt): transfer of 'home.htt/IN': AXFR started
Sep  7 14:00:05 homebase named[1133]: client 192.168.192.5#51888 
(home.htt): transfer of 'home.htt/IN': AXFR ended



On the DNS server, 192.168.192.5, I can resolve hosts in the home.htt zone.

But there is no slaves/bak.home.htt file.  Perhaps my notes are old from 
when I did this some years back (and static master zone), but I would 
think that there should be the slaves/bak.home.htt file?


I also need to implement Notify for changes to the home.htt zone.

thanks


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Installing bind is not very clear for me

[Robert Moskowitz]

On 09/03/2015 01:45 PM, Leandro wrote:

Dear All:
While installing bind still have not clear some issues:
Im using Centos 6.6 since Im not very comfortable with Centos7 yet.

My final goal is to get an updated and stable version and also use 
json format for the statistics channel.


1) Some bind users recommended to get at least a 9.10 release but:
Using yum and repos, founded that 9.8 is available for Centos 6.6.
Also , Centos recommend not to build from source when possible.

2)Building bind 9.10 from source is not complicated but:
Could not install on chroot.
Could not get the json or xml statistics , only html.


If you need 9.10 for json, and you want to stay with Centos, you WILL be 
doing your own builds.  I am working with C7 and it is 'only' 9.9.4 (or 
at least that is what dig is reporting).


There are a lot of fun debates that if you are using selinux on Centos, 
you do not need chroot.  In fact chroot introduces its own set of 
challenges.  I tend to believe this, though it was years ago that I went 
through the arguments.


There are people on the Centos list that build their own bind.  Ask over 
there.





Any ideas ?
Is possible to update / add my repos to install a recent version with 
json support and chrooted with:
If not , Is it possible to build from source in chrooted enviroment ? 
Any doc ?


btw: Server is not in production yet.

Thanks!!
Leandro.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Installing bind is not very clear for me

[Robert Moskowitz]

On 09/03/2015 05:02 PM, Reindl Harald wrote:



Am 03.09.2015 um 22:59 schrieb Robert Moskowitz:

On 09/03/2015 04:35 PM, Leandro wrote:

Ok ...
I got BIND 9.10.2-P3  working.
I compiled with

./configure --with-openssl --enable-threads --with-libxml2 
--with-libjson

make
make install

Json statistics channel is working and chroot is not longer mandatory.


But do make sure you have selinux enforced.  Or run behind multiple
firewalls...


behind *multiple firewalls* - ?!?! - oh come on and get serious 
instead promote snakeoil - typically BIND is *not* running as root and 
hence does not need any special handling compared to any other network 
service


get rid of the horror stories from the 1990's..


I dealt with customers that did suffer from island hopping attacks. Deep 
penetration.  They had some systems not registered and vulnerable 
allowing what was thought safe to be stolen.


But I am done with that work.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Installing bind is not very clear for me

[Robert Moskowitz]

On 09/03/2015 04:35 PM, Leandro wrote:

Ok ...
I got BIND 9.10.2-P3  working.
I compiled with

./configure --with-openssl --enable-threads --with-libxml2 --with-libjson
make
make install

Json statistics channel is working and chroot is not longer mandatory.


But do make sure you have selinux enforced.  Or run behind multiple 
firewalls...



Im happy.

Thanks!
Leandro.



On 03/09/15 15:47, Mike Hoskins (michoski) wrote:

Few points for clarification:

With rhel/centos you're not getting the major version as reported.  You
need to look at the changlog for the package to see what fixes/features
have been backported.  That effort including associated QA is part of 
what

you're paying for with rhel or getting for free as part of centos.

If you need to build your own, there are community srpms for that so you
don't have to start from scratch.

http://www.five-ten-sg.com/mapper/bind

ISC themselves has moved away from chroot as an absolute best practice.
Critically think if it really makes sense for you.

https://deepthought.isc.org/article/AA-00768/0/Getting-started-with-BIND-ho 


w-to-build-and-run-named-with-a-basic-recursive-configuration.html


On 9/3/15, 2:40 PM, "bind-users-boun...@lists.isc.org on behalf of 
Robert

Moskowitz" <bind-users-boun...@lists.isc.org on behalf of
r...@htt-consult.com> wrote:
Ok


On 09/03/2015 01:45 PM, Leandro wrote:

Dear All:
While installing bind still have not clear some issues:
Im using Centos 6.6 since Im not very comfortable with Centos7 yet.

My final goal is to get an updated and stable version and also use
json format for the statistics channel.

1) Some bind users recommended to get at least a 9.10 release but:
Using yum and repos, founded that 9.8 is available for Centos 6.6.
Also , Centos recommend not to build from source when possible.

2)Building bind 9.10 from source is not complicated but:
Could not install on chroot.
Could not get the json or xml statistics , only html.
If you need 9.10 for json, and you want to stay with Centos, you 
WILL be

doing your own builds.  I am working with C7 and it is 'only' 9.9.4 (or
at least that is what dig is reporting).

There are a lot of fun debates that if you are using selinux on Centos,
you do not need chroot.  In fact chroot introduces its own set of
challenges.  I tend to believe this, though it was years ago that I 
went

through the arguments.

There are people on the Centos list that build their own bind.  Ask 
over

there.



Any ideas ?
Is possible to update / add my repos to install a recent version with
json support and chrooted with:
If not , Is it possible to build from source in chrooted enviroment ?
Any doc ?

btw: Server is not in production yet.

Thanks!!
Leandro.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Solved - Re: A tale of two nameservers - resolution problems

[Robert Moskowitz]

On 09/03/2015 04:09 AM, Matus UHLAR - fantomas wrote:

On 01.09.15 13:36, Robert Moskowitz wrote:

On the Fedora-arm list I was told about systemd-timesyncd.

Much better for these systems than chronyd which is suppose to be the 
replacement for ntpdate...


chrony is replacement for ntpd (not ntpdate!) on systems that are not 
always

online.
"has been hooked up with networkd to only operate when network 
connectivity

  is available"

according to:
http://lists.freedesktop.org/archives/systemd-devel/2014-May/019537.html

I find that a bit different and i believe that chronyd is better for 
systems

that are often offline, although it doesn't fix the issue with boards
without RTC.


Newer version has added the -s option specifically for these systems.

On Fedora (and soon RHEL/Centos): /etc/sysconfig/chronyd
OPTIONS="-s"

Also: /etc/chrony.conf
#rtcsync
rtcdevice /dev/nonexist


This is useful if your home network nameserver is not adequately 
protected from power outages and comes back up before the Internet 
connection.  A few other interesting edge cases.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Final on - Re: A tale of two nameservers - resolution problems

[Robert Moskowitz]

I have learned a bit in the past time period.

First, adding a 2nd DNS server, in this case my ISP's, got around this 
timing problem, becuase the 'right fix' is not available yet.


The answer is to stop using old ntpd and use modern chronyd.  But more 
than that, ver 2.1.1 which is available in Fedora 22, but not (yet) in 
Centos 7 (perhaps 7.2).  You start chrony with the -s option; this tells 
it you have a bad, or no rtc, and to regularly save the time to a file 
which is read when chrony starts up.  I have tested this out on F22 and 
it works as advertised.


There is also systemd-timesync, but Fedora/redhat went the chrony route, 
and I got more help figuring it out.


On to the next fun challenge.

On 09/01/2015 12:16 PM, Sam Wilson wrote:

In article <mailman.2626.1441122408.26362.bind-us...@lists.isc.org>,
  Robert Moskowitz <r...@htt-consult.com> wrote:


I will be looking more into this.  Obvious when you get ones nose
dragged into time wrong on boot.  This is actually a broader problem on
arm SoC booting.  Your logs all have the wrong time for the boot
messages until there is a network to get time.  I have some ideas for a
process that will set time a boot to the time of the last poweroff.  at
least that is 'close enough' for starters.

I believe that's the solution Apple adopted for the AppleTV, which has
no rtc and couldn't use a certificate to connect to a wireless network
because the certificate wasn't valid in 1970.

Sam



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Solved - Re: A tale of two nameservers - resolution problems

[Robert Moskowitz]

On 09/01/2015 12:16 PM, Sam Wilson wrote:

In article <mailman.2626.1441122408.26362.bind-us...@lists.isc.org>,
  Robert Moskowitz <r...@htt-consult.com> wrote:


I will be looking more into this.  Obvious when you get ones nose
dragged into time wrong on boot.  This is actually a broader problem on
arm SoC booting.  Your logs all have the wrong time for the boot
messages until there is a network to get time.  I have some ideas for a
process that will set time a boot to the time of the last poweroff.  at
least that is 'close enough' for starters.

I believe that's the solution Apple adopted for the AppleTV, which has
no rtc and couldn't use a certificate to connect to a wireless network
because the certificate wasn't valid in 1970.


On the Fedora-arm list I was told about systemd-timesyncd.

Much better for these systems than chronyd which is suppose to be the 
replacement for ntpdate...


I am looking into this; it sounds exactly what I need.  Plus when you 
make your os image you can:


touch //var/lib/systemd/clock
chown systemd-timesync:systemd-timesync //var/lib/systemd/clock

And firstboot will have a rather current time.

Oh course this assumes the image builders include systemd-timesync as 
part of the base install.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: A tale of two nameservers - resolution problems

[Robert Moskowitz]

On 09/01/2015 09:20 AM, John Miller wrote:

If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?


I don't believe this and I have some serious problems.

Part of my challenge is I am running the new server on an armv7 board 
that does not have a rtc.  So when the system boots, the time is jan 1 
1970.  The first thing you want to run is ntp to set the time, but 
requires named running and resolving.


For the 'fun' of it, I used 'date' to set the time to now, and then no 
problem resolving 0.centos.pool.ntp.org.  So there is something about 
that resolution that does not like the early date.


So I am caught in a time bind here!

Is there anyway to get bind not to be particular about system time at first?



John

On Tue, Sep 1, 2015 at 9:09 AM, Robert Moskowitz <r...@htt-consult.com> wrote:

I have one nameserver running bind 9.8.2 and a new one running 9.9.4.

Both can resolve www.ietf.org

Only the 9.8.2 can resolve 0.centos.pool.ntp.org

I literally rsynced all the of the conf and zone files from the old to the
new, then changed all of the server name references.  I have done this
before.  I have another box running the 9.8.2 code that I built the same way
and it resolves both fqdns just fine.

I am a lost at what is the problem.  Both have the same named.conf:

//
//

 include "/etc/named/named.acl";

options
{
 listen-on port 53 { any; };
 listen-on-v6 port 53 { any; };

 allow-query{ localhost; };
 allow-query-cache{ localhost; };
 recursion no;

 directory "/var/named";
 dump-file "/var/named/data/cache_dump.db";
 statistics-file "/var/named/data/named_stats.txt";
 memstatistics-file "/var/named/data/named_mem_stats.txt";

//dnssec-enable yes;
//dnssec-validation yes;
//dnssec-lookaside auto;

 dnssec-enable no;
 dnssec-validation no;

 /* Path to ISC DLV key */
//bindkeys-file "/etc/named.iscdlv.key";

//managed-keys-directory "/var/named/dynamic";


};
logging
{
/*  If you want to enable debugging, eg. using the 'rndc trace' command,
  *  named will try to write the 'named.run' file in the $directory
(/var/named).
  *  By default, SELinux policy does not allow named to modify the
/var/named directory,
  *  so put the default debug log file in data/ :
  */
 channel default_debug {
 file "data/named.run";
 severity dynamic;
 };
};

view "internal"
{

 include "/etc/named/named.internal";

};
view"external"
{

 include "/etc/named/named.external";

};

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

==
and named.internal has:

/* This view will contain zones you want to serve only to "internal" clients
  * that have addresses that are not on your directly attached LAN interface
subnets:
  */
 match-clients{ httnets; };
 match-destinations{ httnets; };
 allow-query{ httnets; };
 allow-query-cache{ httnets; };
 allow-recursion{ httnets; };
 recursion yes;
 empty-zones-enable yes;

//include "/etc/named/named.trusted.key";
 include "/etc/named.rfc1912.zones";

 zone "." IN {
 type hint;
 file "named.root";
 };

 // These are your "authoritative" internal zones:

 zone "htt-consult.com" {
 type master;
 file "httin-consult.com.zone";
 };

etc.


==


Is the dnssec disabled possibly the problem?  Like required now?


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

A tale of two nameservers - resolution problems

[Robert Moskowitz]

I have one nameserver running bind 9.8.2 and a new one running 9.9.4.

Both can resolve www.ietf.org

Only the 9.8.2 can resolve 0.centos.pool.ntp.org

I literally rsynced all the of the conf and zone files from the old to 
the new, then changed all of the server name references.  I have done 
this before.  I have another box running the 9.8.2 code that I built the 
same way and it resolves both fqdns just fine.


I am a lost at what is the problem.  Both have the same named.conf:

//
//

include "/etc/named/named.acl";

options
{
listen-on port 53 { any; };
listen-on-v6 port 53 { any; };

allow-query{ localhost; };
allow-query-cache{ localhost; };
recursion no;

directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";

//dnssec-enable yes;
//dnssec-validation yes;
//dnssec-lookaside auto;

dnssec-enable no;
dnssec-validation no;

/* Path to ISC DLV key */
//bindkeys-file "/etc/named.iscdlv.key";

//managed-keys-directory "/var/named/dynamic";


};
logging
{
/*  If you want to enable debugging, eg. using the 'rndc trace' command,
 *  named will try to write the 'named.run' file in the $directory 
(/var/named).
 *  By default, SELinux policy does not allow named to modify the 
/var/named directory,

 *  so put the default debug log file in data/ :
 */
channel default_debug {
file "data/named.run";
severity dynamic;
};
};

view "internal"
{

include "/etc/named/named.internal";

};
view"external"
{

include "/etc/named/named.external";

};

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

==
and named.internal has:

/* This view will contain zones you want to serve only to "internal" clients
 * that have addresses that are not on your directly attached LAN 
interface subnets:

 */
match-clients{ httnets; };
match-destinations{ httnets; };
allow-query{ httnets; };
allow-query-cache{ httnets; };
allow-recursion{ httnets; };
recursion yes;
empty-zones-enable yes;

//include "/etc/named/named.trusted.key";
include "/etc/named.rfc1912.zones";

zone "." IN {
type hint;
file "named.root";
};

// These are your "authoritative" internal zones:

zone "htt-consult.com" {
type master;
file "httin-consult.com.zone";
};

etc.


==


Is the dnssec disabled possibly the problem?  Like required now?


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: A tale of two nameservers - resolution problems

[Robert Moskowitz]

On 09/01/2015 09:36 AM, Reindl Harald wrote:



Am 01.09.2015 um 15:31 schrieb Robert Moskowitz:

On 09/01/2015 09:20 AM, John Miller wrote:

If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?


I don't believe this and I have some serious problems.

Part of my challenge is I am running the new server on an armv7 board
that does not have a rtc.  So when the system boots, the time is jan 1
1970.  The first thing you want to run is ntp to set the time, but
requires named running and resolving.

For the 'fun' of it, I used 'date' to set the time to now, and then no
problem resolving 0.centos.pool.ntp.org.  So there is something about
that resolution that does not like the early date.

So I am caught in a time bind here!

Is there anyway to get bind not to be particular about system time at
first?


what about /etc/hosts and using a "ntpdate customname" at boot 
*before* ntpd and named are started - 


One of the obvious punts I am looking at.

what i honestly don't understand is why you are punishing yourself 
with that ARM crap over years (given all the troubles on other lists)


Because it is FUN!!!  Other reasons too, but those are long to get into.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: A tale of two nameservers - resolution problems

[Robert Moskowitz]

On 09/01/2015 10:38 AM, Reindl Harald wrote:


Am 01.09.2015 um 16:28 schrieb John Miller:
On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz 
<r...@htt-consult.com> wrote:


On 09/01/2015 09:20 AM, John Miller wrote:


If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?



I don't believe this and I have some serious problems.

Part of my challenge is I am running the new server on an armv7 
board that
does not have a rtc.  So when the system boots, the time is jan 1 
1970.  The

first thing you want to run is ntp to set the time, but requires named
running and resolving.

For the 'fun' of it, I used 'date' to set the time to now, and then no
problem resolving 0.centos.pool.ntp.org.  So there is something 
about that

resolution that does not like the early date.

So I am caught in a time bind here!

Is there anyway to get bind not to be particular about system time 
at first?



Hopefully this isn't a production server... rtc's kind of important
;-)  I'll ditto here and say: static /etc/hosts entries or static IPs
in ntp.conf


additionally every network normally should have it's own ntpd using 
the public pool and act as source for all other machines,


But this is the system that will be the internal ntp server  :)  At 
least at first.  One of the base boards I can add has the battery on 
it.  But I would only pay for that for this server.  This is one of the 
other obvious punts:  get a battery rtc.


just because to be nice too the "pool.ntp.org" and hence any other box 
needs just an IP address for doing "ntpdate xx.xx.xx.xx" *before* it's 
own ntpd starts


There will be a lot of arm IoT boxes in the next few years needing their 
time on boot.  Of course booting will not be that frequent, but it will 
interesting to see how it plays out.   And check devices like the 
esp8266, as $6 IoT device.  It also gets its time once connected.



so you just need to make sure the correct order

* ntpdate xx.xx.xx.xx
* start ntpd
* start named


I will be looking more into this.  Obvious when you get ones nose 
dragged into time wrong on boot.  This is actually a broader problem on 
arm SoC booting.  Your logs all have the wrong time for the boot 
messages until there is a network to get time.  I have some ideas for a 
process that will set time a boot to the time of the last poweroff.  at 
least that is 'close enough' for starters.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: A tale of two nameservers - resolution problems

[Robert Moskowitz]

On 09/01/2015 10:28 AM, John Miller wrote:

On Tue, Sep 1, 2015 at 9:31 AM, Robert Moskowitz <r...@htt-consult.com> wrote:


On 09/01/2015 09:20 AM, John Miller wrote:

If you check pcap, logs, etc., is the server's following delegation
for 0.centos.pool.ntp.org? Where do outbound packets stop?


I don't believe this and I have some serious problems.

Part of my challenge is I am running the new server on an armv7 board that
does not have a rtc.  So when the system boots, the time is jan 1 1970.  The
first thing you want to run is ntp to set the time, but requires named
running and resolving.

For the 'fun' of it, I used 'date' to set the time to now, and then no
problem resolving 0.centos.pool.ntp.org.  So there is something about that
resolution that does not like the early date.

So I am caught in a time bind here!

Is there anyway to get bind not to be particular about system time at first?


Hopefully this isn't a production server... rtc's kind of important
;-)


Lack of a battery for the system clock is the norm for arm boards. They 
pretty much expect network time.  This is a problem with designing a 
mobile arm solution.



I'll ditto here and say: static /etc/hosts entries or static IPs in ntp.conf.


Definitely the obvious punt.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Finding authoritative server and last update

[Robert Moskowitz]

I am trying to find out which comcast server is authoritative for

4.254.253.50.in-addr.arpa

and when the zone file for the ptr rr was last updated.

I was told a week ago that the ptr would be updated, but I am still not 
seeing any change...


I am not really good at keeping good notes on using dig.

thanks for help


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Finding authoritative server and last update

[Robert Moskowitz]

On 02/03/2015 05:42 PM, Frank Bulk wrote:

Rob,

I like to use DNSstuff because it can check each path:

http://www.dnsstuff.com/tools#dnsTraversal|type=domainvalue=4.254.253.50.i
n-addr.arparecordType=PTR


But that does not give me the SOA for the comcast NS that is 
authoritative for the rDNS.  Or at least I don't see it on the results page.


but thanks for the tip.



Frank

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Robert Moskowitz
Sent: Tuesday, February 03, 2015 4:01 PM
To: bind-users@lists.isc.org
Subject: Finding authoritative server and last update

I am trying to find out which comcast server is authoritative for

4.254.253.50.in-addr.arpa

and when the zone file for the ptr rr was last updated.

I was told a week ago that the ptr would be updated, but I am still not
seeing any change...

I am not really good at keeping good notes on using dig.

thanks for help


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users






___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Finding authoritative server and last update

[Robert Moskowitz]

On 02/03/2015 05:09 PM, Jeremy C. Reed wrote:

On Tue, 3 Feb 2015, Robert Moskowitz wrote:


I am trying to find out which comcast server is authoritative for

4.254.253.50.in-addr.arpa

and when the zone file for the ptr rr was last updated.

I was told a week ago that the ptr would be updated, but I am still
not seeing any change...

I am not really good at keeping good notes on using dig.

Have a look at output from:

dig +trace 4.254.253.50.in-addr.arpa PTR

dig 254.253.50.in-addr.arpa SOA


Thanks this shows that the supposed update over the weekend probably did 
not occur and that is why I am still seeing the default ptr RR. I was 
assured 24 hour turn around time one month ago.


I suppose if you buy their domain hosting, it 'just works'.

I suspect I will not want them to be the secondary NS for my domain, so 
I am again looking for secondary DNS service that I can afford...



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Finding authoritative server and last update

[Robert Moskowitz]

On 02/03/2015 05:47 PM, Frank Bulk wrote:

There are free ones:
http://www.frankb.us/dns/
http://networking.ringofsaturn.com/Unix/freednsservers.php


Thanks!  I will be following up on this shortly.



Regards,

Frank

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Robert Moskowitz
Sent: Tuesday, February 03, 2015 4:43 PM
To: Jeremy C. Reed
Cc: bind-users@lists.isc.org
Subject: Re: Finding authoritative server and last update


On 02/03/2015 05:09 PM, Jeremy C. Reed wrote:

On Tue, 3 Feb 2015, Robert Moskowitz wrote:


I am trying to find out which comcast server is authoritative for

4.254.253.50.in-addr.arpa

and when the zone file for the ptr rr was last updated.

I was told a week ago that the ptr would be updated, but I am still
not seeing any change...

I am not really good at keeping good notes on using dig.

Have a look at output from:

dig +trace 4.254.253.50.in-addr.arpa PTR

dig 254.253.50.in-addr.arpa SOA

Thanks this shows that the supposed update over the weekend probably did
not occur and that is why I am still seeing the default ptr RR. I was
assured 24 hour turn around time one month ago.

I suppose if you buy their domain hosting, it 'just works'.

I suspect I will not want them to be the secondary NS for my domain, so
I am again looking for secondary DNS service that I can afford...


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to
unsubscribe from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users





___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Glue records for secondary NS

[Robert Moskowitz]

I just found out that I had old garbage in my rgistrar setup for my 
domain.  To wit, an NS server that has not been an NS server for years.  
And now that I use that host name for another usage on another address, 
it was giving lots of problems.  My bad, I should have caught this when 
I moved Registrars almost 2 years ago.


but...

glue records.

I have 3 secondaries run by other domains.  This was to give me some 
geo-diversity.  How do I create glue records for them?  My registrar 
only lets me create glue records within my domain (the web form 
pre-provides the domain part of the fqdn).  I can understand that in not 
allowing people to  populate fqdns on wrong addresses causing 
interesting problems (as I just figured out I have had).



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Glue records for secondary NS

[Robert Moskowitz]

On 12/05/2014 12:30 PM, Casey Deccio wrote:
On Fri, Dec 5, 2014 at 11:47 AM, Robert Moskowitz r...@htt-consult.com 
mailto:r...@htt-consult.com wrote:


I have 3 secondaries run by other domains.  This was to give me
some geo-diversity.  How do I create glue records for them?  My
registrar only lets me create glue records within my domain (the
web form pre-provides the domain part of the fqdn).


Short answer: you don't need, nor should you configure glue, for the 
servers run by the other domains.


It would be nice, then, if all these DNS tool sites would know this and 
not report missing glue records over NS servers in other domains.


thanks



Glue is only necessary if the server names (i.e., the NS targets) are 
subdomains of the child zone.  The reason why they are necessary is to 
prevent a resolution loop.  Here is the relevant text from RFC 1034 
(section 4.2.1) [1]:


In particular, if the name of the name server is itself in the 
subzone, we could be faced with the situation where the NS RRs tell us 
that in order to learn a name server's address, we should contact the 
server using the address we wish to learn. To fix this problem, a zone 
contains glue RRs which are not part of the authoritative data, and 
are address RRs for the servers. These RRs are only necessary if the 
name server's name is below the cut, and are only used as part of a 
referral response.


If the server names are not subdomains of the delegated child zone 
(e.g., your case), then the resolver learns the addresses of the names 
using the normal resolution process. Here is the relevant text from 
RFC 1034 (section 5.3.3) [1]:


These NS RRs list the names of hosts for a zone at or above SNAME.  Copy
the names into SLIST.  Set up their addresses using local data.  It may
be the case that the addresses are not available.  The resolver has many
choices here; the best is to start parallel resolver processes looking
for the addresses while continuing onward with the addresses which are
available.

Cheers,
Casey

[1] http://tools.ietf.org/html/rfc1034


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Value of memory

[Robert Moskowitz]

I have a server that is only running bind 9.8.2 (Centos 6.5).  It has 
2Gb memory and free reports ~1.7Gb used.


I am looking at replacing this server with an armv7 board running 
Redsleeve (until Centos 7 is out and stable for armv7).  I have a choice 
of boards, one with 1Gb memory ($60) and one with 2Gb memory ($90).


This server servers out my zones and supports the couple handfull of 
systems on my net.  I would like to eventually get to DNSSEC, but that 
is another stalled project.


About the only meaningful difference between the two boards (btw, 
Cubieboard2 and Cubietruck) for my needs is the memory.  I know more 
memory is better, but how much better?


Oh, why the move to arm?  Power consumption.  ROI for the C2 board is 
one year just on power saving.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Disabling DNSSEC until...

[Robert Moskowitz]

I solve the EDNS problem, probably on my Juniper SSG5.  This will 
initially have to wait until Juniper gets back to me, or I corner some 
of their developers at IETF in a couple weeks.  Alternatively I replace 
the SSG5...


And I change my registry to one that supports DNSSEC.

Commenting all the lines about DNSSEC does not seem to totally stop it, 
as I see the following message after restarting named:


Mar  3 07:48:45 onlo named[7049]: managed-keys-zone ./IN/external: 
loaded serial 352


And eventhough rigel and klovia were restarted with all the DNSSEC lines 
commented out, I am still getting the 'no valid RRSIG' messages for 
htt.  I suspect I am dealing with defaults here and will have to 
explicitly state:


dnssec-enable no;
dnssec-validation no;

Anything else I need to do to really turn dnssec off for now?


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Disabling DNSSEC until...

[Robert Moskowitz]

On 03/03/2013 08:10 AM, Robert Moskowitz wrote:
I solve the EDNS problem, probably on my Juniper SSG5.  This will 
initially have to wait until Juniper gets back to me, or I corner some 
of their developers at IETF in a couple weeks.  Alternatively I 
replace the SSG5...


And I change my registry to one that supports DNSSEC.

Commenting all the lines about DNSSEC does not seem to totally stop 
it, as I see the following message after restarting named:


Mar  3 07:48:45 onlo named[7049]: managed-keys-zone ./IN/external: 
loaded serial 352


And eventhough rigel and klovia were restarted with all the DNSSEC 
lines commented out, I am still getting the 'no valid RRSIG' messages 
for htt.  I suspect I am dealing with defaults here and will have to 
explicitly state:


dnssec-enable no;
dnssec-validation no;


Still getting the loading of managed-keys-zone, but now I get resolution 
for htt. on the caching server.  I see much testing ahead of me, as 
there is no firewall between rigel and klovia.  This at least will allow 
me to launch klovia as my new mail server as I work out the DNSSEC 
related items.




Anything else I need to do to really turn dnssec off for now?


Still wonder what will stop the manage-keys-zone loading.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bad zone transfer request of reverse addr zone

[Robert Moskowitz]

On 03/01/2013 06:42 PM, Mark Andrews wrote:

In message 5130fba0.3020...@htt-consult.com, Robert Moskowitz writes:

On 03/01/2013 01:50 PM, Jan-Piet Mens wrote:

I get this for all my secondaries for my reverse domain:

client 63.68.132.50 view external: bad zone transfer request:
'192-26.67.83.208.in-addr.arpa/IN': non-authoritative zone
(NOTAUTH): 23 Time(s)

The zone is either not defined in the view the client is accessing,
and/or it wasn't loaded due to errors, which effectively is the same.

Check startup logs to see if zone contains errors, and make sure the
zone is available in your 'external' view.

Mar  1 12:42:01 onlo named[1405]: zone
128-26.67.83.208.in-addr.arpa/IN/external: sending notifies (serial
2013022501)

Does this show that it is available in my external view?

Try using consistent names.

128-26.67.83.208.in-addr.arpa != 192-26.67.83.208.in-addr.arpa


ARGH

Can't see the trees from the forest.  I 'blame' my dyselxia; yeah no 
excuse.  Now to dig in to see what is wrong here



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bad zone transfer request of reverse addr zone

[Robert Moskowitz]

On 03/02/2013 09:14 PM, Robert Moskowitz wrote:


On 03/01/2013 06:42 PM, Mark Andrews wrote:

In message 5130fba0.3020...@htt-consult.com, Robert Moskowitz writes:

On 03/01/2013 01:50 PM, Jan-Piet Mens wrote:

I get this for all my secondaries for my reverse domain:

client 63.68.132.50 view external: bad zone transfer request:
'192-26.67.83.208.in-addr.arpa/IN': non-authoritative zone
(NOTAUTH): 23 Time(s)

The zone is either not defined in the view the client is accessing,
and/or it wasn't loaded due to errors, which effectively is the same.

Check startup logs to see if zone contains errors, and make sure the
zone is available in your 'external' view.

Mar  1 12:42:01 onlo named[1405]: zone
128-26.67.83.208.in-addr.arpa/IN/external: sending notifies (serial
2013022501)

Does this show that it is available in my external view?

Try using consistent names.

128-26.67.83.208.in-addr.arpa != 192-26.67.83.208.in-addr.arpa


ARGH

Can't see the trees from the forest.  I 'blame' my dyselxia; yeah no 
excuse.  Now to dig in to see what is wrong here


The 'problem' is with one of my secondaries that is not configured for 
the right zone.  I will contact the admin to fix that.  There is a bit 
of history behind the name of this zone that does not matter; only 
recognizing the problem and fixing it.


thanks for helping me see the trees clearly.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

in-addr.arpa insecure?

[Robert Moskowitz]

I got tipped off about this from logwatch report. On my public DNS 
server had the following:


Feb 26 04:02:04 onlo named[19336]:   validating @0xb2929ee0: 
in-addr.arpa SOA: got insecure response; parent indicates it should be 
secure
Feb 27 04:02:04 onlo named[32262]:   validating @0xb37e25e0: 
in-addr.arpa SOA: got insecure response; parent indicates it should be 
secure
Feb 27 23:35:37 onlo named[32262]:   validating @0xb444ebc0: 
in-addr.arpa SOA: got insecure response; parent indicates it should be 
secure
Feb 28 04:02:08 onlo named[32262]:   validating @0xb444ebc0: 
in-addr.arpa SOA: got insecure response; parent indicates it should be 
secure
Feb 28 09:37:00 onlo named[32262]:   validating @0xb37d9fb8: 
in-addr.arpa SOA: got insecure response; parent indicates it should be 
secure
Feb 28 18:32:38 onlo named[32262]:   validating @0xb4e014e0: 
in-addr.arpa SOA: got insecure response; parent indicates it should be 
secure
Mar  1 04:02:03 onlo named[32262]:   validating @0xb37eac08: 
in-addr.arpa SOA: got insecure response; parent indicates it should be 
secure


Is this right?  Is there some server out there that I hit occationally 
that does not have the 'right' in-addr.arpa zone information?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: in-addr.arpa insecure?

[Robert Moskowitz]

On 03/01/2013 08:57 AM, Tony Finch wrote:

Robert Moskowitz r...@htt-consult.com wrote:


I got tipped off about this from logwatch report. On my public DNS server had
the following:

Feb 26 04:02:04 onlo named[19336]:   validating @0xb2929ee0: in-addr.arpa SOA:
got insecure response; parent indicates it should be secure

Looks like something in your setup is dropping RRSIGs, and this is
probably responsible for both your private htt. TLD validation problems
and these in-addr.arpa validation problems. Do you all your servers have
dnssec-enable yes? Do you have any non-BIND servers or middleboxes?


All my boxes are Centos 6.3 running RHEL bind 9.8.2.  I have 3. onlo is 
public facing and my main server.  rigel is my internal test box.  
klovia is my new mail server running as a cache server, currently 
forwarding to rigel, but will be switched to onlo when I swap it for the 
current klovia.  onlo and rigel are completely independent and on 
different subnets.  I mention the names as they are all findable via 
DNS; nothing private about that (though I am blocking chaos digs on all 
of them).


All in the global options have the lines:

dnssec-enable yes;
dnssec-lookaside auto;

Onlo and rigel have:

dnssec-validation auto;

and klovia has:

dnssec-validation yes;

hmmm.  I THOUGHT I had set onlo to also be 'dnssec-validation yes'. 
Probably did that in an earlier test version and when I did the final 
build, I forgot to change that line (auto is the RHEL default setting).  
And rigel started life as a clone of onlo.


So I will change dnssec-validation to yes, and see what happens.

Anything else I should look for?

Oh, no non-bind servers knowingly in the way.  I pay my ISP for a clear 
IP connection and 64 IPv4 addresses and a /48 IPv6 allocation.  My 
firewall is a Juniper SSG5 'branch' firewall with current firmware 
(there was an IPv6 bug in earlier releases that caused outbound routing 
problems) that is just passing port 53; no proxying enabled.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: in-addr.arpa insecure?

[Robert Moskowitz]

On 03/01/2013 09:22 AM, Michael W. Lucas wrote:

On Fri, Mar 01, 2013 at 09:19:42AM -0500, Robert Moskowitz wrote:

On 03/01/2013 08:57 AM, Tony Finch wrote:

Robert Moskowitz r...@htt-consult.com wrote:


I got tipped off about this from logwatch report. On my public DNS server had
the following:

Feb 26 04:02:04 onlo named[19336]:   validating @0xb2929ee0: in-addr.arpa SOA:
got insecure response; parent indicates it should be secure

Looks like something in your setup is dropping RRSIGs, and this is
probably responsible for both your private htt. TLD validation problems
and these in-addr.arpa validation problems. Do you all your servers have
dnssec-enable yes? Do you have any non-BIND servers or middleboxes?

All my boxes are Centos 6.3 running RHEL bind 9.8.2.  I have 3. onlo is
public facing and my main server.  rigel is my internal test box.
klovia is my new mail server running as a cache server, currently
forwarding to rigel, but will be switched to onlo when I swap it for the
current klovia.  onlo and rigel are completely independent and on
different subnets.  I mention the names as they are all findable via
DNS; nothing private about that (though I am blocking chaos digs on all
of them).

All in the global options have the lines:

  dnssec-enable yes;
  dnssec-lookaside auto;

Onlo and rigel have:

  dnssec-validation auto;

and klovia has:

  dnssec-validation yes;

hmmm.  I THOUGHT I had set onlo to also be 'dnssec-validation yes'.
Probably did that in an earlier test version and when I did the final
build, I forgot to change that line (auto is the RHEL default setting).
And rigel started life as a clone of onlo.

So I will change dnssec-validation to yes, and see what happens.

Anything else I should look for?

Oh, no non-bind servers knowingly in the way.  I pay my ISP for a clear
IP connection and 64 IPv4 addresses and a /48 IPv6 allocation.  My
firewall is a Juniper SSG5 'branch' firewall with current firmware
(there was an IPv6 bug in earlier releases that caused outbound routing
problems) that is just passing port 53; no proxying enabled.


You might have been here, but I feel obliged to throw this out: reply
size problem?

https://www.dns-oarc.net/oarc/services/replysizetest


Well something is south.  Running this on onlo:

dig +short rs.dns-oarc.net txt
;; Truncated, retrying in TCP mode.
rst.x4091.rs.dns-oarc.net.
rst.x4049.x4091.rs.dns-oarc.net.
rst.x4055.x4049.x4091.rs.dns-oarc.net.
2607:f4b8:3:0:9254:5400:0:148 DNS reply size limit is at least 4091
2607:f4b8:3:0:9254:5400:0:148 sent EDNS buffer size 4096
Tested at 2013-03-01 14:34:28 UTC

But running it from this notebook I get:

dig @onlo +short rs.dns-oarc.net txt
rst.x1002.rs.dns-oarc.net.
rst.x1994.x1002.rs.dns-oarc.net.
rst.x2495.x1994.x1002.rs.dns-oarc.net.
2607:f4b8:3:0:9254:5400:0:148 sent EDNS buffer size 4096
Tested at 2013-03-01 14:37:18 UTC
2607:f4b8:3:0:9254:5400:0:148 DNS reply size limit is at least 2495

So why when run from the DNS server it truncates, but when same server 
processes the request from a client it does not?  Or is it, and just not 
telling the client?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: in-addr.arpa insecure?

[Robert Moskowitz]

On 03/01/2013 09:22 AM, Michael W. Lucas wrote:

On Fri, Mar 01, 2013 at 09:19:42AM -0500, Robert Moskowitz wrote:

On 03/01/2013 08:57 AM, Tony Finch wrote:

Robert Moskowitz r...@htt-consult.com wrote:


I got tipped off about this from logwatch report. On my public DNS server had
the following:

Feb 26 04:02:04 onlo named[19336]:   validating @0xb2929ee0: in-addr.arpa SOA:
got insecure response; parent indicates it should be secure

Looks like something in your setup is dropping RRSIGs, and this is
probably responsible for both your private htt. TLD validation problems
and these in-addr.arpa validation problems. Do you all your servers have
dnssec-enable yes? Do you have any non-BIND servers or middleboxes?

All my boxes are Centos 6.3 running RHEL bind 9.8.2.  I have 3. onlo is
public facing and my main server.  rigel is my internal test box.
klovia is my new mail server running as a cache server, currently
forwarding to rigel, but will be switched to onlo when I swap it for the
current klovia.  onlo and rigel are completely independent and on
different subnets.  I mention the names as they are all findable via
DNS; nothing private about that (though I am blocking chaos digs on all
of them).


Oh, rigel and klovia are on the same subnet, so not going through any 
firewall.  Other than Centos'.




All in the global options have the lines:

  dnssec-enable yes;
  dnssec-lookaside auto;

Onlo and rigel have:

  dnssec-validation auto;

and klovia has:

  dnssec-validation yes;

hmmm.  I THOUGHT I had set onlo to also be 'dnssec-validation yes'.
Probably did that in an earlier test version and when I did the final
build, I forgot to change that line (auto is the RHEL default setting).
And rigel started life as a clone of onlo.

So I will change dnssec-validation to yes, and see what happens.

Anything else I should look for?

Oh, no non-bind servers knowingly in the way.  I pay my ISP for a clear
IP connection and 64 IPv4 addresses and a /48 IPv6 allocation.  My
firewall is a Juniper SSG5 'branch' firewall with current firmware
(there was an IPv6 bug in earlier releases that caused outbound routing
problems) that is just passing port 53; no proxying enabled.


You might have been here, but I feel obliged to throw this out: reply
size problem?

https://www.dns-oarc.net/oarc/services/replysizetest

==ml



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: in-addr.arpa insecure?

[Robert Moskowitz]

On 03/01/2013 09:19 AM, Robert Moskowitz wrote:


On 03/01/2013 08:57 AM, Tony Finch wrote:

Robert Moskowitz r...@htt-consult.com wrote:

I got tipped off about this from logwatch report. On my public DNS 
server had

the following:

Feb 26 04:02:04 onlo named[19336]:   validating @0xb2929ee0: 
in-addr.arpa SOA:

got insecure response; parent indicates it should be secure

Looks like something in your setup is dropping RRSIGs, and this is
probably responsible for both your private htt. TLD validation problems
and these in-addr.arpa validation problems. Do you all your servers have
dnssec-enable yes? Do you have any non-BIND servers or middleboxes?


All my boxes are Centos 6.3 running RHEL bind 9.8.2.  I have 3. onlo 
is public facing and my main server.  rigel is my internal test box.  
klovia is my new mail server running as a cache server, currently 
forwarding to rigel, but will be switched to onlo when I swap it for 
the current klovia.  onlo and rigel are completely independent and on 
different subnets.  I mention the names as they are all findable via 
DNS; nothing private about that (though I am blocking chaos digs on 
all of them).


All in the global options have the lines:

dnssec-enable yes;
dnssec-lookaside auto;

Onlo and rigel have:

dnssec-validation auto;

and klovia has:

dnssec-validation yes;

hmmm.  I THOUGHT I had set onlo to also be 'dnssec-validation yes'. 
Probably did that in an earlier test version and when I did the final 
build, I forgot to change that line (auto is the RHEL default 
setting).  And rigel started life as a clone of onlo.


So I will change dnssec-validation to yes, and see what happens.


No change in any behaviour wrt rrsig changing this to yes.  Stopping 
iptables and ip6tables also no change.  rigel and klovia on same subnet, 
so no firewall (Juniper ssg5) interfering.




Anything else I should look for?

Oh, no non-bind servers knowingly in the way.  I pay my ISP for a 
clear IP connection and 64 IPv4 addresses and a /48 IPv6 allocation.  
My firewall is a Juniper SSG5 'branch' firewall with current firmware 
(there was an IPv6 bug in earlier releases that caused outbound 
routing problems) that is just passing port 53; no proxying enabled.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

bad zone transfer request of reverse addr zone

[Robert Moskowitz]

I get this for all my secondaries for my reverse domain:

client 63.68.132.50 view external: bad zone transfer request: 
'192-26.67.83.208.in-addr.arpa/IN': non-authoritative zone (NOTAUTH): 23 
Time(s)


I don't get this for my forward domain and the SOA for both are 
similarly structured.  For the reverse I have:


zone 128-26.67.83.208.in-addr.arpa {
type master;
file 128-26.67.83.208.in-addr.arpa.zone;
allow-transfer { httslaves; };
};

$ORIGIN128-26.67.83.208.in-addr.arpa.
@INSOAonlo.htt-consult.com. rgm.htt-consult.com. (
2013022501
2h
20m
2w
2h )

@INNSonlo.htt-consult.com.
INNSns1.icsl.net.
INNSns1.clearrate.com.
INNSns2.clearrate.com.

Is this a case of my ISP not properly setting up the delegation?  I have 
tested from the outside and have no trouble resolving, say 208.83.67.148 
to onlo, so they have something right (they still have not done the 
delegation for my ip6.arpa zone).



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: bad zone transfer request of reverse addr zone

[Robert Moskowitz]

On 03/01/2013 01:03 PM, Robert Moskowitz wrote:

I get this for all my secondaries for my reverse domain:

client 63.68.132.50 view external: bad zone transfer request: 
'192-26.67.83.208.in-addr.arpa/IN': non-authoritative zone (NOTAUTH): 
23 Time(s)


I don't get this for my forward domain and the SOA for both are 
similarly structured.  For the reverse I have:


zone 128-26.67.83.208.in-addr.arpa {
type master;
file 128-26.67.83.208.in-addr.arpa.zone;
allow-transfer { httslaves; };
};

$ORIGIN128-26.67.83.208.in-addr.arpa.
@INSOAonlo.htt-consult.com. rgm.htt-consult.com. (
2013022501
2h
20m
2w
2h )

@INNSonlo.htt-consult.com.
INNSns1.icsl.net.
INNSns1.clearrate.com.
INNSns2.clearrate.com.

Is this a case of my ISP not properly setting up the delegation? I 
have tested from the outside and have no trouble resolving, say 
208.83.67.148 to onlo, so they have something right (they still have 
not done the delegation for my ip6.arpa zone).


Further review shows that ns1.clearrate.com and ns2 have no problems 
with the transfer:


Feb 25 19:43:21 onlo named[19336]: client 208.83.64.6#56237: view 
external: transfer of '128-26.67.83.208.in-addr.arpa/IN': AXFR-style 
IXFR started
Feb 25 19:43:21 onlo named[19336]: client 208.83.64.6#56237: view 
external: transfer of '128-26.67.83.208.in-addr.arpa/IN': AXFR-style 
IXFR ended


but ns1.icsl.net fails:

Mar  1 10:33:20 onlo named[32262]: client 63.68.132.50#48353: view 
external: bad zone transfer request: '192-26.67.83.208.in-addr.arpa/IN': 
non-authoritative zone (NOTAUTH)


SInce this zone is delegated from 67.83.208.in-addr.arpa. from 
ns1.clearrate.com, do I ping them to add ns1.icsl.net as an NS?  It is 
not enough for me to list them in my zone file?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with resolving a local tld

[Robert Moskowitz]

Still not working even with htt. signed.  See below.  I guess what I 
need for right now is to turn off DNSSEC checking of a branch in the 
tree; in this case the tld htt.


On 02/27/2013 08:34 PM, Mark Andrews wrote:

In message 512e31ca.5030...@htt-consult.com, Robert Moskowitz writes:

For various testing reasons, I have been running a tld here of htt. It
has worked of old and continues to work on my new 9.8.2 Centos servers.
Problem came up from a namecaching server that 'forwards only' to my
internal server.  It cannot resolve any hosts in this tld and on the
server forwarded to I see:

Well one really shouldn't be creating one's own tlds.


As the instigator and a co-author of rfc 1918, I beg to differ. Many 
have been using internal tlds for decades for various reasons. It works 
fine for the client going to the servers of the zone, but my namecaching 
server that is forwarding to same DNS server fails.



That said sign the zone and add a trust anchor (managed-keys/trusted-keys)
for it.  The validator won't ask the root zone for the DS records
from the zone once you do that.


So I cheated and used webmin for doing the signing, but it looks right:

htt.INDNSKEY257 3 7 
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi 
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP 
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w 
Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW 
Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD 
8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X 
DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w==


htt.INDNSKEY256 3 7 
AwEAAfH28LiEU7QxpCdeR6qB6sol8d3AUsKokil7nmCvT3yusSIF8iDR 
lWPEzs+BeTEVoQwhlEZZm6ZqvYEihxvR72mQLzS1r0GYzE/G4Kjs3oOq 
1ro4vTlO6Nk9/i8/sxbpl9jgC/3T3cHs97Whq6+PvFLQPeFa3pNqhEWl 
NnHo7p47ddI5Y+XfTUmgEQjbPo36XqQQGIgFORT7G+tpB/LLd17P3F3O 
vYKsXGat7z8/86118HwcYtZQx5e1AaRWm+SKk5gbGDYvATt/hGB883oz 
hI6umyVhWSXTiDolEnWf2L89cedda0hf8EGKIeCjJPKAbhjgp00sPDvF 
gEwnJ4xw29MIM9DgfDIaHZ0xXRNd1QQjKAqY5yseq9m8JobnoEPZdw==


htt.43200INRRSIGDNSKEY 7 1 43200 20130330032518 
20130228032518 63362 htt. 1tmMcjfjyt9dy5ERAHRHgps2udBGJyJ1hVcz 
Hpctu1Y8TONfrjuqGcACRPpE0cHUTRSxqxZ7 
WyseCQxvApd7NH93swcCKplls485p40pKLn8 
7VLExwW4H76VmuBhO/IXVYaYQHDgw9fOcwRN 
91eSzM6qjvQZX4yNR8ErFYGrQzGX/NBvAz5K 
ngGa1a3UO33QSZJ0NA5lv9NzBp1bNxAdSjpv 
mAsE7xjnMFfQgxAixbyalCIJ/adrt2OScaRt 
gx6i/42u9B1Uni2OKVlyQ3fuWU2BqpAR3QXv 
8r89Zl7CdB/F0Jepdi2wi2hh/XqcOEf+Ef6i 
HSROR2Bo/X8ILlirM5ZA1u3aVAXqB6bxqDv1 H5FYFPZocuxF4Glcc//XzQvu


htt.43200INRRSIGDNSKEY 7 1 43200 20130330032518 
20130228032518 1470 htt. o7PY4emvDvdoYjSyXh1zsDLshKt9p+3N6TNt 
YX93emC8vVhZtU1GozQ51E6tCucnOro+Z8DR 
WK2xyDdBFABTfwJne8duVmclzuQnvC87ocYB 
lNq5v1SRta0IBkTras4wYNRn29J5bTUumfv/ 
Q4MPl4QAqZzOTQ+LAjAfqFqnbKb3OFktSrUL 
G/OoUfAyv8gku4eR+CU1I4TAtJOzAQl8h1yu 
XIhph60EI2351nGHo6HAFGcIPyDYKIzKu4jg 
gD9NJSQoJtsKP+Yddn4864ZPVT/PbRIbu26E 
Qumvn0eYrbD8Mn7Wjbvhz9SlZLds4nuG2O/P 
E3rxW7L7OIkksPkCGAgbA8jmLlc7e7jbnzk9 mUpxI1CYerpfkYmeszrHilzg


Q4K4G6TITMCM3TJSB7N55OLQ9I5274S7.htt.7200INNSEC31 0 10 - 
SK60GBPTP3OUAO9NB0GRASPVOGOJDI1M A NS SOA  RRSIG DNSKEY NSEC3PARAM


I have hosts directly in this zone (as well as subzones).  So medon.htt. 
is defined as:


medon.htt.IN2607:f4b8:3:1:2b0:d0ff:feb1:b82d
medon.htt.INA208.83.67.154
medon.htt.43200INRRSIGA 7 2 43200 20130330032518 
20130228032518 63362 htt. slcOa3AKixrntI+OSpbYKuSXJLy5ECL5X7ky 
ODm9PZ7UoDXCOsl6Pn6wC4Q/eOYk5wy8yqqW 
IT3J6iM9K5QkR+mKe7FCpWsz2lY+eJTY0gKV 
Y/r/KFByGxsYtY6/zMYcR6S0f9sVCe81kaLA 
8Jo/2XZJQVrEJatbXCgDB1M2qHiwMwJ7SrGY 
/h29OHkZNUmiD9+mcU1V31492OVLRvj/kht5 
fKVsGOLMdhqi3RjpSC6inTHhIMQO8wU5B0aV 
ZMqQBg07Rhn78wlRJ8e1KU9yVz+CoRkVogzR 
QS4TzKgqGN6ekKYHDiWAnRvaCpYdeZoEg/bh 
q4eiKNXLWUPEDxdmyLRwc1hSjxzVomsJ/GUh fdyNvBOQn8/ebAiUZhTgO7GT
medon.htt.43200INRRSIG 7 2 43200 20130330032518 
20130228032518 63362 htt. FQShruERtC/WxILDeeQyFhX6cFRm7nHoFeb8 
q8gIhaIexF8tZ38JP5GqSclcxn4wyN02AAzz 
WY9S1OCpVV/F6AtYKhDyutb6HJ6pUcnIivYh 
BO/uJ3blKFrMLbN6xklKv7LIXa1NHgscd9Cj 
6MHdao9RLrJIcVOV0lSLQU+8ciXX0rWFliop 
ZMT+2IQ3AxcPw9f20W6SMHrR5f5adnnwvH2W 
KmGie6jq6p+e3f2oae+sem/EzYcKfFFzsrKN 
uTX7LAz3DKUxoJynfLbBvk72AS/RsSq3sB8/ 
mhp65POqUgSrBn+pWw/pl2aykZIXrlBO4reW 
4LU20l06RkBkjb7xGZYzC3izR3+UPd0wIspw 0tZ8wPW59+5x4mWvav8V3dVb


When I do 'host medon.htt.' on my DNS server, rigel, it works.  When I 
go over to the namecaching server, kovia, it fails:


Host medon.htt not found: 2(SERVFAIL)

Feb 28 12:14:16 rigel named[786]: error (chase DS servers) resolving 
'htt/DS/IN': 208.83.67.188#53


Feb 28 12:14:16 klovia named[22332]:   validating @0xb421ba30: htt SOA: 
got insecure response; parent indicates it should be secure
Feb 28 12:14:16 klovia named[22332]: error (no valid RRSIG) resolving 
'medon.htt/DS/IN': 208.83.67.188#53
Feb 28 12:14:16 klovia named[22332]:   validating @0xb421ba30: htt SOA: 
got insecure response; parent

Re: Problems with resolving a local tld

[Robert Moskowitz]

On 02/28/2013 12:37 PM, Doug Barton wrote:

On 02/28/2013 09:34 AM, Robert Moskowitz wrote:

Only for my internal tld does the lookup fail.


Are you distributing the trust anchor for htt to all of the servers 
that are doing validation?


No. Of course I did not think of that! I just ASSuMEd a namecaching 
server would get all it needed from the forward server.


Well let's figure out which of these records I need to move...


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with resolving a local tld

[Robert Moskowitz]

On 02/28/2013 12:57 PM, Vernon Schryver wrote:

From: Robert Moskowitz r...@htt-consult.com

Well one really shouldn't be creating one's own tlds.

As the instigator and a co-author of rfc 1918, I beg to differ.

Many people considered the notion in RFC 1918 harmful.  See RFC 1627.


Um, I lived that debate.

RFC 1597 came first. Then there was 1627. Then the IAB called for an 
armistice and the gang of 4 got together with the gang of 4 and produced 
1918. Postel claimed with a straight face that that number just happened 
to be next. Yeah right Jon; read RFC 2468...



(My personal view was that standardizing the notion was better because
it would minimize the harm suffered and caused by those who were going
to use net-10 no matter what the other self-described experts, mavens,
and gurus said.)


In many ways it was bad for the internet. But is your cup half full or 
half empty? IPv6 thus has not been rushed and we have taken time to 
hopefully get it right. I wonder what situation we would have been in if 
we did not have registered private addresses and we had free for all 
address food fights and a rush for IPv6? Well this is about bind and not 
about IP addressing...


Oh, and don't get me going on EIDs. Noel 'said' he was upset that I 
caved in first during the EID cabal effort.





 Many
have been using internal tlds for decades for various reasons. It works
fine for the client going to the servers of the zone, but my namecaching
server that is forwarding to same DNS server fails.

Many things have worked fine for decades, are popular, and are even
both popular and old.  Many of those old and popular things cause
significant harm to their perpetrators and to others and are just
plain stupid in almost all of their existing installations, such
as not following BCP 38 or running open DNS resolvers.


Moving to views for my DNS was such a pain, and I was grateful in the 
end to get there. CIDR reverse in-addr.arpa allocations such a pain, and 
worth getting right (and I found a few errata in Liu's book along the 
way). Now if I can only get my ISP to delegate my ipv6.arpa subzone, I 
would be happier. We live and learn to be better. Hopefully.



In other words, what does your private htt TLD do that could not be
done at least as well as a private, secret sub-domain of one of your
legitimate domains?


First it was a particular product that wanted to run in its own zone 
with its own dns server that I had to access from other systems; last 
version of it will be gone soon. Then it was a portable test lab that 
could work plugged in or isolated. Really now I could force things to 
work as a subzone; or at least I think I am nearly to that point in the 
upgrades. But there are some human interaction reasons for a very short 
fqdn for a class of testing. It has to be typed in real fast in a 
mobility demonstration, and it is the convenience factor for doing some 
testing. So it is just for testing, and if I can't get it working to 
this server, it will probably be OK; it works on the main server. After 
I complete the whole grumble grumble network upgrade.


But it is PHUN! I can have my own special tld for MY use in MY network!

All these stupid security layers just take the phun out of it. ;)'


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with resolving a local tld

[Robert Moskowitz]

On 02/28/2013 01:14 PM, Tony Finch wrote:

Robert Moskowitz r...@htt-consult.com wrote:


Feb 28 12:14:16 klovia named[22332]:   validating @0xb421ba30: htt SOA: got
insecure response; parent indicates it should be secure

I think this suggests that one of the servers for htt doesn't have the
signed version.

Another reason not to use made-up domain names: CAs are going to stop
issuing X.509 certificates for them. (It baffles me why they ever did so.)
http://ssl.entrust.net/blog/?p=1831


Day job disclaimer: I work for Verizon Enterprise Systems. We have a 
group that provides LOTS of server certs and is the leader in client 
certs and attend HIMSS next week for more announcements.


But that said my personal position is: a made-up domain name should 
never leak, and thus why are you getting a public cert for it? run your 
own CA, add it to your trusted list and do what you got to do.


As to why they did so? It is called money.

But this is a different subject. Enough down this rat hole.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with resolving a local tld

[Robert Moskowitz]

On 02/28/2013 01:31 PM, Vernon Schryver wrote:

From: Tony Finch d...@dotat.at
Another reason not to use made-up domain names: CAs are going to stop
issuing X.509 certificates for them. (It baffles me why they ever did so.)
http://ssl.entrust.net/blog/?p=1831

That's another reason to publish your own DANE records including
TLSA and SMIMEA.


I have been on a thread over on the postfix list where DANE support and 
such is being discussed. Will get there eventually.



Also consider this comment in that announcement:
 This issue is particularly a problem with Microsoft Exchange
 users where non-FQDN names are used frequently
I wish that would be enough to get Microsoft to teach Exchange to
use DANE.

Why am I not surprised to see that the recommended solutions of
https://www.cabforum.org/Guidance-Deprecated-Internal-Names.pdf linked
from that Entrust.net web page mentions DANE or DNSSEC not at all but
does include some less plausible solutions?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Adding trusted-keys to named.conf

[Robert Moskowitz]

I MAY be doing something wrong, or my problem is elsewhere...

In zone htt. I have the DNSKEY RR:

htt.INDNSKEY257 3 7 
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi 
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP 
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w 
Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW 
Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD 
8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X 
DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w==


So in my caching server's named.conf I added at the end:

include /etc/named.trusted.key;

and this contains:

trusted-keys {

# DNSKEY for htt zone.

htt.257 3 7 
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi 
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP 
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w 
Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW 
Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD 
8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X 
DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w==;


};

And I am still getting:

Feb 28 14:35:17 klovia named[24806]:   validating @0xb4855220: htt SOA: 
got insecure response; parent indicates it should be secure


The logged for starting named does have:

Feb 28 14:35:00 klovia named[24806]: managed-keys-zone ./IN: loaded 
serial 103


but nothing about trusted-keys loaded.  In the 
http://www.isc.org/software/bind/documentation/arm95 it shows the 
trusted-keys clause before the global options.  Does order matter; it 
seems to for ACLs?   Is there something else I am missing?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Adding trusted-keys to named.conf

[Robert Moskowitz]

On 02/28/2013 02:42 PM, Robert Moskowitz wrote:

I MAY be doing something wrong, or my problem is elsewhere...

In zone htt. I have the DNSKEY RR:

htt. IN DNSKEY 257 3 7 
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi 
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP 
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w 
Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW 
Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD 
8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X 
DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w==


So in my caching server's named.conf I added at the end:

include /etc/named.trusted.key;

and this contains:

trusted-keys {

# DNSKEY for htt zone.

htt. 257 3 7 AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi 
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP 
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w 
Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW 
Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD 
8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X 
DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w==;


};

And I am still getting:

Feb 28 14:35:17 klovia named[24806]: validating @0xb4855220: htt SOA: 
got insecure response; parent indicates it should be secure


The logged for starting named does have:

Feb 28 14:35:00 klovia named[24806]: managed-keys-zone ./IN: loaded 
serial 103


but nothing about trusted-keys loaded. In the 
http://www.isc.org/software/bind/documentation/arm95 it shows the 
trusted-keys clause before the global options. Does order matter; it 
seems to for ACLs? Is there something else I am missing?


I moved the named.trusted.key include to the beginning of named.conf and 
no change in behaviour. So order does not seem to be the issue. How can 
I determine if my trusted keys are being loaded?


I tried

dig @localhost dnskey htt. +noall +answer


And no content.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Adding trusted-keys to named.conf

[Robert Moskowitz]

On 02/28/2013 06:21 PM, Mark Andrews wrote:

In message 512fb319.7030...@htt-consult.com, Robert Moskowitz writes:

I MAY be doing something wrong, or my problem is elsewhere...

In zone htt. I have the DNSKEY RR:

htt.INDNSKEY257 3 7
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w
Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW
Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD
8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X
DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w==

So in my caching server's named.conf I added at the end:

include /etc/named.trusted.key;

and this contains:

trusted-keys {

  # DNSKEY for htt zone.

htt.257 3 7
AwEAAfEIWjDoEesqC4NLAwNFgviq+IGbUFmnFn0/2L8UvLWMjYiGFETi
NyA4CVaaG4GMekSJM8dI0FepyIKurxAhYzyV+phS5C6MoVmnYdF27dkP
qS0pFDZ/Hpp25qTrKIUjcqvxgECP1ArXa7yyE7/xWzQjH9nk5gEnad6w
Gy41lRnv3/UPtkxw669V2Ikb1NLAB5XnAzpTc4Tm7QPRPtbN8+FKWyYW
Ie9/nYKf67vSrlwbxRFbb27GeEmnrqMtsLkSFP1zDoUbmgJs3yiVjFCD
8hRYlbOA9lgAMbOGm4tNsLOFx0vyBZEVtdh4l/YDAaklygtR+f60271X
DHWaC4U/VYrHRidg2krM+UpPhjqn3aPJFIyyKEEE66cMSlf7ROL71w==;

};

And I am still getting:

Feb 28 14:35:17 klovia named[24806]:   validating @0xb4855220: htt SOA:
got insecure response; parent indicates it should be secure

The forwarders are not DNSSEC enabled.  parent here means named.conf.


The forwarder has:

dnssec-enable yes;
dnssec-validation auto;
dnssec-lookaside auto;

and I just added the trusted-keys clause to the internal view via an 
include.  So now the trusted-keys clause is in the forward server and 
the caching server.  I no longer get on the forward server:


Feb 28 12:14:16 rigel named[786]: error (chase DS servers) resolving 
'htt/DS/IN': 208.83.67.188#53



But still getting on caching server:

Feb 28 23:08:19 klovia named[466]:   validating @0xb4655220: htt SOA: 
got insecure response; parent indicates it should be secure



From the recursive server run

dig @forwarder +dnssec htt soa

This should work and have RRSIG records.  Do some other queries also
with +dnssec.  negative responses should have NSEC/NSEC3 records if
they are coming from a signed zone.


dig +bufsize=4096 @rigel +dnssec htt soa

;  DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6  +bufsize=4096 
@rigel +dnssec htt soa

; (2 servers found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 8381
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;htt.INSOA

;; ANSWER SECTION:
htt.43200INSOArigel.htt-consult.com. 
rgm.htt-consult.com. 2013021402 7200 1200 1209600 7200


;; AUTHORITY SECTION:
htt.43200INNSoqo3.htt.
htt.43200INNSrigel.htt-consult.com.

;; ADDITIONAL SECTION:
oqo3.htt.43200IN 2607:f4b8:3:11:20c:96ff:fe40:cb63
rigel.htt-consult.com.43200INA208.83.67.188
rigel.htt-consult.com.43200IN 2607:f4b8:3:3:9254:5400:0:188
oqo3.htt.43200INRRSIG 7 2 43200 20130330032518 
20130228032518 63362 htt. 
iOSHk0B9+OPDuKJiWP1ArR/eleHi7KNUmEiQAw9ztGLzzqh1zsoDH3ZA 
Su6z2IlX33GS7FsdmeZB7SdflVsXSc4LyRFoX2lxHPopjo3M26w947J5 
7RwmHZ8VvA9Q93BkyikhRai9s+ql4haXDcV+xW+lTz+cokkB5ASXY/Xh 
X5JqkOO7XEjoliDCJxFF1OeSEk0p40U+d7f4SXccrVy940AJHbQJuOXb 
TyvjHjrqOgo/5Gy2Att/MjN+cDYW79bDQCY4cDOLZ96ZCBSFqfaKUQq/ 
vIx7kqlb/RlM7tFcxm0pd7XsPfjRopac5FRXubLVAVrM/qP5I3RH+0Qy 
NM4oHEYf2S72iPGIpkhrR5r8MfC8YS7nDFqFgcMbsxn42xku


;; Query time: 1 msec
;; SERVER: 2607:f4b8:3:3:9254:5400:0:188#53(2607:f4b8:3:3:9254:5400:0:188)
;; WHEN: Thu Feb 28 23:17:40 2013
;; MSG SIZE  rcvd: 521

Why just oqo3.htt. with a RRSIG?  All the hosts in htt. have RRSIG 
records.  And, no, 'host oqo3.htt.' also fails when run on klovia.


  

The logged for starting named does have:

Feb 28 14:35:00 klovia named[24806]: managed-keys-zone ./IN: loaded
serial 103

managed-keys in named.conf are just the initial keys used as the
starting point for RFC 5011 style trusted key managment.  The runtime
keys are pulled from a seperate database.  That message says that
the serial number for that database is 103.


So there is no message at startup about loading trusted-keys.




but nothing about trusted-keys loaded.  In the
http://www.isc.org/software/bind/documentation/arm95 it shows the
trusted-keys clause before the global options.  Does order matter; it
seems to for ACLs?   Is there something else I am missing?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Problems with resolving a local tld

[Robert Moskowitz]

For various testing reasons, I have been running a tld here of htt. It 
has worked of old and continues to work on my new 9.8.2 Centos servers.  
Problem came up from a namecaching server that 'forwards only' to my 
internal server.  It cannot resolve any hosts in this tld and on the 
server forwarded to I see:


htt. is mastered on my servers and home.htt is slaved off of old server 
(that will get upgraded later).  The host I want to access is 
repo.home.htt.  From my 'regular' DNS servers this works well, but from 
the namecaching server that 'forwards only' to this server I get on the 
caching server:


Feb 27 09:52:48 klovia named[1703]: error (insecurity proof failed) 
resolving 'repo.home.htt//IN': 208.83.67.188#53
Feb 27 09:52:48 klovia named[1703]: error (insecurity proof failed) 
resolving 'repo.home.htt/A/IN': 208.83.67.188#53


and on the main server (at 208.83.67.188) I see:

Feb 27 09:52:47 rigel named[9294]: error (chase DS servers) resolving 
'htt/DS/IN': 208.83.67.188#53


what little research I have done directs me to htt is not signed? Of 
course home.htt is not either as that server is rather old (bind 9.6.2)


Interestingly when 208.83.67.188 does a lookup in my regular domain I see:

Feb 27 11:16:14 rigel named[9294]: error (chase DS servers) resolving 
'htt-consult.com/DS/IN': 208.83.67.188#53


So what am I missing here?


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Problems with resolving a local tld

[Robert Moskowitz]

On 02/27/2013 08:34 PM, Mark Andrews wrote:

In message 512e31ca.5030...@htt-consult.com, Robert Moskowitz writes:

For various testing reasons, I have been running a tld here of htt. It
has worked of old and continues to work on my new 9.8.2 Centos servers.
Problem came up from a namecaching server that 'forwards only' to my
internal server.  It cannot resolve any hosts in this tld and on the
server forwarded to I see:

Well one really shouldn't be creating one's own tlds.  That said
sign the zone and add a trust anchor (managed-keys/trusted-keys)
for it.  The validator won't ask the root zone for the DS records
from the zone once you do that.


So I get to dive into zone signing slightly before I wanted to. Well 
time to get my feet wet!



Anything from 9.3.0 onwards can sign modern ones.  If you want NSEC3
the 9.6.0 onwards.


The 9.6.2 server has a bunch of cruft on it that makes it hard to muck 
with.  It is scheduled for replacement as well, but it is last on the 
list.  Maybe just signing the tld will 'fix' this for now.





Feb 27 11:16:14 rigel named[9294]: error (chase DS servers) resolving
'htt-consult.com/DS/IN': 208.83.67.188#53

Something not fully dnssec aware in the resolution path?


Probably.  NetSol is my registry...

Time to unlock it and move it.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

disabling lame server logging

[Robert Moskowitz]

Continuing to 'clean up' my new server by reviewing logged messages. 
Researching a common one:


Feb 26 07:30:29 onlo named[19336]: error (unexpected RCODE SERVFAIL) 
resolving 'foo.com/MX/IN': 1.2.3.4#53


I get the drift that my server has been directed to a 'lame server' and 
logs that fact.  Supposedly I am to lookup the SOA record and contact 
the admin to fix this.  What I really want to do is stop all these 
messages as I suspect I will not be able to do anything to fix the 
problem.  So far what I have found is to add to my global logging section:


category lame-servers { null; };

Is there a finer scalpel?  I believe there are other lame server 
failures? Like 'RCODE REFUSED' and 'RCODE 15' (these are the 3 I see in 
my messages)?  Can I block logging by RCODE, so as new ones appear I can 
learn what they mean before /dev/null ing them?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: disabling lame server logging

[Robert Moskowitz]

On 02/26/2013 08:38 AM, Robert Moskowitz wrote:
Continuing to 'clean up' my new server by reviewing logged messages. 
Researching a common one:


Feb 26 07:30:29 onlo named[19336]: error (unexpected RCODE SERVFAIL) 
resolving 'foo.com/MX/IN': 1.2.3.4#53


I get the drift that my server has been directed to a 'lame server' 
and logs that fact.  Supposedly I am to lookup the SOA record and 
contact the admin to fix this.  What I really want to do is stop all 
these messages as I suspect I will not be able to do anything to fix 
the problem.  So far what I have found is to add to my global logging 
section:


category lame-servers { null; };

Is there a finer scalpel?  I believe there are other lame server 
failures? Like 'RCODE REFUSED' and 'RCODE 15' (these are the 3 I see 
in my messages)?  Can I block logging by RCODE, so as new ones appear 
I can learn what they mean before /dev/null ing them?


I would be interested in which client is requesting these lookups that 
end up going to lame servers.  I am assuming the IP address in the log 
is the address of the lame server, not the requesting client.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: disabling lame server logging

[Robert Moskowitz]

On 02/26/2013 09:13 AM, Phil Mayers wrote:

On 26/02/13 13:54, Robert Moskowitz wrote:


I would be interested in which client is requesting these lookups that
end up going to lame servers.  I am assuming the IP address in the log
is the address of the lame server, not the requesting client.


Look at the query logs?


I suspect I do not have any query logs.  Where are they, typically. How 
are they controled (logging commands)?


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: disabling lame server logging

[Robert Moskowitz]

On 02/26/2013 09:25 AM, Robert Moskowitz wrote:


On 02/26/2013 09:13 AM, Phil Mayers wrote:

On 26/02/13 13:54, Robert Moskowitz wrote:


I would be interested in which client is requesting these lookups that
end up going to lame servers.  I am assuming the IP address in the log
is the address of the lame server, not the requesting client.


Look at the query logs?


I suspect I do not have any query logs.  Where are they, typically. 
How are they controled (logging commands)?


OK.   I found the 'rndc querylog' command.

Boy is my mailserver hitting me up with repeated queries!  I should 
probably be running a namecaching server on it to stop this resource hit?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: disabling lame server logging

[Robert Moskowitz]

On 02/26/2013 09:37 AM, Phil Mayers wrote:

On 26/02/13 14:31, Robert Moskowitz wrote:


On 02/26/2013 09:25 AM, Robert Moskowitz wrote:


On 02/26/2013 09:13 AM, Phil Mayers wrote:

On 26/02/13 13:54, Robert Moskowitz wrote:

I would be interested in which client is requesting these lookups 
that
end up going to lame servers.  I am assuming the IP address in the 
log

is the address of the lame server, not the requesting client.


Look at the query logs?


I suspect I do not have any query logs.  Where are they, typically.
How are they controled (logging commands)?


OK.   I found the 'rndc querylog' command.


Yes. Note that you can enable this by default in the options 
statement. This is all pretty well documented and easy to find in the 
ARM...


This is traffic I only want occationally!  I am trying to reduce the 
logging size to find new problems.





Boy is my mailserver hitting me up with repeated queries!  I should
probably be running a namecaching server on it to stop this resource 
hit?


Shrug. It depends on your config, load and so forth. There's no right 
answer to that sort of question.


We do run caching resolvers on our MX/outbound relays. You can still 
forward such to your main resolvers.


I would expect that a namecaching server on the mailserver would reduce 
traffic and resources all the way around.


I don't need my mailserver to constantly be asking my name server about, 
say, zen.spamhaus.org.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

name caching and forwarding

[Robert Moskowitz]

So now I am working on adding a name caching service to my mailserver.  
And I am reading up on namecaching.  For RHEL/Centos, there is not much 
to doing this as the default install of bind SEEMS to be a name caching 
server.  But I want it to NOT go out on the net for queries, but to 
direct all of its queries to my internal bind server.


The latter I see I need:

forwarders { 10.2.3.4; 192.168.2.5; };

But it seems that with this you need to include:

forward ( only | first );

And I am having challenges with the forward option.  It reads that 
'forward only' will always ask the forwarder about the query and seems 
to defeat caching?  And 'forward first' only looks in cache after a 
forward fails?  This does not sound right and I am missing something in 
the documentation; like forwarding ONLY applies IF the query is NOT in 
cache?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: name caching and forwarding

[Robert Moskowitz]

On 02/26/2013 11:14 AM, Phil Mayers wrote:

On 26/02/13 16:07, Robert Moskowitz wrote:


And I am having challenges with the forward option.  It reads that
'forward only' will always ask the forwarder about the query and seems
to defeat caching?  And 'forward first' only looks in cache after a
forward fails?  This does not sound right and I am missing something in
the documentation; like forwarding ONLY applies IF the query is NOT in
cache?


No, you've misunderstood.


forward first means try the forwarders, and if you don't get a 
reply, try the query yourself starting from the root


forward only means only ever try the forwarders

forward replies are always cached for the relevant TTL.


OK.  This is what I was hoping it meant, but I was not good at 
expressing it.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: disabling lame server logging

[Robert Moskowitz]

On 02/26/2013 11:43 AM, Sten Carlsen wrote:


On 26/02/13 15:50, Robert Moskowitz wrote:


I would expect that a namecaching server on the mailserver would 
reduce traffic and resources all the way around.


I don't need my mailserver to constantly be asking my name server 
about, say, zen.spamhaus.org.
This is one reason my mailserver has a DNS server. No forward, that 
only slows down things.
The question here is whether there is a good reason that this instance 
must not go directly to the roots?


To support systems only visable to your internal view?


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: disabling lame server logging

[Robert Moskowitz]

On 02/26/2013 12:58 PM, Sten Carlsen wrote:


On 26/02/13 18:06, Robert Moskowitz wrote:


On 02/26/2013 11:43 AM, Sten Carlsen wrote:


On 26/02/13 15:50, Robert Moskowitz wrote:


I would expect that a namecaching server on the mailserver would 
reduce traffic and resources all the way around.


I don't need my mailserver to constantly be asking my name server 
about, say, zen.spamhaus.org.
This is one reason my mailserver has a DNS server. No forward, that 
only slows down things.
The question here is whether there is a good reason that this 
instance must not go directly to the roots?


To support systems only visable to your internal view?
I have in my internal view mostly systems that are not visible from 
the outside but my internal view has direct access to the world with 
regards to DNS. I don't see any risk in that , except the 
predictability of RBL-lookups as mentioned elsewhere.
Speed is much improved, even with a standard ADSL line I have better 
performance than by forwarding to the ISP DNS server.


What I meant here, rather poorly stated, is that my mail server would 
have to look up clients that only resolve within my internal view.  For 
example foo.bar which resolves to 192.168.178.5.  That query would fail 
if all the caching server had was public DNS data.


I DO run a hidden TLD here for some testing and those devices currently 
do send mail from one to another through my current mail server.







--
Best regards

Sten Carlsen

No improvements come from shouting:

MALE BOVINE MANURE!!!


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: disabling lame server logging

[Robert Moskowitz]

On 02/26/2013 01:19 PM, Doug Barton wrote:
You want to set up your resolver on your mail server to forward to 
your main resolver, using the forward only option. This will allow 
your mail server resolver to benefit from the cache already populated 
on your main resolver, while still maintaining the value of caching 
the answers itself locally.


What I have done.

Your goal of reducing the number of error messages in your main 
resolver's logs so that you can better chase down real problems is a 
good one. However you eventually reach a point of diminishing return 
where further reducing the errors ends up in you missing actual new 
problems.


Pretty quite.  For now.  I would like a scalpel for lame logging, but 
probably would not discover any actionable data.




Or, put another way, slogging through noisy logs is part of the job, 
given the horrific state of most DNS out there. Welcome to the club.


Well I am working at getting off the 'horrific state' list.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: name caching and forwarding

[Robert Moskowitz]

hey, Kevin, hope you are hanging well back at the old stomping ground!

On 02/26/2013 01:42 PM, Kevin Darcy wrote:

On 2/26/2013 11:39 AM, Robert Moskowitz wrote:


On 02/26/2013 11:14 AM, Phil Mayers wrote:

On 26/02/13 16:07, Robert Moskowitz wrote:


And I am having challenges with the forward option.  It reads that
'forward only' will always ask the forwarder about the query and seems
to defeat caching?  And 'forward first' only looks in cache after a
forward fails?  This does not sound right and I am missing 
something in

the documentation; like forwarding ONLY applies IF the query is NOT in
cache?


No, you've misunderstood.


forward first means try the forwarders, and if you don't get a 
reply, try the query yourself starting from the root


forward only means only ever try the forwarders

forward replies are always cached for the relevant TTL.


OK.  This is what I was hoping it meant, but I was not good at 
expressing it.
To clarify even further, caching is *always* in effect, no matter what 
kind of non-authoritative zone you define (forward, stub, etc.) or 
even if you have no explicit zone definition at all and simply follow 
the delegation chain to the data, as Phil described.


Think of forward first as opportunistic, in the sense that you'll 
try to get the data via forwarding, but if that doesn't work, you'll 
fall back to whatever mechanism you'd use to resolve the name, if the 
zone definition didn't exist at all. Generally speaking, forward 
first is an attempt (usually unsuccessful, in most environments) to 
improve query performance by utilizing a centralized cache.


Forward only, on the other hand, is dependent, in the sense that 
your forwarders are the *only* thing that will allow you to resolve 
the name. If that doesn't work, the query fails completely. Forward 
only should be used, not solely as an attempt to enhance performance, 
but as a way to get around connectivity restrictions, e.g. firewalls 
or a restrictive routing regime.


So, in a nutshell: forward first as an opportunistic attempt to 
improve performance, but you can still fall back to your regular 
resolution methods; forward only to get around blockages or 
connectivity restrictions.


Very well summarized.  Thank you.  What I was expecting it to work, but 
verify; don't just trust.




If all you want to do is run a private namespace, I wouldn't be 
fiddling around with forwarding at all. Set up your own root zone, 
propagate a private set of hints data, and be happy. I know that you 
once thrived in such a DNS environment :-)


Them were the days.



- Kevin

P.S. Insightful readers may have picked up from the above that I am 
not particularly fond of forwarding at all. In my experience, 
iterative resolution usually shows better performance, especially in 
geographically-diverse infrastructures with many subdomain levels 
(would I really want to forward through Italian nameservers to resolve 
names that I could resolve from nameservers in the same metro area, 
for the North American subdivision of one of our partners?). For that 
matter, I'm an even bigger fan of replicating zone data far and wide 
on stealth slaves -- give your users the maximum in performance and 
resiliency, and they'll be happier for it. In practical terms, one of 
the biggest issues I have about forwarding is that admins who go hog 
wild with it tend to get really lazy and sloppy about keeping their 
delegations and glue straight. Which means they create massive 
interoperability problems for anyone who doesn't want to play in their 
forwarding sandbox. Even though I eschew forwarding myself, I leave 
the option open for people to forward to my infrastructure 
*if*they*must*, but with all of the broken delegations/glue, I am not 
afforded the same opportunity to utilize my preferred resolution 
methodology. That seems a little selfish/one-sided.


My little network will do well as I am setting it up.  Plus I can run my 
HIP testing.  I leave the world-wide mess to old hands like you.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: disabling lame server logging

[Robert Moskowitz]

On 02/26/2013 01:57 PM, Doug Barton wrote:

On 02/26/2013 10:38 AM, Robert Moskowitz wrote:

I would like a scalpel for lame logging, but probably would not discover
any actionable data.


There is a logging category for lame-servers. It's in the ARM.


So far 2 reads and I am not getting out of it what to do for selective 
logging based on return codes.  I am going to let it stay for now as I 
move on to other parts of this project.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Stop of logging of No Valid Signature Found

[Robert Moskowitz]

Yes, I know lots of places don't have DNSSEC signed zones.  **I** have 
not done mine yet, but I turned on DNSSEC checking on my server and I am 
getting all too many messages like:


  validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid signature 
found: 1 Time(s)
  validating @0xb4247b50: 117.in-addr.arpa SOA: no valid signature 
found: 1 Time(s)



How can I stop the logging of only  no valid signature found?  So I 
can watch for more meaningful events and not so quickly grow 
/var/log/messages?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Stop of logging of No Valid Signature Found

[Robert Moskowitz]

On 02/25/2013 02:00 PM, Casey Deccio wrote:
On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz r...@htt-consult.com 
mailto:r...@htt-consult.com wrote:


Yes, I know lots of places don't have DNSSEC signed zones.  **I**
have not done mine yet, but I turned on DNSSEC checking on my
server and I am getting all too many messages like:

  validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid
signature found: 1 Time(s)
  validating @0xb4247b50: 117.in-addr.arpa SOA: no valid
signature found: 1 Time(s)


Yes, but 117.in-addr.arpa *is* signed [1], so if you're not getting 
signatures, that's problematic.


So that is not good.  This is over port 53, right?  I have that open for 
udp and tcp.  My general options section has:


dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

/* Path to ISC DLV key */
bindkeys-file /etc/named.iscdlv.key;

managed-keys-directory /var/named/dynamic;



How can I stop the logging of only  no valid signature found?
 So I can watch for more meaningful events and not so quickly grow
/var/log/messages?


Logging can be tuned on a per-category (e.g., DNSSEC) basis, including 
the location to which log messages are sent (e.g., file, syslog, 
etc.).  See the section on logging in the BIND 9 Configuration 
Reference for more information on how to do this [2].


thanks I will read this AFTER I find out why I am not getting the 
signature.  Perhaps I should check to see if I am getting any sigs? How 
might I do that?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Stop of logging of No Valid Signature Found

[Robert Moskowitz]

On 02/25/2013 02:33 PM, Robert Moskowitz wrote:


On 02/25/2013 02:00 PM, Casey Deccio wrote:
On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz 
r...@htt-consult.com mailto:r...@htt-consult.com wrote:


Yes, I know lots of places don't have DNSSEC signed zones.  **I**
have not done mine yet, but I turned on DNSSEC checking on my
server and I am getting all too many messages like:

  validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid
signature found: 1 Time(s)
  validating @0xb4247b50: 117.in-addr.arpa SOA: no valid
signature found: 1 Time(s)


Yes, but 117.in-addr.arpa *is* signed [1], so if you're not getting 
signatures, that's problematic.


So that is not good.  This is over port 53, right?  I have that open 
for udp and tcp.  My general options section has:


dnssec-enable yes;
dnssec-validation yes;
dnssec-lookaside auto;

/* Path to ISC DLV key */
bindkeys-file /etc/named.iscdlv.key;

managed-keys-directory /var/named/dynamic;



How can I stop the logging of only  no valid signature found?
 So I can watch for more meaningful events and not so quickly
grow /var/log/messages?


Logging can be tuned on a per-category (e.g., DNSSEC) basis, 
including the location to which log messages are sent (e.g., file, 
syslog, etc.).  See the section on logging in the BIND 9 
Configuration Reference for more information on how to do this [2].


thanks I will read this AFTER I find out why I am not getting the 
signature.  Perhaps I should check to see if I am getting any sigs?  
How might I do that?


Well I am not getting this sig authenticated.  Per offlist instructions 
I did (and got no aa flag):


dig +dnssec 117.in-addr.arpa ptr

;  DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.6  +dnssec 
117.in-addr.arpa ptr

;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 34757
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;117.in-addr.arpa.INPTR

;; AUTHORITY SECTION:
117.in-addr.arpa.10800INSOAns1.apnic.net. 
read-txt-record-of-zone-first-dns-admin.apnic.net. 3006077576 7200 1800 
604800 172800
117.in-addr.arpa.10800INRRSIGSOA 5 3 172800 
20130327180149 20130225170149 31261 117.in-addr.arpa. 
bC/xkWAsZ9+NdEMshdBQKqE4Xkdvjnwtqquvbl2142Og64XkgplTlrB8 
gMgCGxeorXpzvPJDsCfhlpXWsq2ck+qSSvOEJeOEt88BBumMAO1Bc46k 
klXmQ4+eckbnWEwrpk4nkG+3K8lbAgZZjSPiVpbu4klfRyZ+T45EnZx0 oJc=
117.in-addr.arpa.10800INRRSIGNSEC 5 3 172800 
20130327180149 20130225170149 31261 117.in-addr.arpa. 
LIxMYOMIW8eTRACvq02vqMrhSk7tX8Az2gahOJ5jYCUvGDzsTtcm7ub+ 
qyWADcklsVi3hiWHnSzAPTIrO6WIrxj/wZl/5m5QTOK38Ml4ut0FFkK+ 
4qujylUJ8+3mmPbTbTIe6gdB8Lv/6pV2rZy1pDm1TxhGykwG82v+1R2E +88=
117.in-addr.arpa.10800INNSEC0.117.in-addr.arpa. NS SOA 
TXT RRSIG NSEC DNSKEY


;; Query time: 207 msec
;; SERVER: 208.83.67.148#53(208.83.67.148)
;; WHEN: Mon Feb 25 15:16:54 2013
;; MSG SIZE  rcvd: 527


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Stop of logging of No Valid Signature Found

[Robert Moskowitz]

On 02/25/2013 03:25 PM, Robert Moskowitz wrote:


On 02/25/2013 02:33 PM, Robert Moskowitz wrote:


On 02/25/2013 02:00 PM, Casey Deccio wrote:
On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz 
r...@htt-consult.com mailto:r...@htt-consult.com wrote:


Yes, I know lots of places don't have DNSSEC signed zones.
 **I** have not done mine yet, but I turned on DNSSEC checking
on my server and I am getting all too many messages like:

  validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid
signature found: 1 Time(s)
  validating @0xb4247b50: 117.in-addr.arpa SOA: no valid
signature found: 1 Time(s)


Yes, but 117.in-addr.arpa *is* signed [1], so if you're not getting 
signatures, that's problematic.


So that is not good.  This is over port 53, right?  I have that open 
for udp and tcp.  My general options section has:


dnssec-enable yes;
dnssec-validation yes;


digging back in the archive here, I find out this should be

dnssec-validation auto;

And now I don't have all those false no valid sig messages and I can 
look for the NEXT problem.



dnssec-lookaside auto;

/* Path to ISC DLV key */
bindkeys-file /etc/named.iscdlv.key;

managed-keys-directory /var/named/dynamic;




___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Stop of logging of No Valid Signature Found

[Robert Moskowitz]

On 02/25/2013 08:15 PM, Mark Andrews wrote:

In message 512c09f5.4040...@htt-consult.com, Robert Moskowitz writes:

On 02/25/2013 03:25 PM, Robert Moskowitz wrote:

On 02/25/2013 02:33 PM, Robert Moskowitz wrote:

On 02/25/2013 02:00 PM, Casey Deccio wrote:

On Mon, Feb 25, 2013 at 5:09 AM, Robert Moskowitz
r...@htt-consult.com mailto:r...@htt-consult.com wrote:

 Yes, I know lots of places don't have DNSSEC signed zones.
  **I** have not done mine yet, but I turned on DNSSEC checking
 on my server and I am getting all too many messages like:

   validating @0xb4247b50: 117.in-addr.arpa NSEC: no valid
 signature found: 1 Time(s)
   validating @0xb4247b50: 117.in-addr.arpa SOA: no valid
 signature found: 1 Time(s)


Yes, but 117.in-addr.arpa *is* signed [1], so if you're not getting
signatures, that's problematic.

So that is not good.  This is over port 53, right?  I have that open
for udp and tcp.  My general options section has:

 dnssec-enable yes;
 dnssec-validation yes;

digging back in the archive here, I find out this should be

  dnssec-validation auto;

Actually it can be either.  It's all a matter of how you want to
setup your trust anchors.  For private root zones it is absolutely
the wrong thing to do.


I got this from some old messages from you on the subject of no valid 
signature.


Perhaps tieing into my using the builtin root hints rather than 
explicitly including a root.hint stub?


Like the other person, once I changed from 'yes' to 'auto' I stopped 
logging these messages so I ASSuME that now all those zones are being 
validated.


No private root zones here.  At least that I know of!

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Stop of logging of No Valid Signature Found

[Robert Moskowitz]

On 02/25/2013 08:38 PM, Mark Andrews wrote:

In message 512c1009.4060...@htt-consult.com, Robert Moskowitz writes:

  dnssec-enable yes;
  dnssec-validation yes;

digging back in the archive here, I find out this should be

   dnssec-validation auto;

Actually it can be either.  It's all a matter of how you want to
setup your trust anchors.  For private root zones it is absolutely
the wrong thing to do.

I got this from some old messages from you on the subject of no valid
signature.

Perhaps tieing into my using the builtin root hints rather than
explicitly including a root.hint stub?

Like the other person, once I changed from 'yes' to 'auto' I stopped
logging these messages so I ASSuME that now all those zones are being
validated.

No private root zones here.  At least that I know of!

dnssec-validation auto; adds a implicit managed-keys clause for the
root.  If you just do dnssec-validation yes; you need to add a
explict trusted-keys / managed-keys clause.

managed-keys {
 . initial-key 257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=;
};


Yes, I wondered about this as I have the include:

bindkeys-file /etc/named.iscdlv.key;

which contains:

managed-keys {
# ISC DLV: See https://www.isc.org/solutions/dlv for details.
# NOTE: This key is activated by setting dnssec-lookaside auto;
# in named.conf.
dlv.isc.org. initial-key 257 3 5 
BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2

brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt
TDN0YUuWrBNh;

# ROOT KEY: See https://data.iana.org/root-anchors/root-anchors.xml
# for current trust anchor information.
# NOTE: This key is activated by setting dnssec-validation auto;
# in named.conf.
. initial-key 257 3 8 
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF

FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
QxA+Uk1ihz0=;
};

So why did this not work?


If you have islands of trust you will need to have managed/trusted
keys for them.  It is also a good idea to have managed/trusted keys
for your internal zones so you are not dependent on external zones
for internal lookups when your internet connection goes down.


I know I need to tackle my internal view.  After I put up the new 
server, I built a test server for only a few internal systems to use.  I 
will work on my internal view there, and then bring that over to my main 
server.


One step at a time.  Or maybe two or three?


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Stop of logging of No Valid Signature Found

[Robert Moskowitz]

On 02/25/2013 09:36 PM, Mark Andrews wrote:

In message 512c18eb.2050...@htt-consult.com, Robert Moskowitz writes:

On 02/25/2013 08:38 PM, Mark Andrews wrote:

In message 512c1009.4060...@htt-consult.com, Robert Moskowitz writes:

   dnssec-enable yes;
   dnssec-validation yes;

digging back in the archive here, I find out this should be

dnssec-validation auto;

Actually it can be either.  It's all a matter of how you want to
setup your trust anchors.  For private root zones it is absolutely
the wrong thing to do.

I got this from some old messages from you on the subject of no valid
signature.

Perhaps tieing into my using the builtin root hints rather than
explicitly including a root.hint stub?

Like the other person, once I changed from 'yes' to 'auto' I stopped
logging these messages so I ASSuME that now all those zones are being
validated.

No private root zones here.  At least that I know of!

dnssec-validation auto; adds a implicit managed-keys clause for the
root.  If you just do dnssec-validation yes; you need to add a
explict trusted-keys / managed-keys clause.

managed-keys {
  . initial-key 257 3 8 AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOy

QbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVP
QuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apA
zvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ
57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=;

};

Yes, I wondered about this as I have the include:

  bindkeys-file /etc/named.iscdlv.key;

which contains:

managed-keys {
  # ISC DLV: See https://www.isc.org/solutions/dlv for details.
  # NOTE: This key is activated by setting dnssec-lookaside auto;
  # in named.conf.
  dlv.isc.org. initial-key 257 3 5
BEPHMu/5onzrEE7z1egmhg/WPO0+juoZrW3euWEn4MxDCE1+lLy2
  brhQv5rN32RKtMzX6Mj70jdzeND4XknW58dnJNPCxn8+jAGl2FZLK8t+
  1uq4W+nnA3qO2+DL+k6BD4mewMLbIYFwe0PG73Te9fZ2kJb56dhgMde5
  ymX4BI/oQ+cAK50/xvJv00Frf8kw6ucMTwFlgPe+jnGxPPEmHAte/URk
  Y62ZfkLoBAADLHQ9IrS2tryAe7mbBZVcOwIeU/Rw/mRx/vwwMCTgNboM
  QKtUdvNXDrYJDSHZws3xiRXF1Rf+al9UmZfSav/4NWLKjHzpT59k/VSt
  TDN0YUuWrBNh;

  # ROOT KEY: See https://data.iana.org/root-anchors/root-anchors.xml
  # for current trust anchor information.
  # NOTE: This key is activated by setting dnssec-validation auto;
  # in named.conf.
  . initial-key 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjF
  FVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoX
  bfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaD
  X6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpz
  W5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relS
  Qageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulq
  QxA+Uk1ihz0=;
};

So why did this not work?

Because it is only processed in the auto cases and only the approritate
trusted keys are extracted.

bindkeys-file /etc/named.iscdlv.key;

is not the same as

include /etc/named.iscdlv.key;


Oops.  That's what I get for copying the DNSSEC 'stuff' from the default 
named.conf supplied by RHEL/Centos which looks like it is for a caching 
server.


So should I change this to an include and put dnssec-validation back to yes?

  

If you have islands of trust you will need to have managed/trusted
keys for them.  It is also a good idea to have managed/trusted keys
for your internal zones so you are not dependent on external zones
for internal lookups when your internet connection goes down.

I know I need to tackle my internal view.  After I put up the new
server, I built a test server for only a few internal systems to use.  I
will work on my internal view there, and then bring that over to my main
server.

One step at a time.  Or maybe two or three?


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Registrar that supports self-run domains and provides DNSSEC support

[Robert Moskowitz]

On 02/22/2013 10:51 AM, Mike Hoskins (michoski) wrote:
I know this last bit from experience, having worked at CELECs back in 
the day and running an ISP that was severely underfunded because the 
Internet was new and couldn't be trusted like a telephone. Lots of 
committed people working long hours for very little, but there's only 
so much you can do with blood, sweat and tears.


Lived this to, in part.  Thus we have for the most part big players with 
big fees.


But I will start my migration shortly.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Not - Re: New DNS server up and running

[Robert Moskowitz]

On 02/21/2013 02:38 AM, Sten Carlsen wrote:

What about allow-query?

At some point the default changed to allow only localhost.


oh.  Yes I see; at bind 9.4.1.P1...  And my old server is a bit earlier 
than that!  So this is most likely my problem.  Will change and test 
again.  thanks.




On 21/02/13 2:59, Robert Moskowitz wrote:


On 02/20/2013 08:28 PM, Robert Moskowitz wrote:
It looks like no system, internal or external could access the DNS 
on my new server.  IPTABLES was set for 53 both UDP and TCP. 
Firewall was OK.  In fact a local system on the same subnet, thus 
NOT going through my firewall was denied access to the internal 
domain. Localhost of course works.

Oh, here is what I have for options in my internal view:

match-clients{ httnets; };
match-destinations{ httnets; };
recursion yes;
empty-zones-enable yes;

and httnets contains:

acl httnets {
127.0.0.1;
208.83.67.128/26;
192.168.32.0/24;
192.168.64.0/24;
192.168.96.0/24;
192.168.128.0/24;
192.168.192.0/24;
::1;
2607:f4b8:3:0::/64;
2607:f4b8:3:1::/64;
2607:f4b8:3:2::/64;
2607:f4b8:3:3::/64;
2607:f4b8:3:4::/64;
2607:f4b8:3:5::/64;
2607:f4b8:3:8::/64;
2607:f4b8:3:9::/64;
2607:f4b8:3:10::/64;
2607:f4b8:3:11::/64;
2607:f4b8:3:12::/64;
2607:f4b8:3:13::/64;
};

But I used my Verizon cellular wifi to connect a system from outside, 
and when I did a DIG to my ip address, it was denied by named (as 
seen in /var/log/messages), so the problem is broader than just my 
internal view and why i think it is either the randomized port and 
firewall interaction of selinux.





So it is either the Linux firewall and bind port randomization, or 
it is SELINUX.  How do I test to find out which?


Since the new server is on the same IP address as the old, it is 
unplugged from the switch.  I can switch back and forth between to 
two boxes, only taking the time for ARP table updates.


So I hope someone can point me to what I have missed.


On 02/20/2013 02:07 PM, Robert Moskowitz wrote:
Phase I is hopefully complete.  A new onlo.htt-consult.com is up in 
place of the old one.


This is a faster box with current software.  I will 'leave it 
alone' for a week, unless someone tells me something is wrong with it.


Next I unlock my domain from NetSol and choose my new registrar and 
move.  Thank you on all the recommendations. Now to choose.


I study up on DNSSEC, maybe read a book or two.

Then after Passover, start the signing!

So I will be, ahem, quite here for awhile.  Yeah sure.  Well I DO 
have other systems and services to migrate.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


--
Best regards

Sten Carlsen

No improvements come from shouting:
MALE BOVINE MANURE!!!


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Not - Re: New DNS server up and running

[Robert Moskowitz]

On 02/21/2013 02:38 AM, Sten Carlsen wrote:

What about allow-query?


OK.  That was it.  The default named.conf had:

allow-query { localhost; };

and I commented that out, but ASSuMEd that if the default conf was 
forcing it to localhost, the default must be any.  Yeah, right.  So 
right now I am running with my internal nets for the internal view, and 
any for the external view.  ISC has an FAQ on this and talk about 
allowing external authoritative query, but not cache query.  I will have 
to play around a bit with that.




At some point the default changed to allow only localhost.

On 21/02/13 2:59, Robert Moskowitz wrote:


On 02/20/2013 08:28 PM, Robert Moskowitz wrote:
It looks like no system, internal or external could access the DNS 
on my new server.  IPTABLES was set for 53 both UDP and TCP. 
Firewall was OK.  In fact a local system on the same subnet, thus 
NOT going through my firewall was denied access to the internal 
domain. Localhost of course works.

Oh, here is what I have for options in my internal view:

match-clients{ httnets; };
match-destinations{ httnets; };
recursion yes;
empty-zones-enable yes;

and httnets contains:

acl httnets {
127.0.0.1;
208.83.67.128/26;
192.168.32.0/24;
192.168.64.0/24;
192.168.96.0/24;
192.168.128.0/24;
192.168.192.0/24;
::1;
2607:f4b8:3:0::/64;
2607:f4b8:3:1::/64;
2607:f4b8:3:2::/64;
2607:f4b8:3:3::/64;
2607:f4b8:3:4::/64;
2607:f4b8:3:5::/64;
2607:f4b8:3:8::/64;
2607:f4b8:3:9::/64;
2607:f4b8:3:10::/64;
2607:f4b8:3:11::/64;
2607:f4b8:3:12::/64;
2607:f4b8:3:13::/64;
};

But I used my Verizon cellular wifi to connect a system from outside, 
and when I did a DIG to my ip address, it was denied by named (as 
seen in /var/log/messages), so the problem is broader than just my 
internal view and why i think it is either the randomized port and 
firewall interaction of selinux.





So it is either the Linux firewall and bind port randomization, or 
it is SELINUX.  How do I test to find out which?


Since the new server is on the same IP address as the old, it is 
unplugged from the switch.  I can switch back and forth between to 
two boxes, only taking the time for ARP table updates.


So I hope someone can point me to what I have missed.


On 02/20/2013 02:07 PM, Robert Moskowitz wrote:
Phase I is hopefully complete.  A new onlo.htt-consult.com is up in 
place of the old one.


This is a faster box with current software.  I will 'leave it 
alone' for a week, unless someone tells me something is wrong with it.


Next I unlock my domain from NetSol and choose my new registrar and 
move.  Thank you on all the recommendations. Now to choose.


I study up on DNSSEC, maybe read a book or two.

Then after Passover, start the signing!

So I will be, ahem, quite here for awhile.  Yeah sure.  Well I DO 
have other systems and services to migrate.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


--
Best regards

Sten Carlsen

No improvements come from shouting:
MALE BOVINE MANURE!!!


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

allow-query and views

[Robert Moskowitz]

I am reading: https://www.isc.org/software/bind/faq and 'What has 
changed in the behavior of allow-recursion and allow-query-cache '.



I am struggling here trying to match up the various access control 
features, particularly when we are suppose to have different views for 
different clients.


So for my internal view where I:

match-clients{ httnets; };
match-destinations{ httnets; };
recursion yes;
allow-query{ httnets; };

Do I also add

allow-query-cache{ httnets; };

???

And for the external view where:

match-clients{ any; };
match-destinations{ any; };
allow-query{ any; };
recursion no;

Do I add:

allow-query-cache{ localhost; };

???  Supposedly localhost will fall into the internal view (along with 
httnet), so nothing should be querying cache?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query and views

[Robert Moskowitz]

On 02/21/2013 10:40 AM, Matus UHLAR - fantomas wrote:

On 21.02.13 08:59, Robert Moskowitz wrote:
I am reading: https://www.isc.org/software/bind/faq and 'What has 
changed in the behavior of allow-recursion and allow-query-cache '.



I am struggling here trying to match up the various access control 
features, particularly when we are suppose to have different views 
for different clients.


So for my internal view where I:

   match-clients{ httnets; };
   match-destinations{ httnets; };
   recursion yes;
   allow-query{ httnets; };


allow-query is useless here, unless you have disabled it somewhere.
the match-clients does enough.


No. allow-query made my internal view available to my local clients.  
Check my earlier posts here.  I was down here with just the 
match-clients and without the allow-query; all local hosts were getting 
denied access.  It was painful for a little while.





Do I also add

   allow-query-cache{ httnets; };
???


you apparently want to turn on recursion for your clients, which 
means, you

should use allow-recursion and let allow-query-cache be teh same by
default.


Recursion seems to be working with just  recursion yes here.  What 
does allow-recursion add with given all the other restrictive clauses?





And for the external view where:

   match-clients{ any; };
   match-destinations{ any; };
   allow-query{ any; };
   recursion no;

Do I add:

   allow-query-cache{ localhost; };


???  Supposedly localhost will fall into the internal view (along 
with httnet)


and does localhost belong to the httnets ACL?


Yes.  both 127.0.0.1 and ::1 are listed.




, so nothing should be querying cache?


correct, no external hosts should query your cache.


OK.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query and views

[Robert Moskowitz]

On 02/21/2013 12:10 PM, Matus UHLAR - fantomas wrote:

On 21.02.13 08:59, Robert Moskowitz wrote:
I am reading: https://www.isc.org/software/bind/faq and 'What has 
changed in the behavior of allow-recursion and 
allow-query-cache '.



I am struggling here trying to match up the various access control 
features, particularly when we are suppose to have different views 
for different clients.


So for my internal view where I:

  match-clients{ httnets; };
  match-destinations{ httnets; };
  recursion yes;
  allow-query{ httnets; };



On 02/21/2013 10:40 AM, Matus UHLAR - fantomas wrote:

allow-query is useless here, unless you have disabled it somewhere.
the match-clients does enough.


On 21.02.13 11:08, Robert Moskowitz wrote:
No. allow-query made my internal view available to my local clients. 


allow-query defaults to all. match-clients directs your internal 
clients to
the internal view and unless you have disabled querying elsewhere, 
allowing

it is not important.


Fact:

No clients could access DNS from my server, both internal and external 
(I have hotspot on my cellphone, so I can attach a client to it to get 
external testing) UNTIL I added the allow-query option.  Once added 
things started working right.


All I can report is what was not working and what made it work. 
allow-query SEEMS to be working the same way as allow-query-cache.




Check my earlier posts here.  I was down here with just the 
match-clients and without the allow-query; all local hosts were 
getting denied access.  It was painful for a little while.


Probably they did not have a recursion enabled. allow-recursion 
defaults to

local networks, if not specified directly or by allow-query-cache.


I had the recursion yes option in my internal view.  But even queries of 
zones it was master for were coming up DENIED without the allow-query 
option.





Do I also add

  allow-query-cache{ httnets; };
???


you apparently want to turn on recursion for your clients, which 
means, you

should use allow-recursion and let allow-query-cache be teh same by
default.


Recursion seems to be working with just  recursion yes here.


Recursion by itself, yes. But the default for allow-recursion might 
not be

enough for you.
In fact, you can use allow-recursion { all; }; and still only internal
clients (in internal view) would have it allowed.


So recursion yes does not override allow-recursion?  Strange.




 What does allow-recursion add with given all the other restrictive
clauses?


It allows specified clients to use recursion. Both allow-query-cache and
allow-recursion default to the other one, when only one is specified.
However, allow-recursion gives a better idea of what is really allowed.


Then what is the basic recursion option for now?  Is it just a hold-over 
from more trusting days?





And for the external view where:

  match-clients{ any; };
  match-destinations{ any; };
  allow-query{ any; };
  recursion no;

Do I add:

  allow-query-cache{ localhost; };




thanks

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query and views

[Robert Moskowitz]

On 02/21/2013 11:50 AM, Vernon Schryver wrote:

correct, no external hosts should query your cache.


OK.

There is no substitute for testing assumptions, mailing list assurances,
understandings of documentation, etc.  Test from outside your network
to see that your DNS servers don't answer requests they shouldn't and
answer those they should as they should (e.g. with(out) consulting the
cache).


I have external testing via my Verizon phone's WiFi hotspot.  Very handy.


Don't forget to check `dig @whatever chaos txt version.bind` whether
your preference is to publish your version, hostname, and server-ID
or not.  Restrictions such as allow-query{} in the main options{}
statement can turn off the hidden _bind view defined in
bin/named/config.c.


Whow...  This is news.  A hidden view?  Where is this documented.  I 
have no restrictions in my general options section.  Figured that the 
specific view ones were all that was needed.  Now I am upset.



https://www.google.com/search?q=dig+command+web
finds at least three web pages with loose enough parsing to allow not
only simply requests for A records but poking at chaos, so you don't
need to pay for a shell account somewhere or rely on charity.


thanks

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query and views

[Robert Moskowitz]

On 02/21/2013 12:58 PM, Mike Hoskins (michoski) wrote:

-Original Message-

From: Robert Moskowitz r...@htt-consult.com
Date: Thursday, February 21, 2013 12:53 PM
To: Vernon Schryver v...@rhyolite.com
Cc: bind-users@lists.isc.org bind-users@lists.isc.org
Subject: Re: allow-query and views


Whow...  This is news.  A hidden view?  Where is this documented.  I
have no restrictions in my general options section.  Figured that the
specific view ones were all that was needed.  Now I am upset.

As usual, knowledge is easy but wisdom takes time...

http://www.cymru.com/Documents/secure-bind-template.html


It will take much time to gain wisdom from this piece of advice, as it 
does not answer questions about the hidden view Vern mentioned. It does 
address the chaos part; in part.



You can easily incorporate that before Passover.  :-)


Hah!  That is what you think!  Perhaps we can talk about this at IETF?

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query and views

[Robert Moskowitz]

On 02/21/2013 01:54 PM, Matus UHLAR - fantomas wrote:

On 21.02.13 12:45, Robert Moskowitz wrote:

Fact:


No clients could access DNS from my server, both internal and 
external (I have hotspot on my cellphone, so I can attach a client to 
it to get external testing) UNTIL I added the allow-query option.  
Once added things started working right.


Which BIND version do you use?


Centos 6.3 which Redhat has bind 9.8.2 with patches they have included; 
most notably the security patches.



Do you use your own named.conf? Some OSes/distributions provide multiple
included files with some defaults that may deny access, for example.
Are you sure your named.conf doesn't include such file?


Yes, I have crafted the named.conf and all of its includes.  It was at 
first a port of what I was running on Centos 5.5 which was bind 9.3.6 
(thus before the changes wrought by by 9.4.1.P1).  I added a few items 
from the default named.conf that came with Centos 6.3, notably the 
DNSSEC and support for port randomization (instead of set to 53).




All I can report is what was not working and what made it work. 
allow-query SEEMS to be working the same way as allow-query-cache.


but they both do different things.


I get that.  But I had neither, thus living with the defaults. Adding 
'allow-query { httnet;}' got my local clients working again, and to any 
for when I was testing via my cellular connection.




Check my earlier posts here.  I was down here with just the 
match-clients and without the allow-query; all local hosts were 
getting denied access.  It was painful for a little while.


Probably they did not have a recursion enabled. allow-recursion 
defaults

to local networks, if not specified directly or by allow-query-cache.


I had the recursion yes option in my internal view.  But even queries 
of zones it was master for were coming up DENIED without the 
allow-query option.


There's something strange about this issue. The default for 
allow-query is

all and I don't think this was different any time.
Are you sure there's no other allow-query directive anywhere in your
named's config files?


No.  None.  There was a commented one that came with the default, but it 
was commented out.  It WAS set to localhost, but again it was commented out.





Recursion seems to be working with just  recursion yes here.


Recursion by itself, yes. But the default for allow-recursion might 
not be

enough for you.


In fact, you can use allow-recursion { all; }; and still only 
internal

clients (in internal view) would have it allowed.



So recursion yes does not override allow-recursion?  Strange.


recursion yes/no will tell the server (not) to recurse at all. 
allow-recursion only specifies, for whom to recurse.

recursion no will disable recursing for all (matching) clients.
recursion yes will enable recursing, but only for allowed clients.


So for my external zone with recursion no, I can leave off the 
allow-recursion.





What does allow-recursion add with given all the other restrictive
clauses?


It allows specified clients to use recursion. Both allow-query-cache 
and

allow-recursion default to the other one, when only one is specified.
However, allow-recursion gives a better idea of what is really allowed.


Then what is the basic recursion option for now?  Is it just a 
hold-over from more trusting days?


it's kind of general switch to allow/deny recursion.



GOt it.  Thanks.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query and views

[Robert Moskowitz]

On 02/21/2013 02:04 PM, Vernon Schryver wrote:

From: Robert Moskowitz r...@htt-consult.com
Whow...  This is news.  A hidden view?  Where is this documented.

The ARM says in part:

   Built-in server information zones
 The server provides some helpful diagnostic information through a
 number of built-in zones under the pseudo-top-level-domain bind
 in the CHAOS class. These zones are part of a built-in view (see
 the section called view Statement Grammar) of class CHAOS which
 is separate from the default view of class IN; therefore, any
 global server options such as allow-query do not apply the these
 zones.  If you feel the need to disable these zones, use the options
 below, or hide the built-in CHAOS view by defining an explicit
 view of class CHAOS that matches all clients.


Oy vey, through a glass darkly.  Pieces come back to me about things I 
learned when Kevin introduced me to bind back in '93 and since then I 
have only delved into it when I did an upgrade (like right now!).


I missed Chaosnet, I was doing X.25 stuff around then.  Of course use it 
for odds and ends these days.


And I seemed to have tighted up my rules real tight.  In the global 
options I have locked down queries to only localhost, then open it up in 
the views.  I just tested externally and no access to chaos now.  Here 
is the log entry:


Feb 21 14:14:37 onlo named[24803]: client 70.194.0.112#9517: query 
'version.bind/TXT/CH' denied






I
have no restrictions in my general options section.  Figured that the
specific view ones were all that was needed.  Now I am upset.

It's not a real view, because that you can't change it except by
editing the BIND source, using the version, hostname, and server-id
options, hiding it as the ARM says, or with default options.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query and views

[Robert Moskowitz]

On 02/21/2013 02:16 PM, Vernon Schryver wrote:

The ARM says in part:

   Built-in server information zones
 The server provides some helpful diagnostic information through a
 number of built-in zones under the pseudo-top-level-domain bind
 in the CHAOS class. These zones are part of a built-in view (see
 the section called view Statement Grammar) of class CHAOS which
 is separate from the default view of class IN; therefore, any
 global server options such as allow-query do not apply the these
 zones.  If you feel the need to disable these zones, use the options
 below, or hide the built-in CHAOS view by defining an explicit
 view of class CHAOS that matches all clients.

Now that I read what I wrote, I see that it's wrong.

I found and just now verified that options{allow-query{}} affects
the _bind view at least in 9.10.0pre-alpha with the rrl and rpz2
patches.  I found that feature (or perhap bug) when I decided to
stop hiding the version I use lest anyone think I don't do what I
advocate with BIND patches.

I don't know whether the bug is in the ARM or the code.  If you
pick one, I can argue the other.


Well my named.conf now has in general options:

allow-query{ localhost; };
allow-query-cache{ localhost; };
recursion no;

And no access to the chaos zone from my testing out on the internet.

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Most specific match on PTR records

[Robert Moskowitz]

On 02/21/2013 06:49 PM, Mark Andrews wrote:

In message 
CANYsE-zYQh7Jv4QoVM45q-w1Vz1=YBk7j=K=ooq01ugyvw_...@mail.gmail.com, Nikita 
Koshiko
v writes:

Hello list,


I'm trying to cut /24 network from the scope of /8 network, here is
example:

 zone 11.2.10.in-addr.arpa {
 type forward;
 forwarders { 192.168.1.23; 192.168.1.24; };
 };

 zone 10.in-addr.arpa {
 type master;
 file master/int/10.in-addr.arpa;
 };

10.in-addr.arpa is just a file that returns NXDOMAIN for any 10.0.0.0/8 ip
address. But I need to forward requests for 10.2.11.0/24 net to other dns
servers and the above config not working.
I got empty responses for 10.2.11.0/24 net.

When I see questions like this I ask Why are you doing this the
most complicated way?  Just add a delegation for 11.2.10.in-addr.arpa
to 10.in-addr.arpa.  If you are using global forwarders turn them
off.


ARGH!!!  Mark! Your 'problem' is you are too close to the code and see 
obvious solutions!  :)


This will make some things I do here with my 192.168 nets cleaner. Thanks.

From the guy that started the 'net10' effort.



zone 10.in-addr.arpa {
type master;
file master/int/10.in-addr.arpa;
forwarders { /* empty */ };
};

11.2NS  nameserver1.
11.2NS  nameserver2.


This is right: (192.168.1.8 - server with bind)

$ host -t ptr 10.1.1.1 192.168.1.8
Using domain server:
Name: 192.168.1.8
Address: 192.168.1.8#53
Aliases:
Host 1.1.1.10.in-addr.arpa. not found: 3(NXDOMAIN)

This is wrong:
$ host -t ptr 10.2.11.10  192.168.1.8
Using domain server:
Name: 192.168.1.8
Address: 192.168.1.8#53
Aliases:
Host 10.11.2.10.in-addr.arpa. not found: 3(NXDOMAIN)

This is expected answer from the forwarded server  - 192.168.1.23
$ host -t ptr 10.2.11.10  192.168.1.23
Using domain server:
Name: 192.168.1.23
Address: 192.168.1.23#53
Aliases:
10.11.2.10.in-addr.arpa domain name pointer hawk-agent.local.intranet.

Can someone help with this ?



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

New DNS server up and running

[Robert Moskowitz]

Phase I is hopefully complete.  A new onlo.htt-consult.com is up in 
place of the old one.


This is a faster box with current software.  I will 'leave it alone' for 
a week, unless someone tells me something is wrong with it.


Next I unlock my domain from NetSol and choose my new registrar and 
move.  Thank you on all the recommendations.  Now to choose.


I study up on DNSSEC, maybe read a book or two.

Then after Passover, start the signing!

So I will be, ahem, quite here for awhile.  Yeah sure.  Well I DO have 
other systems and services to migrate.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Not - Re: New DNS server up and running

[Robert Moskowitz]

It looks like no system, internal or external could access the DNS on my 
new server.  IPTABLES was set for 53 both UDP and TCP. Firewall was OK.  
In fact a local system on the same subnet, thus NOT going through my 
firewall was denied access to the internal domain.  Localhost of course 
works.


So it is either the Linux firewall and bind port randomization, or it is 
SELINUX.  How do I test to find out which?


Since the new server is on the same IP address as the old, it is 
unplugged from the switch.  I can switch back and forth between to two 
boxes, only taking the time for ARP table updates.


So I hope someone can point me to what I have missed.


On 02/20/2013 02:07 PM, Robert Moskowitz wrote:
Phase I is hopefully complete.  A new onlo.htt-consult.com is up in 
place of the old one.


This is a faster box with current software.  I will 'leave it alone' 
for a week, unless someone tells me something is wrong with it.


Next I unlock my domain from NetSol and choose my new registrar and 
move.  Thank you on all the recommendations.  Now to choose.


I study up on DNSSEC, maybe read a book or two.

Then after Passover, start the signing!

So I will be, ahem, quite here for awhile.  Yeah sure.  Well I DO have 
other systems and services to migrate.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Not - Re: New DNS server up and running

[Robert Moskowitz]

On 02/20/2013 08:28 PM, Robert Moskowitz wrote:
It looks like no system, internal or external could access the DNS on 
my new server.  IPTABLES was set for 53 both UDP and TCP. Firewall was 
OK.  In fact a local system on the same subnet, thus NOT going through 
my firewall was denied access to the internal domain. Localhost of 
course works.

Oh, here is what I have for options in my internal view:

match-clients{ httnets; };
match-destinations{ httnets; };
recursion yes;
empty-zones-enable yes;

and httnets contains:

acl httnets {
127.0.0.1;
208.83.67.128/26;
192.168.32.0/24;
192.168.64.0/24;
192.168.96.0/24;
192.168.128.0/24;
192.168.192.0/24;
::1;
2607:f4b8:3:0::/64;
2607:f4b8:3:1::/64;
2607:f4b8:3:2::/64;
2607:f4b8:3:3::/64;
2607:f4b8:3:4::/64;
2607:f4b8:3:5::/64;
2607:f4b8:3:8::/64;
2607:f4b8:3:9::/64;
2607:f4b8:3:10::/64;
2607:f4b8:3:11::/64;
2607:f4b8:3:12::/64;
2607:f4b8:3:13::/64;
};

But I used my Verizon cellular wifi to connect a system from outside, 
and when I did a DIG to my ip address, it was denied by named (as seen 
in /var/log/messages), so the problem is broader than just my internal 
view and why i think it is either the randomized port and firewall 
interaction of selinux.





So it is either the Linux firewall and bind port randomization, or it 
is SELINUX.  How do I test to find out which?


Since the new server is on the same IP address as the old, it is 
unplugged from the switch.  I can switch back and forth between to two 
boxes, only taking the time for ARP table updates.


So I hope someone can point me to what I have missed.


On 02/20/2013 02:07 PM, Robert Moskowitz wrote:
Phase I is hopefully complete.  A new onlo.htt-consult.com is up in 
place of the old one.


This is a faster box with current software.  I will 'leave it alone' 
for a week, unless someone tells me something is wrong with it.


Next I unlock my domain from NetSol and choose my new registrar and 
move.  Thank you on all the recommendations.  Now to choose.


I study up on DNSSEC, maybe read a book or two.

Then after Passover, start the signing!

So I will be, ahem, quite here for awhile.  Yeah sure.  Well I DO 
have other systems and services to migrate.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
unsubscribe from this list


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Registrar that supports self-run domains and provides DNSSEC support

[Robert Moskowitz]

Delving further into my challenges.

Right now I use Network Solutions as my registrar.  Just never changes 
as they were the only show in town back then.


But they don't seem to support DNSSEC protected domains, and even IPv6 
glue records are special requests, it seems.


My registration is up for renewal; it expires 4/6/13 so this is a good 
time to move.  But of course my domain is locked and I can't see on NS 
account page how to change that.


I was pointed to dyn.com, but they are not clear about how to apply for 
them just being a registrar and how to contact them for help. Either you 
are asking for their managedDNS service of go to their free community 
forum(s).



I suppose nothing worth doing is easy to do.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Free secondary servers supporting DNSSEC?

[Robert Moskowitz]

I hope to roll out my DNS upgrade today, but without enabling DNSSEC; 
that will take a bit longer.


One of my secondaries, though, does not support DNSSEC and it is the one 
that gives me a bit of geographical diversity.  So I am looking for 
someplace that will accept my smallish domains.


thank you for all of your help in getting me this far along.  Stay tune 
for the inevitable DNSSEC questions!



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Free secondary servers supporting DNSSEC?

[Robert Moskowitz]

On 02/17/2013 09:57 AM, David Forrest wrote:

On Sun, 17 Feb 2013, Vernon Schryver wrote:


In any case, some naming and shaming seems appropriate.  Basic


Naming and shaming seems excessive for a free service.


Just like I am FINALLY moving to DNSSEC, the fellow running the system I 
have been using as a secondary, is a tad behind my efforts.  And 
watching them.  So my doing this is going to get him going as well.



___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Free secondary servers supporting DNSSEC?

[Robert Moskowitz]

On 02/17/2013 09:44 AM, Vernon Schryver wrote:

From: Robert Moskowitz r...@htt-consult.com
One of my secondaries, though, does not support DNSSEC

How does a secondary authoritative DNS server fail to support DNSSEC?
It's not as if it would be doing any signature checking or automagic
(re)signing.  Does it not tolerate the not at all new RRSIG and
NSEC or NSEC3 record types?  Or does not not haves EDNS support?


The Redhat docs on bind had a warning about not implementing features, 
like DNSSEC if your secondaries doesn't support it.  That is all I am 
going on.  I think I also saw it in some isc.org doc.



In any case, some naming and shaming seems appropriate.  Basic
DNSSEC support (i.e. maybe not yet TLSA or SMIMEA) is a fundamental
checklist item today.


Go for it, Vern!


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Free secondary servers supporting DNSSEC?

[Robert Moskowitz]

On 02/17/2013 11:48 AM, Vernon Schryver wrote:

From: David Forrest d...@maplepark.com

In any case, some naming and shaming seems appropriate.  Basic

Naming and shaming seems excessive for a free service.

Services that do not charge users money are often not really free.


This is my concern in coming out and asking about secondary services out 
there.


Given what I do in my day job, I have to be careful to choose a service 
that is trustworthy.  Right now my secondaries are my ISP and a 
colleague that also has another life besides maintaining this old DNS 
server that I use.  But this will get him as much off the ball as I have 
finally gotten.


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users