about NS server authorize

2016-03-21 Thread support 

Hello,

We have two nameservers,
ns5.cloudwebdns.com
ns6.cloudwebdns.com

the primary types of domains, like com/net/org/info can be setup to be 
resolved by them.
But some other domsins, like .me one, can't be setup in registrar's 
admin panel, saying nameserver not authorized.


Can you help with this issue?

Thanks,
Kevin
___
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: about NS server authorize

2016-03-21 Thread support 


Hi,

ns5.cloudwebdns.com
ns6.cloudwebdns.com

For these two nameservers (they are the native BIND 9), we can use them 
to resolve the other domains like .com/.net/.org/.info etc.


But when we try to setup a .me domain to be resolved by them, from the 
registrar's control panel, it gets failed, saying name server not 
authorized.


This is may be something wrong around EPP and host object.

Can you help setup the host object with these two nameservers into .me's 
registry?


Thanks.



On 21.03.16 15:42, supp...@cloudwebdns.com wrote:

We have two nameservers,
ns5.cloudwebdns.com
ns6.cloudwebdns.com

the primary types of domains, like com/net/org/info can be setup to be 
resolved by them.
But some other domsins, like .me one, can't be setup in registrar's 
admin panel, saying nameserver not authorized.


contact your registrar about this issue.
thisa is not a bind problem.


___
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

CNAME used in Global Server Loadbalancing - is it RFC compliant ?

2009-05-26 Thread support 

Hello,

we are using Global Server Loadbalancing (GSLB) for site redundancy.

GSLB is based on DNS technology and works as follows

---
 standard implementation case
---

www.example.com.NS   loadbalancer-1.example.com.
#   --> ( LB located at site-a)

www.example.com.NS   loadbalancer-2.example.com.
#   --> ( LB located at site-b)


#  the loadbalancer (LB) resolves the DNS query for www.example.com, based
#  on load balancing criteria with a site specific public IP address

loadbalancer-1.example.com. A   1.y.z.w
loadbalancer-2.example.com. A   2.y.z.w



---
 ?? 'CNAME approach' in question
---

(-) Above setup works fine and for each service and we need 2 public IP
addresses ­ one at each site hosted on the loadbalancer device.

(--) now considering that we host the same application with different names
on the same server ­ we need for each one another 2 public IP addresses -
this leads to an unnecessary waste of addresses (x * 2)

==> NEW APPROACH 

Instead of using two new IP public addresses for the new service name I
defined following:

new-www.example.com  CNAME www.example.com.

==> it works fine so far an the resolve process is as it should be, but




Is it legitimate (RFC compliant) to use CNAME in this setup or is is just
luck that it works and more compliant resolvers won't work properly ??


Thanks a lot
Marcel


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

DNS and Remote Host over VPN

2013-07-10 Thread IT Support 

Hi brothers

I have a question about dns Address record, I´m running Bind9 over d 
ebian, and  I wonder if is posible to add address record for a remote 
host? this remote host i reach it by a site to site vpn,

this is my scenario

-dns server 192.168.10.100
-remote host 172.28.15.34

I already add a address record on my internal view for that remote host, 
if I ping this host by IP address i got answer, but if i ping the same 
host by name i got this message:

ping: unknown host

Thanks in advance.
Cheers.

Jah Love.

___
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 and Remote Host over VPN

2013-07-10 Thread IT Support 

Hi Steve

this is the output commands:

 dig pc12.mydomain.com

; <<>> DiG 9.6-ESV-R4 <<>> pc12.mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 28662
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;pc12.mydomain.com   IN  A

;; AUTHORITY SECTION:
mydomain.com 1800IN  SOA server.pc12.mydomain.com. 
hostmaster.pc12.mydomain.com. 2013070968 10800 3600 604800 3600


;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Jul 10 11:41:05 2013
;; MSG SIZE  rcvd: 113

nslookup pc12.mydomain.com
Server: 127.0.0.1
Address:127.0.0.1#53

** server can't findpc12.mydomain.com: NXDOMAIN

Thanks for the advice, I got both commands for testing dns


On 10/07/2013 11:39 AM, Steven Carr wrote:

On 10 July 2013 17:34, IT Support  wrote:

I already add a address record on my internal view for that remote host, if
I ping this host by IP address i got answer, but if i ping the same host by
name i got this message:
ping: unknown host


In future please copy/paste the commands you have ran and the output
so we can see the exact responses.

What response do you get when you run a `dig` or `nslookup` for the
hostname? (Ping does not test DNS, it may attempt a DNS query but it
does not fully test DNS). Did you try the FQDN of the host?

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

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


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

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

Internernal view is answering to external ping

2013-07-31 Thread IT Support 

Hi brothers

I have running bind9 on debian, with master zone for mydomain.com i 
created internal view for resolve names on my lan, and external zone for 
resolve my host on Internet, this is the working scenario


Internal view
LAN IP 192.168.0.67
Hostname sales.mydomain.com

External view
WAN IP 200.57.66.77
Hostname sales.mydomain.com

When I make a ping from a other Internet access I get the answer from 
internal View


Pinging sales.mydomain.com [192.168.0.67] with 32 bytes o

Ping statistics for 192.168.0.67
Packets: Sent = 3, Received = 3, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 2ms, Average = 1ms

Is it possible to change this issue?

Thanks in advance.

___
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: Internernal view is answering to external ping

2013-07-31 Thread IT Support 

Dear Carl

Thanks for your answer here the output:

acl allowed-users {
localhost;
200.57.66.77/28;
192.168.0.0/23;
189.0.0.0/8;
172.16.102.1;
172.28.76.0/24;
};

acl internal {
localhost;
200.57.66.77/28;
192.168.0.0/23
};

acl slaves {
200.57.66.78;
};

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


include "/etc/bind/named.conf.options";

// prime the server with knowledge of the root servers
//zone "." {
//  type hint;
//  file "/etc/bind/db.root";
//};

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

//zone "localhost" {
//  type master;
//  file "/etc/bind/db.local";
//};
//zone "127.in-addr.arpa" {
//  type master;
//  file "/etc/bind/db.127";
//};

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

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

//zone "168.192.IN-ADDR.ARPA" {
//type master;
//file "/etc/bind/db.192";
//};

