Re: RPZ and negative answers

[Torsten Segner]

Am Thu, 4 Apr 2013 23:51:23 GMT
schrieb Vernon Schryver :

> > From: Chris Buxton 
> 
> > A company wants to halt the spread of a piece of malware that
> > uses DNS lookups to find its C&C. ...
> 
> > The company has determined the first N domains of the sequence,
> > but does not know how to calculate the complete set of domains.
> > ...
> 
> > Unfortunately, because RPZ doesn't return a policy-based answer when
> > there is no positive answer to be found out on the Internet, RPZ is
> > not a suitable solution. Therefore, the customer is forced to create
> > the individual zones normally, mixing them with other data in their
> > management solution, rather than using RPZ to trap the malware into
> > contacting the honeypot server.
> 
> Why isn't it both sufficient and better to list the NS servers or
> NS servers for the NS servers of the evil domains?  Won't NS servers
> for the N domains be known, espcially after the first of the N
> domains goes active?
> 
> 


Uhm... maybe I'm doing something wrong but RPZ answer rewrites on NXDOMAIN 
hosts do work for me.

We do have a customer who wants us to resolve some hosts which are normally on 
their insite zone inside their platform in our datacenter wile the rest of the 
zone should be answered by the outside zone. 


Here's our config


named.conf:

options {
directory "/named/dns01.somecustomer.de/";

query-source address x.x.x.x port *;
listen-on port 53 { x.x.x.x; };

pid-file "log/named.pid";
allow-query { any; };
minimal-responses yes;
version "";
statistics-file "log/stats";
max-cache-size 1000M;
clients-per-query 25;
};

view "MESA_live" {

match-clients { any; };

response-policy {
zone "myrpz-rpz";  
};

empty-zones-enable yes;
empty-server "blackhole.easynet.de";
empty-contact "admin.easynet.com";

zone "com" {
type delegation-only;
};

zone "net" {
type delegation-only;
};

zone "myrpz-rpz" {
type master;
file "conf/myrpz-rpz";
allow-query { none; };
};
}


view "MCS_compact" {

...
};




myrpz-rpz:

$TTL 43200
@   IN  SOA a.prim-ns.de.   hostmaster.de.easynet.net.   (
2012041802  ;
28800   ;
7200;
604800  ;
1200;
)

IN  NS  localhost.

subdomain.domain.de  60 A   172.26.30.231





The above setting is rewriting NXDOMAIN answers for subdomain.domain.de to the 
above IP address while every other host still has the information of the 
customers outside zone.

Am I doing something substantially wrong here RPZ wise?



Ciao
Torsten
___
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 can cause excessive amount of _dns-sd queries?

[Torsten Segner]

Am Thu, 23 Aug 2012 13:43:32 +0200
schrieb "Eivind Olsen" :

> Hello.
> 
> I haven't seen this before.. I'm currently seeing someone (1 ip address)
> do about 2.1 million queries / hour where a majority of the queries seem
> to be:
> 
> b._dns-sd._udp.0.129.16.172.in-addr.arpa IN PTR +
> db._dns-sd._udp.0.129.16.172.in-addr.arpa IN PTR +
> r._dns-sd._udp.0.129.16.172.in-addr.arpa IN PTR +
> talk.l.google.com IN A +
> gmail-pop.l.google.com IN A +
> gmail-imap.l.google.com IN A +
> 
> ...and similar variations of these.
> 
> Have any of you seen something like this before?
> 


Hi Eivind,

these seem to be DNS Service Discovery requests and yes, we see loads of them 
on our servers.


http://files.dns-sd.org/draft-cheshire-dnsext-dns-sd.txt



Ciao
Torsten
___
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 can i start and stops bind service using named command

[Torsten Segner]

Am Thu, 8 Mar 2012 10:10:04 +0300
schrieb mustafa alhussona :

> hi
> i have bind9.9.0 installed manually now i want to start the service using
> the command named i used named -fg to start it and it works, now how i can
> stop it the man named page is encrypted and the options of this command are
> not clear, i dont have bind9 script , i want to start the named services in
> the background, stop it and restart the service is there any way to do
> that,
> 
> thanks best regards

rndc stop
___
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: dnssec-keygen not responding

[Torsten Segner]

Am Wed, 30 Nov 2011 09:40:44 +0100
schrieb Adam Tkac :

