Re: connections to root servers

[Emmanuel Fusté]

Le 19/12/2022 à 20:06, BÖSCH Christian a écrit :


Hello,

I have two bind dns servers as client resolvers with local zones and 
for the rest


configured forwarders. The root zone “.” and hints file is commented out.

In the connection logs on the firewall I see a lot of connections from 
the resolvers


to the root dns servers.

So can anybody explain why this happens? In my opinion everything 
should go to


the forwarders and I’m also wondering how bind knows about the root 
servers


when there is no hint file?

Thanks,

Christian



It will use build-in fallback definition.
Use the "forward only" directive with the forwarders declaration.

The primary use case for overwriting the root zone/hint content is for 
private root server implementation  in totally disconnected/fully 
private DNS infrastructure.
Otherwise, global forwarders with forward only directive are sufficient 
to stop any direct root servers queries.


Emmanuel.
--
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

connections to root servers

[BÖSCH Christian]

Hello,

 

I have two bind dns servers as client resolvers with local zones and for the 
rest

configured forwarders. The root zone “.” and hints file is commented out.

In the connection logs on the firewall I see a lot of connections from the 
resolvers

to the root dns servers. 

So can anybody explain why this happens? In my opinion everything should go to

the forwarders and I’m also wondering how bind knows about the root servers

when there is no hint file?

 

Thanks,

Christian



smime.p7s
Description: S/MIME cryptographic signature
-- 
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

dig: couldn't get address for root servers

[salma smaoui]

Greetings,

Hope you're all doing great.
Actually, I am using bind 9.11.28-S1, and I am facing some problems : whenever 
I use the command dig +trace, I came across this error : dig: couldn't get 
address for 'F.ROOT-SERVERS.NET': failure.
Does anyone have an idea why I see this error ? It is really causing DNS 
failures.
Best regards.
___
Please 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: NS ROOT queries to root servers

[Tony Finch]

Medina, Antonio <antonio.med...@gibtele.com> wrote:
>
> We have noticed that each query forwarded towards root servers creates
> an extra NS ROOT query.

This is due to a long-standing bug which was recently fixed. You need
change number 4770 - see
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=CHANGES;hb=v9_9#l169

Complain to your vendor if it isn't present in their mystery meat version.

> In addition, we are going to configure a second provider that has warned
> us on they do not reply to NS ROOT queries. Could this pose a problem
> for our DNS servers? Is it possible to instruct our DNS servers not to
> perform root priming?

Jeez, are they deliberately trying to break things? :-)

You should find that it works as they require if you configure the root
zone on your server as a static-stub zone, with the server-addresses
clause pointing at your upstreams. From a brief test I think this
suppresses the priming queries, but I'm running bleeding edge BIND, so
your milage may vary.

I have a crazy setup on my test server, with a local mirror of the root
zone (which feeds https://twitter.com/diffroot). Because BIND does not
normally validate authoritative data, I have separate views for
authoritative service and recursive service. The rec view is configured
with static-stub versions of all the auth zones, pointing at localhost.
When I remove the static-stub root zone and restart the server, it logs
about sending priming queries; when I restart with my usual configuration
it does not.

Tony.
-- 
f.anthony.n.finch  <d...@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
Irish Sea: Westerly 5 to 7, occasionally gale 8 at first, becoming variable 3
or 4. Moderate or rough, becoming slight. Wintry showers, rain later in south.
Good, occasionally poor.
___
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

NS ROOT queries to root servers

[Medina, Antonio]

Hi all,



we are running BIND in linux servers. We are using release 
bind-9.9.4-51.el7_4.1.x86_64



We are not using BIND in an standard Internet environment. Instead, we are 
using BIND in a mobile network environment, in which DNS Root service is 
provided by service providers. Therefore, we are no using built-in root 
servers. So, we have customized the content of db.root file to include IP 
addresses of DNS servers belonging to our service provider. In our case we have 
configuration similar to the following one (we have omitted real server names 
and IP addresses):





. 360 IN NS SERVER1.grx.



SERVER1.grx. 360 IN A 10.10.10.1







. 360 IN NS SERVER2.grx.



SERVER2.grx. 360 IN A 10.10.20.1







. 360 IN NS SERVER3.grx.



SERVER3.grx. 360 IN A 10.10.30.1







. 360 IN NS SERVER4.grx.



SERVER4.grx. 360 IN A 10.10.40.1







. 360 IN NS SERVER5.grx.



SERVER5.grx. 360 IN A 10.10.50.1







. 360 IN NS SERVER6.grx.



SERVER6.grx. 360 IN A 10.10.60.1







We have noticed that each query forwarded towards root servers creates an extra 
NS ROOT query. We have been reading about "root priming", so were expecting 
this NS ROOT query upon server restart. However, we are seeing this kind of 
query for each query that has to be resolved with root servers assistance. We 
believed that "root priming" was supposed to happen once a day or upon ROOT 
SERVER TTL, which in our case is 3600, i.e., our root servers are replying with 
TTL 3600 to NS ROOT queries.



In addition, we have also tested with DNSSEC disabled as follows:



dnssec-enable no;

dnssec-validation no;



Disabling DNSSEC has not made any difference.



How can we stop/limit these massive NS ROOT queries?







In addition, we are going to configure a second provider that has warned us on 
they do not reply to NS ROOT queries. Could this pose a problem for our DNS 
servers? Is it possible to instruct our DNS servers not to perform root priming?







Thanks for your help.







Kind regards,



Antonio.







P.S. Below you can find the structure of our named.conf file











acl "ExternalACL" {any;};







acl "InternalACL" {10.10.100.1/32;10.10.200.1/32; };







options {







allow-recursion {10.10.100.1/32;10.10.200.1/32;};



directory "/var/named";











};











view "InternalView" IN {







match-clients {InternalACL;};







allow-recursion {10.10.100.1/32;10.10.200.1/32;};







zone "." IN {



type hint;



file "db.root";



};







# Master Zone(s):







MASTER ZONES







};







view "ExternalView" IN {



allow-recursion {127.0.0.1;};



allow-transfer {none;};



match-clients {key 
gibraltar-externalview-smkey;!gibraltar-externalview-other-smkeys;ExternalACL;};



zone "." IN {



type hint;



file "db.root";



};



# Master Zone(s):



MASTER ZONES



};






















Antonio Medina Ortega
Analyst
Broadband & Transport Networks

Gibtelecom
Mob: +350 58008261
Fax: +350 20071673
Email: antonio.med...@gibtele.com<mailto:antonio.med...@gibtele.com>
Web: www.gibtele.com<http://www.gibtele.com/>

___
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: Can bind works without defining root servers

[Andrew Latham]

Read about it at
https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=blob;f=lib/dns/rootns.c;h=d86d0172d10625050ff1938c1869ce28921a1226;hb=HEAD

On Tue, Aug 15, 2017 at 10:29 AM, King, Harold Clyde (Hal) <h...@utk.edu>
wrote:

> How does Bind update the root servers? Does it go out and check, or is a
> release made for each change?
>
>
> --
> Hal King  - h...@utk.edu
> Systems Administrator
> Office of Information Technology
> Shared Systems Services
>
> The University of Tennessee
> 103C5 Kingston Pike Building
> 2309 Kingston Pk. Knoxville, TN 37996
> Phone : 974-1599
> Helpdesk 24/7 : 974-9900
>
> On 8/15/17, 11:02, "bind-users on behalf of Alan Clegg" <
> bind-users-boun...@lists.isc.org on behalf of a...@clegg.com> wrote:
>
> Root hints have been built in forever.  (and that's "forever" in
> Internet years)
>
> On 8/15/17 10:58 AM, Duleep Thilakarathne wrote:
> > Hi,
> >
> > I can observe, bind can resolve host names without following entry
> in
> > named.conf. could anyone help me to understand this default behavior.
> >
> >
> > zone "." {
> >   type hint;
> >   file "root.servers";
> > };
> >
> > regards
> > DT
> >
> >
> > ___
> > 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
>



-- 
- Andrew "lathama" Latham lath...@gmail.com http://lathama.com
<http://lathama.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

Re: Can bind works without defining root servers

[Warren Kumari]

On Tue, Aug 15, 2017 at 11:36 AM, Matthew Pounsett <m...@conundrum.com> wrote:
>
>
> On 15 August 2017 at 11:29, King, Harold Clyde (Hal) <h...@utk.edu> wrote:
>>
>> How does Bind update the root servers? Does it go out and check, or is a
>> release made for each change?
>
>
> Yes. :)
>
> BIND has a compiled-in root hints list that is kept up to date at each
> release, which can be overridden with a zone of type 'hint'.   It also does
> what's calling "priming queries", which is to contact one of the known root
> servers from the hints list, and retrieve and up-to-date authoritative NS
> set for the root zone from the root zone itself.

... and for gory details on priming queries, see RFC8109 (
https://datatracker.ietf.org/doc/rfc8109/ )


W
>
>
>
> ___
> 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



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf
___
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: Can bind works without defining root servers

[Matthew Pounsett]

On 15 August 2017 at 11:29, King, Harold Clyde (Hal) <h...@utk.edu> wrote:

> How does Bind update the root servers? Does it go out and check, or is a
> release made for each change?
>

Yes. :)

BIND has a compiled-in root hints list that is kept up to date at each
release, which can be overridden with a zone of type 'hint'.   It also does
what's calling "priming queries", which is to contact one of the known root
servers from the hints list, and retrieve and up-to-date authoritative NS
set for the root zone from the root zone itself.
___
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: Can bind works without defining root servers

[King, Harold Clyde (Hal)]

How does Bind update the root servers? Does it go out and check, or is a 
release made for each change?


-- 
Hal King  - h...@utk.edu
Systems Administrator
Office of Information Technology
Shared Systems Services

The University of Tennessee
103C5 Kingston Pike Building
2309 Kingston Pk. Knoxville, TN 37996
Phone : 974-1599
Helpdesk 24/7 : 974-9900

On 8/15/17, 11:02, "bind-users on behalf of Alan Clegg" 
<bind-users-boun...@lists.isc.org on behalf of a...@clegg.com> wrote:

Root hints have been built in forever.  (and that's "forever" in
Internet years)

On 8/15/17 10:58 AM, Duleep Thilakarathne wrote:
> Hi,
> 
> I can observe, bind can resolve host names without following entry  in
> named.conf. could anyone help me to understand this default behavior.
> 
> 
> zone "." {
>   type hint;
>   file "root.servers";
> };
> 
> regards
> DT
> 
> 
> ___
> 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: Can bind works without defining root servers

[Alan Clegg]

Root hints have been built in forever.  (and that's "forever" in
Internet years)

On 8/15/17 10:58 AM, Duleep Thilakarathne wrote:
> Hi,
> 
> I can observe, bind can resolve host names without following entry  in
> named.conf. could anyone help me to understand this default behavior.
> 
> 
> zone "." {
>   type hint;
>   file "root.servers";
> };
> 
> regards
> DT
> 
> 
> ___
> 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
> 



signature.asc
Description: OpenPGP digital signature
___
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

Can bind works without defining root servers

[Duleep Thilakarathne]

Hi,

I can observe, bind can resolve host names without following entry  in
named.conf. could anyone help me to understand this default behavior.


zone "." {
  type hint;
  file "root.servers";
};

regards
DT
___
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 - Continuous NS ROOT queries to root servers

[Petr Mensik]

I think you might have problem with DNSSEC validation. Bind in rhel6 validates 
root by default and have got built-in root key compiled in. Have you tried 
dnssec-validation no; option in your config?

--
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com  PGP: 65C6C973


- Original Message -
From: "Antonio Medina" <antonio.med...@gibtele.com>
To: "bind-users@lists.isc.org" <bind-users@lists.isc.org>
Cc: "Kairon Morillo" <kairon.mori...@gibtele.com>, "William Jackson" 
<william.jack...@gibtele.com>
Sent: Thursday, December 22, 2016 9:22:14 AM
Subject: RE: BIND - Continuous NS ROOT queries to root servers