//zone "10.IN-ADDR.ARPA" {
//  type master;
//  file "/etc/empty";
//};

//zone "16.172.IN-ADDR.ARPA" {
//  type master;
//  file "/etc/empty";
//};



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

// From the release notes:
//  Because many of our users are uncomfortable receiving undelegated 
answers

//  from root or top level domains, other than a few for whom that behaviour
//  has been trusted and expected for quite some length of time, we have now
//  introduced the "root-delegations-only" feature which applies 
delegation-only
//  logic to all top level domains, and to the root domain.  An 
exception list
//  should be specified, including "MUSEUM" and "DE", and any other top 
level

//  domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { "DE"; "MUSEUM"; };

include "/etc/bind/named.conf.local";
logging {
category lame-servers { null; };
category edns-disabled { null; };
};
key dhcpupdate {
algorithm hmac-md5;
secret "ddjsdfruifhrfr88r8rr5544==";
};

Thanks in advance.

On 31/07/2013 5:46 PM, Carl Byington wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 2013-07-31 at 17:39 -0500, IT Support wrote:

I have running bind9 on debian, with master zone for mydomain.com i
created internal view for resolve names on my lan, and external zone
for resolve my host on Internet,

standard answer - post your bind config.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlH5k9MACgkQL6j7milTFsEtzgCeKCNBwf7sAtPQDXC+qU+vq6Go
8esAn2aWS7UaRcqWx8CDgG95+jZA1jXC
=knAS
-END PGP SIGNATURE-


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

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


___
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: Internernal view is answering to external ping

2013-07-31 Thread IT Support 
Thanks Mark for the advice, that output is my whole named.conf, please 
let me know if I need to post another output file


This is what do i have on my bind folder:

named.conf
named.conf.dpkg-dist
named.conf.local
named.conf.local.bfRFC1918
named.conf.local.orig
named.conf.options
named.conf.options.dpkg-di
mydomain.com.hosts
mydomain.com.hosts.lan
db.0
db.127
db.192
192.168.0
db.192.168.0.internal
db.192.168.0.internal.jnl
db.192.168.external
db.192.168.internal
db.192.168.internal.jnl
db.192.internal
db.192.jnl
db.255
db.empty
db.local
db.root
root b

On 31/07/2013 7:09 PM, Mark Andrews wrote:

Post your *full* config not half of it.  How the hell do you expect
people to identify problems unless you give them the neccessary
details.

Do you give you car mechanic only access to the boot when you have
a engine problem?

You said you created views yet you didn't send anything that described
how the views were configured.

Mark

In message <51f9a4dc.6040...@gmail.com>, IT Support writes:

Dear Carl

Thanks for your answer here the output:

acl allowed-users {
  localhost;
200.57.66.77/28;
  192.168.0.0/23;
  189.0.0.0/8;
  172.16.102.1;
  172.28.76.0/24;
  };

acl internal {
  localhost;
200.57.66.77/28;
  192.168.0.0/23
  };

acl slaves {
200.57.66.78;
  };

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

include "/etc/bind/named.conf.options";

// prime the server with knowledge of the root servers
//zone "." {
//  type hint;
//  file "/etc/bind/db.root";
//};

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

//zone "localhost" {
//  type master;
//  file "/etc/bind/db.local";
//};
//zone "127.in-addr.arpa" {
//  type master;
//  file "/etc/bind/db.127";
//};

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

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

//zone "168.192.IN-ADDR.ARPA" {
//type master;
//file "/etc/bind/db.192";
//};

//zone "10.IN-ADDR.ARPA" {
//  type master;
//  file "/etc/empty";
//};

//zone "16.172.IN-ADDR.ARPA" {
//  type master;
//  file "/etc/empty";
//};



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

// From the release notes:
//  Because many of our users are uncomfortable receiving undelegated
answers
//  from root or top level domains, other than a few for whom that behaviour
//  has been trusted and expected for quite some length of time, we have now
//  introduced the "root-delegations-only" feature which applies
delegation-only
//  logic to all top level domains, and to the root domain.  An
exception list
//  should be specified, including "MUSEUM" and "DE", and any other top
level
//  domains from whom undelegated responses are expected and trusted.
// root-delegation-only exclude { "DE"; "MUSEUM"; };

include "/etc/bind/named.conf.local";
logging {
  category lame-servers { null; };
  category edns-disabled { null; };
  };
key dhcpupdate {
  algorithm hmac-md5;
  secret "ddjsdfruifhrfr88r8rr5544==";
  };

Thanks in advance.

On 31/07/2013 5:46 PM, Carl Byington wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Wed, 2013-07-31 at 17:39 -0500, IT Support wrote:

I have running bind9 on debian, with master zone for mydomain.com i
created internal view for resolve names on my lan, and external zone
for resolve my host on Internet,

standard answer - post your bind config.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlH5k9MACgkQL6j7milTFsEtzgCeKCNBwf7sAtPQDXC+qU+vq6Go
8esAn2aWS7UaRcqWx8CDgG95+jZA1jXC
=knAS
-END PGP SIGNATURE-


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

be from this list

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


--050203070403020006060804
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit


   
 
   
   
 Dear Carl
   
   Thanks for your answer here the output:
   
   acl allowed-users {
       localhost;
       200.57.66.77/28;
       192.168.0.0/23;
      

Re: Internernal view is answering to external ping

2013-07-31 Thread IT Support 

Hi Steven

Can you tell me what files do I have to post here?

On 31/07/2013 7:04 PM, Steven Carr wrote:

On 1 August 2013 00:59, IT Support  wrote:

Thanks in advance.

Where is your view/zone configuration? (possibly in one of the
included files) you will need to post that configuration as well.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


___
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

weird perfmonce BIND version 9.6

2013-09-25 Thread IT Support 

Hi brothers and sisters.

I´m getting some weird perfomance on  BIND version 9.6  I´m running on 
debian, I have internal and external view created. there are records on 
internal and external views, so the records on external view some of 
them are working and others not working.


I´m testing a record created for a host in external view from dns server 
by a ping and i got a ping: unknown host, but if a ping to other host 
with external record i got a answer.


Is there a way to fix this issue?

Thanks a lot for your support.


___
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

Fwd: Re: weird perfmonce BIND version 9.6

2013-09-25 Thread IT Support 


Hi charles this is what i get from dig

 dig host2.mydomain.com

; <<>> DiG 9.6-ESV-R4 <<>> ost2.mydomain.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 49898
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;host2.mydomain.comIN  A

;; AUTHORITY SECTION:
mydomain.com. 3600IN  SOA server.mydomain.com. 
postmaster.ost2.mydomain.com 2013092500 10800 3600 604800 38400


;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Wed Sep 25 13:40:02 2013
;; MSG SIZE  rcvd: 119

I don´t know what happend I already added the dns record on both 
external and internal. Another issue when i made a dig from a diferent 
internet lynk  i got a answer from the private ip for the host.





On 25/09/2013 1:05 PM, Charles Swiger wrote:

On Sep 25, 2013, at 10:58 AM, IT Support  wrote:

Hi brothers and sisters.

Hi, anonymous IT Support person--  :-)