> On Wed, Nov 30, 2011 at 12:18:04AM -0500, Alan Clegg wrote:
> > On 11/30/2011 12:15 AM, vishesh kumar wrote:
> > > Hi All
> > > 
> > > I am trying to generate keys for signing vishesh.com
> > >  domain using following command (for testing purpose)
> > > 
> > > dnssec-keygen -a RSASHA1 -b 768 -n ZONE vishesh.com .
> > > 
> > > But its not responding , i waited around 30 minutes but there is no result
> > > 
> > > Operating system is RHEL6 on VirtualBox 4.1
> > 
> > You don't have enough entropy in the virtual environment.  You can (if
> > you understand the issues surrounding it), use /dev/urandom as your
> > random source, or look at installing something like haveged
> > (http://freecode.com/projects/haveged) to solve the problem.
> 
> Another good solution is to pass "-r keyboard" to dnssec-keygen.
> 
> Regards, Adam
> 

In RHEL there is a RPM package called unuran. 
It's a random number generator daemon using either a piece of hardware or 
/dev/urandom as source. Running this will provide enough entropy to create lots 
of keys.
___
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: Port number in A record in zone file

[Torsten Segner]

Am Thu, 17 Nov 2011 14:46:45 +0100
schrieb Aleksander Kurczyk :

> Hello,
> Yesterday I asked here how can I run multiple named processes on different 
> ports in one OS. Now I have some troubles with that. How can I specify the 
> port number in zone file A record?
> 


There is a simple answer: You can't.

An A record consists of only an IPv4 address.



Ciao
Torsten



> My config and zone files:
> 
> 095160160157:/var/named root# cat srv1/named.conf
> options {
> directory "/var/named/srv1";
> version "olo-dns-server-1.0";
> allow-transfer { 127.0.0.1; };
> allow-recursion { 127.0.0.1; };
> listen-on 127.0.0.1 port 2001;
> };
> 
> zone "srv1.local" IN {
> type master;
> file "srv1.local.master";
> };
> 
> zone "srv2.local" IN {
> type slave;
> file "srv2.local.slave";
> };
> 
> zone "srv3.local" IN {
> type slave;
> file "srv3.local.slave";
> };
> 
> zone "." IN {
> type hint;
> file "named.ca";
> };
> 
> zone "localhost" IN {
> type master;
> file "localhost.zone";
> allow-update { none; };
> };
> 
> zone "0.0.127.in-addr.arpa" IN {
> type master;
> file "named.local";
> allow-update { none; };
> };
> 
> 
> 095160160157:/var/named root# cat srv1/srv1.local.master 
> $TTL 1d
> $ORIGIN srv1.local.
> @   IN  SOA ns1 hostmaster 201700 12h 5m 3w 2h
> IN  NS  ns1
> IN  NS  ns2
> IN  NS  ns3
> ns1 IN  A   127.0.0.1<<-- port 2001
> ns2 IN  A   127.0.0.1<<-- port 2002
> ns3 IN  A   127.0.0.1<<-- port 2003
> 11  IN  A   192.168.1.11
> 12  IN  A   192.168.1.12
> 13  IN  A   192.168.1.13
> 
> 
> 095160160157:/var/named root# cat srv2/named.conf
> options {
> directory "/var/named/srv2";
> version "olo-dns-server-1.0";
> allow-transfer { 127.0.0.1; };
> allow-recursion { 127.0.0.1; };
> listen-on 127.0.0.1 port 2002;
> };
> 
> zone "srv1.local" IN {
> type slave;
> file "srv1.local.slave";
> };
> 
> zone "srv2.local" IN {
> type master;
> file "srv2.local.master";
> };
> 
> zone "srv3.local" IN {
> type slave;
> file "srv3.local.slave";
> };
> 
> zone "." IN {
> type hint;
> file "named.ca";
> };
> 
> zone "localhost" IN {
> type master;
> file "localhost.zone";
> allow-update { none; };
> };
> 
> zone "0.0.127.in-addr.arpa" IN {
> type master;
> file "named.local";
> allow-update { none; };
> };
> 
> 
> 095160160157:/var/named root# cat srv2/srv2.local.master
> $TTL 1d
> $ORIGIN srv2.local.
> @   IN  SOA ns1 hostmaster 201700 12h 5m 3w 2h
> IN  NS  ns1
> IN  NS  ns2
> IN  NS  ns3
> ns1 IN  A   127.0.0.1<<-- port 2001
> ns2 IN  A   127.0.0.1<<-- port 2002
> ns3 IN  A   127.0.0.1<<-- port 2003
> 11  IN  A   192.168.1.11
> 12  IN  A   192.168.1.12
> 13  IN  A   192.168.1.13
> 
> 
> 095160160157:/var/named root# cat srv3/named.conf
> options {
> directory "/var/named/srv3";
> version "olo-dns-server-1.0";
> allow-transfer { 127.0.0.1; };
> allow-recursion { 127.0.0.1; };
> listen-on 127.0.0.1 port 2003;
> };
> 
> zone "srv1.local" IN {
> type slave;
> file "srv1.local.slave";
> };
> 
> zone "srv2.local" IN {
> type slave;
> file "srv2.local.slave";
> };
> 
> zone "srv3.local" IN {
> type master;
> file "srv3.local.master";
> };
> 
> zone "." IN {
> type hint;
> file "named.ca";
> };
> 
> zone "localhost" IN {
> type master;
> file "localhost.zone";
> allow-update { none; };
> };
> 
> zone "0.0.127.in-addr.arpa" IN {
> type master;
> file "named.local";
> allow-update { none; };
> };
> 
> 
> 095160160157:/var/named root# cat srv3/srv3.local.master
> $TTL 1d
> $ORIGIN srv3.local.
> @   IN  SOA ns1 hostmaster 201700 12h 5m 3w 2h
> IN  NS  ns1
> IN  NS  ns2
> IN  NS  ns3
> ns1 IN  A   127.0.0.1<<-- port 2001
> ns2 IN  A   127.0.0.1<<-- port 2002
> ns3 IN  A   127.0.0.1<<-- port 2003
> 11  IN  A   192.168.1.11
> 12  IN  A   192.168.1.12
> 13  IN  A   192.168.1.13
> 
> 

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

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

Re: allow-transfer not covering ixfr requests?

[Torsten Segner]

Am Tue, 27 Sep 2011 22:03:44 +0200
schrieb "Tom Schmitt" :

> 
> > 
> > The odd part is that both NS3 and NS4 weren't able to request ixfr
> > transfers. 
> > Shouldn't allow-transfer cover these kind of transfer requests as well?
> > 
> 
> 
> First: Do you have statements "provide ixfr;" and "request ixfr;" in your 
> config?
> 
> Second: To do a ixfr a server is first sending a query for the SOA of the 
> zone to determine if a update is necessary. If your servers aren't allowed to 
> do a query, how should they get the SOA? And without a SOA, you don't have 
> the serial number of the zone, so you can't do IXFR.
> 


Silly me... I forgot about the SOA requests triggered by a manual ixfr. :(


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

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

allow-transfer not covering ixfr requests?

[Torsten Segner]

I recently observered a rather strange phaenomenon.
By accident I have configured a nameserver to allow queries from NS1 and NS2 
and allow transfers from NS3 und NS4.
So far so good... 
Naturally NS1 and NS2 could do all kinds of queries but no zone transfers.

NS3 and NS4 weren't allowed to ask anything but were able to request axfr 
transfers.

The odd part is that both NS3 and NS4 weren't able to request ixfr transfers. 
Shouldn't allow-transfer cover these kind of transfer requests as well?


Ciao
Torsten


PS: All nameservers are running on a self-compiled 9.8.1
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Problems with nic.it

[Torsten Segner]

Am Tue, 20 Sep 2011 09:20:12 +0200
schrieb Lucio Crusca :

> Hello *,
> 
> I'm new here though I've been using bind for about 10 years. I've just 
> transferred a domain under the .it TLD for the first time.
> 
> Here in Italy we have nic.it that regulates the .it domain names 
> registrations 
> and transfers.
> 
> The domain transfer went ok, and now I have access to the control panel of 
> the 
> domain where I can set the NS records. I'd like to set those NS records to a 
> Linux box running bind9 (9.7.0.dfsg.P1-1ubuntu0.3).
> 
> However nic.it is refusing to change the NS records, because the new 
> receiving 
> nameservers are failing some automatic checks nic.it performs before changing 
> the NS records. My hosting provider (the one where I transferred the domain) 
> should tell me exactly what checks are failing, but, being the first time I 
> have such problems, I don't know how long they will take to give me those 
> informations. I've waited for 4 days until now. Hence I wonder if there 
> existed any public DNS checker that could check a DNS which is not the NS 
> pointed server yet, so that I could check the new DNS myself before 
> submitting 
> a new NS record change and going through the hassle of waiting nic.it 
> automated checks, eventual failure and assistance from my hosting provider.
> 


Hi Lucio,

Registry dns checks can be somewhat tricky at time.
These are the tests performed by Registro.it


3.1.2.6 Checking the functionality of the nameserver
The verification phase of the configuration of the nameservers associated with 
the domain
name takes place after the registration of the domain name itself in the 
Registry Database.
The procedure for the control of nameservers analyzes the hosts associated with 
domain
names registered in the Registry Database that are in inactive/dnsHold and 
executes the
appropriate query (i.e. queries to the nameserver) to verify that it is 
actually operative. In
particular:

- there must be at least 2 (two) authoritative nameservers for the domain name, 
and
they must correspond exactly to those found in the registration of the domain 
name;

- the IP addresses of hosts in the registration of the domain name must 
correspond to
those actually associated with them in the DNS;

- the domain name cannot be associated with a CNAME record;

- the name of the nameserver specified in the SOA record for the domain name 
cannot
be a CNAME;

- the names of the authoritative nameservers for the domain name cannot be
CNAMEs;

- if there is an MX registration it cannot be associated with a CNAME;

- if, during the checking procedure, at least one nameserver returns the 
following
responses:
o Not responding
o Not reachable
o Not running
o Non-existent domain
o Host not found
o Server failure
o Query failed
the procedure returns an error;

- all hosts in the registration must be authoritative for the domain name 
registered.



Hopefully this will help.


Ciao
Torsten
___
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: CVE-2011-1910 vs bind 9.6-ESV-R4-P3

[Torsten Segner]

Am Wed, 3 Aug 2011 11:25:07 +0200
schrieb Issam Harrathi :

> Hi all,
> when i see this about the affected version by the CVE-2011-1910: 9.6: 9.6.3,
> 9.6-ESV-R2, -R3, -R4, -R5b1
> does this mean that the 9.6-ESV-R4-P1 is affected?
> 
> Thanks.
> Issam Harrathi.


No, because 9.6-ESV-R4-P1 is a patch for this bug.


Ciao
Torsten
___
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: DNS Caching Issue

[Torsten Segner]

Am Mon, 25 Jul 2011 08:22:00 -0600
schrieb "Sathyan Arjunan (sarjunan) [CONTRACTOR]" :

> Recent days, I am facing frequent caching issues with my DNS servers
> which are responsible for recursive lookup to external queries. As a
> temporary solution, we used to refresh the named daemon to clear the
> cache. To isolate this issue we upgraded the BIND to "BIND 9.7.3" but
> even after the upgrade issue repeats. 
> 
>  
> 
> If I do a nslookup for "mail.sin.gpi-g.com", it fails. 
> 
>  
> 
> nslookup mail.sin.gpi-g.com
> Server: dnsserver
> 
> Address:x.x.x.x#53
> 
>  
> 
> ** server can't find mail.sin.gpi-g.com: SERVFAIL
> 
>  
> 
> To fix this I have to restart the named daemon in caching DNS server.
> Once I restart, the lookup resolves well. However the issue appears
> again in few days. Any thoughts?
> 
>  
> 
> nslookup mail.sin.gpi-g.com
> 
> Server: dnsserver
> 
> Address:x.x.x.x#53
> 
>  
> 
> Non-authoritative answer:
> 
> Name:   mail.sin.gpi-g.com
> 
> Address: 203.175.163.180
> 
>  
> 
> Regards,
> 
> --Sathyan
> 



One of the authoritative nameservers (nameserver2.gpi-g.com / 202.182.61.51) is 
not responding properly.
You should ask the administrator (r...@gpi-g.com) of the server to fix this.


Ciao
Torsten
___
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: MX choosing

[Torsten Segner]

Am Fri, 22 Jul 2011 16:50:35 +0800
schrieb Feng He :

> Given the MX hosts for sympatico.ca domain:
> 
> $ dig sympatico.ca mx +short
> 5 mxmta.sympatico.ca.
> 
> $ dig mxmta.sympatico.ca +short
> 67.69.240.17
> 67.69.240.24
> 67.69.240.22
> 67.69.240.23
> 67.69.240.21
> 67.69.240.20
> 67.69.240.19
> 67.69.240.18
> 
> 
> when the peer MTA fail to talk to one of these hosts,will it try the
> next one? or it just give up?
> 
> Thanks.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users



Since there's no fallback MX the MTA will try once and then store the mail for 
a later retry (depends on how your MTA is configured).
Since the TTL of mxmta.sympatico.ca is just 1800 seconds there might be a good 
chance that your MTA will try another server unless the next try is within 1800 
seconds (where it will just reuse the already cached one) or your bad luck 
provides you with the not working IP address again.


Ciao
Torsten
___
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: Wild cards in zone file

[Torsten Segner]

Am Tue, 24 May 2011 09:55:19 +0100
schrieb John Kennedy :

> I tried to google this but could not hit the right keywords (been a long
> week)...
> 
> I have 3 hosts on a domain (example.com) like so:
> 
> int.project   A   10.10.10.2
> stage.project   A  10.10.10.3
> test.project A   10.10.10.4
> 
> Now I want everything else to go to 10.10.10.5
> *.project A   10.10.10.5
> 
> Is this possible?
> 
> Thanks,
> John
> 


Yes, just add the wildcard record to the zone and it will work.


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

Re: slave AXFR bind9

[Torsten Segner]

My first thoughts on this:

Has the slave received a notify from the master server?
Does the slave accept the notify?
What else is in the logs?

Could you please also provide your named configuration (options and the zone 
statement) of both master and slave?


Ciao
Torsten



Am Thu, 21 Apr 2011 06:55:13 +
schrieb hugo hugoo :

> 
> Dear all,
> I am really lost with the working of my slave zone.
> Here the situation/configuration.
>  
>  
> I use a server called "lenny" where the zone is idendified as slave.
> I use a server called custmaster where the zone is master.
>  
> After a stop/start of the BIND9 in the Lenny server (slave zone), the slave 
> zone is never synchronised with the master zone.
> In my test, the serial number in the master is greater than in the slave.
>  
> 
> 
> lennydnstest01:~# dig @194.78.73.65 bind9testcarlos.be AXFR  è what is on 
> the master zone (dig use the IP address of the  master)
>  
> ; <<>> DiG 9.6-ESV-R3 <<>> @194.78.73.65 bind9testcarlos.be AXFR
> ; (1 server found)
> ;; global options: +cmd
> bind9testcarlos.be. 86400   IN  SOA ns1.skynet.be. 
> dnsmaster.skynet.be. 1999101725 600 3600 604800 86400
> bind9testcarlos.be. 86400   IN  NS  ns.uat.
> bind9testcarlos.be. 86400   IN  NS  ns2.uat.
> ns.bind9testcarlos.be.  3600IN  A   1.2.3.4
> ns2.bind9testcarlos.be. 3600IN  A   1.2.3.4
> sgtest1.bind9testcarlos.be. 3600 IN A   1.2.3.30
> cs1.sgtest1.bind9testcarlos.be. 3600 IN A   1.2.3.4
> bind9testcarlos.be. 86400   IN  SOA ns1.skynet.be. 
> dnsmaster.skynet.be. 1999101725 600 3600 604800 86400
> ;; Query time: 5 msec
> ;; SERVER: 194.78.73.65#53(194.78.73.65)
> ;; WHEN: Wed Apr 20 14:03:20 2011
> ;; XFR size: 8 records (messages 1, bytes 250)
>  
> dnscustmaster901:/etc/bind/zones/master# cat bind9testcarlos.be   
>==> master zone file
> $TTL 3600;Positive Caching
> bind9testcarlos.be.  86400   IN SOA  ns1.skynet.be.  dnsmaster.skynet.be. 
>(
>  1999101725 ; Serial
>  600  ; Refresh
>  3600   ; Retry
>  604800 ; Expire
>  86400 ); Negative Caching
>  
> bind9testcarlos.be.  86400   IN  NS ns.uat.
> bind9testcarlos.be.  86400   IN  NS ns2.uat.
> cs1.sgtest1.bind9testcarlos.be.  3600IN  A   1.2.3.4 
> ns.bind9testcarlos.be.   3600IN  A   1.2.3.4
> ns2.bind9testcarlos.be.  3600IN  A   1.2.3.4 
> sgtest1.bind9testcarlos.be.  3600IN  A   1.2.3.30
>  
>  
> lennydnstest01:~# dig @localhost bind9testcarlos.be AXFR è what is on the 
> slave zone
>  
> ; <<>> DiG 9.6-ESV-R3 <<>> @localhost bind9testcarlos.be AXFR
> ; (2 servers found)
> ;; global options: +cmd
> bind9testcarlos.be. 86400   IN  SOA ns1.skynet.be. 
> dnsmaster.skynet.be. 1999101723 600 3600 604800 86400
> bind9testcarlos.be. 86400   IN  NS  ns.uat.
> bind9testcarlos.be. 86400   IN  NS  ns2.uat.
> ns.bind9testcarlos.be.  3600IN  A   1.2.3.4
> ns2.bind9testcarlos.be. 3600IN  A   1.2.3.4
> sgtest1.bind9testcarlos.be. 3600 IN A   1.2.3.20
> cs1.sgtest1.bind9testcarlos.be. 3600 IN A   1.2.3.4
> bind9testcarlos.be. 86400   IN  SOA ns1.skynet.be. 
> dnsmaster.skynet.be. 1999101723 600 3600 604800 86400
> ;; Query time: 3 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Wed Apr 20 14:03:21 2011
> ;; XFR size: 8 records (messages 1, bytes 250)
>  
>  
> ennydnstest01:~# cat /etc/bind/zones/slave/bind9testcarlos.be==> slave 
> zone file
> $ORIGIN .
> $TTL 86400  ; 1 day
> bind9testcarlos.be  IN SOA  ns1.skynet.be. dnsmaster.skynet.be. (
> 1999101723 ; serial
> 600; refresh (10 minutes)
> 3600   ; retry (1 hour)
> 604800 ; expire (1 week)
> 86400  ; minimum (1 day)
> )
> NS  ns.uat.
> NS  ns2.uat.
> $ORIGIN bind9testcarlos.be.
> $TTL 3600   ; 1 hour
> ns  A   1.2.3.4
> ns2 A   1.2.3.4
> sgtest1 A   1.2.3.20
> $ORIGIN sgtest1.bind9testcarlos.be.
> cs1 A   1.2.3.4
>  
>  
>  
>  
> After a reload zonefile (not working with "rndc reload")   ==> AXFR is done!
>  
> lennydnstest01:~# rndc reload bind9testcarlos.be
> zon

Re: rndc: 'reload' failed: not found

[Torsten Segner]

This usually happens when your nameserver isn't configured for the zone to be 
reloaded.


Ciao
Torsten



Am Tue, 8 Mar 2011 14:47:02 +0800
schrieb "ShanyiWan" :

> Cent OS+BIND 9.7.3+DLZ(BDB as backend)
> 
> # rndc reload 2mysite.net
> rndc: 'reload' failed: not found
> 
> "rndc reload" not work correctly,why?
>   
> --
> ShanyiWan
> 2011-03-08
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

Re: Bind not returning A record

[Torsten]

N:
;www.kwsp.gov.my.   IN  A

;; ANSWER SECTION:
www.kwsp.gov.my.43200   IN  CNAME   www.yu.kwsp.gov.my.

;; Query time: 360 msec
;; SERVER: 202.184.117.10#53(202.184.117.10)
;; WHEN: Wed Dec 22 15:15:21 2010
;; MSG SIZE  rcvd: 54



dig +norec @ns3.pttcdc.com.my www.yu.kwsp.gov.my a

; <<>> DiG 9.7.2-P3-RedHat-9.7.2-4.P3.fc14 <<>> +norec @ns3.pttcdc.com.my 
www.yu.kwsp.gov.my a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58486
;; flags: qr ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;www.yu.kwsp.gov.my.IN  A

;; ANSWER SECTION:
www.yu.kwsp.gov.my. 20  IN  A   202.162.21.166

;; Query time: 361 msec
;; SERVER: 202.184.117.10#53(202.184.117.10)
;; WHEN: Wed Dec 22 15:12:20 2010
;; MSG SIZE  rcvd: 52



dig +norec @ns3.pttcdc.com.my yu.kwsp.gov.my ns

; <<>> DiG 9.7.2-P3-RedHat-9.7.2-4.P3.fc14 <<>> +norec @ns3.pttcdc.com.my 
yu.kwsp.gov.my ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21431
;; flags: qr ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;yu.kwsp.gov.my.IN  NS

;; ANSWER SECTION:
yu.kwsp.gov.my. 43200   IN  NS  ns1.yu.kwsp.gov.my.
yu.kwsp.gov.my. 43200   IN  NS  ns2.yu.kwsp.gov.my.

;; ADDITIONAL SECTION:
ns1.yu.kwsp.gov.my. 43200   IN  A   202.162.21.163
ns2.yu.kwsp.gov.my. 43200   IN  A   211.25.56.211

;; Query time: 360 msec
;; SERVER: 202.184.117.10#53(202.184.117.10)
;; WHEN: Wed Dec 22 15:14:39 2010
;; MSG SIZE  rcvd: 100



Ciao
Torsten



> > 
> > Lyle Giese
> > LCR Computer Services, Inc.
> > 
> > ___
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Rules against links or certain links?

[Torsten]

Do you refer to this posting?

Am Thu, 11 Nov 2010 07:35:51 -0500
schrieb "Lightner, Jeff" :

> +2 on this - I use the Linux based whois every time I need to search a
> domain.   Also there are some web sites that you can use for this
> general kind of search such as:
> http://www.iptools.com/



Ciao
Torsten



Am Thu, 11 Nov 2010 09:07:19 -0500
schrieb "Lightner, Jeff" :

> I've noticed a couple of times on this list that if I post links for
> certain on line sites with free tools like whois that they never seem
> to make it to the list.
> 
>  
> 
> Is there some prohibition against posting those links that would cause
> them to be filtered out?  I know at least one of them also has pay
> services but it does provide free services including whois.  Today I
> specifically didn't post that one but another one that (so far as I
> know) is all free yet it hasn't appeared here either.
> 
>  
> 
> 
> __
> 
> Jeff Lightner | UNIX/Linux Administrator | DS Waters of America, Inc |
> 5660 New Northside Drive, Ste 250 | Atlanta, GA 30328 
> *: (Direct Dial) 770-486-3516 |*: (Cell) 678-772-0018 |
> *:jlight...@water.com
>  
> Proud partner. Susan G. Komen for the Cure.
>  
> Please consider our environment before printing this e-mail or
> attachments. --
> CONFIDENTIALITY NOTICE: This e-mail may contain privileged or
> confidential information and is for the sole use of the intended
> recipient(s). If you are not the intended recipient, any disclosure,
> copying, distribution, or use of the contents of this information is
> prohibited and may be unlawful. If you have received this electronic
> transmission in error, please reply immediately to the sender that
> you have received the message in error, and delete it. Thank you.
> --
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Could DNS help solve this?

[Torsten]

Ian was propably talking about jwhois which is part of almost all Linux
distibutions.
This whois client "automagically" selects the correct whois server for
you. It comes with a configuration file with lots of known tld => whois
server pairs. For .com/.net domains it selects the whois server by
first asking whois.internic.net. 

Maybe you should give it a try


Ciao
Torsten


Am Thu, 11 Nov 2010 09:59:25 +0100
schrieb Sten Carlsen :

> Hi
> 
> Yes, I do use whois, my problem is which of the many dozens of whois
> servers to ask.
> 
> E.g. if you want to know who owns telephone.com(random example), do
> you ask whois.moniker.com, whois.markmonitor.com, whois.enum.com
> or ???.
> 
> If you don't know who to ask, it can take maybe 20 attempts before you
> find a whois server tha gives some helpful info. In some cases looking
> at the NS records helps
> 
> Somebody put up the whois.uwhois.net, but that rarely gives an answer.
> 
> How do you determine where to ask?
> 
> 
> On 11/11/10 4:07, Ian Manners wrote:
> > Hi Sten,
> >
> >> With the growing number of registrars of e.g. .com domains, it
> >> becomes difficult or even almost impossible to figure out which
> >> whois server you should ask for information about a domain name.
> > Use Whois (first under the 'Other software:' heading) from
> > the command prompt.
> >
> > <http://www.linux.it/~md/software/>
> >
> > Even compiles ok under OS/2.
> >
> > Cheers
> > Ian Manners
> > http://www.os2site.com/
> >
> > ___
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: How to get easily (from a script) all CNAME of a A record?

[Torsten]

Am Wed, 10 Nov 2010 01:49:08 +0100
schrieb Michelle Konzack :

> Hello Torsten,
> 
> Am 2010-11-09 15:46:05, hacktest Du folgendes herunter:
> > Maybe it's easier to get a dump with rndc dumpdb -zones and then run
> > the grep on the dump file.
> 
> Ehm, but AFAIK the dumpfiles are the same as the orginal zone  files
> in /etc/bind or do I something missing?
> 
> Thanks, Greetings and nice Day/Evening
> Michelle Konzack
> 


That's true... but grepping a single file is a lot faster than grepping
80k files one by one.


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

Re: How to get easily (from a script) all CNAME of a A record?

[Torsten]

Am Tue, 9 Nov 2010 15:14:04 +0100
schrieb Michelle Konzack :

> Hello Matus UHLAR - fantomas,
> 
> Am 2010-11-09 14:13:47, hacktest Du folgendes herunter:
> > I am not sure whether dnswalk over whole internet can do that, but
> > on your
> 
> I will try it...
> 
> > server you can either run recursive grep over named data directory,
> > or dump the named dsatabase and grep it...
> 
> This is what I currently do...
> 
> [ '/usr/sbin/get_hosts_in
> cname' ]-- #!/bin/sh
> 
> QUERY="$1"
> 
> for FILE in $(cd /etc/bind && ls *.signed)
> do
>   grep --regexp=" IN CNAME .*${QUERY}" /etc/bind/${FILE} 2>/dev/null
> |cut -d ' ' -f1 |sed 's|.$||' done
> 
> 
> ...and it is to slow do to more then  80.000  Zones  (they  have  to
> be greped all) number of VHosts.
> 
> Oh, it is now time to use "xargs", because I saw today, that I  hit
> the limits for "ls".  :-D
> 
> Following is working:
> cd /etc/bind && ls
> 
> but not:
> cd /etc/bind && ls *
> or
> cd /etc/bind && ls *.signed
> 
> and the OSes are called Linux and BSD...  WTF?
> 
> It seems that a commandline can not have more then 31.000 characters.
> (no not options but total lenght)
> 
> Thanks, Greetings and nice Day/Evening
> Michelle Konzack
> 

Maybe it's easier to get a dump with rndc dumpdb -zones and then run
the grep on the dump file.


Ciao
Torsten

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

Re: Logging SERVFAIL Errors

[Torsten]

You have to set a debug level of at least 1 to capture SERVFAIL errors
in your logfile.


Ciao
Torsten


Am Fri,  8 Oct 2010 09:09:16 -0500 (CDT)
schrieb b19...@anl.gov (Barry Finkel):

> On BIND 9.7.1-P2 I have in named.conf:
> 
>  channel query-errors-log {
>  file "/var/log/named.query-errors.log" versions 3 size
> 200k; print-category yes;
>  print-severity yes;
>  print-time yes;
>  severity info;
>  };
> 
>  category query-errors { query-errors-log; };  // no
> default_syslog
> 
> Is this correct for logging queries that produce SERVFAIL?
> 
> I ran this query on the DNS server:
> 
> dns# dig klyuniv.ernet.in @t1dns2.anl.gov
> 
> ; <<>> DiG 9.7.1-P2 <<>> klyuniv.ernet.in @t1dns2.anl.gov
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 7278
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;klyuniv.ernet.in.  IN  A
> 
> ;; Query time: 1860 msec
> ;; SERVER: 130.202.101.37#53(130.202.101.37)
> ;; WHEN: Fri Oct  8 09:06:04 2010
> ;; MSG SIZE  rcvd: 34
> 
> dns# 
> 
> and there is nothing logged in
> 
>  /var/log/named.query-errors.log
> 
> Am I doing something wrong?  Thanks.
> --
> Barry S. Finkel
> Computing and Information Systems Division
> Argonne National Laboratory  Phone:+1 (630) 252-7277
> 9700 South Cass Avenue   Facsimile:+1 (630) 252-4601
> Building 240, Room 5.B.8 Internet: bsfin...@anl.gov
> Argonne, IL   60439-4828 IBMMAIL:  I1004994
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Verizon Users Can't See Site

[Torsten]

Am Tue, 14 Sep 2010 05:15:16 + (UTC)
schrieb cybers...@comcast.net:

> 
> 
> 
> Hello List, 
> 
> 
> 
> I've run into an issue that has me stumped for the time being. I'm
> working on a website that is hosted on a delegated subdomain. The
> site is www-mbclive.mbc.irides.com. The mbc.irides.com subdomain is
> delegated to two Barracuda load balancers known as
> dns1.mbc.irides.com and dns2.mbc.irides.com. 
> 
> 
> 
> DNS seems to work fine for the majority of our users, however, in the
> past week we've heard from many Verizon FIOS users that they are
> unable to visit the site due to resolution issues. One sent in a dig
> from his home computer and I was wondering why he doesn't receive an
> answer: 
> 
> 
> 
> scott$ dig @71.252.0.12 www-mbclive.mbc.irides.com 
> 
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> @71.252.0.12
> www-mbclive.mbc.irides.com ; (1 server found) 
> ;; global options: +cmd 
> ;; Got answer: 
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62184 
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 
> 
> ;; QUESTION SECTION: 
> ;www-mbclive.mbc.irides.com.    IN  A 
> 
> ;; AUTHORITY SECTION: 
> www-mbclive.mbc.irides.com. 10  IN  SOA dns1.mbc.irides.com.
> 1. 3600 3600 3600 3600 3600 
> 
> ;; Query time: 20 msec 
> ;; SERVER: 71.252.0.12#53(71.252.0.12) 
> ;; WHEN: Mon Sep 13 21:31:08 2010 
> ;; MSG SIZE  rcvd: 86 
> 
> 
> 
> Can anyone tell if there is a DNS issue on our end that may cause us
> to not play nice w/ Verizon? This issue just popped up in the last
> two weeks. Prior to that time visitors were not complaining. Any
> assistance is greatly appreciated. 
> 

I'm having troubles getting an answer from both dns1.mbc.irides.com and
dns2.mbc.irides.com for www-mbclive.mbc.irides.com.

A dig query freezes for about 12 seconds before returning an answer.
Maybe there's a problem with a misconfigured firewall.

[...@localhost ~]$ traceroute -q 1 dns2.mbc.irides.com
traceroute to dns2.mbc.irides.com (209.252.251.240), 30 hops max, 60
byte packets 1  10.43.64.254 (10.43.64.254)  0.336 ms
 2  vl67.cr30.isham.de.easynet.net (194.64.6.252)  0.927 ms
 3  ge1-5.br2.isham.de.easynet.net (194.64.4.126)  0.695 ms
 4  ge3-0-2.gr10.isham.de.easynet.net (87.86.71.244)  0.632 ms
 5  te2-0-0.gr10.ixfra.de.easynet.net (87.86.77.95)  9.862 ms
 6  ge-5-1-4.edge3.frankfurt1.level3.net (212.162.40.77)  9.964 ms
 7  vlan79.csw2.Frankfurt1.Level3.net (4.68.23.126)  18.392 ms
 8  ae-72-72.ebr2.Frankfurt1.Level3.net (4.69.140.21)  10.387 ms
 9  ae-41-41.ebr2.washington1.level3.net (4.69.137.50)  98.620 ms
10  ae-5-5.ebr2.washington12.level3.net (4.69.143.222)  101.159 ms
11  ae-6-6.ebr2.chicago2.level3.net (4.69.148.146)  113.618 ms
12  ae-22-52.car2.chicago2.level3.net (4.69.138.165)  115.322 ms
13  paetec-comm.car2.chicago2.level3.net (4.71.250.34)  115.955 ms
14  gi-3-1-0.core01.chcgil01.paetec.net (66.155.191.97)  139.525 ms
15  po-4-0-0.core02.rochny01.paetec.net (64.80.253.217)  137.915 ms
16  gi-6-0-0.edge02.rochny01.paetec.net (66.155.216.183)  140.368 ms
17  *
18  *
19  *
20  *
21  *
22  *
23  *
24  *
25  *
26  *
27  *
28  *
29  *
30  *



Ciao
Torsten


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

Re: Clarification about DNS notify

[Torsten]

Am Fri, 10 Sep 2010 12:51:11 +0530
schrieb Sherin George :

> Hey Guys,
> 
> I have an issue which need some help.
> 
> I have two master DNS servers, say A & B.
> 
> A is running freebsd & B is running centos. B is running BIND 9 also.
> Now, I want to add one more to this cluster say C.
> 
> I have installed centos in C with BIND 9. Now, I have copied
> /etc/named.conf & /var/name from B to C. Now I restarted named in C.
> Everything worked.
> 
> Now, I have a question which may be quite simple, but I couldn't find
> an answer even after lot of googling. So, I would be extremely
> grateful for any advice you could offer.
> 
> When I restarted named in C, I could see that C is sending DNS
> notifications and B is receiving it
> 
> from /var/log/messages in C:
> 
> "Sep  9 23:53:44 serverC named[11844]: zone example.com/IN: sending
> notifies (serial 2005030401)"
> 
> from /var/log/messages in B:
> 
> Sep 9  23:53:44 serverB named[30375]: client XX.XX.XX.XX#54546:
> received notify for zone 'example.com'
> 
> I checked  /etc/named.conf and I couldn't see any particular reason
> for C choosing to notify B.
> 
> Any explanation to this behavior or a link to any relevant guide will
> be helpful.
> 

Sharing your current configuration would help in helping you with your
problem. ;)

A wild guess would be that you're missing a "notify no" or "notify
master-only" option on your slave servers.


Ciao
Torsten

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

Re: new IPs for our name servers problems

[Torsten]

Am Thu, 12 Aug 2010 12:58:54 +0300
schrieb Michael Dilworth :

> hi
> 
> many thanks for the help and apologies for my ignorance. The parent
> zone here would be the .com ? how does one go about updating the
> delegation in this?
> 
> mike

You need to contact your registrar (Register.com) to do this for you
(unless they provide you with an end-customer self-provisioning
interface).


Ciao
Torsten

> 
> 
> On Thu, Aug 12, 2010 at 12:50 PM, Matus UHLAR - fantomas
> wrote:
> 
> > On 12.08.10 12:40, Michael Dilworth wrote:
> > > We are in the process of moving our address space from a PA block
> > > to a PI block.  This means I have had to use 2 new IPs for our
> > > name servers.
> > >
> > > the old address space was 89.221.36.0/24 and the new address
> > > space is 91.213.52.0/24
> > >
> > > the old name servers we on 89.221.36.20 and 89.221.36.30  I have
> > > now
> > updated
> > > the records and we use
> > >
> > > ns1.upstreamsystems.com on 91.213.52.20
> > > ns2.upstreamsystems.com on 91.213.52.30
> >
> > % dig any upstreamsystems.com @a.gtld-servers.net
> > [...]
> > ;; AUTHORITY SECTION:
> > upstreamsystems.com.172800  IN  NS
> > ns1.upstreamsystems.com. upstreamsystems.com.172800  IN
> > NS  ns2.upstreamsystems.com.
> >
> > ;; ADDITIONAL SECTION:
> > ns1.upstreamsystems.com. 172800 IN  A   89.221.36.20
> > ns2.upstreamsystems.com. 172800 IN  A   89.221.36.30
> >
> >
> > you must update the delegation in parentzone as well
> > --
> > 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.
> > 10 GOTO 10 : REM (C) Bill Gates 1998, All Rights Reserved!
> > ___
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> >
> 
> 
> 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Protecting bind from DNS cache poisoning!!!

[Torsten]

Am Mon, 09 Aug 2010 14:08:26 +0200
schrieb Wolfgang Solfrank :

> >>> Allow bind to use as wide a range of port numbers as possible for
> >>> UDP traffic.
> >
> > On 09.08.10 17:14, Shiva Raman wrote:
> >> Yes this is allowed in the firewall.
> >
> > note that bind also should not have "port" potion in query-source
> > statement.
> 
> In addition, be carefull with the use of NAT on your firewall.  This
> will probably unrandomize the port numbers on your outgoing requests.
> 
> Ciao,
> Wolfgang


Port deviation could easily be tested via porttest.dns-oarc.net

dig +short @127.0.0.1 porttest.dns-oarc.net txt
porttest.y.x.w.v.u.t.s.r.q.p.o.n.m.l.k.j.i.h.g.f.e.d.c.b.a.pt.dns-oarc.net.
"195.180.9.198 is GREAT: 53 queries in 9.1 seconds from 53 ports with
std dev 19687"


Every result other than "GREAT" should alert you.


Also, checking wether DNSSEC is working or not, send a recursing querie
to your resolver and check the returned flags for ad.


[t...@daddelkiste ~]$ dig +dnssec @127.0.0.1 iis.se a

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> +dnssec @127.0.0.1
iis.se a ; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12422
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;iis.se.IN  A

;; ANSWER SECTION:
iis.se. 21  IN  A
212.247.7.218 iis.se.   21  IN
RRSIG   A 5 2 60 20100815115001 20100805115001 53249 iis.se.
pWMYsqufhD4RkHX6IltLOcxMob3rNpc1+UnXZKgOMsO5HgbtIjALoq9+
ReqKziKev3PiEBLNdqrxT95TVlzVb7qgnLmlHABsap7m2uzuHFQKsFmh
RGxqpiuzu9bPEIfZKout4TmzILaP1Nua4ntSXyyjS35EUszfX+F/Mqrm fcc=

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug  9 14:35:37 2010
;; MSG SIZE  rcvd: 217



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

Re: new webserver ip

[Torsten]

Am Tue, 03 Aug 2010 08:07:58 -0400
schrieb dhottin...@harrisonburg.k12.va.us:

> My employer decided to host our website on another server off-site.   
> My problem is getting our dns to point from our old server to the
> new. Currently we own all the ip's and host our own website.  Here is
> the zone file for harrisonburg.k12.va.us:
> 
> 
> $ORIGIN .
> $TTL 259200 ; 3 days
> harrisonburg.k12.va.us IN SOA ns1.harrisonburg.k12.va.us.  
> rlineweaver.harrisonburg.k12.va.us. (
>  201080503 ; serial
>  28800  ; refresh (8 hours)
>  7200   ; retry (2 hours)
>  2419200; expire (4 weeks)
>  86400  ; minimum (1 day)
>  )
>  NS  ns1.harrisonburg.k12.va.us.
>  NS  ns2.harrisonburg.k12.va.us.
> $TTL 144000 ; 40 hours
> harrisonburg.k12.va.us. MX  10
> plum.harrisonburg.k12.va.us. mail.harrisonburg.k12.va.us.MX
> 10  plum.harrisonburg.k12.va.us. student.harrisonburg.k12.va.us.
> MX  10  plum.harrisonburg.k12.va.us. harrisonburg.k12.va.us. IN
> TXT "v=spf1 ip4:204.111.40.0/24 a:mail.harrisonburg.k12.va.us
> a:student.harrisonburg.k12.va.us ~all" $ORIGIN harrisonburg.k12.va.us.
> $TTL 259200; 3 days
> harrisonburg.k12.va.us. A   174.143.193.47
> 
> 
> I made the entry for the new website's ip (174.143.193.47).  But
> when I do a dig, it still comes back with 204.111.40.10.  What do I
> need to do in order to get this ip to point to the newserver
> offsite?  Or is it even possible for me to do this?
> 
> ddh
> 


It's just a wild guess but I think you've 'malformed' your serial. ;)
>From the looks it should propably be 2010080503 and not 201080503 which
is considerably lower than it should be.


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