Hi all, 



we are running BIND in Red Hat servers. We are using release BIND 
9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.6. 



We are not using BIND in an standard Internet environment. Instead, we are 
using BIND in a mobile network environment, in which DNS Root service is 
provided by service providers. Therefore, we are no using built-in root 
servers. So, we have customized the content of db.root file to include IP 
addresses of DNS servers belonging to our service provider. In our case we have 
configuration similar to the following one (we have omitted real server names 
and IP addresses): 





. 360 IN NS SERVER1.grx. 

SERVER1.grx. 360 IN A 10.10.10.1 



. 360 IN NS SERVER2.grx. 

SERVER2.grx. 360 IN A 10.10.20.1 



. 360 IN NS SERVER3.grx. 

SERVER3.grx. 360 IN A 10.10.30.1 



. 360 IN NS SERVER4.grx. 

SERVER4.grx. 360 IN A 10.10.40.1 



. 360 IN NS SERVER5.grx. 

SERVER5.grx. 360 IN A 10.10.50.1 



. 360 IN NS SERVER6.grx. 

SERVER6.grx. 360 IN A 10.10.60.1 



We have noticed that each query forwarded towards root servers creates an extra 
NS ROOT query. We have been reading about “root priming”, so were expecting 
this NS ROOT query upon server restart. However, we are seeing this kind of 
query for each query that has to be resolved with root servers assistance. We 
believed that “root priming” was supposed to happen once a day or upon ROOT 
SERVER TTL, which in our case is 3600, i.e., our root servers are replying with 
TTL 3600 to NS ROOT queries. 



How can we stop/limit these massive NS ROOT queries? 



In addition, we are going to configure a second provider that has warned us on 
they do not reply to NS ROOT queries. Could this pose a problem for our DNS 
servers? Is it possible to instruct our DNS servers not to perform root 
priming? 



Thanks for your help. 



Kind regards, 

Antonio. 



P.S. Below you can find the structure of our named.conf file 





acl "ExternalACL" {any;}; 



acl "InternalACL" {10.10.100.1/32;10.10.200.1/32; }; 



options { 



allow-recursion {10.10.100.1/32;10.10.200.1/32;}; 

directory "/var/named"; 





}; 





view "InternalView" IN { 



match-clients {InternalACL;}; 



allow-recursion {10.10.100.1/32;10.10.200.1/32;}; 



zone "." IN { 

type hint; 

file "db.root"; 

}; 



# Master Zone(s): 



MASTER ZONES 



}; 



view "ExternalView" IN { 

allow-recursion {127.0.0.1;}; 

allow-transfer {none;}; 

match-clients {key 
gibraltar-externalview-smkey;!gibraltar-externalview-other-smkeys;ExternalACL;};
 

zone "." IN { 

type hint; 

file "db.root"; 

}; 

# Master Zone(s): 

MASTER ZONES 

}; 











___
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: BIND - Continuous NS ROOT queries to root servers

[Medina, Antonio]

Hi all,

we are running BIND in Red Hat servers. We are using release BIND 
9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.6.

We are not using BIND in an standard Internet environment. Instead, we are 
using BIND in a mobile network environment, in which DNS Root service is 
provided by service providers. Therefore, we are no using built-in root 
servers. So, we have customized the content of db.root file to include IP 
addresses of DNS servers belonging to our service provider. In our case we have 
configuration similar to the following one (we have omitted real server names 
and IP addresses):


. 360 IN NS SERVER1.grx.
SERVER1.grx. 360 IN A 10.10.10.1

. 360 IN NS SERVER2.grx.
SERVER2.grx. 360 IN A 10.10.20.1

. 360 IN NS SERVER3.grx.
SERVER3.grx. 360 IN A 10.10.30.1

. 360 IN NS SERVER4.grx.
SERVER4.grx. 360 IN A 10.10.40.1

. 360 IN NS SERVER5.grx.
SERVER5.grx. 360 IN A 10.10.50.1

. 360 IN NS SERVER6.grx.
SERVER6.grx. 360 IN A 10.10.60.1

We have noticed that each query forwarded towards root servers creates an extra 
NS ROOT query. We have been reading about "root priming", so were expecting 
this NS ROOT query upon server restart. However, we are seeing this kind of 
query for each query that has to be resolved with root servers assistance. We 
believed that "root priming" was supposed to happen once a day or upon ROOT 
SERVER TTL, which in our case is 3600, i.e., our root servers are replying with 
TTL 3600 to NS ROOT queries.

How can we stop/limit these massive NS ROOT queries?

In addition, we are going to configure a second provider that has warned us on 
they do not reply to NS ROOT queries. Could this pose a problem for our DNS 
servers? Is it possible to instruct our DNS servers not to perform root priming?

Thanks for your help.

Kind regards,
Antonio.

P.S. Below you can find the structure of our named.conf file


acl "ExternalACL" {any;};

acl "InternalACL" {10.10.100.1/32;10.10.200.1/32; };

options {

  allow-recursion {10.10.100.1/32;10.10.200.1/32;};
  directory "/var/named";


};


view "InternalView" IN {

  match-clients {InternalACL;};

  allow-recursion {10.10.100.1/32;10.10.200.1/32;};

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

# Master Zone(s):

MASTER ZONES

};

view "ExternalView" IN {
  allow-recursion {127.0.0.1;};
  allow-transfer {none;};
  match-clients {key 
gibraltar-externalview-smkey;!gibraltar-externalview-other-smkeys;ExternalACL;};
  zone "." IN {
type hint;
file "db.root";
  };
  # Master Zone(s):
MASTER ZONES
};





___
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 - Continuous NS ROOT queries to root servers

[Medina, Antonio]

Hi all,

we are running BIND in Red Hat servers. We are using release BIND 
9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.6.

We are not using BIND in an standard Internet environment. Instead, we are 
using BIND in a mobile network environment, in which DNS Root service is 
provided by service providers. Therefore, we are no using built-in root 
servers. So, we have customized the content of db.root file to include IP 
addresses of DNS servers belonging to our service provider. In our case we have 
configuration similar to the following one (we have omitted real server names 
and IP addresses):


. 360 IN NS SERVER1.grx.
SERVER1.grx. 360 IN A 10.10.10.1

. 360 IN NS SERVER2.grx.
SERVER2.grx. 360 IN A 10.10.20.1

. 360 IN NS SERVER3.grx.
SERVER3.grx. 360 IN A 10.10.30.1

. 360 IN NS SERVER4.grx.
SERVER4.grx. 360 IN A 10.10.40.1

. 360 IN NS SERVER5.grx.
SERVER5.grx. 360 IN A 10.10.50.1

. 360 IN NS SERVER6.grx.
SERVER6.grx. 360 IN A 10.10.60.1

We have noticed that each query forwarded towards root servers creates an extra 
NS ROOT query. We have been reading about "root priming", so were expecting 
this NS ROOT query upon server restart. However, we are seeing this kind of 
query for each query that has to be resolved with root servers assistance. We 
believed that "root priming" was supposed to happen once a day or upon ROOT 
SERVER TTL, which in our case is 3600, i.e., our root servers are replying with 
TTL 3600 to NS ROOT queries.

How can we stop/limit these massive NS ROOT queries?

In addition, we are going to configure a second provider that has warned us on 
they do not reply to NS ROOT queries. Could this pose a problem for our DNS 
servers? Is it possible to instruct our DNS servers not to perform root priming?

Thanks for your help.

Kind regards,
Antonio.

P.S. Below you can find the structure of our named.conf file


acl "ExternalACL" {any;};

acl "InternalACL" {10.10.100.1/32;10.10.200.1/32; };

options {

  allow-recursion {10.10.100.1/32;10.10.200.1/32;};
  directory "/var/named";


};


view "InternalView" IN {

  match-clients {InternalACL;};

  allow-recursion {10.10.100.1/32;10.10.200.1/32;};

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

# Master Zone(s):

MASTER ZONES

};

view "ExternalView" IN {
  allow-recursion {127.0.0.1;};
  allow-transfer {none;};
  match-clients {key 
gibraltar-externalview-smkey;!gibraltar-externalview-other-smkeys;ExternalACL;};
  zone "." IN {
type hint;
file "db.root";
  };
  # Master Zone(s):
MASTER ZONES
};




___
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: root zone on a nameserver which cannot reach root-servers

[Reindl Harald]

Am 03.10.2016 um 04:28 schrieb blrmaani:

We have a DNS server setup where all zones are either slaves or forwards to a 
internal DNS servers which resolves external names.

Questions:
1. Do we still need a root zone (type=hint) ?
2. What is the side effect of having root zone when our nameserver cannot reach 
root servers? (additional load on DNS if yes what percentage?)


the root nameservers are only needed for recursion, that's it

own zones and forwarding is *not* recursion
___
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

root zone on a nameserver which cannot reach root-servers

[blrmaani]

We have a DNS server setup where all zones are either slaves or forwards to a 
internal DNS servers which resolves external names.

Questions:
1. Do we still need a root zone (type=hint) ?
2. What is the side effect of having root zone when our nameserver cannot reach 
root servers? (additional load on DNS if yes what percentage?)

Thanks
Blr
___
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: frequent queries to root servers

[Simon Forster]

> On 30 Jan 2016, at 21:57, John Levine  wrote:
> 
>> If chained CNAMEs work for you, more power to you.  But don't be 
>> surprised if they fail unexpectedly at some point.
> 
> If they don't, you'll have a lot of unhappy users since there's a
> whole lot of the Internet they won't be able to see.  
> 
> Try www.apple.com and www.microsoft.com, both of which have three
> chained CNAMES through Akamai.

As a data point, we’ve seen occasional fails here with bind running RPZ. And to 
the point being raised, it tends to be with Akamai users (so the smaller 
players).

ISC is aware of the issue. I do not believe that the cause has been identified.

Simon

___
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: frequent queries to root servers

[Sam Wilson]

In article ,
 Grant Taylor  wrote:

> I think chained CNAMEs fall into the gray area (no mans land) between 
> zealots on either side of the RFC interpretation line.
> 
> If chained CNAMEs work for you, more power to you.  But don't be 
> surprised if they fail unexpectedly at some point.

We should be warning those niche players Microsoft and Akamai.

$ dig www.microsoft.com

; <<>> DiG 9.8.5-P1 <<>> www.microsoft.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18453
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 8, ADDITIONAL: 8

;; QUESTION SECTION:
;www.microsoft.com. IN A

;; ANSWER SECTION:
www.microsoft.com.   846   IN CNAME www.microsoft.com-c.edgekey.net.
www.microsoft.com-c.edgekey.net. 1362 IN CNAME  
www.microsoft.com-c.edgekey.net.globalredir.akadns.net.
www.microsoft.com-c.edgekey.net.globalredir.akadns.net.  2897 IN  CNAME 
e10088.dspb.akamaiedge.net.
e10088.dspb.akamaiedge.net. 6 IN A  2.18.4.103

[snip]

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: frequent queries to root servers

[Grant Taylor]

On 01/30/2016 04:44 AM, Reindl Harald wrote:

nonsense


Okay ...


From RFC 1034 - Domain names - concepts and facilities:
Of course, by the robustness principle, domain software should not fail
when presented with CNAME chains or loops; CNAME chains should be
followed and CNAME loops signalled as an error.


I'll agree that they SHOULD work. But I've had too many occasions over 
the last 15 years where chained CNAMEs DIDN'T work.



"Domain names in RRs which point at another name should always point at
the primary name and not the alias. This avoids extra indirections in
accessing information" is NOT a MUST


I think chained CNAMEs fall into the gray area (no mans land) between 
zealots on either side of the RFC interpretation line.


If chained CNAMEs work for you, more power to you.  But don't be 
surprised if they fail unexpectedly at some point.



see above


I see my experience of poorly written resolvers, and server forbidding 
CNAMEs referring to other CNAMEs in the same zone, and DNS gateways that 
are overly zealous in their filtering.