I´m getting some weird perfomance on  BIND version 9.6  I´m running on debian, 
I have internal and external view created. there are records on internal and 
external views, so the records on external view some of them are working and 
others not working.

That sounds like a misconfiguration of the views, and not a performance problem.


I´m testing a record created for a host in external view from dns server by a 
ping and i got a ping: unknown host, but if a ping to other host with external 
record i got a answer.

If you want to test DNS, use dig.


Is there a way to fix this issue?

Most likely.

Regards,




___
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: weird perfmonce BIND version 9.6

2013-09-25 Thread IT Support 

Hi Chuck, sorry for the mistake.

so i did the dig host2.mydomain.com and this is the result:

host2.mydomain.com @xxx.xxx.xxx.xxx

; <<>> DiG 9.6-ESV-R4 <<>>host2.mydomain.com @xxx.xxx.xxx.xxx
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33734
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 13, ADDITIONAL: 0

;; QUESTION SECTION:
;host2.mydomain.com. IN  A

;; ANSWER SECTION:
host2.mydomain.com.  3377IN  A   192.168.1.133

;; AUTHORITY SECTION:
.   8579IN  NS h.root-servers.net.
.   8579IN  NS k.root-servers.net.
.   8579IN  NS j.root-servers.net.
.   8579IN  NS m.root-servers.net.
.   8579IN  NS d.root-servers.net.
.   8579IN  NS g.root-servers.net.
.   8579IN  NS b.root-servers.net.
.   8579IN  NS l.root-servers.net.
.   8579IN  NS e.root-servers.net.
.   8579IN  NS i.root-servers.net.
.   8579IN  NS a.root-servers.net.
.   8579IN  NS c.root-servers.net.
.   8579IN  NS f.root-servers.net.

;; Query time: 2 msec
;; SERVER: xxx.xxx.xxx.xxx#53(xxx.xxx.xxx.xxx)
;; WHEN: Wed Sep 25 14:38:02 2013
;; MSG SIZE  rcvd: 266

too many times I´ve got advices about to dns testing using dig command, 
but I´m still using ping to check what ip address is answering to me. In 
this case i´m testing host2.mydomain.com  and i´m getting the private ip 
address. I´m wondering how to fix this issue.


thanks in advance.

On 25/09/2013 2:33 PM, Charles Swiger wrote:

"dig host2.mydomain.com @external_IP


___
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: weird perfmonce BIND version 9.6

2013-09-26 Thread IT Support 
Hi Matus thanks for your answer, can you do me a favor? can you tell me 
how to looking for that configuration?


only clients that are supposed to get internal private addresses should 
be in internal view. "...You mean, that I should to create a internal 
and external record in each view? if this is the case I already added 
those records. ¿Is there another thing that I´m forgetting to do?..."


Thanks in advance.8-)


On 26/09/2013 10:13 AM, Matus UHLAR - fantomas wrote:

On 25.09.13 14:58, IT Support wrote:
too many times I´ve got advices about to dns testing using dig 
command, but I´m still using ping to check what ip address is 
answering to me. In this case i´m testing host2.mydomain.com and i´m 
getting the private ip address. I´m wondering how to fix this issue.


you apparently have not configured views properly. only clients that are
supposed to get internal private addresses should be in internal view.



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

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

Re: weird perfmonce BIND version 9.6

2013-10-03 Thread IT Support 
Hi Mathus one thing more. I´m little bit lost in bind9. Can you tell me 
which one those files where is defined the internal o external host? If 
is in mydomain.com.hosts.lan for internal and mydomain.com.hosts for 
external I already put them in each configuration file. But I´m still 
getting the IP Private address answer when i try to pinging for example


ping mydomain.com -t

I got the 192.168.1.3 answer.

you said Check their match-* directives, post them here if possible. 
-which one is that configuration file?



Thanks in advance


On 26/09/2013 12:54 PM, Matus UHLAR - fantomas wrote:

On 26.09.13 10:52, IT Support wrote:
Hi Matus thanks for your answer, can you do me a favor? can you tell 
me how to looking for that configuration?


only clients that are supposed to get internal private addresses 
should be in internal view. "...You mean, that I should to create a 
internal and external record in each view? if this is the case I 
already added those records. ¿Is there another thing that I´m 
forgetting to do?..."


check your view definition and which hosts fall into which view.
Check their match-* directives, post them here if possible.

No, you definitely should NOT mention both IPs in any view.
hosts from internal view should get internal IP and hosts from 
external view

should get external IP.



___
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

Issue running "dig txt rs.dns-oarc.net" on 9.12

2018-01-26 Thread NNEX Support 
I'm sure I'm doing something wrong, but for the life of me I can't figure out 
what. I'm running named 9.12 in a simple recursive setup (built from source on 
CentOS 7).

In named.conf I've set:
dnssec-enable yes;
dnssec-validation auto;

When I try to run "dig txt rs.dns-oarc.net" I get SERVFAIL. The logs show:

validating rs.dns-oarc.net/CNAME: starting
validating rs.dns-oarc.net/CNAME: attempting insecurity proof
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'net'
validating net/DS: starting
validating net/DS: attempting positive response validation
validating net/DS: keyset with trust secure
validating net/DS: verify rdataset (keyid=41824): success
validating net/DS: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/CNAME: in dsfetched2: success
validating rs.dns-oarc.net/CNAME: resuming proveunsecure
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'dns-oarc.net'
validating dns-oarc.net/DS: starting
validating dns-oarc.net/DS: attempting positive response validation
validating net/DNSKEY: starting
validating net/DNSKEY: attempting positive response validation
validating net/DNSKEY: verify rdataset (keyid=35886): success
validating net/DNSKEY: marking as secure (DS)
validating dns-oarc.net/DS: in fetch_callback_validator
validating dns-oarc.net/DS: keyset with trust secure
validating dns-oarc.net/DS: resuming validate
validating dns-oarc.net/DS: verify rdataset (keyid=25733): success
validating dns-oarc.net/DS: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/CNAME: in dsfetched2: success
validating rs.dns-oarc.net/CNAME: resuming proveunsecure
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net'
validating rs.dns-oarc.net/CNAME: continuing validation would lead to deadlock: 
aborting validation
validating rs.dns-oarc.net/CNAME: deadlock found (create_fetch)
Jan 26 15:06:59 red named[3036]: no valid RRSIG resolving 
'rs.dns-oarc.net/TXT/IN': 64.191.0.133#53

However if I run "dig txt rs.dns-oarc.net +trace" and then "dig txt 
rs.dns-oarc.net" the query completes as expected. It continues to complete as 
expected until I restart named.

If I alter named.conf  to say 
dnssec-enable yes;
dnssec-validation yes;

The running "dig txt rs.dns-oarc.net" works immediately, but of course that 
breaks verification of the root zone, so DNSSEC is worthless.

My named.conf is super simple:

key "rndc-key" {
  algorithm hmac-sha256;
  secret "$KEY";
};
controls {
  inet 127.0.0.1 port 953
  allow { 127.0.0.1; } keys { "rndc-key"; };
};
acl "NNEX" {
127.0.0.1;
aaa.bbb.ccc.0/22;
};
options {
listen-on port 53 { 127.0.0.1; };
listen-on port 53 { aaa.bbb.ccc.d; };
directory   "/var/named";
dnssec-enable yes;
dnssec-validation auto;
allow-recursion { nnex; };
allow-query { nnex; };
recursion yes;
};
logging {
channel dnssec_log {
file "/var/log/dnssec.log";
severity debug 3;
};
category dnssec { dnssec_log; };
};

Thank you,

-Nick

___
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: Issue running "dig txt rs.dns-oarc.net" on 9.12

2018-01-27 Thread NNEX Support 
Good thought but no luck, it doesn’t matter how many times I run “dig txt 
rs.dns-oarc.net” or how long I wait it continues to SERVFAIL until I run "dig 
txt rs.dns-oarc.net +trace" Interestingly I've found that running "dig txt 
dns-oarc.net +trace" isn't enough to fix it, I actually have to run "dig txt 
rs.dns-oarc.net +trace" before things start working.

[...]

There's an insecure delegation (NS set, and NSEC proving the nonexistence of a 
DS set) from dns-oarc.net to rs.dns-oarc.net.  However, there's disagreement 
between the parent and child about what name servers actually serve 
rs.dns-oarc.net, and at least some of them are refusing to answer TCP.  It's 
likely your recursive server is, for whatever reason, being drawn to the ones 
failing to respond, and not getting good data elsewhere fast enough to answer 
your query.

[...]

I agree, from my limited understanding this seems to describe what is happening 
well. The thing I'm wondering is why? I'm running older visions of named 
(9.9.4, yum provided RPM on CentOS 6) that seem immune to this issue. I've been 
digging through release notes and can't find any setting that has changed 
between the versions that might explain it (I know 9.9.4 to 9.12 is a big jump, 
so I'm sure I'm missing something)

Thank you!

-Nick

___
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: Issue running "dig txt rs.dns-oarc.net" on 9.12

2018-02-06 Thread NNEX Support 
[…]
If you want to understand why your resolver is failing, again I'd have a look 
at the 'resolver' log channel.  It should have some detail about what's 
resulting in the SERVFAIL message.
[…]

I took a look at the ‘resolver’ log channel.  I didn’t find any useful 
information there, just:

fetch: rs.dns-oarc.net/TXT
fetch: sns-pb.isc.org/A
fetch: ns.isc.afilias-nst.info/A
fetch: net/DS
fetch: dns-oarc.net/DS
fetch: net/DNSKEY

I started trying different releases and found this query works consistently for 
me all the way up to bind-9.12.0rc1. As soon as I try bind-9.12.0rc3 the 
queries start failing. I’m using the exact same config and server for both the 
working rc1 and not working rc3 (both complied from source). Any thoughts on 
any differences between RC1 and RC3 that might explain this or any other logs I 
should be checking?

The ‘resolver’ log channel on rc1 (which works) shows:

fetch: rs.dns-oarc.net/TXT
fetch: sns-pb.isc.org/A
fetch: ns.isc.afilias-nst.info/A
fetch: net/DS
fetch: dns-oarc.net/DS
fetch: net/DNSKEY
fetch: rs.dns-oarc.net/DS
fetch: dns-oarc.net/DNSKEY
fetch: rst.x487.rs.dns-oarc.net/TXT
fetch: rst.x461.x487.rs.dns-oarc.net/TXT
fetch: rst.x466.x461.x487.rs.dns-oarc.net/TXT

Looking at the ‘dnssec’ log channel I see this on RC1:

validating rs.dns-oarc.net/CNAME: starting
validating rs.dns-oarc.net/CNAME: attempting insecurity proof
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'net'
validating net/DS: starting
validating net/DS: attempting positive response validation
validating net/DS: keyset with trust secure
validating net/DS: verify rdataset (keyid=41824): success
validating net/DS: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/CNAME: in dsfetched2: success
validating rs.dns-oarc.net/CNAME: resuming proveunsecure
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'dns-oarc.net'
validating dns-oarc.net/DS: starting
validating dns-oarc.net/DS: attempting positive response validation
validating net/DNSKEY: starting
validating net/DNSKEY: attempting positive response validation
validating net/DNSKEY: verify rdataset (keyid=35886): success
validating net/DNSKEY: marking as secure (DS)
validating dns-oarc.net/DS: in fetch_callback_validator
validating dns-oarc.net/DS: keyset with trust secure
validating dns-oarc.net/DS: resuming validate
validating dns-oarc.net/DS: verify rdataset (keyid=25733): success
validating dns-oarc.net/DS: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/CNAME: in dsfetched2: success
validating rs.dns-oarc.net/CNAME: resuming proveunsecure
validating rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net'
validating rs.dns-oarc.net/DS: starting
validating rs.dns-oarc.net/DS: attempting negative response validation
  validating dns-oarc.net/SOA: starting
  validating dns-oarc.net/SOA: attempting positive response validation