Re: Signed root - missing RRSIG for delegation?

[Torsten]

Am Fri, 16 Jul 2010 12:25:44 +0200
schrieb Niobos :

> Hi,
> 
> It's probably just my lack of knowledge, but there seems to be a
> missing RRSIG in the root zone.
> 
> I try to securely resolve example.net. I obviously get a delegation
> returned (dig output below), but I can't seem to validate that
> delegation. The delegation itself (and a direct request for net./NS)
> only yield an RRSIG over the NSEC RRset, not over the NS RRset and not
> over the glue A-records (which are in bailiwick, and I have "no other
> way" to resolve them)
> 
> Can anyone clarify?
> 
> thx,
> Niobos
> 

You're asking the root servers for example.net. They only know .net
though and thus give you a list of nameservers responsible for .net.

But even if you'd asked a validating resolver instead of one of the
root servers, there wouldn't be a validatable answer as there's no
delegation signer for .net in the root yet.


Ciao
Torsten

> 
> $ dig @l.root-servers.net. +dnssec example.net. A
> 
> ; <<>> DiG 9.6.0-APPLE-P2 <<>> @l.root-servers.net. +dnssec
> example.net. A ; (2 servers found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1174
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 15, ADDITIONAL: 16
> ;; WARNING: recursion requested but not available
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;example.net. IN  A
> 
> ;; AUTHORITY SECTION:
> net.  172800  IN  NS
> a.gtld-servers.net. net.  172800
> INNS  b.gtld-servers.net. net.
> 172800IN  NS  c.gtld-servers.net.
> net.  172800  IN  NS
> d.gtld-servers.net. net.  172800
> INNS  e.gtld-servers.net. net.
> 172800IN  NS  f.gtld-servers.net.
> net.  172800  IN  NS
> g.gtld-servers.net. net.  172800
> INNS  h.gtld-servers.net. net.
> 172800IN  NS  i.gtld-servers.net.
> net.  172800  IN  NS
> j.gtld-servers.net. net.  172800
> INNS  k.gtld-servers.net. net.
> 172800IN  NS  l.gtld-servers.net.
> net.  172800  IN  NS
> m.gtld-servers.net. net.  86400
> INNSECnf. NS RRSIG NSEC net.
> 86400 IN  RRSIG   NSEC 8 1 86400 2010072200
> 2010071423 41248 .
> XNB4appdNqmX630pa76WvD7nVhSqz908XQ2DXxLUB2q6VeMsVVPnYppg
> 5w7zStc5DSFboylq9XeJJXrYJcGmLo9llWj2WNkRa/X4TfGm0P4s1zC5
> BDAzvbTYm2KbUv88b3TzZzIxmyyCMWbo8sY+ihJckmkpftg5LAVcU9B6 Ajs=
> 
> ;; ADDITIONAL SECTION:
> a.gtld-servers.net.   172800  IN  A   192.5.6.30
> b.gtld-servers.net.   172800  IN  A
> 192.33.14.30 c.gtld-servers.net.  172800  IN
> A 192.26.92.30 d.gtld-servers.net.172800
> INA   192.31.80.30 e.gtld-servers.net.
> 172800IN  A   192.12.94.30
> f.gtld-servers.net.   172800  IN  A
> 192.35.51.30 g.gtld-servers.net.  172800  IN
> A 192.42.93.30 h.gtld-servers.net.172800
> INA   192.54.112.30 i.gtld-servers.net.
> 172800IN  A   192.43.172.30
> j.gtld-servers.net.   172800  IN  A
> 192.48.79.30 k.gtld-servers.net.  172800  IN
> A 192.52.178.30 l.gtld-servers.net.   172800
> INA   192.41.162.30 m.gtld-servers.net.
> 172800IN  A   192.55.83.30
> a.gtld-servers.net.   172800  IN  
> 2001:503:a83e::2:30 b.gtld-servers.net.   172800
> IN2001:503:231d::2:30
> 
> ;; Query time: 69 msec
> ;; SERVER: 199.7.83.42#53(199.7.83.42)
> ;; WHEN: Fri Jul 16 12:21:13 2010
> ;; MSG SIZE  rcvd: 711
> 
> 
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: R: Does bind send email?

[Torsten]

Am Fri, 9 Jul 2010 15:09:24 +0200
schrieb "Chiesa Stefano" :

> A couple of details:
> 
> * bind is working fine and on the server the Task Manager shows just
> one named.exe process ("show processes from all users" checked)
> * I don't' think McAfee is triggering on MX lookups because he's
> blocking connection on port 25  (look at the end of log line:
> 187.58.17.194:25)
> 
> 08/06/201023.31.191094
> C:\bind\bin\named.exe Protezione antivirus standard:Impedisci
> a worm distribuiti tramite mass-mailing di inviare messaggi
> 187.58.17.194:25


Just being curious... where did you download your bind package? Was it
directly from ISC or some other site?


Ciao
Torsten

> 
> Regards.
> Stefano.
> 
> -Messaggio originale-
> Da: bind-users-bounces+stefano.chiesa=wki...@lists.isc.org
> [mailto:bind-users-bounces+stefano.chiesa=wki...@lists.isc.org] Per
> conto di Phil Mayers Inviato: venerdì 9 luglio 2010 14.23 A:
> bind-users@lists.isc.org Oggetto: Re: Does bind send email?
> 
> On 09/07/10 12:18, tomasz dereszynski wrote:
> 
> >
> > check below link
> > apparently viruses (some) hide themselves behind that name/process.
> > http://www.file.net/process/named.exe.html
> >
> > mind you, it might be something else ...
> >
> 
> Maybe McAfee is triggering on MX lookups?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: cname chain limit

[Torsten]

Am Fri, 9 Jul 2010 15:08:20 +0530
schrieb rams :

> Hi ,
> 
> What is the cname chains limit ?
> 
> Thanks & Regards,
> Ramesh


I've managed to get 17 cnames into a chain returned by dig. named-checkzone 
wouldn't mind additional cnames though. In my example zone I've put 100 cnames 
into a chain without any complains.


[t...@daddelkiste conf]# dig @127.0.0.1 cname-1.test a

; <<>> DiG 9.6.2-P2-RedHat-9.6.2-5.P2.fc12 <<>> @127.0.0.1 cname-1.test a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59028
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cname-1.test.  IN  A

;; ANSWER SECTION:
cname-1.test.   43200   IN  CNAME   cname-2.test.
cname-2.test.   43200   IN  CNAME   cname-3.test.
cname-3.test.   43200   IN  CNAME   cname-4.test.
cname-4.test.   43200   IN  CNAME   cname-5.test.
cname-5.test.   43200   IN  CNAME   cname-6.test.
cname-6.test.   43200   IN  CNAME   cname-7.test.
cname-7.test.   43200   IN  CNAME   cname-8.test.
cname-8.test.   43200   IN  CNAME   cname-9.test.
cname-9.test.   43200   IN  CNAME   cname-10.test.
cname-10.test.  43200   IN  CNAME   cname-11.test.
cname-11.test.  43200   IN  CNAME   cname-12.test.
cname-12.test.  43200   IN  CNAME   cname-13.test.
cname-13.test.  43200   IN  CNAME   cname-14.test.
cname-14.test.  43200   IN  CNAME   cname-15.test.
cname-15.test.  43200   IN  CNAME   cname-16.test.
cname-16.test.  43200   IN  CNAME   cname-17.test.
cname-17.test.  43200   IN  CNAME   cname-18.test.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jul  9 12:55:50 2010
;; MSG SIZE  rcvd: 413



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

Re: Negative Cache won't go!

[Torsten]

Hmm... where to start...


First, the authoritative nameservers for the domain klawrojna.com don't
even exist.


dig +norec @j.gtld-servers.net klawrojna.com ns

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-10.P2.fc13 <<>> @j.gtld-servers.net 
klawrojna.com ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54332
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

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

;; AUTHORITY SECTION:
klawrojna.com.  172800  IN  NS  ns1.klawrojna.com.
klawrojna.com.  172800  IN  NS  ns2.klawrojna.com.

;; ADDITIONAL SECTION:
ns1.klawrojna.com.  172800  IN  A   69.64.77.15
ns2.klawrojna.com.  172800  IN  A   69.64.77.15

;; Query time: 264 msec
;; SERVER: 192.48.79.30#53(192.48.79.30)
;; WHEN: Tue Jul  6 08:32:49 2010
;; MSG SIZE  rcvd: 99



dig +norec @69.64.77.15 ns1.klawrojna.com a

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-10.P2.fc13 <<>> +norec @69.64.77.15 
ns1.klawrojna.com a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 46455
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;ns1.klawrojna.com. IN  A

;; AUTHORITY SECTION:
klawrojna.com.  10800   IN  SOA ns.klawrojna.com. a.a.org. 
1274650868 10800 3600 604800 10800

;; Query time: 166 msec
;; SERVER: 69.64.77.15#53(69.64.77.15)
;; WHEN: Tue Jul  6 08:35:26 2010
;; MSG SIZE  rcvd: 81



The only existing NS Record in the zone is ns.klawrojna.com which will
never be asked directly because it's not known by any nameservers up to
this point.


A +trace doesn't really work since the last response you get is
from one of the gtld root servers.



dig +trace www.klawrojna.com

; <<>> DiG 9.7.0-P2-RedHat-9.7.0-10.P2.fc13 <<>> +trace www.klawrojna.com
;; global options: +cmd
.   28185   IN  NS  l.root-servers.net.
.   28185   IN  NS  k.root-servers.net.
.   28185   IN  NS  d.root-servers.net.
.   28185   IN  NS  a.root-servers.net.
.   28185   IN  NS  i.root-servers.net.
.   28185   IN  NS  c.root-servers.net.
.   28185   IN  NS  b.root-servers.net.
.   28185   IN  NS  m.root-servers.net.
.   28185   IN  NS  g.root-servers.net.
.   28185   IN  NS  h.root-servers.net.
.   28185   IN  NS  j.root-servers.net.
.   28185   IN  NS  e.root-servers.net.
.   28185   IN  NS  f.root-servers.net.
;; Received 257 bytes from 10.43.3.1#53(10.43.3.1) in 2 ms

com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
;; Received 498 bytes from 2001:500:3::42#53(l.root-servers.net) in 163 ms

klawrojna.com.  172800  IN  NS  ns1.klawrojna.com.
klawrojna.com.  172800  IN  NS  ns2.klawrojna.com.
;; Received 103 bytes from 192.55.83.30#53(m.gtld-servers.net) in 348 ms

;; connection timed out; no servers could be reached




The main reason it's working is because all of those nameservers share
the same IP (69.64.77.15). This is okay as long as this
nameserver isn't misbehaving (returning servfails or whatever else).



Ciao
Torsten



Am Mon, 5 Jul 2010 22:01:56 +0300
schrieb "Alans" :

> BE CARFUL: my antivirus detects certain .png files on that website as
> potential viruses, please don't open it in the browser.
> The Website is: www.klawrojna.com Again, be careful.
> 
> Thanks,
> Alans
> 
> -Original Message-
> From: bind-users-bounces+batpower83=yahoo.co...@lists.isc.org
> [mailto:bind-users-bounces+batpower83=yahoo.co...@lists.isc.org] On
> Behalf Of Tor

Re: Negative Cache won't go!

[Torsten]

Am Mon, 5 Jul 2010 09:17:06 +0300
schrieb "Alans" :

> Hi everyone,
> 
> There is a website that was returning servfail but works fine with
> +trace. AFAIK, negative cache default value is 3 hrs, and I haven't
> set max-ncache-ttl, also domain owner says he used default TTL in his
> zone files.
> I waited for 1 day and the website didn't work till I restarted named.
> Also I used rndc flushname domainname.com (with and without www.).
> 
> Is there any other way to solve this issue without restarting named?
> And any clue why named isn't purging it?
> I'm using Bind v9.4.2 on Centos 5.2.
> 
> Regards, 
> Alans
> 


Which domain are you talking about?


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

Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((

[Torsten]

Am Wed, 23 Jun 2010 11:01:29 +0200
schrieb Erwin Lansing :

> On Wed, Jun 23, 2010 at 05:51:24PM +1000, Mark Andrews wrote:
> > 
> > In message
> > ,
> > Piff writes:
> > > Mark,
> > > 
> > > more than once you have blamed firewal but I have tested without
> > > firewall and NSxx.DOMAINCONTROL.COM do not answer to "dig
> > > +dnssec".
> > 
> > Wrong.  The nameserver DO answer these queries.
> 
> Right, unfortunately.  All is fine on a freshly reloaded bind, but
> after a while no answers are seen.  This is on Bind 9.4, 9.5 and 9.6.
> > 
> > # dig +dnssec @ns33.domaincontrol.com. replacementservices.com.
> > 
> > ; <<>> DiG 9.3.6-P1 <<>> +dnssec @ns33.domaincontrol.com.
> > replacementservices.com. ; (1 server found)
> > ;; global options:  printcmd
> > ;; Got answer:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41760
> > ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 0
> > 
> > ;; QUESTION SECTION:
> > ;replacementservices.com.   IN  A
> > 
> > ;; ANSWER SECTION:
> > replacementservices.com. 3600   IN  A   72.32.12.235
> > 
> > ;; AUTHORITY SECTION:
> > replacementservices.com. 3600   IN  NS
> > ns33.domaincontrol.com. replacementservices.com. 3600   IN
> > NS  ns34.domaincontrol.com.
> > 
> > ;; Query time: 346 msec
> > ;; SERVER: 216.69.185.17#53(216.69.185.17)
> > ;; WHEN: Wed Jun 23 17:39:43 2010
> > ;; MSG SIZE  rcvd: 109
> > 
> > # 
> 
> # dig +dnssec @ns33.domaincontrol.com. replacementservices.com.
> 
> ; <<>> DiG 9.6.1-P3 <<>> +dnssec @ns33.domaincontrol.com.
> replacementservices.com.
> ; (1 server found)
> ;; global options: +cmd
> ;; connection timed out; no servers could be reached
> 
> > 
> > Since you are not getting answers then there is a problem between
> > you and the nameservers in question and as just about every one
> > else is getting answers as well this puts the problem close to you.
> > i.e. Your network or your ISP's network.  Something on the path is
> > doing DPI tests and is rejecting the response.  Do you have a NAT
> > that does DPI?
> 
> No firewall, DPI, NAT or any form of filtering involved on our side,
> direct peering with GLBX.
> 
> -erwin
> 

Since it's working quite okay for several locations on here, the
problem may be found somewhere in between sites.

I personally don't get any failures with the dig statement from above
no matter how often I try.

Looking at a tracepath the last hop I see seems to be an edge router of
AboveNet Communications.


tracepath ns33.domaincontrol.com
 1:  eve.the-damian.de (195.180.9.245)  0.132ms
pmtu 1500
 1:  vl100.cr20.isham.de.easynet.net (195.180.9.252)0.888ms 
 1:  vl100.cr20.isham.de.easynet.net (195.180.9.252)0.830ms 
 2:  ge1-1.br2.isham.de.easynet.net (212.224.4.90)  0.857ms 
 3:  ge3-0-2.gr10.isham.de.easynet.net (87.86.71.244)   0.762ms 
 4:  te0-0-0-0.er10.ixfra.de.easynet.net (87.86.77.247)10.931ms
asymm  7 
 5:  xe-1-2-0.mpr1.fra4.de.above.net (80.81.194.26)10.407ms
asymm  7 
 6:  xe-1-1-0.mpr1.cdg12.fr.above.net (64.125.24.6)22.851ms 
 7:  xe-4-0-0.mpr1.lhr3.uk.above.net (64.125.31.249)   28.677ms
asymm  9 
 8:  so-0-1-0.mpr2.dca2.us.above.net (64.125.27.165)   98.858ms
asymm  9 
 9:  xe-0-3-0.cr2.dca2.us.above.net (64.125.29.25)102.567ms
asymm 10 
10:  xe-0-1-0.er2.dca2.us.above.net (64.125.27.29) 98.730ms
asymm 11 
11:  xe-1-1-0.er2.iad10.above.net (64.125.26.242)  99.116ms
asymm 13 
12:  no reply
13:  no reply
14:  no reply
15:  no reply
16:  no reply
17:  no reply
18:  no reply
19:  no reply
20:  no reply
21:  no reply
22:  no reply
23:  no reply
24:  no reply
25:  no reply
26:  no reply
27:  no reply
28:  no reply
29:  no reply
30:  no reply
31:  no reply
 Too many hops: pmtu 1500
 Resume: pmtu 1500 




Ciao
Torsten

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

Re: Running both a cache-only and an authoritative server on the same server

[Torsten]

Am Thu, 17 Jun 2010 08:43:32 -0500
schrieb Peter Laws :

> On 06/17/10 08:36, Torsten wrote:
> > Am Thu, 17 Jun 2010 13:35:38 +0100
> > schrieb Phil Mayers:
> >
> >> On 17/06/10 12:39, Jørn Skjerven wrote:
> 
> >>> Is it possible to achieve this in a single named.conf, or is it
> >>> recommended to run two instances of bind, each with a different
> >>> listen-on  statement?
> >>
> >> Sure. Use views:
> >>
> >> view authoritative {
> >> recursion no;
> >> match-destinations { mycurrentip; };
> >> zone ...
> >> };
> >>
> >> view authoritative {
> >> recursion yes;
> >> match-destinations { myrecurseip; };
> >> };
> >
> >
> >
> > The important part seems to be "on a secondary IP" and afaik
> > listen-on statements don't work inside of view statements.
> 
> 
> Why not just have named run on as many interfaces as needed and let
> views sort it out?  Views don't need to care which physical interface
> traffic is on.
> 
> 
> 

You're right... I totally forgot about match-destination and
match-recursive-only when I wrote my last message.


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

Re: Running both a cache-only and an authoritative server on the same server

[Torsten]

Am Thu, 17 Jun 2010 13:35:38 +0100
schrieb Phil Mayers :

> On 17/06/10 12:39, Jørn Skjerven wrote:
> > Hi!
> >
> > I've tried to search the archive for for this, but could not find
> > anything relevant.
> >
> > We currently run a server with an authoritative set for domains. We
> > want to use the same server as a cache-only DNS for other customers
> > as well.
> >
> > Is it possible to achieve this in a single named.conf, or is it
> > recommended to run two instances of bind, each with a different
> > listen-on  statement?
> 
> Sure. Use views:
> 
> view authoritative {
>recursion no;
>match-destinations { mycurrentip; };
>zone ...
> };
> 
> view authoritative {
>recursion yes;
>match-destinations { myrecurseip; };
> };



The important part seems to be "on a secondary IP" and afaik listen-on
statements don't work inside of view statements.

That leaves you with running two seperate instances of Bind on the same
server.


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

Re: odd behaviour on caching ns with views

[Torsten]

Am Sun, 13 Jun 2010 14:45:22 -0700
schrieb JINMEI Tatuya / 神明達哉 :

> At Tue, 8 Jun 2010 11:03:55 +0200,
> Torsten  wrote:
> 
> > Everything works perfectly okay except queries for
> > 1.0.0.127.in-addr.arpa and 0.0.0.0.in-addr.arpa. These are refused
> > by the caching server (denied entries in default log).
> > Asking those queries on an identical server without views returns
> > the usual NXDOMAIN answer.
> > 
> > Is there something special about 0.in-addr.arpa and
> > 127.in-addr.arpa in views I haven't seen yet?
> 
> That sounds like something related to builtin "empty zones".  But I
> have no idea how the existence/non-existence of views affects the
> behavior.  That may be due to your separate configuration file:
> 
>   include "/named/default/private_netblocks.conf";
> 
> and showing the content of this file may help.
> 

Oh... sorry, that file should have been in the original post.
It contains forwardings for RFC1918 net blocks to our own blackhole
instances, since we had some problems with the generally available
servers located in Amsterdam in the past.

zone "10.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "16.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "17.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "18.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "19.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "20.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "21.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "22.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "23.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "24.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "25.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "26.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "27.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "28.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "29.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "30.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "31.172.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};

zone "168.192.in-addr.arpa" {
type forward;
forwarders { 195.180.210.154; 195.180.210.130; };
};



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

odd behaviour on caching ns with views

[Torsten]

Hi,

I've observed an odd behaviour in one of our customers caching
nameservers (running an ISC 9.6.1-P3 installation on a RHEL5.4 box).

The server uses views for different parts of the customer environment:

options { 
directory "/named/custenv/"; 

query-source address 10.10.3.22 port *; 
listen-on port 53 { 10.10.3.22; }; 

pid-file "log/named.pid"; 
allow-query { any; }; 
minimal-responses yes;
version "you should know"; 
statistics-file "log/stats"; 
max-cache-size 1000M; 
}; 

acl "transfer" { 10.230.0.123; }; 

view "transfer" { 

match-clients { "transfer"; }; 

include "/named/default/private_netblocks.conf";

zone "com" { 
type delegation-only; 
}; 

zone "net" { 
type delegation-only; 
}; 

zone "3.10.10.in-addr.arpa" { 
type forward; 
forwarders { 194.163.252.5; 195.180.210.23; }; 
}; 

zone "230.10.in-addr.arpa" { 
type forward; 
forwarders { 194.163.252.5; 195.180.210.23; }; 
}; 

zone "content" { 
type forward; 
forwarders { 10.230.43.200; 10.230.43.201; }; 
}; 

zone "isilon-nfs" {
type forward;
forwarders { 10.230.0.250; };
};
}; 

view "prod" { 

match-clients { any; }; 

include "/named/default/private_netblocks.conf";

zone "com" { 
type delegation-only; 
}; 

zone "net" { 
type delegation-only; 
}; 

zone "3.10.10.in-addr.arpa" { 
type forward; 
forwarders { 194.163.252.5; 195.180.210.23; }; 
}; 


zone "230.10.in-addr.arpa" { 
type forward; 
forwarders { 194.163.252.5; 195.180.210.23; }; 
};

zone "isilon-nfs" {
type forward;
forwarders { 10.230.0.250; };
}; 
};




Everything works perfectly okay except queries for
1.0.0.127.in-addr.arpa and 0.0.0.0.in-addr.arpa. These are refused by
the caching server (denied entries in default log).
Asking those queries on an identical server without views returns the
usual NXDOMAIN answer.

Is there something special about 0.in-addr.arpa and 127.in-addr.arpa in
views I haven't seen yet?


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

Re: Dnssec zone signing problem

[Torsten]

Am Fri, 21 May 2010 09:35:31 -0400
schrieb "Sergiu Bivol" :

> We were invoking the dnssec-signzone tool once with each key. We'd
> start by signing with KSK, then sign with ZSK. When we upgraded to
> 9.6.2-P1, dnssec-signzone started failing with errors when signing
> with KSK: ---
> Verifying the zone using the following algorithms: RSASHA1.
> no signatures for example.com/NSEC
> no signatures for example.com/SOA
> no signatures for example.com/NS
> no signatures for subzone.example.com/NSEC
> no signatures for subzone.example.com/A
> ---
> 
> Then we tried signing with both KSK and ZSK at the same time, but got
> some other error (no self signed KSK found). Without spending more
> time on this we found a workaround - to disable post signing
> validation with the newly introduced paratmeter "-P".
> 


Hmm... dnssec-signzone (version 9.7.0-P1) seems to work perfectly well:

dnssec-signzone -k Kexample.com.+008+53749.key -N INCREMENT -g -o
example.com example.com Kexample.com.+008+41979 
Verifying the zone using the following algorithms: RSASHA256. 
Zone signing complete:
Algorithm: RSASHA256: KSKs: 1 active, 0 stand-by, 0 revoked 
      ZSKs: 1 active, 1 stand-by, 0 revoked 
example.com.signed



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

Re: Misconfigured slave?

[Torsten]

Am Thu, 29 Apr 2010 10:33:37 +0200
schrieb Claes Gyllenswärd :

> Hello bind-users
> 
> I have recently set up my first two BIND-instances, and I believe that
> I have gotten things nearly right, but something is amiss.
> "Internetstiftelsen", handles the TLD .se, and they have a self-test
> one can run on ones DNS's before actually using them. Running this
> test, it returns a number of errors:
> 
> 1) You only have 1 DNS

There is only one working NS in your zonefile (ns1.letharion.se). 

> 2) Glue for DNS-server ns1.letharion.se differs between child and
> parent zone. This is a configuration problem that should be corrected.

According to the .se nameservers the authoritative Nameservers for
letharion.se should be:

letharion.se.   604800  IN NS ns3.everlast.se.
letharion.se.   604800  IN NS ns1.everlast.se.
letharion.se.   604800  IN NS ns2.everlast.se.

> 3) I can find no adress for SLAVE_IP.letharion.se. Incorrect hostname
> or adress for SLAVE_IP.letharion.se.

There's no A record for a host slave_ip in your zone file.

In case you're using acl's for MY_IP and SLAVE_IP, those are not
working within a zone file.

> Below are what I believe to be the relevant configuration files. I
> have used sed to replace the ip-adresses of both servers,
> which verified that all ip have been typed in correctly. I also
> removed any logging for brevity.
> 
> I will appreciate any input on what I have done wrong.
> 
> Master config:
> options {
>     directory "/var/bind";
>     listen-on-v6 { none; };
>     listen-on port 53 { 127.0.0.1; MY_IP; };
>     pid-file "/var/run/named/named.pid";
> };
> view "external" {
>     match-clients { any; };
>     recursion no;
>     zone "." IN {
>     type hint;
>     file "named.ca";
>     };
>     zone "127.in-addr.arpa" IN {
>     type master;
>     file "pri/127.zone";
>     allow-update { none; };
>     notify no;
>     };
>     zone "letharion.se" {
>     type master;
>     file "pri/letharion.se.external";
>     allow-query { any; };
>     allow-transfer { SLAVE_IP; };
>     };
> };
> Zonefile:
> $TTL 2d
> @  IN SOA   ns1.letharion.se. ADMIN.letharion.se. (
>    10042601 ;serial
>    3h ;refresh
>    1h ;retry
>    1w ;expiry
>    1d )  ;minimum
> 
> letharion.se.    IN MX 0 mail.letharion.se.
> letharion.se.    IN TXT   "v=spf1 ip4:MY_IP/32 mx ptr
> mx:mail.letharion.se ~all"
> letharion.se.    IN NS ns1.letharion.se.
> letharion.se.    IN NS SLAVE_IP
> www.letharion.se.    IN A  MY_IP
> ns1.letharion.se.    IN A  MY_IP
> mail.letharion.se.   IN A  MY_IP
> 
> Slave config:
> options {
>     directory "/var/bind";
>     listen-on-v6 { none; };
>     listen-on port 53 { 127.0.0.1; SLAVE_IP; };
>     pid-file "/var/run/named/named.pid";
> };
> 
> view "external" {
>     match-clients { any; };
>     recursion no;
>     zone "." IN {
>     type hint;
>     file "named.ca";
>     };
>     zone "127.in-addr.arpa" IN {
>     type master;
>     file "pri/127.zone";
>     allow-update { none; };
>     notify no;
>     };
>     zone "letharion.se" {
>     type slave;
>     file "pri/letharion.se.external.bak";
>     allow-query { any; };
>     masters { MY_IP; };
>     };
> };
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: one record to be redirected to a specific IP

[Torsten]

Am Mon, 26 Apr 2010 11:30:26 +0200
schrieb Sten Carlsen :

> I wonder if the following could be done:
> 
> - make the zone for www.abcd.com, which would also redirect the
> "anything else" part.
> - delegate the "anything else" back to its original owner.
> 
> like:
> 
> www.abcd.com.   soa 
> @ IN   A1.2.3.4
> *   NS
> 
> I am not sure this could work? I am not sure how this redelegation
> would be seen by the original servers of the zone?
> 


Bind would refuse to load that zone since a wildcard can't have NS
records.


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

Re: Resolving .gov w/dnssec

[Torsten]

Am Thu, 22 Apr 2010 10:03:43 -0400 (EDT)
schrieb Paul Wouters :

> On Thu, 22 Apr 2010, Timothe Litt wrote:
> 
> > I'm having trouble resolving uspto.gov with bind 9.6.1-P3 and
> > 9.6-ESV configured as valdidating resolvers.
> >
> > Using dig, I get a connection timeout error after a long (~10 sec)
> > delay. +cdflag provides an immediate response.
> 
> > Is anyone else seeing this?  Ideas on how to troubleshoot?
> 
> I have the same problems with our validating unbound instance. The
> logs show:
> 

Maybe something went wrong in the key-rollover process. Queries
for DS, DNSKEY and NSEC get a reply with the ad flag set. All other
records fail.


Ciao
Toto

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

Re: strange behaviour of resolving nameserver

[Torsten]

Am Wed, 10 Mar 2010 08:34:41 +0100
schrieb Torsten :

> Am Wed, 10 Mar 2010 08:36:54 +1100
> schrieb Mark Andrews :
> 
> > 
> > In message <20100309154017.4801c...@the-damian.de>, Torsten writes:
> > > Am Wed, 10 Mar 2010 00:44:46 +1100
> > > schrieb Mark Andrews :
> > > 
> > > > 
> > > > In message <20100309142153.016c7...@the-damian.de>, Torsten
> > > > writes:
> > > > > Hi,
> > > > > 
> > > > > I'm a bit clueless about what's happening here exactly.
> > > > > I have a server (9.6.1-P3) that tries resolving
> > > > > ws.mobilecdn.verisign.com. Queries for this host permanently
> > > > > fail with SERVFAIL.
> > > > > 
> > > > > I've narrowed the problem down to answers from c2.nstld.net 
> > > > > 
> > > > > 
> > > > > dig @c2.nstld.com mobilecdn.verisign.com 
> > > > > ;; Got referral reply from 192.26.92.31, trying next server
> > > > 
> > > > Fix /etc/resolv.conf to point to recursive nameservers.
> > > > 192.26.92.31 is not a recursive nameserver.
> > > 
> > > /etc/resolv.conf already points to recursive nameservers. Since
> > > these nameservers can't resolve ws.mobilecdn.verisign.com I tried
> > > every single nameserver found by dig +trace and ended up with the
> > > behaviour of c2.nstld.net.
> > 
> > I mis-read.  192.26.92.31 is c2.nstld.net so someone at RedHat has
> > hacked dig to return " ;; Got referral reply from 192.26.92.31,
> > trying next server" when it see a referral and move onto the next
> > address which is a IPv6 addresss which presumably you don't have
> > connectivity for.
> > 
> > Try "dig -4 @c2.nstld.com mobilecdn.verisign.com".  Then yell at
> > RedHat.  Dig is not supposed to move on when it sees a referral.
> > Dig is a diagnostic tool first and foremost, not a general hostname
> > lookup tool.  One needs to see the answers to queries in a
> > diagnostic tool not have them skipped.
> > 
> 
> Hmm... you're right. Using the self compiled dig doesn't return the
> referral notice.
> 
> Still I'm not sure why named can't resolve the hostname and always
> breaks with a servfail. Shouldn't it just skip servers which ran into
> a timeout and try the next (even though this might take a bit longer
> to resolve)?
> 
> 
> Anyway, there must have been some sort of error somewhere 'cause now
> resolving is working perfectly fine again.
> 
> 



It happened again... only this time, I have network packets of working
queries and those answered with servfail by the local resolver.

What I've done:
I've flushed the cache, made a dig to the local resolver and at the
same time captured the network traffic.

The disturbing part about it is, that both times (those queries
resolving and those ending in a servfail) the last packet seen is an
answer packet from dns2.m-qube.com (64.14.96.64) and both look okay to
me. I wonder why named sometimes responds with a servfail and most of
the time not.


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

Re: strange behaviour of resolving nameserver

[Torsten]

Am Wed, 10 Mar 2010 08:36:54 +1100
schrieb Mark Andrews :

> 
> In message <20100309154017.4801c...@the-damian.de>, Torsten writes:
> > Am Wed, 10 Mar 2010 00:44:46 +1100
> > schrieb Mark Andrews :
> > 
> > > 
> > > In message <20100309142153.016c7...@the-damian.de>, Torsten
> > > writes:
> > > > Hi,
> > > > 
> > > > I'm a bit clueless about what's happening here exactly.
> > > > I have a server (9.6.1-P3) that tries resolving
> > > > ws.mobilecdn.verisign.com. Queries for this host permanently
> > > > fail with SERVFAIL.
> > > > 
> > > > I've narrowed the problem down to answers from c2.nstld.net 
> > > > 
> > > > 
> > > > dig @c2.nstld.com mobilecdn.verisign.com 
> > > > ;; Got referral reply from 192.26.92.31, trying next server
> > > 
> > > Fix /etc/resolv.conf to point to recursive nameservers.
> > > 192.26.92.31 is not a recursive nameserver.
> > 
> > /etc/resolv.conf already points to recursive nameservers. Since
> > these nameservers can't resolve ws.mobilecdn.verisign.com I tried
> > every single nameserver found by dig +trace and ended up with the
> > behaviour of c2.nstld.net.
> 
> I mis-read.  192.26.92.31 is c2.nstld.net so someone at RedHat has
> hacked dig to return " ;; Got referral reply from 192.26.92.31,
> trying next server" when it see a referral and move onto the next
> address which is a IPv6 addresss which presumably you don't have
> connectivity for.
> 
> Try "dig -4 @c2.nstld.com mobilecdn.verisign.com".  Then yell at
> RedHat.  Dig is not supposed to move on when it sees a referral.
> Dig is a diagnostic tool first and foremost, not a general hostname
> lookup tool.  One needs to see the answers to queries in a diagnostic
> tool not have them skipped.
> 

Hmm... you're right. Using the self compiled dig doesn't return the
referral notice.

Still I'm not sure why named can't resolve the hostname and always
breaks with a servfail. Shouldn't it just skip servers which ran into a
timeout and try the next (even though this might take a bit longer to
resolve)?


Anyway, there must have been some sort of error somewhere 'cause now
resolving is working perfectly fine again.


Ciao
Torsten


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

strange behaviour of resolving nameserver

[Torsten]

Hi,

I'm a bit clueless about what's happening here exactly.
I have a server (9.6.1-P3) that tries resolving
ws.mobilecdn.verisign.com. Queries for this host permanently fail with
SERVFAIL.

I've narrowed the problem down to answers from c2.nstld.net 


dig @c2.nstld.com mobilecdn.verisign.com 
;; Got referral reply from 192.26.92.31, trying next server

; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.1 <<>> @c2.nstld.com
mobilecdn.verisign.com ; (2 servers found)
;; global options:  printcmd
;; connection timed out; no servers could be reached


This happens only if the hostname is used in a dig. Using the ipv4
address everything turns out fine.


What's even more strange is the answer packet received (at least I
can't see any errors there).


No. TimeSourceDestination
Protocol Info 4 3.529927192.26.92.31  10.10.3.22
DNS  Standard query response

Frame 4 (140 bytes on wire, 140 bytes captured)
Arrival Time: Mar  9, 2010 13:33:49.987181000
[Time delta from previous captured frame: 0.086282000 seconds]
[Time delta from previous displayed frame: 0.086282000 seconds]
[Time since reference or first frame: 3.529927000 seconds]
Frame Number: 4
Frame Length: 140 bytes
Capture Length: 140 bytes
[Frame is marked: True]
[Protocols in frame: eth:ip:udp:dns]
[Coloring Rule Name: UDP]
[Coloring Rule String: udp]
Ethernet II, Src: Cisco_46:45:d3 (00:04:27:46:45:d3), Dst:
HewlettP_08:78:76 (00:1f:29:08:78:76) Destination: HewlettP_08:78:76
(00:1f:29:08:78:76) Address: HewlettP_08:78:76 (00:1f:29:08:78:76)
 ...0     = IG bit: Individual address
(unicast)  ..0.     = LG bit: Globally unique
address (factory default) Source: Cisco_46:45:d3 (00:04:27:46:45:d3)
Address: Cisco_46:45:d3 (00:04:27:46:45:d3)
 ...0     = IG bit: Individual address
(unicast)  ..0.     = LG bit: Globally unique
address (factory default) Type: IP (0x0800)
Internet Protocol, Src: 192.26.92.31 (192.26.92.31), Dst: 10.10.3.22
(10.10.3.22) Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
 00.. = Differentiated Services Codepoint: Default (0x00)
 ..0. = ECN-Capable Transport (ECT): 0
 ...0 = ECN-CE: 0
Total Length: 126
Identification: 0x (0)
Flags: 0x02 (Don't Fragment)
0.. = Reserved bit: Not Set
.1. = Don't fragment: Set
..0 = More fragments: Not Set
Fragment offset: 0
Time to live: 58
Protocol: UDP (0x11)
Header checksum: 0x1716 [correct]
[Good: True]
[Bad : False]
Source: 192.26.92.31 (192.26.92.31)
Destination: 10.10.3.22 (10.10.3.22)
User Datagram Protocol, Src Port: domain (53), Dst Port: 48885 (48885)
Source port: domain (53)
Destination port: 48885 (48885)
Length: 106
Checksum: 0x1190 [validation disabled]
[Good Checksum: False]
[Bad Checksum: False]
Domain Name System (response)
[Request In: 3]
[Time: 0.086282000 seconds]
Transaction ID: 0x3824
Flags: 0x8100 (Standard query response, No error)
1...    = Response: Message is a response
.000 0...   = Opcode: Standard query (0)
 .0..   = Authoritative: Server is not an authority
for domain  ..0.   = Truncated: Message is not truncated
 ...1   = Recursion desired: Do query recursively
  0...  = Recursion available: Server can't do
recursive queries   .0..  = Z: reserved (0)
  ..0.  = Answer authenticated: Answer/authority
portion was not authenticated by the server     = Reply
code: No error (0) Questions: 1
Answer RRs: 0
Authority RRs: 2
Additional RRs: 0
Queries
ws.mobilecdn.verisign.com: type A, class IN
Name: ws.mobilecdn.verisign.com
Type: A (Host address)
Class: IN (0x0001)
Authoritative nameservers
mobilecdn.verisign.com: type NS, class IN, ns
dns2-auth.m-qube.com Name: mobilecdn.verisign.com
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 15 minutes
Data length: 19
Name server: dns2-auth.m-qube.com
mobilecdn.verisign.com: type NS, class IN, ns
dns1-auth.m-qube.com Name: mobilecdn.verisign.com
Type: NS (Authoritative name server)
Class: IN (0x0001)
Time to live: 15 minutes
Data length: 12
Name server: dns1-auth.m-qube.com



Asking any of the other nameservers responsible for
verisign.com about mobilecdn.verisign.com works just fine and they all
return with a proper answer.

As a workaround I have set c2.nstld.net to bogus but I'm still unsure

Re: strange behaviour of resolving nameserver

[Torsten]

Am Wed, 10 Mar 2010 00:44:46 +1100
schrieb Mark Andrews :

> 
> In message <20100309142153.016c7...@the-damian.de>, Torsten writes:
> > Hi,
> > 
> > I'm a bit clueless about what's happening here exactly.
> > I have a server (9.6.1-P3) that tries resolving
> > ws.mobilecdn.verisign.com. Queries for this host permanently fail
> > with SERVFAIL.
> > 
> > I've narrowed the problem down to answers from c2.nstld.net 
> > 
> > 
> > dig @c2.nstld.com mobilecdn.verisign.com 
> > ;; Got referral reply from 192.26.92.31, trying next server
> 
> Fix /etc/resolv.conf to point to recursive nameservers.  192.26.92.31
> is not a recursive nameserver.

/etc/resolv.conf already points to recursive nameservers. Since these
nameservers can't resolve ws.mobilecdn.verisign.com I tried every
single nameserver found by dig +trace and ended up with the behaviour
of c2.nstld.net.

>  
> > ; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.1 <<>> @c2.nstld.com
> > mobilecdn.verisign.com ; (2 servers found)
> > ;; global options:  printcmd
> > ;; connection timed out; no servers could be reached
> > 
> > 
> > This happens only if the hostname is used in a dig. Using the ipv4
> > address everything turns out fine.
> > 
> > What's even more strange is the answer packet received (at least I
> > can't see any errors there).
> > 
> > 
> > No. TimeSourceDestination
> > Protocol Info 4 3.529927192.26.92.31  10.10.3.22
> > DNS  Standard query response
> > 
> > Frame 4 (140 bytes on wire, 140 bytes captured)
> > Arrival Time: Mar  9, 2010 13:33:49.987181000
> > [Time delta from previous captured frame: 0.086282000 seconds]
> > [Time delta from previous displayed frame: 0.086282000 seconds]
> > [Time since reference or first frame: 3.529927000 seconds]
> > Frame Number: 4
> > Frame Length: 140 bytes
> > Capture Length: 140 bytes
> > [Frame is marked: True]
> > [Protocols in frame: eth:ip:udp:dns]
> > [Coloring Rule Name: UDP]
> > [Coloring Rule String: udp]
> > Ethernet II, Src: Cisco_46:45:d3 (00:04:27:46:45:d3), Dst:
> > HewlettP_08:78:76 (00:1f:29:08:78:76) Destination: HewlettP_08:78:76
> > (00:1f:29:08:78:76) Address: HewlettP_08:78:76 (00:1f:29:08:78:76)
> >  ...0     = IG bit: Individual address
> > (unicast)  ..0.     = LG bit: Globally unique
> > address (factory default) Source: Cisco_46:45:d3 (00:04:27:46:45:d3)
> > Address: Cisco_46:45:d3 (00:04:27:46:45:d3)
> >  ...0     = IG bit: Individual address
> > (unicast)  ..0.     = LG bit: Globally unique
> > address (factory default) Type: IP (0x0800)
> > Internet Protocol, Src: 192.26.92.31 (192.26.92.31), Dst: 10.10.3.22
> > (10.10.3.22) Version: 4
> > Header length: 20 bytes
> > Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN:
> > 0x00)  00.. = Differentiated Services Codepoint: Default (0x00)
> >  ..0. = ECN-Capable Transport (ECT): 0
> >  ...0 = ECN-CE: 0
> > Total Length: 126
> > Identification: 0x (0)
> > Flags: 0x02 (Don't Fragment)
> > 0.. = Reserved bit: Not Set
> > .1. = Don't fragment: Set
> > ..0 = More fragments: Not Set
> > Fragment offset: 0
> > Time to live: 58
> > Protocol: UDP (0x11)
> > Header checksum: 0x1716 [correct]
> > [Good: True]
> > [Bad : False]
> > Source: 192.26.92.31 (192.26.92.31)
> > Destination: 10.10.3.22 (10.10.3.22)
> > User Datagram Protocol, Src Port: domain (53), Dst Port: 48885
> > (48885) Source port: domain (53)
> > Destination port: 48885 (48885)
> > Length: 106
> > Checksum: 0x1190 [validation disabled]
> > [Good Checksum: False]
> > [Bad Checksum: False]
> > Domain Name System (response)
> > [Request In: 3]
> > [Time: 0.086282000 seconds]
> > Transaction ID: 0x3824
> > Flags: 0x8100 (Standard query response, No error)
> > 1...    = Response: Message is a response
> > .000 0...   = Opcode: Standard query (0)
> >  .0..   = Authoritative: Server is not an
> > authority for domain  ..0.   = Truncated: Message is
> > not truncated  ...1   = Recursion desired: Do query
> > recursively   0...

rrset-order and resolvers

[Torsten Segner]

Hi,

I have a question regarding the rrset-order option.
I have compiled a nameserver with the --enable-fixed-rrset option and 
configured it with the following rrset-order in global options.

rrset-order {
   class IN type NS name "host.example.com" order fixed;
   order cyclic;
};

Querying the autoritative nameserver I get the resulting RRset in fixed order.

When asking a resolver I get answers in random order as long as I don't insert 
the above rrset-order option in the resolver config as well.

Have I missed something or is this an intended behaviour of resolving 
nameservers?


Ciao
Torsten

-- 
Torsten Segner  |  Systemadministrator Internet Services  |  Easynet GmbH 
T +49 (0)40 77175 650  |  F +49 (0)40 77175 569
E torsten.seg...@de.easynet.net  |  GPG KeyID 0xC84C7841
Harburger Schlosstrasse 1
21079 Hamburg, Germany.
www.easynet.com
Geschäftsführer: Diethelm Siebuhr, David Rowe
Gesellschaftssitz: Hamburg 
Registergericht: Amtsgericht Hamburg; Registernummer: HRB 87822
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users