I maintain that using chained CNAMEs is not safe, and as such should not 
be relied upon.  -  We are each entitled to our own opinions.




--
Grant. . . .
unix || die
___
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: frequent queries to root servers

[John Levine]

>If chained CNAMEs work for you, more power to you.  But don't be 
>surprised if they fail unexpectedly at some point.

If they don't, you'll have a lot of unhappy users since there's a
whole lot of the Internet they won't be able to see.  

Try www.apple.com and www.microsoft.com, both of which have three
chained CNAMES through Akamai.

R's,
John
___
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: frequent queries to root servers

[Reindl Harald]

Am 30.01.2016 um 03:45 schrieb Grant Taylor:

On 01/26/2016 04:46 PM, Reindl Harald wrote:

violating what?


Chaining CNAMEs is a violation according to RFCs.


nonsense

From RFC 1034 - Domain names - concepts and facilities:
Of course, by the robustness principle, domain software should not fail
when presented with CNAME chains or loops; CNAME chains should be 
followed and CNAME loops signalled as an error.


http://www.faqs.org/rfcs/rfc1034.html

"Domain names in RRs which point at another name should always point at 
the primary name and not the alias. This avoids extra indirections in 
accessing information" is NOT a MUST



It works, but it is unsupported, and you can only blame yourself when it
doesn't


see above



signature.asc
Description: OpenPGP digital signature
___
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: frequent queries to root servers

[Grant Taylor]

On 01/26/2016 04:46 PM, Reindl Harald wrote:

violating what?


Chaining CNAMEs is a violation according to RFCs.

It works, but it is unsupported, and you can only blame yourself when it 
doesn't.




--
Grant. . . .
unix || die
___
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: frequent queries to root servers

[Dave Warren]

On 2016-01-29 18:45, Grant Taylor wrote:

On 01/26/2016 04:46 PM, Reindl Harald wrote:

violating what?


Chaining CNAMEs is a violation according to RFCs.

It works, but it is unsupported, and you can only blame yourself when 
it doesn't.


Maybe I'm misremembering RFC 1034, but a CNAME chain only violates a 
"should", and later in that RFC it says that software "should not" fail 
to handle chains, so even if you take a "should" as gospel, the "should 
not" should be equally gospel, making CNAME chains supported (although 
not advised.)


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren


___
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

frequent queries to root servers

[HONTVÁRI Levente]

Hi All,

I assumed that the root servers are only queried a few times a week 
(corresponding to the number of top level domains). The logs show a 
different picture, Queries to the root servers are quite frequent. What 
am I missing?


I have attached a dnstop screen (local network traffic was filtered 
out), after running for about 2 hours. I also attached a log extract 
about a single query from 10.0.3.44 resolved by 10.0.3.48, which 
involves a query to the root servers. I notice that there is a DS record 
query before the root server query, but otherwise I do not see anything 
strange.


I have an almost stock Bind 9.9.5 resolver configuration on an Ubuntu 
server.


L.
Queries: 0 new, 3758 total Tue Jan 26 14:57:27 2016

Query Name   Count  %   cum%
 - -- --
com   2015   53.6   53.6
net934   24.9   78.5
hu 2777.4   85.8
.  2055.5   91.3
org 932.5   93.8
pl  340.9   94.7
uk  290.8   95.4
nl  190.5   96.0
cn  180.5   96.4
tv  170.5   96.9
in-addr.arpa120.3   97.2
de  120.3   97.5
ru  110.3   97.8
club100.3   98.1
se  100.3   98.4
co   90.2   98.6
am   90.2   98.8
info 90.2   99.1
io   70.2   99.3
edu  60.2   99.4
hk   40.1   99.5
be   40.1   99.6
at   30.1   99.7
cc   30.1   99.8
it   20.1   99.8
cz   20.1   99.9
local20.1   99.9
biz  10.0  100.0
lan  10.0  100.0