validating dns-oarc.net/DNSKEY: starting
validating dns-oarc.net/DNSKEY: attempting positive response validation
validating dns-oarc.net/DNSKEY: verify rdataset (keyid=20899): success
validating dns-oarc.net/DNSKEY: marking as secure (DS)
  validating dns-oarc.net/SOA: in fetch_callback_validator
  validating dns-oarc.net/SOA: keyset with trust secure
  validating dns-oarc.net/SOA: resuming validate
  validating dns-oarc.net/SOA: verify rdataset (keyid=12093): success
  validating dns-oarc.net/SOA: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/DS: in authvalidated
validating rs.dns-oarc.net/DS: resuming nsecvalidate
  validating rs.dns-oarc.net/NSEC: starting
  validating rs.dns-oarc.net/NSEC: attempting positive response validation
  validating rs.dns-oarc.net/NSEC: keyset with trust secure
  validating rs.dns-oarc.net/NSEC: verify rdataset (keyid=12093): success
  validating rs.dns-oarc.net/NSEC: marking as secure, noqname proof not needed
validating rs.dns-oarc.net/DS: in authvalidated
validating rs.dns-oarc.net/DS: looking for relevant NSEC
validating rs.dns-oarc.net/DS: nsec proves name exists (owner) data=0
validating rs.dns-oarc.net/DS: resuming nsecvalidate
validating rs.dns-oarc.net/DS: nonexistence proof(s) found
validating rs.dns-oarc.net/CNAME: in dsfetched2: ncache nxrrset
validating rs.dns-oarc.net/CNAME: marking as answer (dsfetched2)
validating rst.x476.rs.dns-oarc.net/CNAME: starting
validating rst.x476.rs.dns-oarc.net/CNAME: attempting insecurity proof
validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 'net'
validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 
'dns-oarc.net'
validating rst.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 
'rs.dns-oarc.net'
validating rst.x476.rs.dns-oarc.net/CNAME: marking as answer (proveunsecure (4))
validating rst.x461.x476.rs.dns-oarc.net/CNAME: starting
validating rst.x461.x476.rs.dns-oarc.net/CNAME: attempting insecurity proof
validating rst.x461.x476.rs.dns-oarc.net/CNAME: checking existence of DS at 
'net'
validating rst.x4

RE: Issue running "dig txt rs.dns-oarc.net" on 9.12

2018-02-22 Thread NNEX Support 
Just wanted to follow up 9.12.1b1 fixes this issue for me.

Thanks,

-Nick

___
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: Issue running "dig txt rs.dns-oarc.net" on 9.12

2018-02-22 Thread NNEX Support 
I apologize, I sent the previous email in error. This is what I get for having 
so many revisions of named sitting around on one server, I was not running 
9.12.1b1 when I tested this. I will be more careful in the future. I just 
tested this with 9.12.1b1 and it still fails, the same as 9.12.

I do understand that the function of rs.dns-oarc.net is to test things that can 
no longer be tested in 9.12, but regardless I should still be able to resolve 
the nameservers for rs.dns-oarc.net, right?

Is anyone on 9.12 able to do this? Is this just my problem?

Thank you again,

-Nick


-Original Message-
From: NNEX Support 
Sent: Thursday, February 22, 2018 8:21 AM
To: 'bind-users@lists.isc.org'
Subject: RE: Issue running "dig txt rs.dns-oarc.net" on 9.12

Just wanted to follow up 9.12.1b1 fixes this issue for me.

Thanks,

-Nick

___
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: Issue running "dig txt rs.dns-oarc.net" on 9.12

2018-02-22 Thread NNEX Support 
I'm sorry to keep replying to myself but I believe I've found the line of code 
that is causing this issue. Looking at validator.c, in the check_deadlock 
function, 9.12.0rc1 says:

...

