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
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
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 reall
Medina, Antonio 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=C
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
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)
wrote:
> How does Bind update the root servers? Does it go out and check, or i
On Tue, Aug 15, 2017 at 11:36 AM, Matthew Pounsett wrote:
>
>
> On 15 August 2017 at 11:29, King, Harold Clyde (Hal) wrote:
>>
>> How does Bind update the root servers? Does it go out and check, or is a
>> release made for each change?
>
>
> Yes. :)
>
&
On 15 August 2017 at 11:29, King, Harold Clyde (Hal) 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 wi
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
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 "
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/mailma
: 65C6C973
- Original Message -
From: "Antonio Medina"
To: "bind-users@lists.isc.org"
Cc: "Kairon Morillo" , "William Jackson"
Sent: Thursday, December 22, 2016 9:22:14 AM
Subject: RE: BIND - Continuous NS ROOT queries to root servers
Hi
. 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
. 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
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-
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
> 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
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 shoul
Am 30.01.2016 um 22:40 schrieb Grant Taylor:
On 01/30/2016 04:44 AM, Reindl Harald wrote:
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 a
>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 ha
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 a
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 f
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 onl
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:/
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 dn
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 CN
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
t: 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
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
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 d
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 rece
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
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
t 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
u 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
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, a
> 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 res
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
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
On Apr 9, 2014, at 12:02 AM, Dean Gibson (DNS Administrator)
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
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
d
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 t
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.17
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? Als
On Fri, Dec 14, 2012 at 09:00:31AM +,
Can Şirin 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
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
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
.@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
rmick
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 sy
-Original Message-
From: Martin McCormick
Date: Wednesday, November 7, 2012 1:12 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 ser
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 out
>
>
>
> 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/bi
On Mon, Sep 10, 2012 at 11:47:38AM -0700,
Ponga 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.o
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.
-- Edwa
On Monday, September 10, 2012 1:23:47 PM UTC-6, Doug Barton wrote:
>
>
> 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
BLY! You guys are absolutely right. Not sure what
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.
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
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??
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 dom
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, i
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 o
In article ,
Marcos Lorenzo de Santiago 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
> >
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
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 qu
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
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
lves if they are
provisioned like this but really it's just an open end experiment in
my test lab.
I did include the root "." zone in the external view before which
didn't work either so I guess if I can get that particular zone to
work with any public IP address then I can l
usted_wan" zone in which certain public IP
addresses are accepted for recursive lookup for root servers.
For example if I added:
zone "." {
type hint;?
file "/etc/opt/csw/bind/db.root";?
};
to both external and internal views would that work??
so if I did something mor
ting 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 authoritativ
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
sk
Thanks
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: sábado, 15 de noviembre de 2008 22:25
To: Ian Gregson
Subject: Re: Most external domains do not resolve (missing root servers?)
/16 or /24 are ways to specify a network mask. Its called CIDR or class
not resolve (missing root servers?)
/16 or /24 are ways to specify a network mask. Its called CIDR or classless
inter domain routing (I think that's the meaning) syntax and its pretty
easy.
/8 = 255.0.0.0
/16 = 255.255.0.0
/24 = 255.255.255.0
Those are the standard subnets, but others
2008 22:08
To: Ian Gregson
Subject: Re: Most external domains do not resolve (missing root servers?)
You have recursion set to "no" and forwarding set to "only". This means
your nameserver will never look anything up for clients but will forward all
requests to the specified for
: Dawn Connelly [mailto:[EMAIL PROTECTED]
Sent: sábado, 15 de noviembre de 2008 18:51
To: Ian Gregson
Cc: [EMAIL PROTECTED]
Subject: Re: Most external domains do not resolve (missing root servers?)
You have recursion set to no. So the only thing the DNS server will answer
for is zones it is
with firefox but NOT many, i.e.
> experts-exchange.com, linux.derkeiler.com work OK
>
>
>
> I presume its working off some kind of cache…
>
>
>
> What I did do was downloaded the named.root file and placed it in etc (see
> my named.conf for config "." Zone -
, linux.derkeiler.com work OK
I presume its working off some kind of cache.
What I did do was downloaded the named.root file and placed it in etc (see
my named.conf for config "." Zone - I have placed after this).
I think the issue is with the root servers not resolving as I ran a t
76 matches
Mail list logo