10.0.3.44.28233 > 10.0.3.48.53: 31685+ A? livetileedge.dsx.mp.microsoft.com. (51)
10.0.3.48.19620 > 208.76.45.53.53: 51063% [1au] A? livetileedge.dsx.mp.microsoft.com. ar: . OPT UDPsize=4096 OK (62)
208.76.45.53.53 > 10.0.3.48.19620: 51063*- q: A? livetileedge.dsx.mp.microsoft.com. 1/0/1 livetileedge.dsx.mp.microsoft.com. [1h] CNAME livetileedge.dsx.mp.microsoft.com.akadns.net
10.0.3.48.52753 > 96.7.49.129.53: 55032% [1au] A? livetileedge.dsx.mp.microsoft.com.akadns.net. ar: . OPT UDPsize=4096 OK (73)
96.7.49.129.53 > 10.0.3.48.52753: 55032*- q: A? livetileedge.dsx.mp.microsoft.com.akadns.net. 1/0/1 livetileedge.dsx.mp.microsoft.com.akadns.net. [5m] CNAME livetileedge.dsx.mp.mic
10.0.3.48.54539 > 198.41.0.4.53: 53961% [1au] DS? akadns.net. ar: . OPT UDPsize=4096 OK (39)
10.0.3.48.55442 > 198.41.0.4.53: 64095% [1au] NS? . ar: . OPT UDPsize=4096 OK (28)
198.41.0.4.53 > 10.0.3.48.55442: 64095*- q: NS? . 14/0/25 . [6d] NS g.root-servers.net., . [6d] NS c.root-servers.net., . [6d] NS k.root-servers.net., . [6d] NS b.root-servers.net.
198.41.0.4.53 > 10.0.3.48.54539: 53961- q: DS? akadns.net. 0/15/16 ns: net. [2d] NS m.gtld-servers.net., net. [2d] NS l.gtld-servers.net., net. [2d] NS k.gtld-servers.net., net. [2
10.0.3.48.42551 > 192.52.178.30.53: 2282% [1au] DS? akadns.net. ar: . OPT UDPsize=4096 OK (39)
192.52.178.30.53 > 10.0.3.48.42551: 2282*- q: DS? akadns.net. 0/6/1 ns: A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. [1d] Type50, A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. [1d] RRSIG, net. [1
10.0.3.48.1357 > 2.22.230.65.53: 20299% [1au] A? livetileedge.dsx.mp.microsoft.com.edgekey.net. ar: . OPT UDPsize=4096 OK (74)
2.22.230.65.53 > 10.0.3.48.1357: 20299*- q: A? livetileedge.dsx.mp.microsoft.com.edgekey.net. 1/0/1 livetileedge.dsx.mp.microsoft.com.edgekey.net. [5m] CNAME e1898.b.akamaiedge.net
10.0.3.48.45774 > 2.20.182.166.53: 57507% [1au] A? e1898.b.akamaiedge.net. ar: . OPT UDPsize=4096 OK (51)
2.20.182.166.53 > 10.0.3.48.45774: 57507*- q: A? e1898.b.akamaiedge.net. 1/0/0 e1898.b.akamaiedge.net. [20s] A 23.7.197.25 (56)
10.0.3.48.2767 > 192.33.4.12.53: 8654% [1au] DS? akamaiedge.net. ar: . OPT UDPsize=4096 OK (43)
192.33.4.12.53 > 10.0.3.48.2767: 8654- q: DS? akamaiedge.net. 0/15/16 ns: net. [2d] NS m.gtld-servers.net., net. [2d] NS k.gtld-servers.net., net. [2d] NS b.gtld-servers.net., net.
10.0.3.48.18914 > 192.54.112.30.53: 53417% [1au] DS? akamaiedge.net. ar: . OPT UDPsize=4096 OK (43)
192.54.112.30.53 > 10.0.3.48.18914: 53417*- q: DS? akamaiedge.net. 0/6/1 ns: A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. [1d] Type50, A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. [1d] RRSIG, ne
10.0.3.48.53 > 10.0.3.44.28233: 31685 q: A? livetileedge.dsx.mp.microsoft.com. 4/8/8 livetileedge.dsx.mp.microsoft.com. [1h] CNAME livetileedge.dsx.mp.microsoft.com.akadns.net., li

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users 

RE: frequent queries to root servers

[Darcy Kevin (FCA)]

Well, when I queried the name livetileedge.dsx.mp.microsoft.com, I got a CNAME 
chain where all of the links in the chain had TTLs of 300 seconds or less:

livetileedge.dsx.mp.microsoft.com. 43 IN CNAME  
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net. 300 IN CNAME 
livetileedge.dsx.mp.microsoft.com.edgekey.net.
livetileedge.dsx.mp.microsoft.com.edgekey.net. 46 IN CNAME 
e1898.b.akamaiedge.net.
e1898.b.akamaiedge.net. 20  IN  A   23.201.56.85

Now, the Authority Section had NS records for b.akamaiedge.net, but that 
doesn't help mitigate future queries for {whatever}.microsoft.com, 
{whatever}.akadns.net or {whatever}.edgekey.net, so repeated queries of the 
same name will need to go back up to the roots again, whenever the TTLs expire 
(assuming nothing else queried names *directly* in those domains, or 
intermediate domains, through the same recursive resolver and thus populated 
relevant NS records).

Yet another reason why chained CNAMEs are bad. But, it's hard to argue with a 
successful company whose whole business model is based on chaining CNAMEs. Who 
ever knew that violating Internet standards and/or best practices could be so 
profitable?


- Kevin

-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of HONTVÁRI Levente
Sent: Tuesday, January 26, 2016 9:07 AM
To: bind-users@lists.isc.org
Subject: frequent queries to root servers

Hi All,

I assumed that the root servers are only queried a few times a week 
(corresponding to the number of top level domains). The logs show a different 
picture, Queries to the root servers are quite frequent. What am I missing?

I have attached a dnstop screen (local network traffic was filtered out), after 
running for about 2 hours. I also attached a log extract about a single query 
from 10.0.3.44 resolved by 10.0.3.48, which involves a query to the root 
servers. I notice that there is a DS record query before the root server query, 
but otherwise I do not see anything strange.

I have an almost stock Bind 9.9.5 resolver configuration on an Ubuntu server.

L.
___
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: frequent queries to root servers

[Reindl Harald]

Am 27.01.2016 um 00:36 schrieb Darcy Kevin (FCA):

Well, when I queried the name livetileedge.dsx.mp.microsoft.com, I got a CNAME 
chain where all of the links in the chain had TTLs of 300 seconds or less:

livetileedge.dsx.mp.microsoft.com. 43 IN CNAME  
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net. 300 IN CNAME 
livetileedge.dsx.mp.microsoft.com.edgekey.net.
livetileedge.dsx.mp.microsoft.com.edgekey.net. 46 IN CNAME 
e1898.b.akamaiedge.net.
e1898.b.akamaiedge.net. 20  IN  A   23.201.56.85

Now, the Authority Section had NS records for b.akamaiedge.net, but that 
doesn't help mitigate future queries for {whatever}.microsoft.com, 
{whatever}.akadns.net or {whatever}.edgekey.net, so repeated queries of the 
same name will need to go back up to the roots again, whenever the TTLs expire 
(assuming nothing else queried names *directly* in those domains, or 
intermediate domains, through the same recursive resolver and thus populated 
relevant NS records).

Yet another reason why chained CNAMEs are bad. But, it's hard to argue with a 
successful company whose whole business model is based on chaining CNAMEs. Who 
ever knew that violating Internet standards and/or best practices could be so 
profitable?


violating what? complain at the vendor of your DNS cache or the device 
doing "DNS ALG" in front of you!


;; ANSWER SECTION:
livetileedge.dsx.mp.microsoft.com. 3581 IN CNAME 
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net. 281 IN CNAME 
livetileedge.dsx.mp.microsoft.com.edgekey.net.
livetileedge.dsx.mp.microsoft.com.edgekey.net. 281 IN CNAME 
e1898.b.akamaiedge.net.

e1898.b.akamaiedge.net. 1   IN  A   104.87.22.10

;; ANSWER SECTION:
livetileedge.dsx.mp.microsoft.com. 3580 IN CNAME 
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net. 280 IN CNAME 
livetileedge.dsx.mp.microsoft.com.edgekey.net.
livetileedge.dsx.mp.microsoft.com.edgekey.net. 280 IN CNAME 
e1898.b.akamaiedge.net.

e1898.b.akamaiedge.net. 0   IN  A   104.87.22.10

;; ANSWER SECTION:
livetileedge.dsx.mp.microsoft.com. 3579 IN CNAME 
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net. 279 IN CNAME 
livetileedge.dsx.mp.microsoft.com.edgekey.net.
livetileedge.dsx.mp.microsoft.com.edgekey.net. 279 IN CNAME 
e1898.b.akamaiedge.net.

e1898.b.akamaiedge.net. 17  IN  A   104.87.22.10






signature.asc
Description: OpenPGP digital signature
___
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: frequent queries to root servers

[Reindl Harald]

Am 27.01.2016 um 00:46 schrieb Reindl Harald:

Am 27.01.2016 um 00:36 schrieb Darcy Kevin (FCA):

Well, when I queried the name livetileedge.dsx.mp.microsoft.com, I got
a CNAME chain where all of the links in the chain had TTLs of 300
seconds or less:

livetileedge.dsx.mp.microsoft.com. 43 IN CNAME
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net. 300 IN CNAME
livetileedge.dsx.mp.microsoft.com.edgekey.net.
livetileedge.dsx.mp.microsoft.com.edgekey.net. 46 IN CNAME
e1898.b.akamaiedge.net.
e1898.b.akamaiedge.net. 20  IN  A   23.201.56.85

Now, the Authority Section had NS records for b.akamaiedge.net, but
that doesn't help mitigate future queries for
{whatever}.microsoft.com, {whatever}.akadns.net or
{whatever}.edgekey.net, so repeated queries of the same name will need
to go back up to the roots again, whenever the TTLs expire (assuming
nothing else queried names *directly* in those domains, or
intermediate domains, through the same recursive resolver and thus
populated relevant NS records).

Yet another reason why chained CNAMEs are bad. But, it's hard to argue
with a successful company whose whole business model is based on
chaining CNAMEs. Who ever knew that violating Internet standards
and/or best practices could be so profitable?


violating what? complain at the vendor of your DNS cache or the device
doing "DNS ALG" in front of you!


or better at the party set such a low TTL (e1898.b.akamaiedge.net.) 
which is *not* the result of the CNAMES


;; ANSWER SECTION:
www.rhsoft.net. 3600IN  CNAME   proxy.thelounge.net.
proxy.thelounge.net.3598IN  A   10.0.0.4

;; ANSWER SECTION:
www.rhsoft.net. 3600IN  CNAME   proxy.thelounge.net.
proxy.thelounge.net.3598IN  A   10.0.0.4



;; ANSWER SECTION:
livetileedge.dsx.mp.microsoft.com. 3581 IN CNAME
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net. 281 IN CNAME
livetileedge.dsx.mp.microsoft.com.edgekey.net.
livetileedge.dsx.mp.microsoft.com.edgekey.net. 281 IN CNAME
e1898.b.akamaiedge.net.
e1898.b.akamaiedge.net. 1   IN  A   104.87.22.10

;; ANSWER SECTION:
livetileedge.dsx.mp.microsoft.com. 3580 IN CNAME
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net. 280 IN CNAME
livetileedge.dsx.mp.microsoft.com.edgekey.net.
livetileedge.dsx.mp.microsoft.com.edgekey.net. 280 IN CNAME
e1898.b.akamaiedge.net.
e1898.b.akamaiedge.net. 0   IN  A   104.87.22.10

;; ANSWER SECTION:
livetileedge.dsx.mp.microsoft.com. 3579 IN CNAME
livetileedge.dsx.mp.microsoft.com.akadns.net.
livetileedge.dsx.mp.microsoft.com.akadns.net. 279 IN CNAME
livetileedge.dsx.mp.microsoft.com.edgekey.net.
livetileedge.dsx.mp.microsoft.com.edgekey.net. 279 IN CNAME
e1898.b.akamaiedge.net.
e1898.b.akamaiedge.net. 17  IN  A   104.87.22.10




signature.asc
Description: OpenPGP digital signature
___
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: frequent queries to root servers

[Robert Edmonds]

HONTVÁRI Levente wrote:
> I assumed that the root servers are only queried a few times a week
> (corresponding to the number of top level domains). The logs show a
> different picture, Queries to the root servers are quite frequent. What am I
> missing?
> 
> I have attached a dnstop screen (local network traffic was filtered out),
> after running for about 2 hours. I also attached a log extract about a
> single query from 10.0.3.44 resolved by 10.0.3.48, which involves a query to
> the root servers. I notice that there is a DS record query before the root
> server query, but otherwise I do not see anything strange.

You can't actually tell which queries went to root servers by just
looking at the query names in packets, or in the case of the dnstop
output you showed, parts of query names.

If you wanted to count traffic to root servers, you would need a BPF
expression that listed each of the 24 root server addresses, something
like:

'host (198.41.0.4 or 192.228.79.201 or 192.33.4.12 or \
199.7.91.13 or 192.203.230.10 or 192.5.5.241 or 192.112.36.4 or \
198.97.190.53 or 192.36.148.17 or 192.58.128.30 or 193.0.14.129 or \
199.7.83.42 or 202.12.27.33 or 2001:503:ba3e::2:30 or \
2001:500:84::b or 2001:500:2::c or 2001:500:2d::d or \
2001:500:2f::f or 2001:500:1::53 or 2001:7fe::53 or \
2001:503:c27::2:30 or 2001:7fd::1 or 2001:500:3::42 or \
2001:dc3::35)'

Maybe you could run two dnstop instances, one with the root-servers only
BPF, and one without, and compare the totals reported by each.

If you had a version of BIND compiled with dnst*a*p support (the version
you mentioned does not), you could turn on the RESOLVER_QUERY and/or
RESOLVER_RESPONSE message logging options and filter the resulting
output for messages having a 'query_zone' field set to the root label,
which is a little less awkward and more future-proof than enumerating
all of the root server addresses.

-- 
Robert Edmonds
___
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

How does bind 9.x chooses root servers?

[Jittinan Suwanruengsri]

Hi,

 

How does bind 9.x chooses root servers? 

 

This is sample result from tcpdump on Bind 9.x .From this result it
means bind chooses root servers base on weight of response time. It does
not choose the lowest response time server. Do I understand correctly?

 

  2 a.root-servers.net.domain

  2 b.root-servers.net.domain

  2 c.root-servers.net.domain

 33 d.root-servers.net.domain

 25 e.root-servers.net.domain

 14 f.root-servers.net.domain

  3 h.root-servers.net.domain

 64 i.root-servers.net.domain

  5 j.root-servers.net.domain

  3 k.root-servers.net.domain

  4 l.root-servers.net.domain

 

But ripe.net show that bind 9.x chooses the lowest response time
server(http://www.google.co.th/url?sa=trct=jq=esrc=ssource=webcd=4;
cad=rjauact=8ved=0CDQQFjADurl=http%3A%2F%2Fmeetings.ripe.net%2Fripe-4
5%2Fpresentations%2Fripe45-eof-rickard.pdfei=Te4bVMi1LYeQuATQ4IKgAgusg
=AFQjCNFB2OeVZxZR8qtNuRIJBJDFSmoeIQ)

 

 

Thank You,

 

Mr.Jittinan Suwanrueangsri

___
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: How does bind 9.x chooses root servers?

[Matus UHLAR - fantomas]

On 19.09.14 15:57, Jittinan Suwanruengsri wrote:

How does bind 9.x chooses root servers?


based on RTT, with ocasional re-tries of other servers

try googling for bind server selection
--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Linux IS user friendly, it's just selective who its friends are...
___
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: How does bind 9.x chooses root servers?

[Mukund Sivaraman]

Hi Jittinan

On Fri, Sep 19, 2014 at 03:57:32PM +0700, Jittinan Suwanruengsri wrote:
 How does bind 9.x chooses root servers? 

The question is better phrased as How does BIND choose name servers?

The SRTT selection method used by BIND is not quite described anywhere
in an ISC document (such as in the ARM), but sometime ago there was a
presentation about a vulnerability that described it:

https://www.usenix.org/sites/default/files/conference/protected-files/hay_woot13_slides.pdf

Since the publication of this presentation, it has been tweaked, but the
selection method is somewhat similar and the paper will give you a good
description.

See also ISC's KB article about the issue described in the presentation:

https://kb.isc.org/article/AA-01030/169/Operational-Notification-A-Vulnerability-in-the-SRTT-Algorithm-affects-BIND-9-Authoritative-Server-Selection.html

Mukund


pgp7A1538bpIQ.pgp
Description: PGP signature
___
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: Root servers

[Anand Buddhdev]

On 16/08/2014 04:55, Bill Christensen wrote:

 Interesting.  I'm running BIND 9.10.0-P2.  Apparently the package system
 I'm using (MacPorts) isn't updating the root servers file though.
 
 I'll report the problem there.  Meantime, I'll download the recent one
 and see if that makes a difference.

I'd advise packagers to stop shipping a root hints file with BIND. It's
perfectly capable of using its built-in list to do a priming query. The
built-in list is kept up-to-date by ISC, so you'll always have the
latest copy when you update BIND.

I generate pull requests for the BIND port in Homebrew, and I fixed it
some time ago by deleting the root hints file.

Anand
___
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: Root servers

[Thomas Schulz]

 On Thu, Aug 14, 2014 at 02:26:54PM -0500, Bill Christensen wrote:
  I'm seeing some root server errors on startup:
  
  14-Aug-2014 13:14:08.142 info: host unreachable resolving 
  'd.gtld-servers.net//IN': 2001:503:ba3e::2:30#53
  14-Aug-2014 13:14:08.215 info: host unreachable resolving 
  'b.gtld-servers.net/A/IN': 2001:503:231d::2:30#53
  14-Aug-2014 13:14:08.220 info: host unreachable resolving 
  'c.gtld-servers.net/A/IN': 2001:503:231d::2:30#53
  14-Aug-2014 13:14:08.522 info: host unreachable resolving 
  'd.gtld-servers.net//IN': 2001:503:83eb::2:31#53
  14-Aug-2014 13:14:08.595 info: host unreachable resolving 
  'c.gtld-servers.net/A/IN': 2001:503:a83e::2:31#53
  14-Aug-2014 13:14:08.793 info: host unreachable resolving 
  'b.gtld-servers.net//IN': 2001:503:c27::2:30#53
  14-Aug-2014 13:14:08.794 info: host unreachable resolving 
  'b.gtld-servers.net//IN': 2001:dc3::35#53
  14-Aug-2014 13:14:08.795 info: host unreachable resolving 
  'c.gtld-servers.net//IN': 2001:503:c27::2:30#53
  14-Aug-2014 13:14:08.796 info: host unreachable resolving 
  'c.gtld-servers.net//IN': 2001:dc3::35#53
  
  
  How do I correct that?
 
 It looks like your system thinks it has IPv6 connectivity, but it
 doesn't really have it.  You can disable IPv6 at the OS level or:
 named -4.
 
  It looks like my root pointers are horribly out of date.  Seems
  to me this is something which should automatically update...
 
 Not much, and yes.
 
  ;   This file is made available by InterNIC
  ;   under anonymous FTP as
  ;   file/domain/named.root
  ;   on server   FTP.INTERNIC.NET
  ;   -OR-RS.INTERNIC.NET
  ;
  ;   last update:Feb 04, 2008
  ;   related version of root zone:   2008020400
 
 That's old, but not so old as to prevent you from reaching an actual 
 root server.  Of course it was 2 years before the root was signed.
 -- 
   http://rob0.nodns4.us/
   Offlist GMX mail is seen only if /dev/rob0 is in the Subject:

I will add my $0.02. The named executable has the root information built
in so that it can start up if there is no named.root file available.
So, if you had no named.root file but did have the latest release of
Bind then you would have the current data. If you do not update Bind
the moment that a new version is released then you need a current
named.root file. Just go get a new one from the server listed at the
top of the old file.

Tom Schulz
Applied Dynamics Intl.
sch...@adi.com
___
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: Root servers

[/dev/rob0]

On Fri, Aug 15, 2014 at 10:14:09AM -0400, Thomas Schulz wrote:
I wrote:
  On Thu, Aug 14, 2014 at 02:26:54PM -0500, Bill Christensen wrote:
   It looks like my root pointers are horribly out of date.  Seems
   to me this is something which should automatically update...
  
  Not much, and yes.
  
   ;   This file is made available by InterNIC
   ;   under anonymous FTP as
   ;   file/domain/named.root
   ;   on server   FTP.INTERNIC.NET
   ;   -OR-RS.INTERNIC.NET
   ;
   ;   last update:Feb 04, 2008
   ;   related version of root zone:   2008020400
  
  That's old, but not so old as to prevent you from reaching an 
  actual root server.  Of course it was 2 years before the root
  was signed.
 
 I will add my $0.02. The named executable has the root information 
 built in so that it can start up if there is no named.root file 
 available. So, if you had no named.root file but did have the 
 latest release of Bind then you would have the current data. If you 
 do not update Bind the moment that a new version is released then 
 you need a current named.root file.

Not really.  There are enough valid servers from 2008020400 to be 
able to resolve ./IN/NS now.  In fact I bet you could turn on an 
ancient BIND 4 today and still be able to resolve the root.

 Just go get a new one from the 
 server listed at the top of the old file.

Sure, that's good advice, which is why I left it in the posted 
message.  But probably better advice is to upgrade to a supported 
BIND version.  If the OS is so old to be have a 2008020400 hint 
file, it probably means no updates have been done along the way.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
___
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: Root servers

[Barry Margolin]

In article mailman.806.1408112054.26362.bind-us...@lists.isc.org,
 sch...@adi.com (Thomas Schulz) wrote:

 I will add my $0.02. The named executable has the root information built
 in so that it can start up if there is no named.root file available.
 So, if you had no named.root file but did have the latest release of
 Bind then you would have the current data. If you do not update Bind
 the moment that a new version is released then you need a current
 named.root file. Just go get a new one from the server listed at the
 top of the old file.

One of the first things that BIND does after startup is contact one of 
the root servers that it knows about, either from its named.root file or 
the ones hard-coded into the executable, and ask it for the current list 
of root servers.

So you only really need to a named.root file if the executable is so old 
that none of the hard-coded IPs still work (that's unlikely to ever 
happen), or some of the IPs have been reassigned to untrusted servers (I 
expect that IANA takes care not to allow this).

-- 
Barry Margolin
Arlington, MA
___
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: Root servers

[Bill Christensen]

On 8/15/14 9:42 AM, /dev/rob0 wrote:

On Fri, Aug 15, 2014 at 10:14:09AM -0400, Thomas Schulz wrote:
I wrote:

On Thu, Aug 14, 2014 at 02:26:54PM -0500, Bill Christensen wrote:

It looks like my root pointers are horribly out of date.  Seems
to me this is something which should automatically update...

Not much, and yes.


;   This file is made available by InterNIC
;   under anonymous FTP as
;   file/domain/named.root
;   on server   FTP.INTERNIC.NET
;   -OR-RS.INTERNIC.NET
;
;   last update:Feb 04, 2008
;   related version of root zone:   2008020400

That's old, but not so old as to prevent you from reaching an
actual root server.  Of course it was 2 years before the root
was signed.

I will add my $0.02. The named executable has the root information
built in so that it can start up if there is no named.root file
available. So, if you had no named.root file but did have the
latest release of Bind then you would have the current data. If you
do not update Bind the moment that a new version is released then
you need a current named.root file.

Not really.  There are enough valid servers from 2008020400 to be
able to resolve ./IN/NS now.  In fact I bet you could turn on an
ancient BIND 4 today and still be able to resolve the root.


Just go get a new one from the
server listed at the top of the old file.

Sure, that's good advice, which is why I left it in the posted
message.  But probably better advice is to upgrade to a supported
BIND version.  If the OS is so old to be have a 2008020400 hint
file, it probably means no updates have been done along the way.
Interesting.  I'm running BIND 9.10.0-P2.  Apparently the package system 
I'm using (MacPorts) isn't updating the root servers file though.


I'll report the problem there.  Meantime, I'll download the recent one 
and see if that makes a difference.


___
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

Root servers

[Bill Christensen]

Hi all,

I'm seeing some root server errors on startup:

14-Aug-2014 13:14:08.142 info: host unreachable resolving 
'd.gtld-servers.net//IN': 2001:503:ba3e::2:30#53
14-Aug-2014 13:14:08.215 info: host unreachable resolving 
'b.gtld-servers.net/A/IN': 2001:503:231d::2:30#53
14-Aug-2014 13:14:08.220 info: host unreachable resolving 
'c.gtld-servers.net/A/IN': 2001:503:231d::2:30#53
14-Aug-2014 13:14:08.522 info: host unreachable resolving 
'd.gtld-servers.net//IN': 2001:503:83eb::2:31#53
14-Aug-2014 13:14:08.595 info: host unreachable resolving 
'c.gtld-servers.net/A/IN': 2001:503:a83e::2:31#53
14-Aug-2014 13:14:08.793 info: host unreachable resolving 
'b.gtld-servers.net//IN': 2001:503:c27::2:30#53
14-Aug-2014 13:14:08.794 info: host unreachable resolving 
'b.gtld-servers.net//IN': 2001:dc3::35#53
14-Aug-2014 13:14:08.795 info: host unreachable resolving 
'c.gtld-servers.net//IN': 2001:503:c27::2:30#53
14-Aug-2014 13:14:08.796 info: host unreachable resolving 
'c.gtld-servers.net//IN': 2001:dc3::35#53


How do I correct that?  It looks like my root pointers are horribly out 
of date.  Seems to me this is something which should automatically update...



;   This file is made available by InterNIC
;   under anonymous FTP as
;   file/domain/named.root
;   on server   FTP.INTERNIC.NET
;   -OR-RS.INTERNIC.NET
;
;   last update:Feb 04, 2008
;   related version of root zone:   2008020400
;
; formerly NS.INTERNIC.NET
;
.360  IN  NSA.ROOT-SERVERS.NET.
A.ROOT-SERVERS.NET.  360  A 198.41.0.4
A.ROOT-SERVERS.NET.  360    2001:503:BA3E::2:30
;
; formerly NS1.ISI.EDU
;
.360  NSB.ROOT-SERVERS.NET.
B.ROOT-SERVERS.NET.  360  A 192.228.79.201
;
; formerly C.PSI.NET
;
.360  NSC.ROOT-SERVERS.NET.
C.ROOT-SERVERS.NET.  360  A 192.33.4.12
;
; formerly TERP.UMD.EDU
;
.360  NSD.ROOT-SERVERS.NET.
D.ROOT-SERVERS.NET.  360  A 128.8.10.90
;
; formerly NS.NASA.GOV
;
.360  NSE.ROOT-SERVERS.NET.
E.ROOT-SERVERS.NET.  360  A 192.203.230.10
;
; formerly NS.ISC.ORG
;
.360  NSF.ROOT-SERVERS.NET.
F.ROOT-SERVERS.NET.  360  A 192.5.5.241
F.ROOT-SERVERS.NET.  360    2001:500:2f::f
;
; formerly NS.NIC.DDN.MIL
;
.360  NSG.ROOT-SERVERS.NET.
G.ROOT-SERVERS.NET.  360  A 192.112.36.4
;
; formerly AOS.ARL.ARMY.MIL
;
.360  NSH.ROOT-SERVERS.NET.
H.ROOT-SERVERS.NET.  360  A 128.63.2.53
H.ROOT-SERVERS.NET.  360    2001:500:1::803f:235
;
; formerly NIC.NORDU.NET
;
.360  NSI.ROOT-SERVERS.NET.
I.ROOT-SERVERS.NET.  360  A 192.36.148.17
;
; operated by VeriSign, Inc.
;
.360  NSJ.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET.  360  A 192.58.128.30
J.ROOT-SERVERS.NET.  360    2001:503:C27::2:30
;
; operated by RIPE NCC
;
.360  NSK.ROOT-SERVERS.NET.
K.ROOT-SERVERS.NET.  360  A 193.0.14.129
K.ROOT-SERVERS.NET.  360    2001:7fd::1
;
; operated by ICANN
;
.360  NSL.ROOT-SERVERS.NET.
L.ROOT-SERVERS.NET.  360  A 199.7.83.42
;
; operated by WIDE
;
.360  NSM.ROOT-SERVERS.NET.
M.ROOT-SERVERS.NET.  360  A 202.12.27.33
M.ROOT-SERVERS.NET.  360    2001:dc3::35
; End of 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: Root servers

[/dev/rob0]

On Thu, Aug 14, 2014 at 02:26:54PM -0500, Bill Christensen wrote:
 I'm seeing some root server errors on startup:
 
 14-Aug-2014 13:14:08.142 info: host unreachable resolving 
 'd.gtld-servers.net//IN': 2001:503:ba3e::2:30#53
 14-Aug-2014 13:14:08.215 info: host unreachable resolving 
 'b.gtld-servers.net/A/IN': 2001:503:231d::2:30#53
 14-Aug-2014 13:14:08.220 info: host unreachable resolving 
 'c.gtld-servers.net/A/IN': 2001:503:231d::2:30#53
 14-Aug-2014 13:14:08.522 info: host unreachable resolving 
 'd.gtld-servers.net//IN': 2001:503:83eb::2:31#53
 14-Aug-2014 13:14:08.595 info: host unreachable resolving 
 'c.gtld-servers.net/A/IN': 2001:503:a83e::2:31#53
 14-Aug-2014 13:14:08.793 info: host unreachable resolving 
 'b.gtld-servers.net//IN': 2001:503:c27::2:30#53
 14-Aug-2014 13:14:08.794 info: host unreachable resolving 
 'b.gtld-servers.net//IN': 2001:dc3::35#53
 14-Aug-2014 13:14:08.795 info: host unreachable resolving 
 'c.gtld-servers.net//IN': 2001:503:c27::2:30#53
 14-Aug-2014 13:14:08.796 info: host unreachable resolving 
 'c.gtld-servers.net//IN': 2001:dc3::35#53
 
 
 How do I correct that?

It looks like your system thinks it has IPv6 connectivity, but it
doesn't really have it.  You can disable IPv6 at the OS level or:
named -4.

 It looks like my root pointers are horribly out of date.  Seems
 to me this is something which should automatically update...

Not much, and yes.

 ;   This file is made available by InterNIC
 ;   under anonymous FTP as
 ;   file/domain/named.root
 ;   on server   FTP.INTERNIC.NET
 ;   -OR-RS.INTERNIC.NET
 ;
 ;   last update:Feb 04, 2008
 ;   related version of root zone:   2008020400

That's old, but not so old as to prevent you from reaching an actual 
root server.  Of course it was 2 years before the root was signed.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if /dev/rob0 is in the Subject:
___
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: What if no root servers?

[Chris Buxton]

On Apr 9, 2014, at 12:02 AM, Dean Gibson (DNS Administrator) 
i...@ultimeth.com wrote:

 I'm interested in a special use-case, where (say, in an emergency), access to 
 most of the Internet (and hence the root servers) is cut off.  In this 
 situation, there is an emergency connected network consisting of several 
 domains, each with known nameserver IP addresses.   The hosts in domain 
 aaa.com know (typically, via DHCP) about the nameservers for their domain, 
 but nothing about domain bbb.com.
 
 At first I thought that one should place glue NS records for domain bbb.com 
 in the zone for aaa.com, so that hosts in aaa.com that use the aaa.com 
 nameservers, will be able to refer to the hostnames in domain bbb.com.
 
 I understand that one can do this for subdomains.  However, a bit of research 
 seems to suggest that a stub zone is the proper way to do this.  Is this what 
 a stub zone is for?

Yes, put the stub zone(s) on your recursive name servers so that they know 
where to find your authoritative zones or those outside zones to which you 
cannot lose contact. Use static-stub zones in place of stub zones where 
appropriate.

Then you have to maintain your masters statements as those zones move around.

Chris
___
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

What if no root servers?

[Dean Gibson (DNS Administrator)]

I'm interested in a special use-case, where (say, in an emergency), 
access to most of the Internet (and hence the root servers) is cut off.  
In this situation, there is an emergency connected network consisting of 
several domains, each with known nameserver IP addresses.   The hosts in 
domain aaa.com know (typically, via DHCP) about the nameservers for 
their domain, but nothing about domain bbb.com.


At first I thought that one should place glue NS records for domain 
bbb.com in the zone for aaa.com, so that hosts in aaa.com that use the 
aaa.com nameservers, will be able to refer to the hostnames in domain 
bbb.com.


I understand that one can do this for subdomains.  However, a bit of 
research seems to suggest that a stub zone is the proper way to do 
this.  Is this what a stub zone is for?


-- Dean
___
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

Reverse look-up returns root servers?

[Shawn Bakhtiar]

background:
last month we enabled the feature on sendmail to do a reverse look-up of the 
name and verify the IP address before accepting an email for delivery 
FEATURE(`require_rdns')dnl. I know this breaks the RFC but given all the spam 
this actually helps weed out a few.

Received a call from purchasing today, that (all of a sudden) one of our 
vendors is no longer able to send us email. Checking the mail log I get:
Oct 28 05:30:48 smtp sendmail[9092]: r9SCUmtY009092: ruleset=check_rcpt, 
arg1=rwe...@inksystems.com, relay=[198.173.12.21], reject=550 5.7.1 
rwe...@inksystems.com... Fix reverse DNS for 198.173.12.21
Oct 28 05:30:49 smtp sendmail[9092]: r9SCUmtY009092: 
from=prvs=1013b1b09b=h...@apollocolors.com, size=0, class=0, nrcpts=0, 
proto=ESMTP, daemon=MTA, relay=[198.173.12.21]

now normally the second line should end with relay=mailgw.apollocolors.com. 
[198.173.12.21] (not just the IP in brackets)

However, we implemented the rule over a month ago, and all of a sudden as of 
yesterday this stopped working??

Question:
When I dig the MX record I get mailgw.apollocolors.com. 

pompt dig apollocolors.com MX

;  DiG 9.8.4-P1-RedHat-9.8.4-3.P1.fc16  apollocolors.com MX
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 50104
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 5

;; QUESTION SECTION:
;apollocolors.com.INMX

;; ANSWER SECTION:
apollocolors.com.3085INMX10 mailgw.apollocolors.com.

;; AUTHORITY SECTION:
apollocolors.com.3332INNSns3.e2services.net.
apollocolors.com.3332INNSns4.e2services.net.
apollocolors.com.3332INNSns2.e2services.net.
apollocolors.com.3332INNSns1.e2services.net.

;; ADDITIONAL SECTION:
mailgw.apollocolors.com. 3085INA198.173.12.21
ns1.e2services.net.3079INA216.35.163.10
ns2.e2services.net.3079INA216.35.163.11
ns3.e2services.net.3079INA64.14.233.10
ns4.e2services.net.3079INA64.14.233.11

;; Query time: 1 msec
;; SERVER: 12.238.189.39#53(12.238.189.39)
;; WHEN: Mon Oct 28 12:53:35 2013
;; MSG SIZE  rcvd: 223


When I look-up the reverse at my recursive server I get:
prompt dig -x 198.173.12.21 

;  DiG 9.8.4-P1-RedHat-9.8.4-3.P1.fc16  -x 198.173.12.21
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 33959
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 4

;; QUESTION SECTION:
;21.12.173.198.in-addr.arpa.INPTR

;; ANSWER SECTION:
21.12.173.198.in-addr.arpa. 8428 INPTRmailgw.apollocolors.com.

;; AUTHORITY SECTION:
12.173.198.in-addr.arpa. 40828INNSauth2.dns.cogentco.com.
12.173.198.in-addr.arpa. 40828INNSauth5.dns.cogentco.com.
12.173.198.in-addr.arpa. 40828INNSauth4.dns.cogentco.com.
12.173.198.in-addr.arpa. 40828INNSauth1.dns.cogentco.com.

;; ADDITIONAL SECTION:
auth1.dns.cogentco.com.16531IN2001:550:1:a::d
auth2.dns.cogentco.com.30846IN2001:550:1:b::d
auth4.dns.cogentco.com.30846IN2001:978:1:a::d
auth5.dns.cogentco.com.30846IN2001:978:1:b::d

;; Query time: 1 msec
;; SERVER: 12.238.189.39#53(12.238.189.39)
;; WHEN: Mon Oct 28 12:55:16 2013
;; MSG SIZE  rcvd: 286


However, and her is the rub, when I do the same reverse look-up at any of their 
servers I get a list of root servers back. Shouldn't I be getting back the IP 
address pointer back? Also according to IntoDNS two of their servers are 
misconfigured or non-existant.

Here is what I get instead:
prompt dig @216.35.163.10 -x 198.173.12.21

;  DiG 9.8.4-P1-RedHat-9.8.4-3.P1.fc16  @216.35.163.10 -x 198.173.12.21
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 29478
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;21.12.173.198.in-addr.arpa.INPTR

;; AUTHORITY SECTION:
.3600INNSj.root-servers.net.
.3600INNSl.root-servers.net.
.3600INNSi.root-servers.net.
.3600INNSm.root-servers.net.
.3600INNSa.root-servers.net.
.3600INNSb.root-servers.net.
.3600INNSc.root-servers.net.
.3600INNSd.root-servers.net.
.3600INNSe.root-servers.net.
.3600INNSf.root-servers.net.
.3600INNSg.root-servers.net.
.3600INNSh.root-servers.net.
.3600INNSk.root-servers.net.

;; ADDITIONAL SECTION:
j.root-servers.net.3600INA192.58.128.30
l.root-servers.net.3600INA199.7.83.42
i.root-servers.net.3600INA192.36.148.17

;; Query time

Re: Reverse look-up returns root servers?

[Matus UHLAR - fantomas]

On 28.10.13 16:07, Shawn Bakhtiar wrote:

When I look-up the reverse at my recursive server I get:
prompt dig -x 198.173.12.21



;; AUTHORITY SECTION:
12.173.198.in-addr.arpa. 40828INNSauth2.dns.cogentco.com.
12.173.198.in-addr.arpa. 40828INNSauth5.dns.cogentco.com.
12.173.198.in-addr.arpa. 40828INNSauth4.dns.cogentco.com.
12.173.198.in-addr.arpa. 40828INNSauth1.dns.cogentco.com.

;; ADDITIONAL SECTION:
auth1.dns.cogentco.com.16531IN2001:550:1:a::d
auth2.dns.cogentco.com.30846IN2001:550:1:b::d
auth4.dns.cogentco.com.30846IN2001:978:1:a::d
auth5.dns.cogentco.com.30846IN2001:978:1:b::d


auth1.dns.cogentco.com. 10800   IN  A   66.28.0.14
auth1.dns.cogentco.com. 43200   IN  2001:550:1:a::d
auth2.dns.cogentco.com. 10800   IN  A   66.28.0.30
auth2.dns.cogentco.com. 43200   IN  2001:550:1:b::d
auth4.dns.cogentco.com. 10800   IN  A   80.245.32.74
auth4.dns.cogentco.com. 43200   IN  2001:978:1:a::d
auth5.dns.cogentco.com. 10800   IN  A   80.91.64.50
auth5.dns.cogentco.com. 43200   IN  2001:978:1:b::d

fix the TTLs, they should be the same. 


BTW, yout parent referral only contains two servers, you should ask for
adding the others:

12.173.198.in-addr.arpa. 14400  IN  NS  auth2.dns.cogentco.com.
12.173.198.in-addr.arpa. 14400  IN  NS  auth1.dns.cogentco.com.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
If Barbie is so popular, why do you have to buy her friends? 
___

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: Reverse look-up returns root servers?

[Shawn Bakhtiar]

I'm inksystems.com

the vendor is apollocolors.com

I reloaded nscd and named, and sent an email to purchasing to have them check 
it again. I'll also ask her to forward the information to the vendor to sync 
their TTLs and make sure they add the other name servers, I wonder if their 
changing over and that's the issue? 

Thanks,


 Date: Mon, 28 Oct 2013 21:47:42 +0100
 From: uh...@fantomas.sk
 To: bind-users@lists.isc.org
 Subject: Re: Reverse look-up returns root servers?
 
 On 28.10.13 16:07, Shawn Bakhtiar wrote:
 When I look-up the reverse at my recursive server I get:
 prompt dig -x 198.173.12.21
 
 ;; AUTHORITY SECTION:
 12.173.198.in-addr.arpa. 40828INNSauth2.dns.cogentco.com.
 12.173.198.in-addr.arpa. 40828INNSauth5.dns.cogentco.com.
 12.173.198.in-addr.arpa. 40828INNSauth4.dns.cogentco.com.
 12.173.198.in-addr.arpa. 40828INNSauth1.dns.cogentco.com.
 
 ;; ADDITIONAL SECTION:
 auth1.dns.cogentco.com.16531IN2001:550:1:a::d
 auth2.dns.cogentco.com.30846IN2001:550:1:b::d
 auth4.dns.cogentco.com.30846IN2001:978:1:a::d
 auth5.dns.cogentco.com.30846IN2001:978:1:b::d
 
 auth1.dns.cogentco.com. 10800   IN  A   66.28.0.14
 auth1.dns.cogentco.com. 43200   IN  2001:550:1:a::d
 auth2.dns.cogentco.com. 10800   IN  A   66.28.0.30
 auth2.dns.cogentco.com. 43200   IN  2001:550:1:b::d
 auth4.dns.cogentco.com. 10800   IN  A   80.245.32.74
 auth4.dns.cogentco.com. 43200   IN  2001:978:1:a::d
 auth5.dns.cogentco.com. 10800   IN  A   80.91.64.50
 auth5.dns.cogentco.com. 43200   IN  2001:978:1:b::d
 
 fix the TTLs, they should be the same. 
 
 BTW, yout parent referral only contains two servers, you should ask for
 adding the others:
 
 12.173.198.in-addr.arpa. 14400  IN  NS  auth2.dns.cogentco.com.
 12.173.198.in-addr.arpa. 14400  IN  NS  auth1.dns.cogentco.com.
 
 
 -- 
 Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
 Warning: I wish NOT to receive e-mail advertising to this address.
 Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
 If Barbie is so popular, why do you have to buy her friends? 
 ___
 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

Caching name server - Choosing the root-servers

[Can Şirin]

Hello,

I would like to set up a caching only name server but besides that I want also 
to edit named.root by this means limit the root hints. I mean, choosing the 
faster ones (root-servers) is gonna be better for speed performans. I had a 
study on it and I realise that even if you edit the root hints file, named 
service is checking the other root-servers' ns from the first one in 
named.root.  Is there any way to configure the caching name server in the way 
of I think. Waiting for your response.

Thanks
Can Şirin

___
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: Caching name server - Choosing the root-servers

[Stephane Bortzmeyer]

On Fri, Dec 14, 2012 at 09:00:31AM +,
 Can Şirin sirin...@itu.edu.tr wrote 
 a message of 114 lines which said:

 I mean, choosing the faster ones (root-servers) is gonna be better
 for speed performans.

Yes, but BIND does it (testing the fastest) and probably better than
you.

 Is there any way to configure the caching name server in the way of
 I think.

I don't think so and it seems quite useless. 
___
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

Should Root Servers Always be Queried First? bind9.7.7

[Martin McCormick]

If I do:

dig @localhost +short +trace somehost.okstate.edu

on a server authoritative for the okstate.edu domain, I would
expect resolution via that authoritative system. I do get it but
the query takes the scenic route and I get all the root name
servers just as if the query was for some host outside our
domains.

Why? We are having issues with random latency right now
so I started checking everything I could and that is how I
discovered this. I don't know if that is normal or not
___
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: Should Root Servers Always be Queried First? bind9.7.7

[Michael Hoskins (michoski)]

-Original Message-

From: Martin McCormick mar...@dc.cis.okstate.edu
Date: Wednesday, November 7, 2012 1:12 PM
To: bind-users@lists.isc.org bind-users@lists.isc.org
Subject: Should Root Servers Always be Queried First? bind9.7.7

If I do:

dig @localhost +short +trace somehost.okstate.edu

on a server authoritative for the okstate.edu domain, I would
expect resolution via that authoritative system. I do get it but
the query takes the scenic route and I get all the root name
servers just as if the query was for some host outside our
domains.

   Why? We are having issues with random latency right now
so I started checking everything I could and that is how I
discovered this. I don't know if that is normal or not

as others have pointed out in the past, +trace and @server really don't
cooperate...  +trace always traces delegations from the root-down.  you
are seeing normal behavior.

  +[no]trace
  Toggle tracing of the delegation path from the root name servers
  for the name being looked up. Tracing is disabled by default. When
  tracing is enabled, dig makes iterative queries to resolve the name
  being looked up. It will follow referrals from the root servers,
  showing the answer from each server that was used to resolve the
  lookup.

___
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: Should Root Servers Always be Queried First? bind9.7.7

[david]

The +trace option ignores the resolver that you specify after the @ sign,
and begins at the root. 


 -DTK

-Original Message-
From: bind-users-bounces+root=nachtmaus...@lists.isc.org
[mailto:bind-users-bounces+root=nachtmaus...@lists.isc.org] On Behalf Of
Martin McCormick
Sent: Wednesday, November 07, 2012 1:13 PM
To: bind-users@lists.isc.org
Subject: Should Root Servers Always be Queried First? bind9.7.7

If I do:

dig @localhost +short +trace somehost.okstate.edu

on a server authoritative for the okstate.edu domain, I would expect
resolution via that authoritative system. I do get it but the query takes
the scenic route and I get all the root name servers just as if the query
was for some host outside our domains.


Why? We are having issues with random latency right now so I started
checking everything I could and that is how I discovered this. I don't know
if that is normal or not ___
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: Should Root Servers Always be Queried First? bind9.7.7

[Josh Kuo]

In other words, if your goal is to identify latency in your resolver, it's
probably best to run tcpdump on the resolver itself, and analyze the
traffic capture to see if there are any latency. The +trace shows you what
should happen.


On Wed, Nov 7, 2012 at 3:05 PM, david r...@nachtmaus.us wrote:


 The +trace option ignores the resolver that you specify after the @ sign,
 and begins at the root.


  -DTK

 -Original Message-
 From: bind-users-bounces+root=nachtmaus...@lists.isc.org
 [mailto:bind-users-bounces+root=nachtmaus...@lists.isc.org] On Behalf Of
 Martin McCormick
 Sent: Wednesday, November 07, 2012 1:13 PM
 To: bind-users@lists.isc.org
 Subject: Should Root Servers Always be Queried First? bind9.7.7

 If I do:

 dig @localhost +short +trace somehost.okstate.edu

 on a server authoritative for the okstate.edu domain, I would expect
 resolution via that authoritative system. I do get it but the query takes
 the scenic route and I get all the root name servers just as if the query
 was for some host outside our domains.


 Why? We are having issues with random latency right now so I
 started
 checking everything I could and that is how I discovered this. I don't know
 if that is normal or not ___
 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: Should Root Servers Always be Queried First? bind9.7.7

[Martin McCormick]

Thanks to all who reminded me how dig resolves lookups.

I have since learned that we are apparently having
intermittent network issues that are causing a lot of systems to
behave oddly and our DNS's are only reflecting those conditions.

We were taking anywhere from 0 milliseconds to 5 seconds
to resolve local hosts and then just as suddenly, everything
cleaned itself up and it is all peace and quiet 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: Glue from Root Servers returns wrong A record, why?

[Stephane Bortzmeyer]

On Mon, Sep 10, 2012 at 11:47:38AM -0700,
 Ponga ponga2...@gmail.com wrote 
 a message of 55 lines which said:

 But if I ask any root server, [...] DiG 9.7.3  -t ns intaq.com
 @192.42.93.30

192.42.93.30 is not a root name server.
___
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 from Root Servers returns wrong A record, why?

[ponga2112]

 
 
 
 192.42.93.30 is not a root name server.

True enough.
___
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 from Root Servers returns wrong A record, why?

[Ponga]

I'm stumped by this, hoping someone can help:

If I ask any DNS server at my disposal (in this example google), I don't get 
glue, and I get the correct answer:
;  DiG 9.8.1-P1  -t ns intaq.com @8.8.8.8
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 38256
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;intaq.com. IN  NS

;; ANSWER SECTION:
intaq.com.  180 IN  NS  ns2.intaq.net.
intaq.com.  180 IN  NS  ns1.intaq.net.

;; Query time: 134 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Sep 10 12:39:26 2012
;; MSG SIZE  rcvd: 72

But if I ask any root server, I get no answer, and the glue I get is absolutely 
the wrong IP address (a record):
;  DiG 9.7.3  -t ns intaq.com @192.42.93.30
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 4562
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;intaq.com. IN  NS

;; AUTHORITY SECTION:
intaq.com.  172800  IN  NS  ns1.intaq.net.
intaq.com.  172800  IN  NS  ns2.intaq.net.

;; ADDITIONAL SECTION:
ns1.intaq.net.  172800  IN  A   216.146.46.198
ns2.intaq.net.  172800  IN  A   216.146.46.198

;; Query time: 38 msec
;; SERVER: 192.42.93.30#53(192.42.93.30)
;; WHEN: Mon Sep 10 09:33:58 2012
;; MSG SIZE  rcvd: 104

I can't find ANYWHERE in my DNS records where this 216. IP address is and 
obviously my understand of DNS is not up to the task. Can anyone offer some 
idea on how to fix this??

Thanks, 
Ponga
___
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 from Root Servers returns wrong A record, why?

[Doug Barton]

On 9/10/2012 11:47 AM, Ponga wrote:
 I can't find ANYWHERE in my DNS records where this 216. IP address is and 
 obviously my understand of DNS is not up to the task. Can anyone offer some 
 idea on how to fix this??

This is almost certainly part of the registration information for the
.net domain. Check the records at your registrar.

-- 

I am only one, but I am one.  I cannot do everything, but I can do
something.  And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
___
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 from Root Servers returns wrong A record, why?

[ponga2112]

On Monday, September 10, 2012 12:51:43 PM UTC-6, Doug Barton wrote:
 On 9/10/2012 11:47 AM, Ponga wrote:
 
  I can't find ANYWHERE in my DNS records where this 216. IP address is and 
  obviously my understand of DNS is not up to the task. Can anyone offer some 
  idea on how to fix this??
 
 
 
 This is almost certainly part of the registration information for the
 
 .net domain. Check the records at your registrar.
 

SOA points correctly to the DNS provider (zoneedit).. there is no mention of 
that 216 address anywhere in the registrar :(
___
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 from Root Servers returns wrong A record, why?

[WBrown]

ponga2...@gmail.com wrote on 09/10/2012 03:11:30 PM:

 
 SOA points correctly to the DNS provider (zoneedit).. there is no 
 mention of that 216 address anywhere in the registrar :(

Is the information below correct?

wbrown@wbrown-D630:~$ whois intaq.com

Whois Server Version 2.0

Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.

   Domain Name: INTAQ.COM
   Registrar: NETWORK SOLUTIONS, LLC.
   Whois Server: whois.networksolutions.com
   Referral URL: http://www.networksolutions.com/en_US/
   Name Server: NS1.INTAQ.NET
   Name Server: NS2.INTAQ.NET
   Status: clientTransferProhibited
   Updated Date: 23-may-2011
   Creation Date: 31-may-2002
   Expiration Date: 31-may-2013

 Last update of whois database: Mon, 10 Sep 2012 19:15:16 UTC 

[Blah blah blah]


Registrant:
Finger Rock Technology
   5030 N. Post Trail
   Tucson, AZ 85750
   US

   Domain Name: INTAQ.COM

[Blah blah blah]

   Administrative Contact, Technical Contact:
  Finger Rock Technologyarma...@fingerrock.com
  5030 N. Post Trail
  Tucson, AZ 85750
  US
  (520) 906-5437 fax: 123 123 1234


   Record expires on 31-May-2013.
   Record created on 31-May-2002.
   Database last updated on 10-Sep-2012 15:15:47 EDT.

   Domain servers in listed order:

   NS1.INTAQ.NET216.146.46.198
   NS2.INTAQ.NET216.146.46.198




Confidentiality Notice: 
This electronic message and any attachments may contain confidential or 
privileged information, and is intended only for the individual or entity 
identified above as the addressee. If you are not the addressee (or the 
employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that 
you may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or 
telephone and delete this message from your system.
___
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 from Root Servers returns wrong A record, why?

[Doug Barton]

On 9/10/2012 12:11 PM, ponga2...@gmail.com wrote:
 On Monday, September 10, 2012 12:51:43 PM UTC-6, Doug Barton wrote:
 On 9/10/2012 11:47 AM, Ponga wrote:

 I can't find ANYWHERE in my DNS records where this 216. IP address is and 
 obviously my understand of DNS is not up to the task. Can anyone offer some 
 idea on how to fix this??



 This is almost certainly part of the registration information for the

 .net domain. Check the records at your registrar.

 
 SOA points correctly to the DNS provider (zoneedit).. there is no mention of 
 that 216 address anywhere in the registrar :(

You misunderstood my suggestion. Go log into your account at the
registrar, and fix the glue records there. WBrown's message verified my
theory.

Doug

-- 

I am only one, but I am one.  I cannot do everything, but I can do
something.  And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
___
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 from Root Servers returns wrong A record, why?

[ponga2112]

On Monday, September 10, 2012 1:23:47 PM UTC-6, Doug Barton wrote:
snipped
 
 
 You misunderstood my suggestion. Go log into your account at the
 
 registrar, and fix the glue records there. WBrown's message verified my
 
 theory.
 
 
 
 Doug
snipped

BLY! You guys are absolutely right. Not sure what I missed there, but by golly 
that's the problem. 

Thanks gentleman! Much appreciated!!!



___
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 from Root Servers returns wrong A record, why?

[Doug Barton]

On 9/10/2012 12:27 PM, ponga2...@gmail.com wrote:
 Thanks gentleman! Much appreciated!!!

Glad to help.

-- 

I am only one, but I am one.  I cannot do everything, but I can do
something.  And I will not let what I cannot do interfere with what
I can do.
-- Edward Everett Hale, (1822 - 1909)
___
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

31 march and root servers

[Ivo]

Hello,


During the research on dns/dnssec amplification attacks against root
servers and evaluation of anonymous operation global blackout (we still
don't know if this is a hoax...), we came up with idea which would limit
one additional attack.

Lets imagine query source spoofed as one of the root servers IP and now
if sending query to DNS cache server, which does all the name resolving
process and finally sends reply to spoofed IP which in this case is one
of the root servers. So this may be additional network traffic during
the attack.

The idea is to filter these outgoing replies with IP matching any of the
root server IP and source port :53 on DNS cache servers, so we will
avoid loading root servers with this spoofed reply.
I hope this does not drop legitimate traffic so let me know if this is a
bad idea. :)


best regards,

Ivo

___
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

forwarder that doesn't ask root servers

[Marcos Lorenzo de Santiago]

I believe bind has some root servers hardcoded inside and bind always
looks for root servers even if you give it a list of forwarders, I see
this in the firewall blocked connections.

So the question is quite simple: Is there anyway to disable this? I
mean, I just want bind to forward queries related to not-owned maps to a
list of forwarders as FW will drop all packages going to non-local nets.

Does any of you know how to accomplish this? 

Thanks in advance.


-- 
,---.
| Son los inocentes y no los sabios los que resuelven las cuestiones|
| difíciles.|
| -- Pío Baroja. (1872-1956) Escritor español.  |
|---|
| Técnico de Sistemas|  |
| Departamento de Informática| Debian GNU/Linux Powerer |
| Ayuntamiento de Getafe |.--.  |
||   |o_o | |
|  _ |  .''`.|:_/ | |
| |~~  @| Marcos Lorenzo de Santiago | : :' :   //   \ \|
| |     | marcos.lore...@ayto-getafe.org | `. `'   (| | )   |
| |_| Teléfono: (+34) 91-202-79-48   |   `-   /'\_   _/`\   |
| Móvil:(+34)  608-300-935   |\___)=(___/   |
||  |
`---'

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

Re: forwarder that doesn't ask root servers

[Adam Tkac]

On Mon, Sep 14, 2009 at 01:31:24PM +0200, Marcos Lorenzo de Santiago wrote:
 I believe bind has some root servers hardcoded inside and bind always
 looks for root servers even if you give it a list of forwarders, I see
 this in the firewall blocked connections.
 
 So the question is quite simple: Is there anyway to disable this? I
 mean, I just want bind to forward queries related to not-owned maps to a
 list of forwarders as FW will drop all packages going to non-local nets.
 
 Does any of you know how to accomplish this? 

options {
...
forward only;
...
};

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: forwarder that doesn't ask root servers

[Marcos Lorenzo de Santiago]

El lun, 14-09-2009 a las 15:01 +0200, Adam Tkac escribió:
 On Mon, Sep 14, 2009 at 01:31:24PM +0200, Marcos Lorenzo de Santiago wrote:
  I believe bind has some root servers hardcoded inside and bind always
  looks for root servers even if you give it a list of forwarders, I see
  this in the firewall blocked connections.
  
  So the question is quite simple: Is there anyway to disable this? I
  mean, I just want bind to forward queries related to not-owned maps to a
  list of forwarders as FW will drop all packages going to non-local nets.
  
  Does any of you know how to accomplish this? 
 
 options {
   ...
   forward only;
   ...
 };
 
 Regards, Adam
 

Thanks a lot... I feel stupid now, but thanks for opening my eyes! :D

Cheers.

-- 
,---.
| Dejemos las conclusiones para los idiotas.|
| -- Pío Baroja. (1872-1956) Escritor español.  |
|---|
| Técnico de Sistemas|  |
| Departamento de Informática| Debian GNU/Linux Powerer |
| Ayuntamiento de Getafe |.--.  |
||   |o_o | |
|  _ |  .''`.|:_/ | |
| |~~  @| Marcos Lorenzo de Santiago | : :' :   //   \ \|
| |     | marcos.lore...@ayto-getafe.org | `. `'   (| | )   |
| |_| Teléfono: (+34) 91-202-79-48   |   `-   /'\_   _/`\   |
| Móvil:(+34)  608-300-935   |\___)=(___/   |
||  |
`---'

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

Re: forwarder that doesn't ask root servers

[Barry Margolin]

In article mailman.486.1252933642.14796.bind-us...@lists.isc.org,
 Marcos Lorenzo de Santiago marcos.lore...@ayto-getafe.org wrote:

 El lun, 14-09-2009 a las 15:01 +0200, Adam Tkac escribió:
  On Mon, Sep 14, 2009 at 01:31:24PM +0200, Marcos Lorenzo de Santiago wrote:
   I believe bind has some root servers hardcoded inside and bind always
   looks for root servers even if you give it a list of forwarders, I see
   this in the firewall blocked connections.
   
   So the question is quite simple: Is there anyway to disable this? I
   mean, I just want bind to forward queries related to not-owned maps to a
   list of forwarders as FW will drop all packages going to non-local nets.
   
   Does any of you know how to accomplish this? 
  
  options {
  ...
  forward only;
  ...
  };
  
  Regards, Adam
  
 
 Thanks a lot... I feel stupid now, but thanks for opening my eyes! :D

Don't feel stupid.  Older versions of BIND queried for the root servers 
even with this option set.

-- 
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Using DNS servers to query root servers from WAN

[samankaya]

 Many thanks again Kevin!

The reason I decided to use views in the first instance is that I wanted to 
separate clients who are in my local internal subnet and clients or are 
requesting information from the public internet.

Since I have defined the local subnet 192.168.0.0/23 currently for my wired and 
wireless networks I don't want them to see what is on the 'outside' of my NAT 
(my public IP address), and hence I used the same thinking behind the public 
internet that I didn't want them to see local information.

I two completely different database files for this reason, the internal which 
contains dns addresses for everything within the network including switches, 
routers, wireless access-points and print servers etc. These are all currently 
defined within the 192.168.1.0/24 range. 

The external view incorporates the WAN database file so everything is mapped to 
my public address. Since I only have one public address all my records whether 
it be A, MX, or PTR get mapped there, as I have internal mechanisms for 
distributing http, smtp and other information that usually requires separate 
public IP addresses.

This is the main reason why I'm using views. So my reasoning is that everybody 
internally sees 192.168.1.0/24 where all servers and other bits and pieces are 
in and everybody else sees the public information which is a highly cut down 
version of the internal one.

As stated before in my previous posting, my network will grow soon and without 
using VPN's I would like to be able to incorporate external sites. However I 
cannot put them onto the internal view otherwise they would see the 
192.168.1.0/24 subnet and since they are coming in from outside won't be able 
to connect. But also I would like to have these external 'branches' of my 
network be able to resolve google.com and all other 'outside' based sites like 
I am able to do inside which is what the hinted zone containing the root 
servers allows me to do which means I would either need to put them onto the 
external view and use recursion for the trusted sites only. eg. if the public 
IP addresses of the remote sites were 1.1.1.1, 1.1.1.2 and 1.1.1.3 just to keep 
things simple then:


view external { 
match-clients { any; !192.168.0.0/22; !127.0.0.1; }; 
allow-recursion { 127.0.0.1;  1.1.1.1; 1.1.1.2; 1.1.1.3; };?


include /etc/opt/csw/bind/named.conf.external;?


?


zone . {?
type hint; 
file /etc/opt/csw/bind/db.root; };?


}; 


 
something like that??

I did actually play around with not having views before but then whenever I did 
any lookups from 'outside' my network I could see all the internal IP addresses 
as well which is not what I want at all!

I am sorry if what I am trying to achieve is not how it would be normally done 
professionally but the whole point that it is currently in a test lab 
environment is that I'm trying to learn about this so that I can make all my 
mistakes and not understand now so that later when I come to implement this 
properly I will know exactly what I'm doing!! Please do not think like I'm 
trying to waste your time or anything!!! I just want to identify how to 
approach a situation like this and implement it. It doesn't really help either 
that every environment that I will deal with will be NAT'ed so I have to take 
extra care with that also!

Regards,

Kaya


 

-Original Message-
From: Kevin Darcy k...@chrysler.com
To: bind-users@lists.isc.org
Sent: Thu, Jul 2, 2009 2:36 am
Subject: Re: Using DNS servers to query root servers from WAN









Well, first of all, do you really need views at all? If the namespace 
you use internally is *distinct* from what you present externally, e.g. 
example-internal.com versus example-external.com, then you may not need 
to use views at all. Just use allow-query to control who can query what, 
and allow-recursion to control who can recurse. Make sure you lock down 
who can access cached data though (you might need a relatively-modern 
version of BIND for fine-grained control of that, i.e. allow-query-cache).?
?

But, assuming you need to use views at all, why do you think you need 
more than 2 views??
?

You need one view for the trusted clients. This view is allowed to 
recurse and needs a hints zone.?
?

You need another view for the untrusted clients. This only serves 
authoritative data, so it doesn't recurse and the source of the root 
zone in that view is irrelevant (you could just not define it at all, in 
which case it'll default to the compiled-in version).?
?

Where is the need for the third view? What value does it add??
?

For simplicity, I'd define the trusted view first, with match-clients 
set to the specific ranges you trust (which you can expand over time, of 
course). Then the untrusted view can be match-clients { any; }; to 
catch anything not matched by the prior view.?
?

?

?   
?- Kevin

Using DNS servers to query root servers from WAN

[samankaya]

Hi, this is my first post here and I have quite an interesting problem at that!

I have migrated my DNS service from Debian Etch Linux to Sun Solaris 9 running 
the Blastwave version of Bind9.

This is a bit hard to explain but basically as default DNS setup in Debian, it 
installs root servers in which domains for which the server is not 
authoritative for get resolved. Currently the setup works fine from within my 
LAN or intranet so? that any queries from 192.168.0.0/23 networks resolve 
perfectly ok as they should for WAN queries.

My issue is that I cannot seem to do the same from the other side of my 
gateway! The gateway is NAt'ed and I've directed ports 53 for both tcp and udp 
connections to the IP of the DNS server.

I have had this working before I decided to use views but now with the views in 
place something is blocking lookups for external sources. This is my current 
named.conf file:

---

// This is the primary configuration file for the BIND DNS server named.
//? 
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize 
// this configuration file.??? 
// 
// If you are just adding zones, please do that in 
//etc/bind/named.conf.local??? 

acl internals {
??? 127.0.0.0/8;
??? 192.168.0.0/22;
}; 

include /etc/opt/csw/bind/named.conf.options;

// View for internal clients

view internal {
??? match-clients { internals; };
??? allow-recursion {??? 
??? 192.168.0.0/22;? 
??? 127.0.0.1;?? 
??? };?? 

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912? 

//zone localhost {
//??? type master;
//??? file /etc/opt/csw/bind/db.local;
//};??? 

//zone 127.in-addr.arpa {
//??? type master; 
//??? file /etc/opt/csw/bind/db.127;
//};? 

//zone 0.in-addr.arpa {
//??? type master;?? 
//??? file /etc/opt/csw/bind/db.0;
//};??? 

//zone 255.in-addr.arpa {
//??? type master; 
//??? file /etc/opt/csw/bind/db.255;
//};? 


include /etc/opt/csw/bind/named.conf.local;


// zone com { type delegation-only; };
// zone net { type delegation-only; };
};? 


// View for external clients

view external {
??? match-clients { any; !192.168.0.0/22; !127.0.0.1; };
??? allow-recursion {?? 
??? 127.0.0.1;? 
??? };? 

include /etc/opt/csw/bind/named.conf.external;

};

// Everyone can view root servers

view all {
??? match-clients { any; };
??? allow-recursion {? 
??? 192.168.0.0/22;
??? 127.0.0.1; 
//? any;?? 
??? }; 

??? zone . {
??? type hint;
??? file /etc/opt/csw/bind/db.root;
??? };

??? zone localhost {
??? type master;
??? file /etc/opt/csw/bind/db.local;
??? };

??? zone 127.in-addr.arpa {
??? type master;
??? file /etc/opt/csw/bind/db.127;
??? };

??? zone 0.in-addr.arpa {
??? type master;
??? file /etc/opt/csw/bind/db.0;
??? };

??? zone 255.in-addr.arpa {
??? type master;
??? file /etc/opt/csw/bind/db.255;
??? };

};


//rndc security

?key rndc-key {
?? algorithm hmac-md5;
?? secret XigPbSdF3oVRXPzax+96xA==;
?};

?controls {
?? inet 127.0.0.1 port 953
?? allow { 127.0.0.1; } keys { rndc-key; };
?};

---

I tried switching the internal zones to a generic 'all' view which can be seen 
by everybody but it didn't seem to work and I also had a go at allowing 
recursion for 'all' for the hinted zone too which again didn't do anything.

Can anybody help me in allowing external users to be allowed to lookup all URLs 
via the hinted zone with the root.db servers file in it??

And at the same time perhaps if I have left some parts (zones) open which I