if (parent->event != NULL &&
parent->event->type == type &&
dns_name_equal(parent->event->name, name) &&

...

9.12.0rc3 and above says:

...

if (parent->event != NULL &&
(parent->event->type == type ||
 parent->event->type == dns_rdatatype_cname) &&
dns_name_equal(parent->event->name, name) &&

...

By removing  "parent->event->type == dns_rdatatype_cname)" (and adjusting the 
rest of the if statement appropriately) the query "dig ns rs.dns-oarc.net" 
works.

I see this commit related to this line of code: 
https://gitlab.isc.org/isc-projects/bind9/commit/2b51d5874c49ac823890b88824290fbf1c18f2cc

I'm sure this line of code is important, otherwise it wouldn't be there and I 
don't know enough to be removing random bits of code, so of course I'd never 
run this in production. Still I want to understand why this is happening and if 
it’s a bug or me not understanding DNS properly. 

As always thank you for your time!
 
-Nick



___
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: Issue running "dig txt rs.dns-oarc.net" on 9.12

2018-02-28 Thread NNEX Support 
Thanks for the information Cathy. I've always run the Red Hat provided packages 
in the past, this is the first time I've ever tried running the newest release 
direct. Mostly I'm just feeling extra cautious since this is something I've 
never done before and admittedly I don't know as much about DNS as I should so 
I really appreciate you taking the time to break down what is happening.

Based on your explanation it sounds like this isn't something I'll ever run 
into other than this one special case so I'll stop worrying about it.

Thank you!

-Nick

-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Cathy 
Almond
Sent: Tuesday, February 27, 2018 4:29 AM
To: bind-users@lists.isc.org
Subject: Re: Issue running "dig txt rs.dns-oarc.net" on 9.12

On 22/02/2018 16:44, NNEX Support wrote:
> I'm sorry to keep replying to myself but I believe I've found the line of 
> code that is causing this issue. Looking at validator.c, in the 
> check_deadlock function, 9.12.0rc1 says:
> 
> ...
> 
> if (parent->event != NULL &&
> parent->event->type == type &&
> dns_name_equal(parent->event->name, name) &&
> 
> ...
> 
> 9.12.0rc3 and above says:
> 
> ...
> 
> if (parent->event != NULL &&
> (parent->event->type == type ||
>  parent->event->type == dns_rdatatype_cname) &&
> dns_name_equal(parent->event->name, name) &&
> 
> ...
> 
> By removing  "parent->event->type == dns_rdatatype_cname)" (and adjusting the 
> rest of the if statement appropriately) the query "dig ns rs.dns-oarc.net" 
> works.
> 
> I see this commit related to this line of code: 
> https://gitlab.isc.org/isc-projects/bind9/commit/2b51d5874c49ac823890b
> 88824290fbf1c18f2cc
> 
> I'm sure this line of code is important, otherwise it wouldn't be there and I 
> don't know enough to be removing random bits of code, so of course I'd never 
> run this in production. Still I want to understand why this is happening and 
> if it’s a bug or me not understanding DNS properly. 

Good sleuthing - though apart from understanding why the query now fails, I 
don't think there's any code defect that needs to be addressed.
 This line of code belongs with these changes between RC1 and RC3.  They are 
kinda important (note the CVE reference):

4859.   [bug]   A loop was possible when attempting to validate
unsigned CNAME responses from secure zones;
this caused a delay in returning SERVFAIL and
also increased the chances of encountering
CVE-2017-3145. [RT #46839]

4858.   [security]  Addresses could be referenced after being freed
in resolver.c, causing an assertion failure.
(CVE-2017-3145) [RT #46839]

The debug log you pointed to was also specific about why the validation
stopped:

validating rs.dns-oarc.net/CNAME: checking existence of DS at 'rs.dns-oarc.net'
validating rs.dns-oarc.net/CNAME: continuing validation would lead to
deadlock: aborting validation
validating rs.dns-oarc.net/CNAME: deadlock found (create_fetch)

The rs.dns-oarc.net zone is broken because it returns a CNAME for queries at 
the apex.

Observe the delegation (I'm querying one of the servers auth for
dns-oarc.net):

; <<>> DiG 9.11.2 <<>> +norec +dnssec @64.191.0.65 rs.dns-oarc.net NS ; (1 
server found) ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43571 ;; flags: qr; QUERY: 
1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096 ; COOKIE: 
47d4eddbbbde6fd18616a25b5a952d35767788ad0b03038f (good) ;; QUESTION SECTION:
;rs.dns-oarc.net.   IN  NS

;; AUTHORITY SECTION:
rs.dns-oarc.net.3600IN  NS  ns00.rs.dns-oarc.net.
rs.dns-oarc.net.3600IN  NSECrs4.dns-oarc.net. NS RRSIG NSEC
rs.dns-oarc.net.3600IN  RRSIG   NSEC 8 3 3600 20180328101103
20180226091103 12093 dns-oarc.net.
floDmByYaxmh+QQWou7PtICj4tnpW6/ea1WzatUfAEMvPOSmm54CJ467
KWpnf5XADFgFrcHOr0gYLlbFVJrwEB5n6R+SvXOTx9zwgva3SY37Vgq8
ZMwdNPdGxmVLOz1Ou5tByfZV2ZLpueF+hBB12wft+wNCysjMuwtx4U2D a64=

;; ADDITIONAL SECTION:
ns00.rs.dns-oarc.net.   3600IN  A   64.191.0.133
ns00.rs.dns-oarc.net.   3600IN  2620:ff:c000:0:2::133

Then look at the query response for a DS RRset that the BIND validator is 
receiving from ns00.rs.dns-oarc.net:

; <<>> DiG 9.11.2 <<>> +nore

update Bind9 ES version

2025-01-31 Thread Support Info 
Hello, 

Following the CVE cve-2024-11187 and cve-2024-12705 concerning Bind9 I have two 
debian servers whose repository cannot find the update: 
apt-cache policy bind9 
bind9: 
Installed: 1:9.18.28-1~deb12u2 
Candidate: 1:9.18.28-1~deb12u2 

To patch to 9.18.33 Extended Support (ES), what do you recommend in this case? 
Do I have to uninstall the ES version to install the Standard version, or can I 
stay with the ES version? 

Thank you in advance 

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

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


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

ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named

2013-03-26 Thread ISC Support Staff 

Note:

  This email advisory is provided for your information. The most
  up to date advisory information will always be at:
  https://kb.isc.org/article/AA-00871  please use this URL for the
  most up to date advisory information.

---

A critical defect in BIND 9 allows an attacker to cause excessive

memory consumption in named or other programs linked to libdns.



CVE:  CVE-2013-2266

Document Version: 2.0

Posting date: 26 March 2013

Program Impacted: BIND

Versions affected:"Unix" versions of  BIND 9.7.x, 9.8.0 -> 9.8.5b1,

  9.9.0 -> 9.9.3b1.  (Windows versions are not
affected.

  Versions of BIND 9 prior to BIND 9.7.0 (including

  BIND 9.6-ESV) are not affected.  BIND 10 is

  not affected.)

Severity: Critical

Exploitable:  Remotely

Description:



   A flaw in a library used by BIND 9.7, 9.8, and 9.9, when compiled

   on Unix and related operating systems, allows an attacker to

   deliberately cause excessive memory consumption by the named

   process, potentially resulting in exhaustion of memory resources

   on the affected server.  This condition can crash BIND 9 and

   will likely severely affect operation of other programs running

   on the same machine.



   Please Note: Versions of BIND 9.7 are beyond their "end of life"

   (EOL) and no longer receive testing or security fixes from ISC.

   However, the re-compilation method described in the "Workarounds"

   section of this document will prevent exploitation in BIND 9.7

   as well as in currently supported versions.



   For current information on which versions are actively supported,

   please seehttp://www.isc.org/software/bind/versions.



   Additional information is available in the CVE-2013-2266 FAQ and

   Supplemental Information article in the ISC Knowledge base,

   https://kb.isc.org/article/AA-00879.



Impact:



   Intentional exploitation of this condition can cause denial of

   service in all authoritative and recursive nameservers running

   affected versions of BIND 9 [all versions of BIND 9.7, BIND 9.8.0

   through 9.8.5b1 (inclusive) and BIND 9.9.0 through BIND 9.9.3b1

   (inclusive)].   Additionally, other services which run on the

   same physical machine as an affected BIND server could be

   compromised as well through exhaustion of system memory.



   Programs using the libdns library from affected versions of BIND

   are also potentially vulnerable to exploitation of this bug if

   they can be forced to accept input which triggers the condition.

   Tools which are linked against libdns (e.g. dig) should also be

   rebuilt or upgraded, even if named is not being used.



CVSS Score:  7.8



CVSS Equation:  (AV:N/AC:L/Au:N/C:N/I:N/A:C)



   For more information on the Common Vulnerability Scoring System

   and to obtain your specific environmental score please visit:



http://nvd.nist.gov/cvss.cfm?calculator&adv&version=2&vector=(AV:N/AC:L/Au:N/C:N/I:N/A:C)



Workarounds:



   Patched versions are available (see the "Solutions:" section

   below) or operators can prevent exploitation of this bug in any

   affected version of BIND 9 by compiling without regular expression

   support.



   Compilation without regular expression support:



  BIND 9.7 (all versions), BIND 9.8 (9.8.0 through 9.8.5b1),

  and BIND 9.9 (9.9.0 through 9.9.3b1) can be rendered completely

  safe from this bug by re-compiling the source with regular

  expression support disabled.  In order to disable inclusion

  of regular expression support:



  - After configuring BIND features as desired using the configure

script in the top level source directory, manually edit the

"config.h" header file that was produced by the configure

script.



  - Locate the line that reads "#define HAVE_REGEX_H 1" and

replace the contents of that line with "#undef

HAVE_REGEX_H".



  - Run "make clean" to remove any previously compiled object

files from the BIND 9 source directory, then proceed to

make and install BIND normally.



Active exploits:



   No known active exploits.



Solution:



   Compile BIND 9 without regular expression support as described

   in the "Workarounds" section of this advisory or upgrade to the

   patched release most closely related to your current version of

   BIND. These can be downloaded fromhttp://www.isc.org/downloads/all.



   BIND 9 version 9.8.4-P2

   BIND 9 version 9.9.2-P2



Acknowledgements:



   ISC would like to thank Matthew Horsfall of Dyn, Inc. for

   discovering this bug and bringing it to our attention.



Document Revision History:



   1.0 Phase One - Advance Notification, 11 March 2013

   1.1 Phase Two & Thre

Re: ISC Security Advisory: CVE-2013-2266: A Maliciously Crafted Regular Expression Can Cause Memory Exhaustion in named

2013-03-26 Thread ISC Support Staff 

On 3/26/13 10:05 AM, Jack Tavares wrote:


I have a request for clarification:

The workaround states to rebuild BIND with regexp support disabled.

And I see new versions of BIND have been released.
Are those versions just a rebuild with regexp support disabled?
Or are they a more comprehensive fix?


This question is addressed in the "CVE-2013-2266: FAQ and Supplemental
Information" Knowledge Base article, which I encourage everyone to read.
https://kb.isc.org/article/AA-00879

Please see specifically the section which begins:

  "What is the difference between deploying the patched versions
  of BIND versus implementing the documented workaround?"

Thanks,

Michael McNally
ISC Support
___
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

R: Question about swupdl.adobe.com

2014-10-10 Thread IDS Sas - Support 
Thanks Carl,

with your fix it works:

--
Server\Bind\bin\dig.exe @81.174.15.142 swupdl.adobe.com

; <<>> DiG 9.10.1 <<>> @81.174.15.142 swupdl.adobe.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26321
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 8, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;swupdl.adobe.com.  IN  A

;; ANSWER SECTION:
swupdl.adobe.com.   10800   IN  CNAME   swupdl.wip4.adobe.com.
swupdl.wip4.adobe.com.  600 IN  CNAME
swupdl.adobe.com.edgesuite.net.
swupdl.adobe.com.edgesuite.net. 21600 IN CNAME  a1577.d.akamai.net.
a1577.d.akamai.net. 20  IN  A   88.149.196.147
a1577.d.akamai.net. 20  IN  A   88.149.196.144

;; AUTHORITY SECTION:
d.akamai.net.   4000IN  NS  n1d.akamai.net.
d.akamai.net.   4000IN  NS  n7d.akamai.net.
d.akamai.net.   4000IN  NS  n4d.akamai.net.
d.akamai.net.   4000IN  NS  n6d.akamai.net.
d.akamai.net.   4000IN  NS  n0d.akamai.net.
d.akamai.net.   4000IN  NS  n3d.akamai.net.
d.akamai.net.   4000IN  NS  n2d.akamai.net.
d.akamai.net.   4000IN  NS  n5d.akamai.net.

;; ADDITIONAL SECTION:
n0d.akamai.net. 4000IN  A   88.221.81.194
n1d.akamai.net. 6000IN  A   88.149.196.142
n2d.akamai.net. 8000IN  A   88.221.212.76
n3d.akamai.net. 4000IN  A   213.254.249.61
n4d.akamai.net. 6000IN  A   88.149.196.143
n5d.akamai.net. 8000IN  A   88.221.212.77
n6d.akamai.net. 4000IN  A   88.149.196.141
n7d.akamai.net. 6000IN  A   88.221.212.84

;; Query time: 2370 msec
;; SERVER: 81.174.15.142#53(81.174.15.142)
;; WHEN: Fri Oct 10 10:23:48 ora legale Europa occidentale 2014
;; MSG SIZE  rcvd: 448
--

Thank you very much

Best regards

Michele


-Messaggio originale-
Da: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] Per conto di Carl Byington
Inviato: venerdì 10 ottobre 2014 0.54
A: bind-users@lists.isc.org
Oggetto: Re: Question about swupdl.adobe.com

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Thu, 2014-10-09 at 13:24 +0200, IDS Submit wrote:
> I have BIND 9.10.1 x86 and I have error on query swupdl.adobe.com

See the archives around July 3rd for previous issues with adobe.

You might add this to /etc/named.conf


// adobe servers that don't understand edns options
server 192.150.16.247   { request-sit no; };
server 192.150.19.247   { request-sit no; };
server 193.104.215.247  { request-sit no; };
// eia.gov servers that don't understand edns options
server 205.254.135.9{ request-sit no; };
server 199.36.140.199   { request-sit no; };


The following two queries demonstrate that.

dig ardownload.wip4.adobe.com @da1gtm001.adobe.com +nsid
dig ardownload.wip4.adobe.com @da1gtm001.adobe.com


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlQ3EfQACgkQL6j7milTFsHTUgCfSSkvXuoJTWwzOighxBBtCmaR
AXkAnjjqaDiPL+1EpPssUb/ZNbGidgWz
=Z/tE
-END PGP SIGNATURE-


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

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

___
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

R: Again question about edns (like swupdl.adobe.com)

2014-10-22 Thread IDS Sas - Support 
Good morning,

 

I have those Bind versions installed:

 

BIND 9.10.1-x86 in a Windows Server 32 bit

BIND 9.10.1-x64 in a Windows Server 64 bit

 

Both versions have the “SIT (Source Identity Token) EDNS option” enabled by
default.

You have DiG 9.10-P1 (May 8 2014) and my problems start with 9.10.0-P2 (June
6 2014)

 

Regards

 

Staff IDS

 

Da: Chiesa Stefano [mailto:stefano.chi...@wki.it] 
Inviato: mercoledì 22 ottobre 2014 14.44
A: IDS Submit; bind-us...@isc.org
Oggetto: R: Again question about edns (like swupdl.adobe.com)

 

Hello all.

Maybe I didn’t understand the problem but in my installation of BIND 9.10
WINDOWS I can’t replicate the error:

 

C:\>dig swupdl.adobe.com @10.39.128.11

 

; <<>> DiG 9.10-P1 <<>> swupdl.adobe.com @10.39.128.11

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43143

;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 8, ADDITIONAL: 9

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;swupdl.adobe.com.  IN  A

 

;; ANSWER SECTION:

swupdl.adobe.com.   10761   IN  CNAME   swupdl.wip4.adobe.com.

swupdl.wip4.adobe.com.  561 IN  CNAME
swupdl.adobe.com.edgesuite.net.

swupdl.adobe.com.edgesuite.net. 21561 IN CNAME  a1577.d.akamai.net.

a1577.d.akamai.net. 20  IN  A   95.101.34.43

a1577.d.akamai.net. 20  IN  A   95.101.34.51

 


-

C:\>dig www.acer.it @10.39.128.11

 

; <<>> DiG 9.10-P1 <<>> www.acer.it @10.39.128.11

;; global options: +cmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49188

;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 8, ADDITIONAL: 9

 

;; OPT PSEUDOSECTION:

; EDNS: version: 0, flags:; udp: 4096

;; QUESTION SECTION:

;www.acer.it.   IN  A

 

;; ANSWER SECTION:

www.acer.it.275 IN  CNAME   public-akamai.gtm.acer.com.

public-akamai.gtm.acer.com. 6   IN  CNAME   www.acer.com.edgesuite.net.

www.acer.com.edgesuite.net. 21576 INCNAME   a492.b.akamai.net.

a492.b.akamai.net.  20  IN  A   2.228.46.113

a492.b.akamai.net.  20  IN  A   2.228.46.122

 

Regards.

Stefano Chiesa

 

Da: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] Per conto di IDS Submit
Inviato: mercoledì 22 ottobre 2014 12:30
A: bind-us...@isc.org
Oggetto: Again question about edns (like swupdl.adobe.com)

 

Good morning, 

  

with www.acer.it I have the same problem as swupdl.adobe.com 

  

NXDOMAIN with bind 9.10 but NOERROR with Google DNS 

  

I have read the Mark Andrews reply on july 4 2014: 

-- 

It looks like nameserver vendors are not doing even rudimentry checks like
those above.  DiG has thos options so that we could perform checks like
these. 

  

Until Adobe fix their broken servers you can use a server clause to disable
sending SIT requests to them.  Obviously this does not scale. 

  

  server  { request-sit no; }; 

  

Mark 

-- 

But this doesn’t solve the problem on others domains … 

… should be possible enable “request-sit no” for all domains and not
manually add it? 

Because I think there are lot of domains with this problem L 

  

  

-- 

\Server\Bind\bin\dig.exe @81.174.15.142 www.acer.it 

  

; <<>> DiG 9.10.1 <<>> @81.174.15.142 www.acer.it 

; (1 server found) 

;; global options: +cmd 

;; Got answer: 

;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 42228 

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 

  

;; OPT PSEUDOSECTION: 

; EDNS: version: 0, flags:; udp: 4096 

;; QUESTION SECTION: 

;www.acer.it.   IN  A 

  

;; ANSWER SECTION: 

www.acer.it.300 IN  CNAME   public-akamai.gtm.acer.com. 

  

;; AUTHORITY SECTION: 

gtm.acer.com.   60  IN  SOA gtm1.acer.com.
hostmaster.gtm1.acer.com. 482 10800 3600 604800 60 

  

;; Query time: 572 msec 

;; SERVER: 81.174.15.142#53(81.174.15.142) 

;; WHEN: Wed Oct 22 12:13:12 ora legale Europa occidentale 2014 

;; MSG SIZE  rcvd: 132 

-- 

  

  

-- 

\Server\Bind\bin\dig.exe @8.8.8.8 www.acer.it 

  

; <<>> DiG 9.10.1 <<>> @8.8.8.8 www.acer.it 

; (1 server found) 

;; global options: +cmd 

;; Got answer: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34510 

;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 

  

;; OPT PSEUDOSECTION: 

; EDNS: version: 0, flags:; udp: 512 

;; QUESTION SECTION: 

;www.acer.it.   IN  A 

  

;; ANSWER SECTION: 

www.acer.it.

DDoS or Hijacking? Some tips for you delete poisoned cache

2013-06-20 Thread ISC Support Engineering Staff 
https://www.isc.org/blogs/hijacking-dns-error-ddos-what-happened-and-what-you-can-do/

>From ISC Support Engineering staff
___
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