ISC BIND & Windows

[jukka . pakkanen]

Just read from the 9.18.0 release notes that Windows is not supported.

Since don't remember reading expressly stated that Windows support would 
end with 9.16.x branch, inquiring if there is more information about 
future Windows compatibility available... is the plan to include support 
to Windows at some point, to some current or future Windows Server 
version, or is it a fact already, that no more Windows past 9.16.x?


Jukka

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

BIND 9.16.15 Windows x64 broken?

[Jukka Pakkanen]

What changed between Bind 9.16.13 and 9.16.15 Windows x64 binaries?

9.16.15 will not start at all in Server 2008 R2 Enterprise x64, 9.16.13 worked 
fine.

Only get "The service is not responding to the control function" when trying to 
start the service.

Tried this as an upgrade to the 9.16.13, or as a fresh install, same result in 
both cases.  Downgrading to 9.16.13 and works fine again.

Jukka


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

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


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

VS: VS: CNAME / TXT

[Jukka Pakkanen]

In their (mailgun) instructions to the client.  And then the client wanted us 
to include those to his zone. 

CNAME of course is useful in general, but like I wrote, *here* it is not 
needed. 

Jukka

On 23.08.20 09:59, Jukka Pakkanen wrote:
>Yes, I think the whole CNAME is useless here anyway.

CNAME is useful, but it does not (and can not) work the way you want.

>These were the recommendations of this service provider, mailgun though..

where? the CNAME issue is long known and clarifies in RFC 2181, section 10.1. 
CNAME resource records ...published in 1997.


>Lähettäjä: bind-users  Puolesta Ben 
>Croswell
>Lähetetty: 23. elokuuta 2020 2:24
>Vastaanottaja: ML BIND Users 
>Aihe: Re: CNAME / TXT
>
>If you uncomment that mg CNAME you end up with a CNAME mx and TXT at the same 
>node in to the DNS tree and that is illegal. That is why you get the error 
>"cname and other data". The mx and txt are the other data.
>On Sat, Aug 22, 2020, 8:19 PM Jukka Pakkanen 
>mailto:jukka.pakka...@qnet.fi>> wrote:
>Cannot figure out what is wrong here… must be something simple but 
>after sitting in airplanes the last 40 hours and it’s 2am…
>
>Only when I comment out the two lines in the end of the named.harriot, it goes 
>through and BIND load the zone. With those two lines, get the following:
>
>C:\DNS\etc\namedb>named-checkzone harriot.fi<http://harriot.fi> 
>named.harriot
>dns_master_load: named.harriot:33: mg.harriot.fi<http://mg.harriot.fi>: 
>CNAME and other data
>dns_rdata_fromtext: named.harriot:35: syntax error zone 
>harriot.fi/IN<http://harriot.fi/IN>: loading from master file 
>named.harriot failed: CNAME and other data zone 
>harriot.fi/IN<http://harriot.fi/IN>: not loaded due to errors.
>
>;
>;File:  named.harriot
>;
>
>$TTL 864
>
>@IN SOA  ns1.qnet.fi<http://ns1.qnet.fi>. 
>helpdesk.qnet.fi<http://helpdesk.qnet.fi>. (
> 202008243  ; serial number
> 28800  ; refresh every 12 hours
>  7200  ; retry after 2 hours
>604800  ; expire after 2 weeks
>  3600) ; default ttl is 2 days
>
>harriot.fi<http://harriot.fi>.   IN A  
>35.214.111.143
>  IN MX 10 
> qntsrv8.qnet.fi<http://qntsrv8.qnet.fi>.
>  IN MX 10 
> qntsrv9.qnet.fi<http://qntsrv9.qnet.fi>.
> IN NS 
> ns1.qnet.fi<http://ns1.qnet.fi>.
> IN NS 
> ns2.qnet.fi<http://ns2.qnet.fi>.
> IN NS 
> ns3.qnet.fi<http://ns3.qnet.fi>.
>  IN NS 
> ns1.z.fi<http://ns1.z.fi>.
>  IN NS 
> ns2.z.fi<http://ns2.z.fi>.
>
>wwwIN A 35.214.111.143
>api IN A 35.214.111.143
>webmailIN CNAME mail.qnet.fi<http://mail.qnet.fi>.
>_autodiscover._tcp  IN SRV 0 5 443 mail.qnet.fi<http://mail.qnet.fi>.
>
>dev
>   IN A  35.214.111.143
>
>; mg   
>   IN CNAME eu.mailgun.org<http://eu.mailgun.org>.
>mg 
>IN MX 10 mxa.eu.mailgun.org<http://mxa.eu.mailgun.org>.
>mg 
>IN MX 10 mxb.eu.mailgun.org<http://mxb.eu.mailgun.org>.
>mg 
>IN TXTv=spf1 include:eu.mailgun.org<http://eu.mailgun.org> 
>~all
>
>; smtp_domainkey.mg<http://smtp_domainkey.mg> IN TXT "k=rsa; 
>p=MII-AQAB"
>
>
>
>___
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>unsubscribe from this list
>
>ISC funds the development of this software with paid support subscriptions. 
>Contact us at https://www.isc.org/contact/ for more information.
>
>
>bind-users mailing list
>bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
>https://lists.isc.org/mailman/listinfo/bind-users

>___
>Please visit https://lists.isc.org/mail

VS: CNAME / TXT

[Jukka Pakkanen]

Yes, I think the whole CNAME is useless here anyway.

These were the recommendations of this service provider, mailgun though..

Thx, Jukka

Lähettäjä: bind-users  Puolesta Ben Croswell
Lähetetty: 23. elokuuta 2020 2:24
Vastaanottaja: ML BIND Users 
Aihe: Re: CNAME / TXT

If you uncomment that mg CNAME you end up with a CNAME mx and TXT at the same 
node in to the DNS tree and that is illegal. That is why you get the error 
"cname and other data". The mx and txt are the other data.
On Sat, Aug 22, 2020, 8:19 PM Jukka Pakkanen 
mailto:jukka.pakka...@qnet.fi>> wrote:
Cannot figure out what is wrong here… must be something simple but after 
sitting in airplanes the last 40 hours and it’s 2am…

Only when I comment out the two lines in the end of the named.harriot, it goes 
through and BIND load the zone. With those two lines, get the following:

C:\DNS\etc\namedb>named-checkzone harriot.fi<http://harriot.fi> named.harriot
dns_master_load: named.harriot:33: mg.harriot.fi<http://mg.harriot.fi>: CNAME 
and other data
dns_rdata_fromtext: named.harriot:35: syntax error
zone harriot.fi/IN<http://harriot.fi/IN>: loading from master file 
named.harriot failed: CNAME and other data
zone harriot.fi/IN<http://harriot.fi/IN>: not loaded due to errors.

;
;File:  named.harriot
;

$TTL 864

@IN SOA  ns1.qnet.fi<http://ns1.qnet.fi>. 
helpdesk.qnet.fi<http://helpdesk.qnet.fi>. (
 202008243  ; serial number
 28800  ; refresh every 12 hours
  7200  ; retry after 2 hours
604800  ; expire after 2 weeks
  3600) ; default ttl is 2 days

harriot.fi<http://harriot.fi>.   IN A  
35.214.111.143
  IN MX 10 
qntsrv8.qnet.fi<http://qntsrv8.qnet.fi>.
  IN MX 10 
qntsrv9.qnet.fi<http://qntsrv9.qnet.fi>.
 IN NS 
ns1.qnet.fi<http://ns1.qnet.fi>.
 IN NS 
ns2.qnet.fi<http://ns2.qnet.fi>.
 IN NS 
ns3.qnet.fi<http://ns3.qnet.fi>.
  IN NS 
ns1.z.fi<http://ns1.z.fi>.
  IN NS 
ns2.z.fi<http://ns2.z.fi>.

wwwIN A 35.214.111.143
api IN A 35.214.111.143
webmailIN CNAME mail.qnet.fi<http://mail.qnet.fi>.
_autodiscover._tcp  IN SRV 0 5 443 mail.qnet.fi<http://mail.qnet.fi>.

dev 
  IN A  35.214.111.143

; mg
  IN CNAME eu.mailgun.org<http://eu.mailgun.org>.
mg  
   IN MX 10 mxa.eu.mailgun.org<http://mxa.eu.mailgun.org>.
mg  
   IN MX 10 mxb.eu.mailgun.org<http://mxb.eu.mailgun.org>.
mg  
   IN TXTv=spf1 include:eu.mailgun.org<http://eu.mailgun.org> 
~all

; smtp_domainkey.mg<http://smtp_domainkey.mg> IN TXT "k=rsa; 
p=MII-AQAB"



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

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


bind-users mailing list
bind-users@lists.isc.org<mailto: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

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

VS: CNAME / TXT

[Jukka Pakkanen]

401 characters… so that’a another problem. Thx.


Lähettäjä: Kyongseon West 
Lähetetty: 23. elokuuta 2020 3:16
Vastaanottaja: Jukka Pakkanen 
Kopio: bind-us...@isc.org
Aihe: Re: CNAME / TXT

How long is the character in txt line? If it’s longer than 255, it will show 
that exact error. Exact thing happened to me yesterday.

You can separate with a quote to make it work.
https://kb.isc.org/docs/aa-00356


v/r,

Kathy West, CISSP
IT Services
Indiana University of Pennsylvania
724-357-3216
kw...@iup.edu<mailto:kw...@iup.edu>


On Aug 22, 2020, at 8:19 PM, Jukka Pakkanen 
mailto:jukka.pakka...@qnet.fi>> wrote:

Cannot figure out what is wrong here… must be something simple but after 
sitting in airplanes the last 40 hours and it’s 2am…

Only when I comment out the two lines in the end of the named.harriot, it goes 
through and BIND load the zone. With those two lines, get the following:

C:\DNS\etc\namedb>named-checkzone harriot.fi named.harriot
dns_master_load: named.harriot:33: mg.harriot.fi: CNAME and other data
dns_rdata_fromtext: named.harriot:35: syntax error
zone harriot.fi/IN: loading from master file named.harriot failed: CNAME and 
other data
zone harriot.fi/IN: not loaded due to errors.

;
;File:  named.harriot
;

$TTL 864

@IN SOA  ns1.qnet.fi. helpdesk.qnet.fi. (
 202008243  ; serial number
 28800  ; refresh every 12 hours
  7200  ; retry after 2 hours
604800  ; expire after 2 weeks
  3600) ; default ttl is 2 days

harriot.fi.   IN A  35.214.111.143
  IN MX 10 
qntsrv8.qnet.fi.
  IN MX 10 
qntsrv9.qnet.fi.
 IN NS ns1.qnet.fi.
 IN NS ns2.qnet.fi.
 IN NS ns3.qnet.fi.
  IN NS ns1.z.fi.
  IN NS ns2.z.fi.

wwwIN A 35.214.111.143
api IN A 35.214.111.143
webmailIN CNAME mail.qnet.fi.
_autodiscover._tcp  IN SRV 0 5 443 mail.qnet.fi.

dev 
  IN A  35.214.111.143

; mg
  IN CNAME eu.mailgun.org.
mg  
   IN MX 10 mxa.eu.mailgun.org.
mg  
   IN MX 10 mxb.eu.mailgun.org.
mg  
   IN TXTv=spf1 include:eu.mailgun.org ~all

; smtp_domainkey.mg IN TXT "k=rsa; p=MII-AQAB"





___
Please visit 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=02%7C01%7Ckwest%40iup.edu%7Ca75aa7ecb8274759774508d846fa318c%7C96704ed7a3e14bb8ba918b63ee16883e%7C0%7C0%7C637337387679615439sdata=dErmGy3Lw%2BZcSJWADnGaIRngbH9HUybmUA8aZTg7a9w%3Dreserved=0
 to unsubscribe from this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at 
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.isc.org%2Fcontact%2Fdata=02%7C01%7Ckwest%40iup.edu%7Ca75aa7ecb8274759774508d846fa318c%7C96704ed7a3e14bb8ba918b63ee16883e%7C0%7C0%7C637337387679615439sdata=Yn%2BtYlW2dCzEJ80f55HM7VpFMmbeoEV5YbsLTDxb0go%3Dreserved=0
 for more information.


bind-users mailing list
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.isc.org%2Fmailman%2Flistinfo%2Fbind-usersdata=02%7C01%7Ckwest%40iup.edu%7Ca75aa7ecb8274759774508d846fa318c%7C96704ed7a3e14bb8ba918b63ee16883e%7C0%7C0%7C637337387679615439sdata=dErmGy3Lw%2BZcSJWADnGaIRngbH9HUybmUA8aZTg7a9w%3Dreserved=0
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

CNAME / TXT

[Jukka Pakkanen]

Cannot figure out what is wrong here... must be something simple but after 
sitting in airplanes the last 40 hours and it's 2am...

Only when I comment out the two lines in the end of the named.harriot, it goes 
through and BIND load the zone. With those two lines, get the following:

C:\DNS\etc\namedb>named-checkzone harriot.fi named.harriot
dns_master_load: named.harriot:33: mg.harriot.fi: CNAME and other data
dns_rdata_fromtext: named.harriot:35: syntax error
zone harriot.fi/IN: loading from master file named.harriot failed: CNAME and 
other data
zone harriot.fi/IN: not loaded due to errors.

;
;File:  named.harriot
;

$TTL 864

@IN SOA  ns1.qnet.fi. helpdesk.qnet.fi. (
 202008243  ; serial number
 28800  ; refresh every 12 hours
  7200  ; retry after 2 hours
604800  ; expire after 2 weeks
  3600) ; default ttl is 2 days

harriot.fi.   IN A  35.214.111.143
  IN MX 10 
qntsrv8.qnet.fi.
  IN MX 10 
qntsrv9.qnet.fi.
 IN NS ns1.qnet.fi.
 IN NS ns2.qnet.fi.
 IN NS ns3.qnet.fi.
  IN NS ns1.z.fi.
  IN NS ns2.z.fi.

wwwIN A 35.214.111.143
api IN A 35.214.111.143
webmailIN CNAME mail.qnet.fi.
_autodiscover._tcp  IN SRV 0 5 443 mail.qnet.fi.

dev 
  IN A  35.214.111.143

; mg
  IN CNAME eu.mailgun.org.
mg  
   IN MX 10 mxa.eu.mailgun.org.
mg  
   IN MX 10 mxb.eu.mailgun.org.
mg  
   IN TXTv=spf1 include:eu.mailgun.org ~all

; smtp_domainkey.mg IN TXT "k=rsa; p=MII-AQAB"




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

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


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

VS: Dumb Question is an A or AAAA record required?

[Jukka Pakkanen]

Many spammers send in addition to MX to A records, if available.  Still, it is 
a good practice to not to publish an A record for the mail zone, if not 
specifically needed for something else.  Of course if it points to somewhere 
else than the receiving SMTP server, not much harm done mail-traffic-wise.


Jukka

-Alkuperäinen viesti-
Lähettäjä: bind-users  Puolesta Matthew 
Richardson
Lähetetty: 9. heinäkuuta 2020 16:06
Vastaanottaja: bind-users 
Aihe: Re: Dumb Question is an A or  record required?

On a related issues there were (perhaps long ago) issues if the A record for a 
domain had an SMTP server on it, where email could sometimes be delivered to 
that A record rather than the MX.  I had (again long ago:
10-15 years) actually seen this occur.

Do people think that this problem could still occur these days?  What sort of 
transient (presumably DNS) failure might cause an SMTP server to deliver to A 
rather than MX?

Best wishes,
Matthew

 --
>From: Anand Buddhdev 
>To: "@lbutlr" , bind-users 
>
>Cc: 
>Date: Thu, 9 Jul 2020 14:43:04 +0200
>Subject: Re: Dumb Question is an A or  record required?

>On 09/07/2020 14:21, @lbutlr wrote:
>
>> Given a domain that is hosted and used for email and web, is an A 
>> record for that domain actually required?
>
>It's not *required*. But see below.
>
>> That is, if bob.tld is hosted by example.com can you simply have
>> 
>>  NS ns1.example.com
>>  NS ns2.example.com
>>  MX mx.example.com
>> 
>> www  CNAME www.example.com
>> 
>> Without specifying
>> 
>>  A 11.22.33.444
>
>These days, many folk try to reach websites by typing just the bare 
>domain name without the "www" prefix.
>
>If a user types "bob.tld" into a browser, the browser will issue an 
>address lookup for "bob.tld", causing the resolver to ask for A and 
> records for "bob.tld". If you don't have an A record at the zone 
>apex, the browser will not get back any address and display an error 
>message for the user. An alert user might try "www.bob.tld" but most 
>users are likely to just give up.
>
>So while it's not *required* to have an address record at the apex, 
>it's good practice to have one.
>
>Anand
>___
>Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>unsubscribe from this list
>
>ISC funds the development of this software with paid support subscriptions. 
>Contact us at https://www.isc.org/contact/ for more information.
>
>
>bind-users mailing list
>bind-users@lists.isc.org
>https://lists.isc.org/mailman/listinfo/bind-users

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

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


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

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

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


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

VS: Dumb Question is an A or AAAA record required?

[Jukka Pakkanen]

Only CNAME is perfectly fine, except if you want the site work without the 
www-prefix like someone already pointed out.  Of course there must be A record 
for that name where the cname points to somewhere, but I read the question that 
this is not your concern.

Jukka

-Alkuperäinen viesti-
Lähettäjä: bind-users  Puolesta @lbutlr
Lähetetty: 9. heinäkuuta 2020 14:22
Vastaanottaja: bind-users 
Aihe: Dumb Question is an A or  record required?

Given a domain that is hosted and used for email and web, is an A record for 
that domain actually required?

That is, if bob.tld is hosted by example.com can you simply have

NS ns1.example.com
NS ns2.example.com
MX mx.example.com

www CNAME www.example.com

Without specifying 

A 11.22.33.444

(I am pretty sure this is *technically* allowed, but is it really OK to do or 
are there reasons not to do this?)



-- 
And there were all the stars, looking remarkably like powered
diamonds spilled on black velvet, the stars that lured and
ultimately called the boldest towards them…

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

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


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

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


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

VS: A And Cname-record

[Jukka Pakkanen]

Yes but before going to RFC details one should check the basic spelling and 
syntax first...

-Alkuperäinen viesti-
Lähettäjä: bind-users  Puolesta Mark Andrews
Lähetetty: 18. kesäkuuta 2020 0:27
Vastaanottaja: Bogdan-Stefan Rotariu 
Kopio: bind-users@lists.isc.org
Aihe: Re: A And Cname-record



> On 18 Jun 2020, at 07:56, Bogdan-Stefan Rotariu  wrote:
> 
> Hi,
> 
>> On 18 Jun 2020, at 00:44, Ejaz Ahmed  wrote:
>> 
>> when i am trying to add A and CNAME record together  for the same 
>> subdomain, getting an error as below, you all kind  assistance would 
>> be highly appreciated thanks in  advance
>> 
>> my records are as follows in zone
>> 
>> auotdiscover IN A 1.1.1.1
>> autodiscover IN CNAME autodiscover.acig.com.sa
>> 
>> ==
>> dns_master_load: acig.com.sa.hosts:102: autodiscover.acig.com.sa: 
>> CNAME and other data
>> 
>> zone acig.com.sa/IN: loading from master file acig.com.sa.hosts 
>> failed: CNAME and other data
>> 
>> zone acig.com.sa/IN: not loaded due to errors
> 
> CNAME records cannot coexist with any other records last time I’ve 
> checked. See section 2.4 from RFC1912[1]
> 
> [1] https://tools.ietf.org/html/rfc1912

Well it actually goes back to RFC 1034.  Unfortunately it wasn’t enforced in 
nameservers at the beginning and is still not enforced by some servers.

3.6.2. Aliases and canonical names

...

The domain system provides such a feature using the canonical name
(CNAME) RR.  A CNAME RR identifies its owner name as an alias, and specifies 
the corresponding canonical name in the RDATA section of the RR.  If a CNAME RR 
is present at a node, no other data should be present; this ensures that the 
data for a canonical name and its aliases cannot be different.  This rule also 
insures that a cached CNAME can be used without checking with an authoritative 
server for other RR types.

Mark

> —
> Bogdan-Stefan Rotariu
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

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

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
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

VS: A And Cname-record

[Jukka Pakkanen]

Including the trailing dots…

Lähettäjä: bind-users  Puolesta Jukka Pakkanen
Lähetetty: 17. kesäkuuta 2020 23:51
Vastaanottaja: Ejaz Ahmed ; bind-users@lists.isc.org
Aihe: VS: A And Cname-record

Check at least the spelling…

Lähettäjä: bind-users 
mailto:bind-users-boun...@lists.isc.org>> 
Puolesta Ejaz Ahmed
Lähetetty: 17. kesäkuuta 2020 23:44
Vastaanottaja: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Aihe: A And Cname-record

when i am trying to add A and CNAME record together  for the same subdomain, 
getting an error as below, you all kind  assistance would be highly appreciated 
thanks in  advance

my records are as follows in zone

auotdiscover IN A 1.1.1.1
autodiscover IN CNAME autodiscover.acig.com.sa<http://autodiscover.acig.com.sa>

==
dns_master_load: acig.com.sa.hosts:102: 
autodiscover.a<http://autodiscover.acig.com.sa/>cig.com.sa<http://cig.com.sa>: 
CNAME and other data
zone acig.com.sa/IN<http://acig.com.sa/IN>: loading from master file 
acig.com.sa.hosts failed: CNAME and other data
zone acig.com.sa/IN<http://acig.com.sa/IN>: not loaded due to errors


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

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


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

VS: A And Cname-record

[Jukka Pakkanen]

Check at least the spelling…

Lähettäjä: bind-users  Puolesta Ejaz Ahmed
Lähetetty: 17. kesäkuuta 2020 23:44
Vastaanottaja: bind-users@lists.isc.org
Aihe: A And Cname-record

when i am trying to add A and CNAME record together  for the same subdomain, 
getting an error as below, you all kind  assistance would be highly appreciated 
thanks in  advance

my records are as follows in zone

auotdiscover IN A 1.1.1.1
autodiscover IN CNAME autodiscover.acig.com.sa

==
dns_master_load: acig.com.sa.hosts:102: 
autodiscover.acig.com.sa: 
CNAME and other data
zone acig.com.sa/IN: loading from master file 
acig.com.sa.hosts failed: CNAME and other data
zone acig.com.sa/IN: not loaded due to errors


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

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


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

VS: VS: DNS Misconfiguration on- http://cyberia.net.sa/

[Jukka Pakkanen]

Yes but I think the rfc1537 refers, and the recommendation always was 
"localhost." hostname, which refers to name "localhost", not 
"localhost.domain". Then I guess, this was already wrong in the O'Reilly "DNS 
and BIND" book (have to check that), which I remember using as a guideline to 
set up our first domains/zones.  And from that, the setting was copied later on 
to all new domains too.

Jukka

-Alkuperäinen viesti-
Lähettäjä: Tony Finch  
Lähetetty: 5. kesäkuuta 2020 16:09
Vastaanottaja: Jukka Pakkanen 
Kopio: Ondřej Surý ; bind-users@lists.isc.org
Aihe: Re: VS: DNS Misconfiguration on- http://cyberia.net.sa/

Jukka Pakkanen  wrote:

> Thx for the info, had missed this one and actually we have that minor 
> misconfiguration too. Have had since 1995 when started our nameservers 
> and never noticed...

Yes, it used to be recommended -
https://tools.ietf.org/html/rfc1537#section-10

But not any more, because -
https://seclists.org/bugtraq/2008/Jan/270

I also only found out about this recently(ish) - 
https://www.dns.cam.ac.uk/news/2017-09-01-localhost.html

Tony.
--
f.anthony.n.finchhttp://dotat.at/ Tyne, Dogger: Northwest 5 
or 6, backing southwest 6 to gale 8, then becoming cyclonic 5 to 7 later. 
Slight or moderate, becoming rough for a time. Rain or thundery showers. Good, 
occasionally poor.

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

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


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

VS: DNS Misconfiguration on- http://cyberia.net.sa/

[Jukka Pakkanen]

Thx for the info, had missed this one and actually we have that minor 
misconfiguration too. Have had since 1995 when started our nameservers and 
never noticed...

Jukka

-Alkuperäinen viesti-
Lähettäjä: Ondřej Surý  
Lähetetty: 5. kesäkuuta 2020 11:53
Vastaanottaja: Jukka Pakkanen 
Kopio: Ejaz Ahmed ; bind-users@lists.isc.org
Aihe: Re: DNS Misconfiguration on- http://cyberia.net.sa/

The localhost. is not scam, but the

„I found this on HackerOne and I now want money“ is scam.

Remove the localhost entry from the zone, but you should not pay money for 
issues that can be produced by automated scanners.

HackerOne is doing everyone disfavor by paying nonsensical amounts of money[*] 
for small issues like this. They (and other wealthy companies) should be paying 
money only for original security research and not this nonsense.

* $100 is a helluva money in some economies...

Ondrej
--
Ondřej Surý
ond...@isc.org

> On 5 Jun 2020, at 11:24, Jukka Pakkanen  wrote:
> 
> Complete scam, ignore.
> 
> Just check the “securityfocus” link, it’s fake too.
> 
> Jukka
> 
> Lähettäjä: bind-users  Puolesta Ejaz 
> Ahmed
> Lähetetty: 5. kesäkuuta 2020 10:55
> Vastaanottaja: bind-users@lists.isc.org
> Aihe: Fwd: DNS Misconfiguration on- http://cyberia.net.sa/
> 
> 
> 
> 
> Some one is is claiming that our name server 212.118.64.2 is 
> vulnerable with below information is this true
> 
> Any suggestions would be appreciated
> 
> Thanks a n advance
> 
> Ejaz
> 
> 
> 
> 
> Dear CYBERIA GROUP Security Team ,
> 
> I Rahul a Ethical Hacker and Security Researcher. I found a vulnerability on 
> your website that is DNS Misconfiguration .
> 
> Your localhost.cyberia.net.sa   has address 127.0.0.1 and this may lead to 
> "Same- Site" Scripting. I can also ping the localhost network.
> 
> 
> Here is detailed description of this minor security issue : 
> http://www.securityfocus.com/archive/1/486606/30/0/threaded
> 
> Find attached POC  Video.
> 
> Dear Team Waiting for your response and I want bounty(money) with an 
> Appreciation letter for my work and effort which I have given for
> 
> 
> Thanks in advance
> Ejaz
> 
> 
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> 
> ISC funds the development of this software with paid support subscriptions. 
> Contact us at https://www.isc.org/contact/ for more information.
> 
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

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


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

VS: DNS Misconfiguration on- http://cyberia.net.sa/

[Jukka Pakkanen]

Complete scam, ignore.

Just check the “securityfocus” link, it’s fake too.

Jukka

Lähettäjä: bind-users  Puolesta Ejaz Ahmed
Lähetetty: 5. kesäkuuta 2020 10:55
Vastaanottaja: bind-users@lists.isc.org
Aihe: Fwd: DNS Misconfiguration on- http://cyberia.net.sa/



Some one is is claiming that our name server 212.118.64.2 is vulnerable with 
below information is this true

Any suggestions would be appreciated

Thanks a n advance

Ejaz



Dear CYBERIA GROUP Security Team ,

I Rahul a Ethical Hacker and Security Researcher. I found a vulnerability on 
your website that is DNS Misconfiguration .

Your localhost.cyberia.net.sa   has address 
127.0.0.1 and this may lead to "Same- Site" Scripting. I can also ping the 
localhost network.


Here is detailed description of this minor security issue : 
http://www.securityfocus.com/archive/1/486606/30/0/threaded

Find attached POC  Video.

Dear Team Waiting for your response and I want bounty(money) with an 
Appreciation letter for my work and effort which I have given for


Thanks in advance
Ejaz







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

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


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

VS: Change DNSSEC algorithm and switch to use KASP

[Jukka Pakkanen]

I just did the same operation in our BIND servers, converted all DNSSEC enabled 
zones with different algorithms to KASP/dnssec-policy and ecdsa256/13.

All I did was replaced the two lines in named.conf:

inline-signing yes;
auto-dnssec maintain;

to 

   dnssec-policy "ecdsa256";

And of course created the policy there too.

If the algorithm in the zone was changed (previously something else than "13"), 
updated the DS record at the registrar as well.

Worked out smoothly, ok there was a brief moment before the new DS was 
published and zone secured again, but did this at night time, at the morning 
everything was perfect, and now all zones using that policy.

Jukka


-Alkuperäinen viesti-
Lähettäjä: bind-users  Puolesta Matthias 
Fechner
Lähetetty: 25. huhtikuuta 2020 10:08
Vastaanottaja: bind-users@lists.isc.org
Aihe: Change DNSSEC algorithm and switch to use KASP

Dear all,

I followed now the series here (again, thanks a lot to make this public!):
https://www.youtube.com/watch?v=MheHMWCOTvE=PLUwyH0o3uuICgnbQj_lQajRI_CzewZr7q

Just now I only sign one domain which is using the "auto-dnssec maintain;".
What I understood from the series is that KASP does not support switching from 
"auto-dnssec maintain" to KASP, yet.

As my single domain is using RSASHA256 and I want to use one algorithm
(ECDSA256)  for each domain I maintain in my DNS servers (to would like to have 
a clean start with KASP).
I just wanted to make sure I do not break this single domain
(fechner.net) which is already signed.
I cannot remove DNSSEC before the DS has disappeared on the parent.

What I understood so far is using the following procedure (to disable DNSSEC 
for this single specific domain):
- ask the parent zone to remove the DS (as long as the DS exists in the parent 
zone I must not remove DNSSEC as that would break the zone)
- after the DS disappeared in the parent zone, wait for at least the TTL of the 
DS (86400) + maybe one day (safety)
- now my zone does not require to have DNSSEC and I can remove DNSSEC
- instruct bind to delete the key using dnssec-settime to remove the key 
(dnssec-settime -I +1d -D +2d keyfile)
- wait 2 days
- check no RRSIGS are existing for the domain
- wait for one day (TTL) + 1 say (safety) = at least 2 days
- now start to use KASP and let it create keys and sign your zone using
ecdsa256 (is this a recommended algo for using DNSSEC?)
- wait till CDS and CDNSKEY appears in the zone (bind ensures here the TTLs 
match, so it will not add the CDS before required time is passed)
- ask parent to add the DS to their zone
- the moment the DS is added on parent, DNSSEC is enforced

If I do not ask the parent to add the DS key, I can keep DNSSEC for the zones, 
but it will not be enforced or?
(this does not work if the registra would import the DS because CDS and CDNSKEY 
keys are existing, so be carefull here)

I'm talking here about zone fechner.net.

The TTL on the parent seems to be 86400:
dig +dnssec +multi -t DS fechner.net. @A.GTLD-SERVERS.NET ...
fechner.net.    86400 IN DS 64539 10 2 (
    12860767104BEE7B250F03B5D03425BC978F65CB426E
    EDC9C9B541AFB5D52D8D ) fechner.net.    
86400 IN DS 64539 10 1 (
    81EF72A9B9D92A9FD4F50856D1371DA05F5ACC27 ) ...

The TTL in my zone is also 86400, so I used this for all waiting times.

Thanks a lot for any comments!

Gruß
Matthias

-- 

"Programming today is a race between software engineers striving to build 
bigger and better idiot-proof programs, and the universe trying to produce 
bigger and better idiots. So far, the universe is winning." -- Rich Cook


___
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

VS: 9.16.2 / DNSSEC / DS records

[Jukka Pakkanen]

Thanks!

-Alkuperäinen viesti-
Lähettäjä: Mark Andrews  
Lähetetty: 16. huhtikuuta 2020 2:30
Vastaanottaja: Jukka Pakkanen 
Kopio: bind-us...@isc.org
Aihe: Re: 9.16.2 / DNSSEC / DS records



> On 16 Apr 2020, at 09:21, Jukka Pakkanen  wrote:
> 
> Updating from 9.14.11 to 9.16.2, and migrating existing signed zones to 
> dnssec-policy, and have couple questions, probably quite trivial…
> 
> We have signed zones with different key algorithms, now I want everything 
> under the same ecdsa256 policy.  I guess when the key algorithm changes, 
> example from 8 to 13, we need to update the DS key at the registrar as well?

Yes.

> About the DS keys, where can I find or retrieve them after the zone is 
> automatically resigned by the dnssec-policy, to insert in to Hover.com’s zone 
> data?

dnssec-policy will publish CDS and CDNSKEY records after the right amount of 
time and if your registrar is checking they will automatically update the DS 
RRset in the parent zone.  Otherwise you can use dnssec-dsfromkey to generate 
DS records from the DNSKEY records.

> The Finnish Traficom .fi root service was able to retrieve the new DS records 
> it self, but for Hover need to insert them manually.
> 
> Do I need to keep the old DS records at the registrar for some period of 
> time, of can I just swap the information there, without breaking anything?

You can swap but note you need to wait until all caches are free of the records 
they where only signed with algorithm 8.  Once the DS records are published you 
have to wait until all old DS records that listed algorithm 8 have cleared from 
caches before you stop signing with algorithm 8.  There should be no CDS or 
CDNSKEY records for algorithm 8 when you do this.

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

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


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

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

VS: 9.16.2 / DNSSEC / DS records

[Jukka Pakkanen]

And yet, after updating Gemtrade.fi to dnssec-policy, ZSK and KSK both "13", 
and updating the DS record at the .fi root, I still get:

(algorithm 13 not supportedsignature verification failed)

In Verisign DNSSEC verifier.


Lähettäjä: bind-users  Puolesta Jukka Pakkanen
Lähetetty: 16. huhtikuuta 2020 1:22
Vastaanottaja: bind-us...@isc.org
Aihe: 9.16.2 / DNSSEC / DS records

Updating from 9.14.11 to 9.16.2, and migrating existing signed zones to 
dnssec-policy, and have couple questions, probably quite trivial...

We have signed zones with different key algorithms, now I want everything under 
the same ecdsa256 policy.  I guess when the key algorithm changes, example from 
8 to 13, we need to update the DS key at the registrar as well?

About the DS keys, where can I find or retrieve them after the zone is 
automatically resigned by the dnssec-policy, to insert in to Hover.com's zone 
data?

The Finnish Traficom .fi root service was able to retrieve the new DS records 
it self, but for Hover need to insert them manually.

Do I need to keep the old DS records at the registrar for some period of time, 
of can I just swap the information there, without breaking anything?
___
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

9.16.2 / DNSSEC / DS records

[Jukka Pakkanen]

Updating from 9.14.11 to 9.16.2, and migrating existing signed zones to 
dnssec-policy, and have couple questions, probably quite trivial...

We have signed zones with different key algorithms, now I want everything under 
the same ecdsa256 policy.  I guess when the key algorithm changes, example from 
8 to 13, we need to update the DS key at the registrar as well?

About the DS keys, where can I find or retrieve them after the zone is 
automatically resigned by the dnssec-policy, to insert in to Hover.com's zone 
data?

The Finnish Traficom .fi root service was able to retrieve the new DS records 
it self, but for Hover need to insert them manually.

Do I need to keep the old DS records at the registrar for some period of time, 
of can I just swap the information there, without breaking anything?
___
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

VS: Advice on balancing web traffic using geoip ACls

[Jukka Pakkanen]

Hi, at the download page the status of 9.16 is “Current-Stable” but it also 
states “only for testing & evalution, *not* recommended for production”?

Can you confirm if the DNSSEC inline-signing problem (signing just stops 
sometimes, affects both 9.11 and 9.14 branch) is present in this or not?  I 
read from the docs that 9.16 had some work to inline signing done, maybe works 
better in that regards too?

Jukka

Lähettäjä: bind-users  Puolesta Victoria Risk
Lähetetty: 23. helmikuuta 2020 20:35
Vastaanottaja: @lbutlr 
Kopio: bind-users 
Aihe: Re: Advice on balancing web traffic using geoip ACls

…
9.14 has just been replaced by 9.16, released just this past week. We will 
continue offering security releases for 9.14 for a 3-month period to support 
migration to 9.16. Someone doing a migration today should look at 9.16 rather 
than 9.14.
…


Victoria Risk
Product Manager
Internet Systems Consortium
vi...@isc.org




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

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

VS: Bind 9.11.13 - inline re-signing stops

[Jukka Pakkanen]

Like reported earlier, this same behavior/problem occurs also in 9.14.x branch, 
hopefully the fix will be found quickly, it is quite disturbing problem.

Jukka

-Alkuperäinen viesti-
Lähettäjä: bind-users  Puolesta Ondrej Surý
Lähetetty: 19. helmikuuta 2020 7:17
Vastaanottaja: Matthew Richardson 
Kopio: bind-users@lists.isc.org
Aihe: Re: Bind 9.11.13 - inline re-signing stops

Matthew,

thank you for the report. Indeed, we have received some more reports about this 
particular issue and we are currently investigating it.

We would appreciate if anybody who encounters the problem could dump the core 
first before restarting the named, so we have more evidence to analyze.

Ondrej
--
Ondřej Surý — ISC

> On 18 Feb 2020, at 23:22, Matthew Richardson  
> wrote:
> 
> Having upgraded to 9.11.15 I am still seeing similar problems, where 
> some zones stop updating their signatures.  I have a suspicion that 
> "rndc reconfig" might get them re-signing, or perhaps updating the 
> serial of the unsigned zone.
> 
> I have logged it on GitLab as #1627, and will take your advice of 
> marking it private as I will be uploading config, zonefiles and logs.  
> If the attachments are removed, I am happy for it to be public as they 
> are the only confidential part.
> 
> Best wishes,
> Matthew
> --
>> From: Ond?ej Surý 
>> To: Matthew Richardson 
>> Cc: bind-users@lists.isc.org
>> Date: Wed, 5 Feb 2020 20:02:17 +0100
>> Subject: Re: Bind 9.11.13 - inline re-signing stops
> 
>> Hi Matthew,
>> 
>> we have fixed a data race in a related code in BIND 9.11.15.
>> 
>> However, if you can get us a coredump using gdb and tar it with associated 
>> binary and libraries, we might be able to look into it. ISC GitLab should 
>> have enough limit to accept tar.xz, make sure you set the issue as 
>> confidential, we will sanitize it before making the issue public in the 
>> future. You may use pandora.isc.org to drop of larger files in a 
>> confidential matter and link it to the GitLab issue.
>> 
>> Ond?ej
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

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

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

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

VS: Bind 9.11.13 - inline re-signing stops

[Jukka Pakkanen]

..except our problem is with the 9.14.9 version/branch.


-Alkuperäinen viesti-
Lähettäjä: Jukka Pakkanen 
Lähetetty: 5. helmikuuta 2020 23:52
Vastaanottaja: 'Matthew Richardson' ; 
bind-users@lists.isc.org
Aihe: VS: Bind 9.11.13 - inline re-signing stops

Maybe related to your earlier reported problem, when signed zonedata is not 
updated after updates to the zone?

And what I already read about 9.11.15, hopefully fixed there.

Jukka

-Alkuperäinen viesti-
Lähettäjä: bind-users  Puolesta Matthew 
Richardson
Lähetetty: 5. helmikuuta 2020 19:28
Vastaanottaja: bind-users@lists.isc.org
Aihe: Bind 9.11.13 - inline re-signing stops

I have an interesting issue with a hidden master running 9.11.13 and configured 
with inline signing on a number of zones, configured thus:-

>zone "42.201.193.in-addr.arpa" {
>type master;
>file "zones/master/42.201.193.in-addr.arpa.db";
>inline-signing yes;
>auto-dnssec maintain;
>};

Prior to 30 January, all the zones configured in this way were regurlarly being 
resigned, logging entries such as:-

>29-Jan-2020 03:37:02.129 general: info: zone 42.201.193.in-addr.arpa/IN
>(signed): reconfiguring zone keys
>29-Jan-2020 03:37:02.131 general: info: zone 42.201.193.in-addr.arpa/IN
>(signed): next key event: 29-Jan-2020 15:37:02.129
>29-Jan-2020 15:37:02.129 general: info: zone 42.201.193.in-addr.arpa/IN
>(signed): reconfiguring zone keys
>29-Jan-2020 15:37:02.131 general: info: zone 42.201.193.in-addr.arpa/IN
>(signed): next key event: 30-Jan-2020 03:37:02.129
>30-Jan-2020 03:35:01.604 general: info: zone 42.201.193.in-addr.arpa/IN
>(signed): reconfiguring zone keys
>30-Jan-2020 03:35:01.606 general: info: zone 42.201.193.in-addr.arpa/IN
>(signed): next key event: 30-Jan-2020 15:35:01.604

Since an "rndc reload" at 12:22 on 30 January, this logging has stopped and 
NONE of the signed zones have had any of their RRSIGs re-signed.  Today, one 
sees:-

>[root@m70 dns]# rndc zonestatus 42.201.193.in-addr.arpa
>name: 42.201.193.in-addr.arpa
>type: master
>files: zones/master/42.201.193.in-addr.arpa.db
>serial: 286
>signed serial: 3829
>nodes: 140
>last loaded: Sun, 24 Nov 2019 07:13:00 GMT
>secure: yes
>inline signing: yes
>key maintenance: automatic
>next key event: Wed, 05 Feb 2020 18:01:42 GMT next resign node: 
>DI2VMBB2GDES2IKFVFRUB7DIDDC7TI8L.42.201.193.in-addr.arpa/NSEC3
>next resign time: Thu, 30 Jan 2020 21:25:35 GMT
>dynamic: no
>reconfigurable via modzone: no

which clearly shows "next resign" as being in the past.  The server
reports:-

>[root@m70 dns]# rndc status
>version: BIND 9.11.13 (Extended Support Version)  running 
>on m70: Linux x86_64 4.14.120-x86_64-linode125 #1 SMP Mon May 20
>16:43:35 UTC 2019 boot time: Sun, 24 Nov 2019 09:51:27 GMT last
>configured: Wed, 05 Feb 2020 18:10:21 GMT configuration file: 
>/etc/named.conf CPUs found: 1 worker threads: 1 UDP listeners per
>interface: 1 number of zones: 773 (0 automatic) debug level: 0 xfers
>running: 0 xfers deferred: 0 soa queries in progress: 0 query logging 
>is OFF recursive clients: 0/900/1000 tcp clients: 6/150 TCP high-water:
>64 server is up and running

As a test I tried incrementing the serial number of only one of the signed 
zones and, after a reload, that zone seems to be being resigned normally.

My suspicion is that retarting Bind will simply fix the issue.

However, I was wondering whether there might be any troubleshooting or 
diagnosis which it might be useful to undertake.  Were ISC to want, it would 
probably be possible to get them temporary access.

Best wishes,
Matthew
___
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

VS: Bind 9.11.13 - inline re-signing stops

[Jukka Pakkanen]

Maybe related to your earlier reported problem, when signed zonedata is not 
updated after updates to the zone?

And what I already read about 9.11.15, hopefully fixed there.

Jukka

-Alkuperäinen viesti-
Lähettäjä: bind-users  Puolesta Matthew 
Richardson
Lähetetty: 5. helmikuuta 2020 19:28
Vastaanottaja: bind-users@lists.isc.org
Aihe: Bind 9.11.13 - inline re-signing stops

I have an interesting issue with a hidden master running 9.11.13 and configured 
with inline signing on a number of zones, configured thus:-

>zone "42.201.193.in-addr.arpa" {
>type master;
>file "zones/master/42.201.193.in-addr.arpa.db";
>inline-signing yes;
>auto-dnssec maintain;
>};

Prior to 30 January, all the zones configured in this way were regurlarly being 
resigned, logging entries such as:-

>29-Jan-2020 03:37:02.129 general: info: zone 42.201.193.in-addr.arpa/IN 
>(signed): reconfiguring zone keys
>29-Jan-2020 03:37:02.131 general: info: zone 42.201.193.in-addr.arpa/IN 
>(signed): next key event: 29-Jan-2020 15:37:02.129
>29-Jan-2020 15:37:02.129 general: info: zone 42.201.193.in-addr.arpa/IN 
>(signed): reconfiguring zone keys
>29-Jan-2020 15:37:02.131 general: info: zone 42.201.193.in-addr.arpa/IN 
>(signed): next key event: 30-Jan-2020 03:37:02.129
>30-Jan-2020 03:35:01.604 general: info: zone 42.201.193.in-addr.arpa/IN 
>(signed): reconfiguring zone keys
>30-Jan-2020 03:35:01.606 general: info: zone 42.201.193.in-addr.arpa/IN 
>(signed): next key event: 30-Jan-2020 15:35:01.604

Since an "rndc reload" at 12:22 on 30 January, this logging has stopped and 
NONE of the signed zones have had any of their RRSIGs re-signed.  Today, one 
sees:-

>[root@m70 dns]# rndc zonestatus 42.201.193.in-addr.arpa
>name: 42.201.193.in-addr.arpa
>type: master
>files: zones/master/42.201.193.in-addr.arpa.db
>serial: 286
>signed serial: 3829
>nodes: 140
>last loaded: Sun, 24 Nov 2019 07:13:00 GMT
>secure: yes
>inline signing: yes
>key maintenance: automatic
>next key event: Wed, 05 Feb 2020 18:01:42 GMT next resign node: 
>DI2VMBB2GDES2IKFVFRUB7DIDDC7TI8L.42.201.193.in-addr.arpa/NSEC3
>next resign time: Thu, 30 Jan 2020 21:25:35 GMT
>dynamic: no
>reconfigurable via modzone: no

which clearly shows "next resign" as being in the past.  The server
reports:-

>[root@m70 dns]# rndc status
>version: BIND 9.11.13 (Extended Support Version)  running 
>on m70: Linux x86_64 4.14.120-x86_64-linode125 #1 SMP Mon May 20 
>16:43:35 UTC 2019 boot time: Sun, 24 Nov 2019 09:51:27 GMT last 
>configured: Wed, 05 Feb 2020 18:10:21 GMT configuration file: 
>/etc/named.conf CPUs found: 1 worker threads: 1 UDP listeners per 
>interface: 1 number of zones: 773 (0 automatic) debug level: 0 xfers 
>running: 0 xfers deferred: 0 soa queries in progress: 0 query logging 
>is OFF recursive clients: 0/900/1000 tcp clients: 6/150 TCP high-water: 
>64 server is up and running

As a test I tried incrementing the serial number of only one of the signed 
zones and, after a reload, that zone seems to be being resigned normally.

My suspicion is that retarting Bind will simply fix the issue.

However, I was wondering whether there might be any troubleshooting or 
diagnosis which it might be useful to undertake.  Were ISC to want, it would 
probably be possible to get them temporary access.

Best wishes,
Matthew
___
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

VS: VL: DNSSEC zones not updated

[Jukka Pakkanen]

Also, now I *can* make changes to zone data, and rndc reload updates also the 
signed zone data like before.  Could it be that handling/format of the signed 
files were changed somehow between versions, and new 9.14.9 could not properly 
handle the 9.14.6/7 created signed files..?  Just wondering, because after 
recreating the files in 9.14.9, everything is now working normally again.

Jukka


-Alkuperäinen viesti-
Lähettäjä: bind-users  Puolesta Alessandro 
Vesely
Lähetetty: 28. tammikuuta 2020 14:26
Vastaanottaja: bind-users@lists.isc.org
Aihe: Re: VL: DNSSEC zones not updated

Same here

See also
https://serverfault.com/questions/897894/bind-is-not-resigning-dnssec-zone-after-zone-update-and-service-restart

Ale

On Thu 23/Jan/2020 09:57:02 +0100 Jukka Pakkanen wrote:
> Yes, that worked.  Also had to delete the .jnl, to prevent the "not exact" 
> error..
> 
> Jukka
> 
> -Alkuperäinen viesti-
> Lähettäjä: Mark Andrews 
> Lähetetty: 23. tammikuuta 2020 0:53
> Vastaanottaja: Jukka Pakkanen 
> Kopio: bind-us...@isc.org; Browne, Stuart 
> Aihe: Re: DNSSEC zones not updated
> 
> On the master stop the server, remove the signed zones and restart.  The 
> server will regenerate the signed zones and the slaves will answer in the 
> meantime.  I’ve opened a ticket to add a code path to address the reported 
> error automatically.
> 
> Marl
> 
>> On 23 Jan 2020, at 10:21, Jukka Pakkanen  wrote:
>> 
>> Unfortunately here a reload or a restart Does not fix it. And the problem of 
>> course is critical... no zone updates are working. So if no reason and fix 
>> is quickly found, need to step back and remove dnssec altogether.
>> 
>> Get Outlook for Android
>> 
>> From: Browne, Stuart 
>> Sent: Thursday, January 23, 2020 12:14:29 AM
>> To: Jukka Pakkanen ; bind-us...@isc.org 
>> 
>> Subject: RE: DNSSEC zones not updated
>>  
>> Sadly, no ideas other than a shared experience. It's not just the Windows 
>> release nor is it just the 9.14 series of releases; we've been witnessing 
>> this since the 9.10 releases on Linux (whilst using inline-signing). I don't 
>> recall off the top of my head if we saw it in the 9.9 series; even for my 
>> memory that is too many iterations ago.
>>  
>> It isn't a regular occurrence by any means and it is fixed with a service 
>> restart. Sadly we only see this in our production environment and coupled 
>> with the time between the occurrence of the issue and the detection of the 
>> issue, getting decent debugging information has been challenging (which is 
>> why we haven't done much else about it other than restarting it when we see 
>> it occur).
>>  
>> Stuart
>>  
>> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf 
>> Of Jukka Pakkanen
>> Sent: Thursday, 23 January 2020 9:41 AM
>> To: Jukka Pakkanen; bind-us...@isc.org
>> Subject: VS: DNSSEC zones not updated
>>  
>> Anyone, any ideas?
>> 
>>  
>> Lähettäjä: bind-users  Puolesta 
>> Jukka Pakkanen
>> Lähetetty: 22. tammikuuta 2020 13:30
>> Vastaanottaja: bind-us...@isc.org
>> Aihe: Re: DNSSEC zones not updated
>>  
>> And we also get after a change and a reload the "secure_serial: not exact" 
>> error, of course because the signed zone is not in sync with the non-signed 
>> anymore. So I guess the question is why it is not signing automatically 
>> after updates to zone.
>>  
>>  
>> Get Outlook for Android
>> From: jukka.pakka...@qnet.fi 
>> Sent: Wednesday, January 22, 2020 1:13:11 PM
>> To: Ondřej Surý 
>> Cc: bind-us...@isc.org 
>> Subject: Re: DNSSEC zones not updated
>>  
>> Yed we have quite several times by now  when trying to find the culprit. 
>> Also the whole windows 2019 server. And it is not only this domain/zone, but 
>> all of them.
>> 
>> Get Outlook for Android
>>  
>> From: Ondřej Surý 
>> Sent: Wednesday, January 22, 2020 1:08:22 PM
>> To: Jukka Pakkanen 
>> Cc: bind-us...@isc.org 
>> Subject: Re: DNSSEC zones not updated
>>  
>> Hi,
>> 
>> did you try stopping BIND, removing journal files and then starting BIND 
>> again?
>> 
>> If the signed copy of the zone got corrupted in the memory, you might be 
>> dumping the corrupted version on disk again with `rndc reload`.
>> 
>> Ondrej
>> --
>> Ondřej Surý
>> ond...@isc.org
>> 
>> > On 22 Jan 2020, at 12:11, Jukka Pakkanen  wrote:
>> > 
>> > 
>> > Running BIND 9.14.9 Windows.   The zone data is not updated for some 
>> > rea

receive_secure_serial: unchanged (why?)

[Jukka Pakkanen]

While sorting out this latest DNSSEC problem, autosign not autosigning, this 
other older *cosmetic* problem would be nice to have fixed too...

Windows Event Viewer filling with these error messages, which I think are not 
actual errors, should be more like warnings or notifications.  When the named 
service is restarted, every signed zone gives this "error" message:

zone qnet.fi/IN (signed): receive_secure_serial: unchanged
___
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

receive_secure_serial: unchanged (why?)

[Jukka Pakkanen]

While sorting this latest DNSSEC problem, autosign not autosigning, this older 
*cosmetic* problem would be nice to have fixed too...

Windows Event Viewer filling with these error messages, which I guess are not 
actual errors, should be more like warnings or notifications.  When the named 
service is restarted, every signed zone gives this "error" message:


Lähettäjä: bind-users  Puolesta Jukka Pakkanen
Lähetetty: 9. lokakuuta 2019 1:51
Vastaanottaja: bind-us...@isc.org
Aihe: DNSSEC 9.14.6 error message

Having these *error* messages in the syslog when restarting the service... 
guess they are not too harmfull, but why exactly is this coming:

zone qnet.fi/IN (signed): receive_secure_serial: unchanged

Just have this zone signed, but similar behaviout with other zones too.

BIND 9.14.6 (Win)

Thx, Jukka
___
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

VL: DNSSEC zones not updated

[Jukka Pakkanen]

Yes, that worked.  Also had to delete the .jnl, to prevent the "not exact" 
error..

Jukka

-Alkuperäinen viesti-
Lähettäjä: Mark Andrews  
Lähetetty: 23. tammikuuta 2020 0:53
Vastaanottaja: Jukka Pakkanen 
Kopio: bind-us...@isc.org; Browne, Stuart 
Aihe: Re: DNSSEC zones not updated

On the master stop the server, remove the signed zones and restart.  The server 
will regenerate the signed zones and the slaves will answer in the meantime.  
I’ve opened a ticket to add a code path to address the reported error 
automatically.

Marl

> On 23 Jan 2020, at 10:21, Jukka Pakkanen  wrote:
> 
> Unfortunately here a reload or a restart Does not fix it. And the problem of 
> course is critical... no zone updates are working. So if no reason and fix is 
> quickly found, need to step back and remove dnssec altogether.
> 
> Get Outlook for Android
> 
> From: Browne, Stuart 
> Sent: Thursday, January 23, 2020 12:14:29 AM
> To: Jukka Pakkanen ; bind-us...@isc.org 
> 
> Subject: RE: DNSSEC zones not updated
>  
> Sadly, no ideas other than a shared experience. It's not just the Windows 
> release nor is it just the 9.14 series of releases; we've been witnessing 
> this since the 9.10 releases on Linux (whilst using inline-signing). I don't 
> recall off the top of my head if we saw it in the 9.9 series; even for my 
> memory that is too many iterations ago.
>  
> It isn't a regular occurrence by any means and it is fixed with a service 
> restart. Sadly we only see this in our production environment and coupled 
> with the time between the occurrence of the issue and the detection of the 
> issue, getting decent debugging information has been challenging (which is 
> why we haven't done much else about it other than restarting it when we see 
> it occur).
>  
> Stuart
>  
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf 
> Of Jukka Pakkanen
> Sent: Thursday, 23 January 2020 9:41 AM
> To: Jukka Pakkanen; bind-us...@isc.org
> Subject: VS: DNSSEC zones not updated
>  
> Anyone, any ideas?
> 
>  
> Lähettäjä: bind-users  Puolesta 
> Jukka Pakkanen
> Lähetetty: 22. tammikuuta 2020 13:30
> Vastaanottaja: bind-us...@isc.org
> Aihe: Re: DNSSEC zones not updated
>  
> And we also get after a change and a reload the "secure_serial: not exact" 
> error, of course because the signed zone is not in sync with the non-signed 
> anymore. So I guess the question is why it is not signing automatically after 
> updates to zone.
>  
>  
> Get Outlook for Android
> From: jukka.pakka...@qnet.fi 
> Sent: Wednesday, January 22, 2020 1:13:11 PM
> To: Ondřej Surý 
> Cc: bind-us...@isc.org 
> Subject: Re: DNSSEC zones not updated
>  
> Yed we have quite several times by now  when trying to find the culprit. Also 
> the whole windows 2019 server. And it is not only this domain/zone, but all 
> of them.
> 
> Get Outlook for Android
>  
> From: Ondřej Surý 
> Sent: Wednesday, January 22, 2020 1:08:22 PM
> To: Jukka Pakkanen 
> Cc: bind-us...@isc.org 
> Subject: Re: DNSSEC zones not updated
>  
> Hi,
> 
> did you try stopping BIND, removing journal files and then starting BIND 
> again?
> 
> If the signed copy of the zone got corrupted in the memory, you might be 
> dumping the corrupted version on disk again with `rndc reload`.
> 
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
> 
> > On 22 Jan 2020, at 12:11, Jukka Pakkanen  wrote:
> > 
> > 
> > Running BIND 9.14.9 Windows.   The zone data is not updated for some reason 
> > anymore, and same problem in all our signed zones. Example "gemtrade.fi":
> > 
> > zone "gemtrade.fi" {
> > type master;
> > file "named.gemtrade";
> > inline-signing yes;
> > auto-dnssec maintain;
> > };
> > 
> > 
> > ;
> > ;File: named.gemtrade
> > ;
> > $TTL 60
> > @IN SOAns1.qnet.fi. helpdesk.qnet.fi. (
> >   202001234  ; serial number
> >   28800  ; refresh every 12 hours
> >   7200   ; retry after 2 hours
> >   604800 ; expire after 2 weeks
> >   33600) ; default ttl is 2 days
> > gemtrade.fi.IN A  62.142.217.154
> >  IN MX 55 qntsrv8.qnet.fi.
> > IN MX 25 qntsrv9.qnet.fi.
> >  IN NS ns1.qnet.fi.
> >  IN NS ns2.qnet.fi.
> >  IN NS ns3.qnet.fi.  
> > www IN A 62.142.217.154
> > _autodiscover._tcp  IN SRV0 5 443 ma

Re: DNSSEC zones not updated

[Jukka Pakkanen]

Unfortunately here a reload or a restart Does not fix it. And the problem of 
course is critical... no zone updates are working. So if no reason and fix is 
quickly found, need to step back and remove dnssec altogether.

Get Outlook for Android<https://aka.ms/ghei36>


From: Browne, Stuart 
Sent: Thursday, January 23, 2020 12:14:29 AM
To: Jukka Pakkanen ; bind-us...@isc.org 

Subject: RE: DNSSEC zones not updated

Sadly, no ideas other than a shared experience. It's not just the Windows 
release nor is it just the 9.14 series of releases; we've been witnessing this 
since the 9.10 releases on Linux (whilst using inline-signing). I don't recall 
off the top of my head if we saw it in the 9.9 series; even for my memory that 
is too many iterations ago.

It isn't a regular occurrence by any means and it is fixed with a service 
restart. Sadly we only see this in our production environment and coupled with 
the time between the occurrence of the issue and the detection of the issue, 
getting decent debugging information has been challenging (which is why we 
haven't done much else about it other than restarting it when we see it occur).

Stuart

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jukka 
Pakkanen
Sent: Thursday, 23 January 2020 9:41 AM
To: Jukka Pakkanen; bind-us...@isc.org
Subject: VS: DNSSEC zones not updated

Anyone, any ideas?

Lähettäjä: bind-users 
mailto:bind-users-boun...@lists.isc.org>> 
Puolesta Jukka Pakkanen
Lähetetty: 22. tammikuuta 2020 13:30
Vastaanottaja: bind-us...@isc.org<mailto:bind-us...@isc.org>
Aihe: Re: DNSSEC zones not updated

And we also get after a change and a reload the "secure_serial: not exact" 
error, of course because the signed zone is not in sync with the non-signed 
anymore. So I guess the question is why it is not signing automatically after 
updates to zone.


Get Outlook for 
Android<https://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_ghei36=DwMFBA=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLbUE6LRGu5fmxLhrDvVJS8=PK_XLg7WPDTgkiPV9YpjwlSSDRG_2lshTvKCwLxitGg=8lAQcjrPuFc7OPf0OgqsKjo4MdT2JO0gs41J86WasWM=>

From: jukka.pakka...@qnet.fi<mailto:jukka.pakka...@qnet.fi> 
mailto:jukka.pakka...@qnet.fi>>
Sent: Wednesday, January 22, 2020 1:13:11 PM
To: Ondřej Surý mailto:ond...@isc.org>>
Cc: bind-us...@isc.org<mailto:bind-us...@isc.org> 
mailto:bind-us...@isc.org>>
Subject: Re: DNSSEC zones not updated

Yed we have quite several times by now  when trying to find the culprit. Also 
the whole windows 2019 server. And it is not only this domain/zone, but all of 
them.
Get Outlook for 
Android<https://urldefense.proofpoint.com/v2/url?u=https-3A__aka.ms_ghei36=DwMFBA=MOptNlVtIETeDALC_lULrw=udvvbouEjrWNUMab5xo_vLbUE6LRGu5fmxLhrDvVJS8=PK_XLg7WPDTgkiPV9YpjwlSSDRG_2lshTvKCwLxitGg=8lAQcjrPuFc7OPf0OgqsKjo4MdT2JO0gs41J86WasWM=>


From: Ondřej Surý mailto:ond...@isc.org>>
Sent: Wednesday, January 22, 2020 1:08:22 PM
To: Jukka Pakkanen mailto:jukka.pakka...@qnet.fi>>
Cc: bind-us...@isc.org<mailto:bind-us...@isc.org> 
mailto:bind-us...@isc.org>>
Subject: Re: DNSSEC zones not updated

Hi,

did you try stopping BIND, removing journal files and then starting BIND again?

If the signed copy of the zone got corrupted in the memory, you might be 
dumping the corrupted version on disk again with `rndc reload`.

Ondrej
--
Ondřej Surý
ond...@isc.org<mailto:ond...@isc.org>

> On 22 Jan 2020, at 12:11, Jukka Pakkanen 
> mailto:jukka.pakka...@qnet.fi>> wrote:
>
>
> Running BIND 9.14.9 Windows.   The zone data is not updated for some reason 
> anymore, and same problem in all our signed zones. Example "gemtrade.fi":
>
> zone "gemtrade.fi" {
> type master;
> file "named.gemtrade";
> inline-signing yes;
> auto-dnssec maintain;
> };
>
>
> ;
> ;File: named.gemtrade
> ;
> $TTL 60
> @IN SOAns1.qnet.fi. helpdesk.qnet.fi. (
>   202001234  ; serial number
>   28800  ; refresh every 12 hours
>   7200   ; retry after 2 hours
>   604800 ; expire after 2 weeks
>   33600) ; default ttl is 2 days
> gemtrade.fi.IN A  62.142.217.154
>  IN MX 55 qntsrv8.qnet.fi.
> IN MX 25 qntsrv9.qnet.fi.
>  IN NS ns1.qnet.fi.
>  IN NS ns2.qnet.fi.
>  IN NS ns3.qnet.fi.
> www IN A 62.142.217.154
> _autodiscover._tcp  IN SRV0 5 443 mail.qnet.fi.
> localhost.gemtrade.fi.   IN A  127.0.0.1
>
>
> Used to work fine, now no matter what change I make to the zo

VS: DNSSEC zones not updated

[Jukka Pakkanen]

Anyone, any ideas?


Lähettäjä: bind-users  Puolesta Jukka Pakkanen
Lähetetty: 22. tammikuuta 2020 13:30
Vastaanottaja: bind-us...@isc.org
Aihe: Re: DNSSEC zones not updated

And we also get after a change and a reload the "secure_serial: not exact" 
error, of course because the signed zone is not in sync with the non-signed 
anymore. So I guess the question is why it is not signing automatically after 
updates to zone.


Get Outlook for Android<https://aka.ms/ghei36>

From: jukka.pakka...@qnet.fi<mailto:jukka.pakka...@qnet.fi> 
mailto:jukka.pakka...@qnet.fi>>
Sent: Wednesday, January 22, 2020 1:13:11 PM
To: Ondřej Surý mailto:ond...@isc.org>>
Cc: bind-us...@isc.org<mailto:bind-us...@isc.org> 
mailto:bind-us...@isc.org>>
Subject: Re: DNSSEC zones not updated

Yed we have quite several times by now  when trying to find the culprit. Also 
the whole windows 2019 server. And it is not only this domain/zone, but all of 
them.
Get Outlook for Android<https://aka.ms/ghei36>


From: Ondřej Surý mailto:ond...@isc.org>>
Sent: Wednesday, January 22, 2020 1:08:22 PM
To: Jukka Pakkanen mailto:jukka.pakka...@qnet.fi>>
Cc: bind-us...@isc.org<mailto:bind-us...@isc.org> 
mailto:bind-us...@isc.org>>
Subject: Re: DNSSEC zones not updated

Hi,

did you try stopping BIND, removing journal files and then starting BIND again?

If the signed copy of the zone got corrupted in the memory, you might be 
dumping the corrupted version on disk again with `rndc reload`.

Ondrej
--
Ondřej Surý
ond...@isc.org<mailto:ond...@isc.org>

> On 22 Jan 2020, at 12:11, Jukka Pakkanen 
> mailto:jukka.pakka...@qnet.fi>> wrote:
>
>
> Running BIND 9.14.9 Windows.   The zone data is not updated for some reason 
> anymore, and same problem in all our signed zones. Example "gemtrade.fi":
>
> zone "gemtrade.fi" {
> type master;
> file "named.gemtrade";
> inline-signing yes;
> auto-dnssec maintain;
> };
>
>
> ;
> ;File:  named.gemtrade
> ;
> $TTL 60
> @IN SOAns1.qnet.fi. helpdesk.qnet.fi. (
>   202001234  ; serial number
>   28800  ; refresh every 12 hours
>   7200   ; retry after 2 hours
>   604800 ; expire after 2 weeks
>   33600) ; default ttl is 2 days
> gemtrade.fi.IN A  62.142.217.154
>  IN MX 55 qntsrv8.qnet.fi.
> IN MX 25 qntsrv9.qnet.fi.
>  IN NS ns1.qnet.fi.
>  IN NS ns2.qnet.fi.
>  IN NS ns3.qnet.fi.
> www IN A 62.142.217.154
> _autodiscover._tcp  IN SRV0 5 443 mail.qnet.fi.
> localhost.gemtrade.fi.   IN A  127.0.0.1
>
>
> Used to work fine, now no matter what change I make to the zone file and 
> reload, it does not show up in queries, but the old data, weeks behind.  The 
> SOA & serial numbers *are* updating in the queries, but the actual records 
> not.  Example the MX records, currently I have priorities 55 and 25, still 
> inquiries return the old 20 and 20. Same with any records, the changes does 
> not get updated.
>
> Deleting the .jnl file does not help, after "rndc reload gemtrade.fi" a new 
> .jnl file is created, but queries still return old data.
>
> The named process has all possible rights in the file structure.
>
> What might be wrong?
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
>
> bind-users mailing list
> bind-users@lists.isc.org<mailto: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: DNSSEC zones not updated

[Jukka Pakkanen]

And we also get after a change and a reload the "secure_serial: not exact" 
error, of course because the signed zone is not in sync with the non-signed 
anymore. So I guess the question is why it is not signing automatically after 
updates to zone.


Get Outlook for Android<https://aka.ms/ghei36>

From: jukka.pakka...@qnet.fi 
Sent: Wednesday, January 22, 2020 1:13:11 PM
To: Ondřej Surý 
Cc: bind-us...@isc.org 
Subject: Re: DNSSEC zones not updated

Yed we have quite several times by now  when trying to find the culprit. Also 
the whole windows 2019 server. And it is not only this domain/zone, but all of 
them.

Get Outlook for Android<https://aka.ms/ghei36>


From: Ondřej Surý 
Sent: Wednesday, January 22, 2020 1:08:22 PM
To: Jukka Pakkanen 
Cc: bind-us...@isc.org 
Subject: Re: DNSSEC zones not updated

Hi,

did you try stopping BIND, removing journal files and then starting BIND again?

If the signed copy of the zone got corrupted in the memory, you might be 
dumping the corrupted version on disk again with `rndc reload`.

Ondrej
--
Ondřej Surý
ond...@isc.org

> On 22 Jan 2020, at 12:11, Jukka Pakkanen  wrote:
>
>
> Running BIND 9.14.9 Windows.   The zone data is not updated for some reason 
> anymore, and same problem in all our signed zones. Example "gemtrade.fi":
>
> zone "gemtrade.fi" {
> type master;
> file "named.gemtrade";
> inline-signing yes;
> auto-dnssec maintain;
> };
>
>
> ;
> ;File:  named.gemtrade
> ;
> $TTL 60
> @IN SOAns1.qnet.fi. helpdesk.qnet.fi. (
>   202001234  ; serial number
>   28800  ; refresh every 12 hours
>   7200   ; retry after 2 hours
>   604800 ; expire after 2 weeks
>   33600) ; default ttl is 2 days
> gemtrade.fi.IN A  62.142.217.154
>  IN MX 55 qntsrv8.qnet.fi.
> IN MX 25 qntsrv9.qnet.fi.
>  IN NS ns1.qnet.fi.
>  IN NS ns2.qnet.fi.
>  IN NS ns3.qnet.fi.
> www IN A 62.142.217.154
> _autodiscover._tcp  IN SRV0 5 443 mail.qnet.fi.
> localhost.gemtrade.fi.   IN A  127.0.0.1
>
>
> Used to work fine, now no matter what change I make to the zone file and 
> reload, it does not show up in queries, but the old data, weeks behind.  The 
> SOA & serial numbers *are* updating in the queries, but the actual records 
> not.  Example the MX records, currently I have priorities 55 and 25, still 
> inquiries return the old 20 and 20. Same with any records, the changes does 
> not get updated.
>
> Deleting the .jnl file does not help, after "rndc reload gemtrade.fi" a new 
> .jnl file is created, but queries still return old data.
>
> The named process has all possible rights in the file structure.
>
> What might be wrong?
>
> ___
> 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: DNSSEC zones not updated

[Jukka Pakkanen]

Yed we have quite several times by now  when trying to find the culprit. Also 
the whole windows 2019 server. And it is not only this domain/zone, but all of 
them.

Get Outlook for Android<https://aka.ms/ghei36>


From: Ondřej Surý 
Sent: Wednesday, January 22, 2020 1:08:22 PM
To: Jukka Pakkanen 
Cc: bind-us...@isc.org 
Subject: Re: DNSSEC zones not updated

Hi,

did you try stopping BIND, removing journal files and then starting BIND again?

If the signed copy of the zone got corrupted in the memory, you might be 
dumping the corrupted version on disk again with `rndc reload`.

Ondrej
--
Ondřej Surý
ond...@isc.org

> On 22 Jan 2020, at 12:11, Jukka Pakkanen  wrote:
>
>
> Running BIND 9.14.9 Windows.   The zone data is not updated for some reason 
> anymore, and same problem in all our signed zones. Example "gemtrade.fi":
>
> zone "gemtrade.fi" {
> type master;
> file "named.gemtrade";
> inline-signing yes;
> auto-dnssec maintain;
> };
>
>
> ;
> ;File:  named.gemtrade
> ;
> $TTL 60
> @IN SOAns1.qnet.fi. helpdesk.qnet.fi. (
>   202001234  ; serial number
>   28800  ; refresh every 12 hours
>   7200   ; retry after 2 hours
>   604800 ; expire after 2 weeks
>   33600) ; default ttl is 2 days
> gemtrade.fi.IN A  62.142.217.154
>  IN MX 55 qntsrv8.qnet.fi.
> IN MX 25 qntsrv9.qnet.fi.
>  IN NS ns1.qnet.fi.
>  IN NS ns2.qnet.fi.
>  IN NS ns3.qnet.fi.
> www IN A 62.142.217.154
> _autodiscover._tcp  IN SRV0 5 443 mail.qnet.fi.
> localhost.gemtrade.fi.   IN A  127.0.0.1
>
>
> Used to work fine, now no matter what change I make to the zone file and 
> reload, it does not show up in queries, but the old data, weeks behind.  The 
> SOA & serial numbers *are* updating in the queries, but the actual records 
> not.  Example the MX records, currently I have priorities 55 and 25, still 
> inquiries return the old 20 and 20. Same with any records, the changes does 
> not get updated.
>
> Deleting the .jnl file does not help, after "rndc reload gemtrade.fi" a new 
> .jnl file is created, but queries still return old data.
>
> The named process has all possible rights in the file structure.
>
> What might be wrong?
>
> ___
> 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: DNSSEC zones not updated

[Jukka Pakkanen]

Both, and notifies/ixfr:s work fine. After updating the zone, the log shows the 
records are updated in the slaves. Feel free to query the servers...


Get Outlook for Android<https://aka.ms/ghei36>


From: Sten Carlsen 
Sent: Wednesday, January 22, 2020, 12:56
To: Jukka Pakkanen
Cc: bind-us...@isc.org
Subject: Re: DNSSEC zones not updated

Just a basic question, are you querying the master or a slave. If a slave, it 
could be the notify/transfer.


Thanks

Sten

On 22 Jan 2020, at 12.11, Jukka Pakkanen 
mailto:jukka.pakka...@qnet.fi>> wrote:


Running BIND 9.14.9 Windows.   The zone data is not updated for some reason 
anymore, and same problem in all our signed zones. Example 
"gemtrade.fi<http://gemtrade.fi/>":

zone "gemtrade.fi<http://gemtrade.fi/>" {
type master;
file "named.gemtrade";
inline-signing yes;
auto-dnssec maintain;
};

;
;File:  named.gemtrade
;
$TTL 60
@IN SOAns1.qnet.fi<http://ns1.qnet.fi/>. 
helpdesk.qnet.fi<http://helpdesk.qnet.fi/>. (
  202001234  ; serial number
  28800  ; refresh every 12 hours
  7200   ; retry after 2 hours
  604800 ; expire after 2 weeks
  33600) ; default ttl is 2 days
gemtrade.fi<http://gemtrade.fi/>.IN A  62.142.217.154
 IN MX 55 
qntsrv8.qnet.fi<http://qntsrv8.qnet.fi/>.
IN MX 25 qntsrv9.qnet.fi<http://qntsrv9.qnet.fi/>.
 IN NS ns1.qnet.fi<http://ns1.qnet.fi/>.
 IN NS ns2.qnet.fi<http://ns2.qnet.fi/>.
 IN NS ns3.qnet.fi<http://ns3.qnet.fi/>.
www IN A 62.142.217.154
_autodiscover._tcp  IN SRV0 5 443 mail.qnet.fi<http://mail.qnet.fi/>.
localhost.gemtrade.fi<http://localhost.gemtrade.fi/>.   IN A  127.0.0.1


Used to work fine, now no matter what change I make to the zone file and 
reload, it does not show up in queries, but the old data, weeks behind.  The 
SOA & serial numbers *are* updating in the queries, but the actual records not. 
 Example the MX records, currently I have priorities 55 and 25, still inquiries 
return the old 20 and 20. Same with any records, the changes does not get 
updated.

Deleting the .jnl file does not help, after "rndc reload 
gemtrade.fi<http://gemtrade.fi/>" a new .jnl file is created, but queries still 
return old data.

The named process has all possible rights in the file structure.

What might be wrong?

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

bind-users mailing list
bind-users@lists.isc.org<mailto: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

DNSSEC zones not updated

[Jukka Pakkanen]

Running BIND 9.14.9 Windows.   The zone data is not updated for some reason 
anymore, and same problem in all our signed zones. Example "gemtrade.fi":

zone "gemtrade.fi" {
type master;
file "named.gemtrade";
inline-signing yes;
auto-dnssec maintain;
};

;
;File:  named.gemtrade
;
$TTL 60
@IN SOAns1.qnet.fi. helpdesk.qnet.fi. (
  202001234  ; serial number
  28800  ; refresh every 12 hours
  7200   ; retry after 2 hours
  604800 ; expire after 2 weeks
  33600) ; default ttl is 2 days
gemtrade.fi.IN A  62.142.217.154
 IN MX 55 qntsrv8.qnet.fi.
IN MX 25 qntsrv9.qnet.fi.
 IN NS ns1.qnet.fi.
 IN NS ns2.qnet.fi.
 IN NS ns3.qnet.fi.
www IN A 62.142.217.154
_autodiscover._tcp  IN SRV0 5 443 mail.qnet.fi.
localhost.gemtrade.fi.   IN A  127.0.0.1


Used to work fine, now no matter what change I make to the zone file and 
reload, it does not show up in queries, but the old data, weeks behind.  The 
SOA & serial numbers *are* updating in the queries, but the actual records not. 
 Example the MX records, currently I have priorities 55 and 25, still inquiries 
return the old 20 and 20. Same with any records, the changes does not get 
updated.

Deleting the .jnl file does not help, after "rndc reload gemtrade.fi" a new 
.jnl file is created, but queries still return old data.

The named process has all possible rights in the file structure.

What might be wrong?

___
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

VS: DNSSEC 9.14.6 error message

[Jukka Pakkanen]

Any more ideas about this?

Like said, this looks like a bogus error, but now when signing more and more 
zones, the Windows event viewer is filling with these *error* messages, and it 
gets more and more difficult to find real errors, if there are any...

Jukka

-Alkuperäinen viesti-
Lähettäjä: bind-users  Puolesta Jukka Pakkanen
Lähetetty: 9. lokakuuta 2019 16:36
Vastaanottaja: Tony Finch 
Kopio: bind-us...@isc.org
Aihe: VS: DNSSEC 9.14.6 error message

Yes I can stop and restart the "isc bind" service without problems and/or 
errors, only get this message in restart, if the zone serial is not updated.  
And everything seems to be working fine despite of that.  Maybe the message is 
just erroneously categorized as an "error" in syslog.

Jukka

-Alkuperäinen viesti-
Lähettäjä: Tony Finch 
Lähetetty: 9. lokakuuta 2019 13:34
Vastaanottaja: Jukka Pakkanen 
Kopio: bind-us...@isc.org
Aihe: Re: DNSSEC 9.14.6 error message

Jukka Pakkanen  wrote:

> Having these *error* messages in the syslog when restarting the 
> service... guess they are not too harmfull, but why exactly is this
> coming:
>
> zone qnet.fi/IN (signed): receive_secure_serial: unchanged

This can happen in the following code, which suggests to me that the error is 
benign. Did the server shut down gracefully?

/*
 * Try to apply diffs from the raw zone's journal to the secure
 * zone.  If that fails, we recover by syncing up the databases
 * directly.
 */
result = sync_secure_journal(zone, zone->rss_raw, rjournal,
 start, end, ,
 >rss_diff);
if (result == DNS_R_UNCHANGED)
goto failure;

Tony.
--
f.anthony.n.finchhttp://dotat.at/
Bailey: Northwest 5 to 7, occasionally gale 8 at first, becoming variable 3 or
4 later. High at first in far southeast, otherwise rough or very rough. Rain or 
showers. Moderate or good, occasionally poor.

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

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

___
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

VS: DNSSEC 9.14.6 error message

[Jukka Pakkanen]

Yes I can stop and restart the "isc bind" service without problems and/or 
errors, only get this message in restart, if the zone serial is not updated.  
And everything seems to be working fine despite of that.  Maybe the message is 
just erroneously categorized as an "error" in syslog.

Jukka

-Alkuperäinen viesti-
Lähettäjä: Tony Finch  
Lähetetty: 9. lokakuuta 2019 13:34
Vastaanottaja: Jukka Pakkanen 
Kopio: bind-us...@isc.org
Aihe: Re: DNSSEC 9.14.6 error message

Jukka Pakkanen  wrote:

> Having these *error* messages in the syslog when restarting the 
> service... guess they are not too harmfull, but why exactly is this
> coming:
>
> zone qnet.fi/IN (signed): receive_secure_serial: unchanged

This can happen in the following code, which suggests to me that the error is 
benign. Did the server shut down gracefully?

/*
 * Try to apply diffs from the raw zone's journal to the secure
 * zone.  If that fails, we recover by syncing up the databases
 * directly.
 */
result = sync_secure_journal(zone, zone->rss_raw, rjournal,
 start, end, ,
 >rss_diff);
if (result == DNS_R_UNCHANGED)
goto failure;

Tony.
--
f.anthony.n.finchhttp://dotat.at/
Bailey: Northwest 5 to 7, occasionally gale 8 at first, becoming variable 3 or
4 later. High at first in far southeast, otherwise rough or very rough. Rain or 
showers. Moderate or good, occasionally poor.

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

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

DNSSEC 9.14.6 error message

[Jukka Pakkanen]

Having these *error* messages in the syslog when restarting the service... 
guess they are not too harmfull, but why exactly is this coming:

zone qnet.fi/IN (signed): receive_secure_serial: unchanged

Just have this zone signed, but similar behaviout with other zones too.

BIND 9.14.6 (Win)

Thx, Jukka
___
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

VS: DNSSEC basic information

[Jukka Pakkanen]

Already found out about 
https://ftp.isc.org/isc/dnssec-guide/html/dnssec-guide.html, and that example 
the dnssec-enable option is now on by default…   but any usefull hints still 
gladly received 

Jukka

Lähettäjä: bind-users  Puolesta Jukka Pakkanen
Lähetetty: 23. syyskuuta 2019 22:17
Vastaanottaja: bind-us...@isc.org
Aihe: DNSSEC basic information

I am finally diging in to DNSSEC, updating out BIND 9.14.5 servers to support 
it, both resolving & signing, secure zone transfers etc.

I just have read the DNSSEC Mastery by Michael W. Lucas from year 2013, and my 
question basically is, is this information from 6 years back still valid, or 
hopelessly outdated?  I do suppose in six years things have already changed a 
lot.  And while started testing some things, noticed they are not working as 
expected, as presented in the book.  Like when upgraded our servers to DNSSEC 
resolving, the only zone I can find the ad flag set is paypal.com, example 
isc.org does not show it.

Also, with current status of DNSSEC, is it still recommend/required to have 
separate authoritative & recursive servers, DNSSEC-wise?

DLV functionality seems to be dropped from the current BIND too?

And so on... would like to know how outdated this book is, what has changed 
since 2013, and also, any hints for a good DNSSEC tutorials with todays BIND 
versions.

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

DNSSEC basic information

[Jukka Pakkanen]

I am finally diging in to DNSSEC, updating out BIND 9.14.5 servers to support 
it, both resolving & signing, secure zone transfers etc.

I just have read the DNSSEC Mastery by Michael W. Lucas from year 2013, and my 
question basically is, is this information from 6 years back still valid, or 
hopelessly outdated?  I do suppose in six years things have already changed a 
lot.  And while started testing some things, noticed they are not working as 
expected, as presented in the book.  Like when upgraded our servers to DNSSEC 
resolving, the only zone I can find the ad flag set is paypal.com, example 
isc.org does not show it.

Also, with current status of DNSSEC, is it still recommend/required to have 
separate authoritative & recursive servers, DNSSEC-wise?

DLV functionality seems to be dropped from the current BIND too?

And so on... would like to know how outdated this book is, what has changed 
since 2013, and also, any hints for a good DNSSEC tutorials with todays BIND 
versions.

Jukka

___
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: Strange DNS problem

[Jukka Pakkanen]

Yeah, another advertising company turned to an ISP... 

Solved *our* problem now by including the suggested server clause for both of 
their broken servers, to our servers.  Of course does not solve the real 
problem, the broken servers of theirs.

Thanks for help.

Jukka

-Original Message-
From: Stephane Bortzmeyer  
Sent: 10. kesäkuuta 2019 20:01
To: Jukka Pakkanen 
Cc: c...@cam.ac.uk; bind-us...@isc.org
Subject: Re: Strange DNS problem

On Mon, Jun 10, 2019 at 05:43:02PM +,  Jukka Pakkanen 
 wrote  a message of 58 lines which said:

> Then, unfortunately our nameservers won't resolve ns.kpk.fi either.

Same authoritative name server, same problem. See my email.

% dig @ns.datatower.fi. NS kpk.fi.

;; Warning: Client COOKIE mismatch

___
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: Strange DNS problem

[Jukka Pakkanen]

-Original Message-
From: Chris Thompson  On Behalf Of Chris Thompson
Sent: 10. kesäkuuta 2019 17:30
To: Jukka Pakkanen 
Cc: bind-us...@isc.org
Subject: Re: Strange DNS problem

On Jun 10 2019, Jukka Pakkanen wrote:

>We have a strange problem related to DNS services, maybe someone here 
>have a clue what could be the problem.
[…]
>An example, the client domain is raimoasikainenoy.fi.

Well, there is certainly something wrong with ns.datatower.fi [193.184.54.212], 
as it consistently returns server cookies that bear no relationship to the 
client cookie sent in the query, and in fact I get *exactly* the same one as 
you report:

>; <<>> DiG 9.14.2 <<>> @193.184.54.212 raimoasikainenoy.fi ns ; (1 
>server found) ;; global options: +cmd ;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14591 ;; flags: qr 
>aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING:
>recursion requested but not available
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 4096
>; COOKIE: a0ff0c014f65b471e0b8b271e7bab2718129c071 (bad)

every time! (Use +qr to show the client cookie sent by dig.)

I expect you could work around this by specifying 

  server 193.184.54.212 { send-cookie no; };

in your named.conf, but it seems to me that BIND 9.14 ought to be able to fall 
back on using ns.kpk.fi [192.130.183.74] which doesn't have this server cookie 
problem.

--
Chris Thompson
Email: c...@cam.ac.uk


Then, unfortunately our nameservers won't resolve ns.kpk.fi either.  So even if 
the fall back works, as I suppose it does, it does not help here.

; <<>> DiG 9.14.2 <<>> @ns1.qnet.fi ns.kpk.fi ; (1 server found) ;; global 
options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64299 ;; flags: qr rd ra; 
QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5fdcace005523ca0f1b0c9c95cfe96f17497773ef05635e1 (good) ;; QUESTION 
SECTION:
;ns.kpk.fi. IN  A

;; Query time: 0 msec
;; SERVER: 62.142.220.5#53(62.142.220.5) ;; WHEN: Mon Jun 10 20:44:17 FLE 
Daylight Time 2019 ;; MSG SIZE  rcvd: 66

And again when inquiring directly with the IP of ns.kpk.fi, we do get an answer:


; <<>> DiG 9.14.2 <<>> @192.130.183.74 ns.kpk.fi ; (1 server found) ;; global 
options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50365 ;; flags: qr aa rd; 
QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion 
requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ef9a3009864a202e5dfe5cfe9648adfe8be2561def4d (good) ;; QUESTION 
SECTION:
;ns.kpk.fi. IN  A

;; ANSWER SECTION:
ns.kpk.fi.  600 IN  A   192.130.183.74

;; Query time: 31 msec
;; SERVER: 192.130.183.74#53(192.130.183.74) ;; WHEN: Mon Jun 10 20:45:48 FLE 
Daylight Time 2019 ;; MSG SIZE  rcvd: 82

Jukka

Maybe because the "lue.keskipohjanmaa.com" NS server for this kpk.fi domain, 
also seems to be having this cookie problem:

;; Warning: Client COOKIE mismatch

; <<>> DiG 9.14.2 <<>> @192.130.183.69 ns.kpk.fi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39629
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a0ffec004f65b471e0b8b271e7bab2718129c071 (bad)
;; QUESTION SECTION:
;ns.kpk.fi. IN  A

;; ANSWER SECTION:
ns.kpk.fi.  600 IN  A   192.130.183.74

;; AUTHORITY SECTION:
kpk.fi. 600 IN  NS  lue.keskipohjanmaa.com.
kpk.fi. 600 IN  NS  ns.datatower.fi.

;; ADDITIONAL SECTION:
ns.datatower.fi.3600IN  A   193.184.54.212
lue.keskipohjanmaa.com. 3600IN  A   192.130.183.69

;; Query time: 31 msec
;; SERVER: 192.130.183.69#53(192.130.183.69)
;; WHEN: Mon Jun 10 20:59:44 FLE Daylight Time 2019
;; MSG SIZE  rcvd: 177


___
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: Strange DNS problem

[Jukka Pakkanen]

-Original Message-
From: Chris Thompson  On Behalf Of Chris Thompson
Sent: 10. kesäkuuta 2019 17:30
To: Jukka Pakkanen 
Cc: bind-us...@isc.org
Subject: Re: Strange DNS problem

On Jun 10 2019, Jukka Pakkanen wrote:

>We have a strange problem related to DNS services, maybe someone here 
>have a clue what could be the problem.
[…]
>An example, the client domain is raimoasikainenoy.fi.

Well, there is certainly something wrong with ns.datatower.fi [193.184.54.212], 
as it consistently returns server cookies that bear no relationship to the 
client cookie sent in the query, and in fact I get *exactly* the same one as 
you report:

>; <<>> DiG 9.14.2 <<>> @193.184.54.212 raimoasikainenoy.fi ns ; (1 
>server found) ;; global options: +cmd ;; Got answer:
>;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14591 ;; flags: qr 
>aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3 ;; WARNING: 
>recursion requested but not available
>
>;; OPT PSEUDOSECTION:
>; EDNS: version: 0, flags:; udp: 4096
>; COOKIE: a0ff0c014f65b471e0b8b271e7bab2718129c071 (bad)

every time! (Use +qr to show the client cookie sent by dig.)

I expect you could work around this by specifying 

  server 193.184.54.212 { send-cookie no; };

in your named.conf, but it seems to me that BIND 9.14 ought to be able to fall 
back on using ns.kpk.fi [192.130.183.74] which doesn't have this server cookie 
problem.

--
Chris Thompson
Email: c...@cam.ac.uk


Then, unfortunately our nameservers won't resolve ns.kpk.fi either.  So even if 
the fall back works, as I suppose it does, it does not help here.

; <<>> DiG 9.14.2 <<>> @ns1.qnet.fi ns.kpk.fi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 64299
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5fdcace005523ca0f1b0c9c95cfe96f17497773ef05635e1 (good)
;; QUESTION SECTION:
;ns.kpk.fi. IN  A

;; Query time: 0 msec
;; SERVER: 62.142.220.5#53(62.142.220.5)
;; WHEN: Mon Jun 10 20:44:17 FLE Daylight Time 2019
;; MSG SIZE  rcvd: 66

And again when inquiring directly with the IP of ns.kpk.fi, we do get an answer:


; <<>> DiG 9.14.2 <<>> @192.130.183.74 ns.kpk.fi
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50365
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ef9a3009864a202e5dfe5cfe9648adfe8be2561def4d (good)
;; QUESTION SECTION:
;ns.kpk.fi. IN  A

;; ANSWER SECTION:
ns.kpk.fi.  600 IN  A   192.130.183.74

;; Query time: 31 msec
;; SERVER: 192.130.183.74#53(192.130.183.74)
;; WHEN: Mon Jun 10 20:45:48 FLE Daylight Time 2019
;; MSG SIZE  rcvd: 82

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

Strange DNS problem

[Jukka Pakkanen]

We have a strange problem related to DNS services, maybe someone here have a 
clue what could be the problem.

We are running BIND 9.14.2 in several servers, ns1.qnet.fi, ns2.qnet.fi etc.  
Everything else works fine, but with one small operator (actually a 
mediahouse), we can not get any replies to DNS queries from them.   First 
thought it is a routing problem somewhere, but inquiring those servers with IP 
works, so can not be.

An example, the client domain is raimoasikainenoy.fi.

; <<>> DiG 9.14.2 <<>> @ns1.qnet.fi raimoasikainenoy.fi ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15578
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 55ba199a6d905273458bc2065cfe655462f150936d882603 (good)
;; QUESTION SECTION:
;raimoasikainenoy.fi. IN
NS

;; Query time: 4999 msec
;; SERVER: 62.142.220.5#53(62.142.220.5)
;; WHEN: Mon Jun 10 17:12:36 FLE Daylight Time 2019
;; MSG SIZE  rcvd: 76


>From our own providers nameservers it works however, also tested ok from a 
>couple other operators:

; <<>> DiG 9.14.2 <<>> @8.8.8.8 raimoasikainenoy.fi ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47848
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;raimoasikainenoy.fi. IN
NS

;; ANSWER SECTION:
raimoasikainenoy.fi. 3599IN 
   NS   ns.kpk.fi.
raimoasikainenoy.fi. 3599IN 
   NS   ns.datatower.fi.

;; Query time: 78 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Mon Jun 10 17:14:11 FLE Daylight Time 2019
;; MSG SIZE  rcvd: 96


Then testing from our network again, inquiring from ns.kpk.fi or 
ns.datatower.fi not working, our server cannot resolve those names.  But when 
inquiring with IP 193.184.54.212 (ns.datatower.fi):

;; Warning: Client COOKIE mismatch

; <<>> DiG 9.14.2 <<>> @193.184.54.212 raimoasikainenoy.fi ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14591
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a0ff0c014f65b471e0b8b271e7bab2718129c071 (bad)
;; QUESTION SECTION:
;raimoasikainenoy.fi. IN
NS

;; ANSWER SECTION:
raimoasikainenoy.fi. 3600IN 
   NS   ns.datatower.fi.
raimoasikainenoy.fi. 3600IN 
   NS   ns.kpk.fi.
;; ADDITIONAL SECTION:
ns.kpk.fi.   600  IN
A  192.130.183.74
ns.datatower.fi. 3600IN 
   A  193.184.54.212

;; Query time: 15 msec
;; SERVER: 193.184.54.212#53(193.184.54.212)
;; WHEN: Mon Jun 10 17:17:50 FLE Daylight Time 2019
;; MSG SIZE  rcvd: 156


So what can it be??   To every other operator/network our inquiries work fine, 
have been working 25 years :)  But only to this "operator" not.  Our servers 
cannot resolve the name of their servers, even it can do it when inquiring 
their servers directly by servers IP addresses.  Their NS records in the 
fi-root look little suspicious, like some of the servers lacked glue records, 
but not sure about that.

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

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

RE: BIND DNS problem (?)

[Jukka Pakkanen]

Yes looks like that, also this problem started suddenly, affects all our SMG & 
DNS servers, so very unlikely the problem is on our end.

Still Symantec "enterprise support technician" claims the problem is on our DNS 
servers, and as a "proof" send the chapter 4.1.1 of the RFC1035, where it is 
stated that "code 2 = server failure", and this should prove that our servers 
are not working because they got "server failure" error ;-)

Jukka


-Original Message-
From: Tony Finch [mailto:d...@dotat.at] 
Sent: keskiviikko 26. syyskuuta 2018 15.06
To: Jukka Pakkanen 
Cc: bind-users@lists.isc.org
Subject: RE: BIND DNS problem (?)

Jukka Pakkanen  wrote:

> Now got some more debug info, but does it help finding out why we get 
> the server failure?

The DNS servers for smg.brightmail.com are broken. They drop most queries which 
causes all sorts of problems.

Tony.
--
f.anthony.n.finchhttp://dotat.at/ Humber, Thames: Southwest 
4 or 5, occasionally 6 at first. Slight or moderate, but rough at first in 
Humber. Fair. Good, occasionally moderate.

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

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

RE: BIND DNS problem (?)

[Jukka Pakkanen]

Now got some more debug info, but does it help finding out why we get the 
server failure?

26-syyskuuta-2018 15.46.33.999 client @024562471630 62.142.220.9#8179 
(1d427bf569fa3b25355a5944e82b5e23.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 1d427bf569fa3b25355a5944e82b5e23.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692

26-syyskuuta-2018 15.46.33.999 client @024561EFABC0 62.142.220.9#37637 
(1d427bf569fa3b25355a5944e82b5e23.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 1d427bf569fa3b25355a5944e82b5e23.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692

26-syyskuuta-2018 15.46.33.999 fetch completed at ..\resolver.c:4175 for 
1d427bf569fa3b25355a5944e82b5e23.smg.ultra.brightmail.com/TXT in 10.014952: 
timed out/success 
[domain:smg.ultra.brightmail.com,referral:2,restart:2,qrysent:7,timeout:6,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

26-syyskuuta-2018 15.46.33.999 fetch completed at ..\resolver.c:4175 for 
31b126c2f9ec0fb531fb6f408760df5c.smg.ultra.brightmail.com/TXT in 10.014952: 
timed out/success 
[domain:smg.ultra.brightmail.com,referral:2,restart:2,qrysent:7,timeout:6,lame:0,quota:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:0]

26-syyskuuta-2018 15.46.33.999 client @024562641060 62.142.220.9#63769 
(31b126c2f9ec0fb531fb6f408760df5c.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 31b126c2f9ec0fb531fb6f408760df5c.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
...

Jukka

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jukka 
Pakkanen
Sent: keskiviikko 26. syyskuuta 2018 11.55
To: bind-users@lists.isc.org
Subject: RE: BIND DNS problem (?)

Started logging named now, but don't see much debug information with these 
logging settings:

logging {
category lame-servers { null; };
category edns-disabled { null; };
category security { security_file; };
category queries { queries_file; };
category resolver { resolver_file; };
category query-errors { query-errors_file; };

channel query-errors_file {
file "d:/logs/named/query-errors.log" versions 3 size 5m;
severity debug;
print-time yes;
};

channel queries_file {
file "d:/logs/named/queries.log" versions 3 size 5m;
severity debug;
print-time yes;
};

channel resolver_file {
file "d:/logs/named/resolver.log" versions 3 size 5m;
severity debug;
print-time yes;
};

channel security_file {
file "d:/logs/named/security.log" versions 3 size 5m;
severity debug;
print-time yes;
};

};


Query-errors:

26-syyskuuta-2018 12.00.59.794 client @01F5160E7150 62.142.220.9#28667 
(73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
26-syyskuuta-2018 12.00.59.794 client @01F516751E40 62.142.220.9#48236 
(6680545bc0584602c24adc8dd123f0b5.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 6680545bc0584602c24adc8dd123f0b5.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
26-syyskuuta-2018 12.00.59.794 client @01F51768CA50 62.142.220.9#47990 
(73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
...

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jukka 
Pakkanen
Sent: Wednesday, September 26, 2018 2:46 AM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: BIND DNS problem (?)

We are running a couple of Symantec SMG servers, and their DNS clients are 
configured to use your BIND 9.12.2 DNS servers.

In both SMG servers we get the same DNS "server failure" error from all our DNS 
servers when they do some TXT queries to SMG:

http://www.qnet.fi/jp/dns.png

(sorry for the bad quality/format, hope you can zoom in. That's all I got from 
Symantec when contacting their support, and they claim the problem is in our 
DNS servers because of the "server failure" error).

Anyway, I suppose the problem is related to these, in the response:


Answer authenticated: Answer/authority portion was not authenticated by the 
server
Non-authenticated data: Unacceptable


Sooo, any ideas what does this mean, is the problem in out BIND servers, or in 
the other end?

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

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

RE: BIND DNS problem (?)

[Jukka Pakkanen]

Started logging named now, but don't see much debug information with these 
logging settings:

logging {
category lame-servers { null; };
category edns-disabled { null; };
category security { security_file; };
category queries { queries_file; };
category resolver { resolver_file; };
category query-errors { query-errors_file; };

channel query-errors_file {
file "d:/logs/named/query-errors.log" versions 3 size 5m;
severity debug;
print-time yes;
};

channel queries_file {
file "d:/logs/named/queries.log" versions 3 size 5m;
severity debug;
print-time yes;
};

channel resolver_file {
file "d:/logs/named/resolver.log" versions 3 size 5m;
severity debug;
print-time yes;
};

channel security_file {
file "d:/logs/named/security.log" versions 3 size 5m;
severity debug;
print-time yes;
};

};


Query-errors:

26-syyskuuta-2018 12.00.59.794 client @01F5160E7150 62.142.220.9#28667 
(73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
26-syyskuuta-2018 12.00.59.794 client @01F516751E40 62.142.220.9#48236 
(6680545bc0584602c24adc8dd123f0b5.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 6680545bc0584602c24adc8dd123f0b5.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
26-syyskuuta-2018 12.00.59.794 client @01F51768CA50 62.142.220.9#47990 
(73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
...

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jukka 
Pakkanen
Sent: Wednesday, September 26, 2018 2:46 AM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: BIND DNS problem (?)

We are running a couple of Symantec SMG servers, and their DNS clients are 
configured to use your BIND 9.12.2 DNS servers.

In both SMG servers we get the same DNS "server failure" error from all our DNS 
servers when they do some TXT queries to SMG:

http://www.qnet.fi/jp/dns.png

(sorry for the bad quality/format, hope you can zoom in. That's all I got from 
Symantec when contacting their support, and they claim the problem is in our 
DNS servers because of the "server failure" error).

Anyway, I suppose the problem is related to these, in the response:


Answer authenticated: Answer/authority portion was not authenticated by the 
server
Non-authenticated data: Unacceptable


Sooo, any ideas what does this mean, is the problem in out BIND servers, or in 
the other end?

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

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

RE: BIND DNS problem (?)

[Jukka Pakkanen]

Started logging named now, but don't see much debug information with these 
logging settings:

logging {
category lame-servers { null; };
category edns-disabled { null; };
category security { security_file; };
category queries { queries_file; };
category resolver { resolver_file; };
category query-errors { query-errors_file; };

channel query-errors_file {
file "d:/logs/named/query-errors.log" versions 3 size 5m;
severity debug;
print-time yes;
};

channel queries_file {
file "d:/logs/named/queries.log" versions 3 size 5m;
severity debug;
print-time yes;
};

channel resolver_file {
file "d:/logs/named/resolver.log" versions 3 size 5m;
severity debug;
print-time yes;
};

channel security_file {
file "d:/logs/named/security.log" versions 3 size 5m;
severity debug;
print-time yes;
};

};


Query-errors:

26-syyskuuta-2018 12.00.59.794 client @01F5160E7150 62.142.220.9#28667 
(73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
26-syyskuuta-2018 12.00.59.794 client @01F516751E40 62.142.220.9#48236 
(6680545bc0584602c24adc8dd123f0b5.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 6680545bc0584602c24adc8dd123f0b5.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
26-syyskuuta-2018 12.00.59.794 client @01F51768CA50 62.142.220.9#47990 
(73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 73cb7fd0d8c8b44cd6e741d6eed0e612.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
26-syyskuuta-2018 12.00.59.794 client @01F5173936D0 62.142.220.9#46275 
(6680545bc0584602c24adc8dd123f0b5.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 6680545bc0584602c24adc8dd123f0b5.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
26-syyskuuta-2018 12.00.59.794 client @01F5173951F0 62.142.220.9#13544 
(84cbbbe69327045981177902b6ed7539.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 84cbbbe69327045981177902b6ed7539.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
26-syyskuuta-2018 12.00.59.794 client @01F5170931C0 62.142.220.9#26021 
(56909d41023d9bee0e972fa4ca487314.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for 56909d41023d9bee0e972fa4ca487314.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692
26-syyskuuta-2018 12.00.59.794 client @01F517390E20 62.142.220.9#35961 
(fb74971ab843d9ef29b498a817f135a0.smg.ultra.brightmail.com): query failed 
(SERVFAIL) for fb74971ab843d9ef29b498a817f135a0.smg.ultra.brightmail.com/IN/TXT 
at ..\query.c:10692



From: Jukka Pakkanen
Sent: keskiviikko 26. syyskuuta 2018 10.17
To: 'bind-users@lists.isc.org' 
Subject: RE: BIND DNS problem (?)

Updated the pic, should be readable now... posting the pcap later.

Jukka

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. 
Blue via bind-users
Sent: keskiviikko 26. syyskuuta 2018 9.50
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: RE: BIND DNS problem (?)

I could not zoom in to see anything.  Please post a better screenshot or better 
yet post the .pcap itself for download and review.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jukka 
Pakkanen
Sent: Wednesday, September 26, 2018 2:46 AM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: BIND DNS problem (?)

We are running a couple of Symantec SMG servers, and their DNS clients are 
configured to use your BIND 9.12.2 DNS servers.

In both SMG servers we get the same DNS "server failure" error from all our DNS 
servers when they do some TXT queries to SMG:

http://www.qnet.fi/jp/dns.png

(sorry for the bad quality/format, hope you can zoom in. That's all I got from 
Symantec when contacting their support, and they claim the problem is in our 
DNS servers because of the "server failure" error).

Anyway, I suppose the problem is related to these, in the response:


Answer authenticated: Answer/authority portion was not authenticated by the 
server
Non-authenticated data: Unacceptable



Sooo, any ideas what does this mean, is the problem in out BIND servers, or in 
the other end?


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

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

RE: BIND DNS problem (?)

[Jukka Pakkanen]

Updated the pic, should be readable now... posting the pcap later.

Jukka

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of John W. 
Blue via bind-users
Sent: keskiviikko 26. syyskuuta 2018 9.50
To: bind-users@lists.isc.org
Subject: RE: BIND DNS problem (?)

I could not zoom in to see anything.  Please post a better screenshot or better 
yet post the .pcap itself for download and review.

John

From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jukka 
Pakkanen
Sent: Wednesday, September 26, 2018 2:46 AM
To: bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>
Subject: BIND DNS problem (?)

We are running a couple of Symantec SMG servers, and their DNS clients are 
configured to use your BIND 9.12.2 DNS servers.

In both SMG servers we get the same DNS "server failure" error from all our DNS 
servers when they do some TXT queries to SMG:

http://www.qnet.fi/jp/dns.png

(sorry for the bad quality/format, hope you can zoom in. That's all I got from 
Symantec when contacting their support, and they claim the problem is in our 
DNS servers because of the "server failure" error).

Anyway, I suppose the problem is related to these, in the response:


Answer authenticated: Answer/authority portion was not authenticated by the 
server
Non-authenticated data: Unacceptable



Sooo, any ideas what does this mean, is the problem in out BIND servers, or in 
the other end?


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

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

BIND DNS problem (?)

[Jukka Pakkanen]

We are running a couple of Symantec SMG servers, and their DNS clients are 
configured to use your BIND 9.12.2 DNS servers.

In both SMG servers we get the same DNS "server failure" error from all our DNS 
servers when they do some TXT queries to SMG:

http://www.qnet.fi/jp/dns.png

(sorry for the bad quality/format, hope you can zoom in. That's all I got from 
Symantec when contacting their support, and they claim the problem is in our 
DNS servers because of the "server failure" error).

Anyway, I suppose the problem is related to these, in the response:


Answer authenticated: Answer/authority portion was not authenticated by the 
server
Non-authenticated data: Unacceptable



Sooo, any ideas what does this mean, is the problem in out BIND servers, or in 
the other end?


Jukka
___
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 ping/traceroute proxying effect

[Jukka Pakkanen]

Are you using IP addresses or domain names when testing?  If it works with IP 
address, but not with names, the sec. DNS server is lacking proper DNS services 
itself.


-Original Message-
From: bind-users-boun...@lists.isc.org 
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of The Doctor
Sent: 18. maaliskuuta 2015 17:17
To: bind-us...@isc.org
Subject: Weird ping/traceroute proxying effect

Finally our secondary's server BIND is working but not the ping/traceroute 
tools.

Unless one server is up, ping/traceroute does not work on the secondary DNS.

What do I need to find this issue?

--
Member - Liberal International This is doctor@@nl2k.ab.ca Ici 
doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware 
AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism Know 
how to listen, and you will profit even from those who talk badly.-Plutarch 
___
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: Resolve only authoritative domain for internet/public addresses

[Jukka Pakkanen]

Why not just:

acl X {A; B, C; ...; };

options {
...
allow-query { any; };
allow-recursion { X; };
...};

Jukka

8.7.2012 11:24, Phil Mayers kirjoitti:

On 07/08/2012 07:15 AM, Mr BeEye wrote:

Hello all.

Let's have a finite list of IPv4 (private and public) addresses, e.g.
{A, B, C, ... N}.

It is possible to configure BIND in the way:
1) BIND resolves EVERYTHING for {A, B, C, ... N}.
2) BIND resolves ONLY its authoritative domain for internet excluding
{A, B, C, ..., N}.



Yes. Use a view:

view internal {
  match-clients { a; b; c; ... n; };
  recursion yes;
  zone ... {
  }:
};

view external {
  zone ... {
  };
};

However, views are tedious in many ways. You need a copy of your 
authoritative zones in each view, and have to arrange the AXFR/NOTIFY 
to go to the right place. It's much easier IMO to run two different 
copies of bind on two different IPs (or machines).

___
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: forwarding @ to a different domain?

[Jukka Pakkanen]

www in cname mydomain.myshopify.com.
mydomain.com. in cname mydomain.myshopify.com.

Is this what you are looking for?


8.1.2012 17:48, enigmedia kirjoitti:

Hi All: I have a situation where I need to forward requests for mydomain.com
and www.mydomain.com to a third party: mydomain.myshopify.com (while still
pointing other things like MX records elsewhere).

I realize I can point a CNAME for WWW to mydomain.myshopify.com, but how do
I point mydomain.com to this third party if there is no A record to point to?

TIA


___
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: forwarding @ to a different domain?

[Jukka Pakkanen]

8.1.2012 19:02, enigmedia (onl) kirjoitti:
On Sun, 08 Jan 2012 20:00:07 +0200 Jukka Pakkanen 
jukka.pakka...@qnet.fi wrote



www in cname mydomain.myshopify.com.
mydomain.com. in cname 

mydomain.myshopify.com.


Is this what you are looking for?



Yes, but I thought you couldn't use a cname for the root record of the 
domain?


Oh yeas... I confused this to pointing the domain to an IP address / A 
record.


Is an A record pointing to the server and a dedicated IP address there 
an option?



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

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

Re: forwarding @ to a different domain?

[Jukka Pakkanen]

8.1.2012 20:46, Jukka Pakkanen kirjoitti:

8.1.2012 19:02, enigmedia (onl) kirjoitti:
On Sun, 08 Jan 2012 20:00:07 +0200 Jukka Pakkanen 
jukka.pakka...@qnet.fi wrote



www in cname mydomain.myshopify.com.
mydomain.com. in cname 

mydomain.myshopify.com.


Is this what you are looking for?



Yes, but I thought you couldn't use a cname for the root record of 
the domain?


Oh yeas... I confused this to pointing the domain to an IP address / A 
record.


Is an A record pointing to the server and a dedicated IP address there 
an option?


Of course don't need to be dedicated address either, but that's the way 
we usually do it.  Helps with the ptr records.



___
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: CNAME or A record?

[Jukka Pakkanen]

I think it's splitting hair but cname might be a bit more efficient. At 
least in the webserver end.


In practise, I don't think there's a real difference. You can choose 
which ever feels better :)


Jukka

28.9.2011 17:36, feralert kirjoitti:

Thanks Jeff,

But I really only wrote that as an example :) . The real question is
what is best or what is recommended, two A RR (one for domain, one for
www) or a single A RR for domain and a CNAME RR for www, is one way
better than the other or can I choose either way?

Cheers!,
Fred.



On Wed, Sep 28, 2011 at 4:30 PM, Lightner, Jeffjlight...@water.com  wrote:

If you set your SOA properly to use @ (which means this zone) your A 
records should be:

domain.com. A   1.1.1.1
www A   1.1.1.1

The SOA should append the domain.com to every record not terminated by a dot so that 
www is read as www.domain.com.  Similarly you put a dot at the end of domain.com A 
record to prevent it from being appended and read as domain.com.domain.com.





-Original Message-
From: bind-users-bounces+jlightner=water@lists.isc.org 
[mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf Of 
feralert
Sent: Wednesday, September 28, 2011 10:20 AM
To: bind-us...@isc.org
Subject: CNAME or A record?

Hi all,

I'm sure this has been asked trillions of times but since I couldn't
find any concrete answer/reference in google I am asking you guys in
this list. Sorry if anyone thinks this a dumb question or something
very obvious.

The thing is that i want users redirected to 'www.domain.com' even
when they just type the domain name 'domain.com'.
In order to do so I am not sure if its best to have one A RR for each
or have an A RR for the domain and a CNAME RR pointing to 'domain.com'
for 'www.domain.com'.


domain.com   A1.1.1.1
www.domain.com   A1.1.1.1

OR

domain.com   A1.1.1.1
www.domain.com   CNAME  domain.com


Any help appreciated.


Thanks,
Fred
___
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




Athena(r), Created for the Cause(tm)
Making a Difference in the Fight Against Breast Cancer

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



___
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: CNAME or A record?

[Jukka Pakkanen]

Webserver still has to get the request, so one way or the other is 
required anyway :)



28.9.2011 17:43, ?? kirjoitti:


this is the stuff what should be done by webserver rather than by DNS. 
i,e, Apache rewrite will do that.


? 2011-9-28 ??10:29,feralert feral...@gmail.com 
mailto:feral...@gmail.com ??:

 Hi all,

 I'm sure this has been asked trillions of times but since I couldn't
 find any concrete answer/reference in google I am asking you guys in
 this list. Sorry if anyone thinks this a dumb question or something
 very obvious.

 The thing is that i want users redirected to 'www.domain.com 
http://www.domain.com' even

 when they just type the domain name 'domain.com http://domain.com'.
 In order to do so I am not sure if its best to have one A RR for each
 or have an A RR for the domain and a CNAME RR pointing to 
'domain.com http://domain.com'

 for 'www.domain.com http://www.domain.com'.


 domain.com http://domain.com A 1.1.1.1
 www.domain.com http://www.domain.com A 1.1.1.1

 OR

 domain.com http://domain.com A 1.1.1.1
 www.domain.com http://www.domain.com CNAME domain.com 
http://domain.com



 Any help appreciated.


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


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


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

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


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

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

9.8.1b3 windows binary

[Jukka Pakkanen]

The link in the download page seems to point to b2...

Jukka
___
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: 9.8.1b3 windows binary

[Jukka Pakkanen]

16.7.2011 21:37, Evan Hunt kirjoitti:

The link in the download page seems to point to b2...

Whoops.  Thanks, we'll get that fixed.  Meantime, you can use the
direct ftp URL:

ftp://ftp.isc.org/isc/bind9/9.8.1b3/BIND9.8.1b3.zip



Yeah figured the correct address and just in the process of upgrading 
our servers...



___
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

9.8.0 in 2008 R2 x64 server

[Jukka Pakkanen]

I'm moving one of our DNS servers (Win 2003 R2, v9.7.0) to a new 2008 R2 
x64 server.


After installing v9.8.0 I copied the /etc directory  subdirectories, 
the named user has full rights in relevant directories and log on as a 
service rights... still I get the following error in eventviewer when 
trying to start the service:


none:0: open: C:\Windows\system32\dns\etc\named.conf: file not found

Any ideas?  The named.conf file IS there, and the directories/datafiles 
are identical to our old, working server.  Tested with administator as 
the user as well, same problem.





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

Re: more flexible serial number handling in dnssec-signzone

[Jukka Pakkanen]

 15.10.2010 20:54, Niobos kirjoitti:

What's the advantage of using a date anyway? I too can see when a zone
was last edited, even down to the second, by watching the RRSIG(SOA) timing.


Time usually goes to one direction only, forward... so using date/time 
makes sure you are always incrementing the serial. And you even don't 
need to know the current serial to update it.





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

Re: new webserver ip

[Jukka Pakkanen]

3.8.2010 15:07, dhottin...@harrisonburg.k12.va.us kirjoitti:
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



Did you update the serial  reloaded the zone?

ns2 seems to return the old address, ns1 didn't return anything. Except 
just started returning the new address...

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

9.7.1-P1 ISC error 54

[Jukka Pakkanen]

Lately have seen in our 9.7.1-P1 server following errors:

SOCKET_RECV: Windows error code: 1236, returning ISC error 54

And this warning:

*** POKED TIMER ***

Browsing the net told that this is/was a a common problem to even 
earlier Bind 9.x.x versions, but couldn't find any explanation or fix 
for it?


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

Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

Doing first time the RFC 2317 style subnet reverse DNS, and have a 
problem with recursion.  When doing a query like dig @ns1.qnet.fi -x 
62.142.217.200 is succeeds from the local network, but outside I get 
recursion requested but not available.  Our /24 reverse zones work 
fine, the server knows it's the master and serves ok, like dig 
@ns1.qnet.fi -x 62.142.220.5.


Recursion is only allowed for the local networks, but why the server 
thinks recursion is needed in the first place?


Server ns1.qnet.fi, BIND 9.7.1-P1 W2K3

named.conf:


zone 128/25.217.142.62.in-addr.arpa {
type master;
file named.62.142.217.25-128;
};


;
;File:  named.62.142.217.25-128
;

$TTL 86400
$ORIGIN 128/25.217.142.62.IN-ADDR.ARPA.

@IN SOAns1.qnet.fi. xxx.qnet.fi. (
201007281  ; serial number
28800  ; refresh every 12 hours
7200   ; retry after 2 hours
604800 ; expire after 2 weeks
86400) ; default ttl is 2 days
;
@IN NSns1.qnet.fi.
 IN NSns2.qnet.fi.
 IN NSns3.qnet.fi.




200  IN PTR   x200.qnet.fi.


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

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 11:29, Phil Mayers kirjoitti:

On 07/29/2010 08:58 AM, Jukka Pakkanen wrote:

Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion.  When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available.  Our /24 reverse zones work


It doesn't look like the reverse is deleted to you:

$ dig +comm +nocmd +noques +nostat @ns6.sci.fi 
25.217.142.62.in-addr.arpa ptr

;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 35109
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; AUTHORITY SECTION:
217.142.62.in-addr.arpa. 3600INSOAns3.sci.fi. 
hostmaster.sci.fi. 1280318067 3600 900 604800 3600


i.e. no CNAME records for the sub-/24.



What kind of output should I see in that query above?  The subnet we 
should have delegated to us is 62.142.217.128/25.


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

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 13:45, Phil Mayers kirjoitti:

On 29/07/10 10:00, Jukka Pakkanen wrote:

29.7.2010 11:29, Phil Mayers kirjoitti:

On 07/29/2010 08:58 AM, Jukka Pakkanen wrote:

Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion.  When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available.  Our /24 reverse zones work


Sorry, I'm being slightly dumb and getting confused. The zone is 
delegated fine.


As you've spotted, two of the 5 servers are responding (ns5.sci.fi and 
ns3.sci.fi) but the three others (ns[1,2,3].qnet.fi) return recursion 
needed


Presumably those servers aren't actually serving the zone correctly. 
Are you using views? If so, do you have the zone statement in all the 
applicable views?


No views on place, here's yet the whole named.conf from ns1.qnet.fi, 
only irrelevant zones removed.


acl qnet {62.142.220.0/24; 62.142.221.0/24; 62.142.217.128/25; 
217.152.62.176/29; 80.248.251.173/32; };
acl qnetservers {62.142.220.5/32; 62.142.220.6/32; 62.142.217.134/32; 
213.192.189.2/32; 195.74.0.10; };

acl admin {62.142.220.0/28; 62.142.217.128/29; };
acl bogusnets {0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24; 
224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };


options {

directory C:\windows\system32\dns\etc\namedb;
pid-file named.pid;
allow-query { any; };
allow-recursion { qnet; };
allow-transfer { qnetservers; };
blackhole { bogusnets; };
version Enttententten...;
statistics-file named_stats.txt;
max-cache-size 128M;
};

key rndc-key {
  algorithm hmac-md5;
  secret xxx;
};

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

logging {
category lame-servers { null; };
category edns-disabled { null; };
};

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

.

zone 64/27.217.142.62.in-addr.arpa {
type master;
file named.62.142.217.27-64;
};

zone 128/25.217.142.62.in-addr.arpa {
type master;
file named.62.142.217.25-128;
};

zone 220.142.62.in-addr.arpa {
type master;
file named.62.142.220;
};

zone 221.142.62.in-addr.arpa {
type master;
file named.62.142.221;
};


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

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 14:23, Mark Andrews kirjoitti:

In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes:
   

Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion.  When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available.  Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.
 

There is NOTHING wrong here.  You are not testing the servers properly.
   


Uuh... NOW I'm confused :)

There's definitely something wrong somewhere, because reverse-DNS for 
62.142.217.128/25 is not working as it should.


ns1.qnet.fi should be the authoritive reverse DNS server for that IP 
range, but it's not serving. Getting recursion requested but not 
available.



While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA,
it is not authoritative for 217.142.62.IN-ADDR.ARPA.  When you do
dig @ns1.qnet.fi -x 62.142.220.5 you are asking for
PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve.
   


62.142.220.0/24 has been delegated to out servers (qnet servers) and 
have been working fine for years. And are working at them moment.  
Mentioning 62.142.220.5 was just to inform that with similar 
configuration, this /24 reverse dns works ok.


The problem is the 62.142.217.128/25 network, which should be delegated 
to out servers, but for some reason they respond with recursion needed.




Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR
5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARPA
then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR
record at 5.128/25.217.142.62.IN-ADDR.ARPA.  It will then combine the
two answers and send it back to the original client.
   


62.142.217.5 is NOT supposed to be delegated to our servers.


Recursion is only allowed for the local networks, but why the server
thinks recursion is needed in the first place?
 

Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA.
   


I'm not asking that.


If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then
have all the information required to answer the query without asking
other services.
   


If it's a slave, how can I administer the zone?


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

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 14:26, Niobos kirjoitti:

On 2010-07-29 09:58, Jukka Pakkanen wrote
   

Recursion is only allowed for the local networks, but why the server
thinks recursion is needed in the first place?
 

Because it is: dig -x looks for 200.217.142.62.in-addr.arpa.
Your server is not a master for this zone; instead it's master for
128/25.217.142.62.in-addr.arpa.

The original request (200.217.142.62.in-addr.arpa.) is mapped via a
CNAME to a name inside your zone, but this mapping is done by the
ns3.sci.fi. nameserver; hence recursion is needed.
   


Ok, this makes sense to me too.  But what is the fix, I can't allow 
general recursion for the world?


Is it possible to allow recursion for this zone only?  (sorry being 
lazy, I'm sure this is in the ARM..).

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

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 14:50, Phil Mayers kirjoitti:

On 29/07/10 12:34, Jukka Pakkanen wrote:

29.7.2010 14:23, Mark Andrews kirjoitti:

In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes:


Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion.  When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available.  Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.


There is NOTHING wrong here.  You are not testing the servers properly.



Uuh... NOW I'm confused :)

There's definitely something wrong somewhere, because reverse-DNS for
62.142.217.128/25 is not working as it should.

ns1.qnet.fi should be the authoritive reverse DNS server for that IP
range, but it's not serving. Getting recursion requested but not
available.


No - Mark is right (apologies for my confusing posts). Assume an 
example IP of 62.142.217.200. Your server is authoritative for:


200.128/25.217.142.62.in-addr.arpa.

...not:

200.217.142.62.in-addr.arpa.

ns{3,5}.sci.fi have CNAMEs linking the two because they own the parent 
zone, so can answer a dig -x THEIP directly.


$ dig @ns3.sci.fi 200.217.142.62.in-addr.arpa ptr

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

;; ANSWER SECTION:
200.217.142.62.in-addr.arpa. 14400 INCNAME 
200.128/25.217.142.62.in-addr.arpa.

200.128/25.217.142.62.in-addr.arpa. 86400 IN PTR x200.qnet.fi.
___


Yeah, this makes sense.  But my question still is, what is wrong in our 
setup, since the goal is we can administer the 62.142.217.128/25 reverse 
DNS, without asking our upstream provider sci.fi for changes to the zone?


I also understand the requirement for the recursion, but I don't believe 
the cure is to allow recursion to any in the global options. I'm just 
browsing the net for zone specific recursion options, but haven't found 
anything yet...



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

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 15:10, Mark Andrews kirjoitti:

In message4c516756.5060...@qnet.fi, Jukka Pakkanen writes:
   

29.7.2010 14:23, Mark Andrews kirjoitti:
 

In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes:

   

Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion.  When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available.  Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.

 

There is NOTHING wrong here.  You are not testing the servers properly.

   

Uuh... NOW I'm confused :)
 

You were confused before but didn't know it. :-)


I knew it, but after your message I was more confused...



You were asking the
wrong question to the wrong server.  When you ask the right questions
to the right servers it works.

   


Well, the goal is to be able to administer the reverse DNS of that zone, 
and at the moment it's not happening. So there is still something wrong. 
Somewhere. I have to think about this from the endusers point of view as 
well, and for them the reverse DNS is broken.





There's definitely something wrong somewhere, because reverse-DNS for
62.142.217.128/25 is not working as it should.
 

The only thing wrong is your understanding of what should be happening.
   


I can't agree with that. Reverse DNS for IP address range 
62.142.217.128-254 is not working as we wish. So something is wrong 
somewhere. Maybe my terminology about address spaces  name spaces is 
off, but I suppose everybody at the list understands what I'm after.



ns1.qnet.fi should be the authoritive reverse DNS server for that IP
range, but it's not serving. Getting recursion requested but not
available.
 
   

While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA,
it is not authoritative for 217.142.62.IN-ADDR.ARPA.  When you do
dig @ns1.qnet.fi -x 62.142.220.5 you are asking for
PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve.
   

62.142.220.0/24 has been delegated to out servers (qnet servers) and
have been working fine for years. And are working at them moment.
Mentioning 62.142.220.5 was just to inform that with similar
configuration, this /24 reverse dns works ok.

The problem is the 62.142.217.128/25 network, which should be delegated
to out servers, but for some reason they respond with recursion needed.
 

No.  128/25.217.142.62.IN-ADDR.ARPA has been delegated to your servers.
If 62.142.217.128/25 was delegated to you servers you would have
128 zones, 128.217.142.62.IN-ADDR.ARPA ... 255.217.142.62.IN-ADDR.ARPA.

The reverses for 62.142.217.128/25 is still served by the servers for
217.142.62.IN-ADDR.ARPA.

   

Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR
5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARPA
   


I think you have missed the difference between the two cases/networks, 
one network of IP address is 62.142.217.128/25, the other one on 
62.142.220.0/24, otherwise I don't understand where you get the number 
5 in the messages refering to this problem?



then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR
record at 5.128/25.217.142.62.IN-ADDR.ARPA.  It will then combine the
two answers and send it back to the original client.

   

62.142.217.5 is NOT supposed to be delegated to our servers.
 


Like said, this IP has nothing to do with us.


Recursion is only allowed for the local networks, but why the server
thinks recursion is needed in the first place?

 

Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA.
   

I'm not asking that.
 

But you are.


No I'm not :)


   Please read the question section of the answers you get back.

;  DiG 9.3.6-P1  @ns1.qnet.fi -x 62.142.220.5

;; QUESTION SECTION:
;5.220.142.62.in-addr.arpa. IN  PTR
   


This is not the 62.142.217.128/25 network, where I have this problem. 
This is 62.142.220.0/24 network. Which works fine, regarding the reverse 
DNS.



If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then
have all the information required to answer the query without asking
other services.

   

If it's a slave, how can I administer the zone?
 

You don't.  You just have a copy of the zone locally.  The administrator
for 217.142.62.IN-ADDR.ARPA changes it.
   


So we gat back to my original problem again, how can I administer the 
zone on our server?  What needs to be done, in addition or differently 
of what's been done now.


Of course I could have asked how can I have reverse DNS delegated and 
working for IP addresses 62.142.217.128-254 to our Bind servers so that 
we can administer the reverse DNS of these IP addresses, but instead I 
tried to be more specific, tell what's been done, and what happens. And 
asked we I'm doing wrong when

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

Please everybody just forget the 62.142.220.0/24 network and 
62.142.220.5 address, the problem is not about them. It was just to 
inform that our servers are doing regular /24 reverse DNS just fine.


The problem is we are trying to set up and administer reverse DNS for 
62.142.217.128/25 IP network.



29.7.2010 15:10, Sami Kerola kirjoitti:

On 07/29/2010 01:38 PM, bind-users-requ...@lists.isc.org wrote:

Date: Thu, 29 Jul 2010 14:38:20 +0300
From: Jukka Pakkanenjukka.pakka...@qnet.fi
Subject: Re: Subnet reverse delagation, RFC 2317
To:bind-users@lists.isc.org
Message-ID:4c51682c.3080...@qnet.fi
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

29.7.2010 14:26, Niobos kirjoitti:

  On 2010-07-29 09:58, Jukka Pakkanen wrote

  Recursion is only allowed for the local networks, but why the 
server

  thinks recursion is needed in the first place?


  Because it is: dig -x looks for 200.217.142.62.in-addr.arpa.
  Your server is not a master for this zone; instead it's master for
  128/25.217.142.62.in-addr.arpa.

  The original request (200.217.142.62.in-addr.arpa.) is mapped via a
  CNAME to a name inside your zone, but this mapping is done by the
  ns3.sci.fi. nameserver; hence recursion is needed.


Ok, this makes sense to me too.  But what is the fix, I can't allow
general recursion for the world?

Is it possible to allow recursion for this zone only?  (sorry being
lazy, I'm sure this is in the ARM..).


I cannot understand why you need RFC 2317 delegation when you have two 
c-classes? But that's not an answer to problem.


# whois 62.142.220.5
[snip]
inetnum:  62.142.220.0 - 62.142.221.255
netname:  Q-NET

I see right that there's delegation  data on ns6.sci.fi. name server...

# dig +trace -x 62.142.220.5
[snip]
142.62.in-addr.arpa.172800  IN  NS  ns3.sci.fi.
142.62.in-addr.arpa.172800  IN  NS  ns6.sci.fi.
142.62.in-addr.arpa.172800  IN  NS  ns5.sci.fi.
142.62.in-addr.arpa.172800  IN  NS  ns.ripe.net.
;; Received 172 bytes from 192.134.0.49#53(NS3.NIC.FR) in 206 ms

220.142.62.in-addr.arpa. 14400  IN  NS  ns3.sci.fi.
220.142.62.in-addr.arpa. 14400  IN  NS  ns5.sci.fi.
220.142.62.in-addr.arpa. 14400  IN  NS  ns6.sci.fi.
;; Received 151 bytes from 195.74.0.10#53(ns3.sci.fi) in 217 ms

5.220.142.62.in-addr.arpa. 86400 IN PTR qntsrv2.qnet.fi.
5.220.142.62.in-addr.arpa. 86400 IN PTR ns1.qnet.fi.
5.220.142.62.in-addr.arpa. 86400 IN PTR qnet.fi.
220.142.62.in-addr.arpa. 86400  IN  NS  ns3.qnet.fi.
220.142.62.in-addr.arpa. 86400  IN  NS  ns1.qnet.fi.
220.142.62.in-addr.arpa. 86400  IN  NS  ns2.qnet.fi.
;; Received 154 bytes from 195.74.0.59#53(ns6.sci.fi) in 224 ms


...and further investigation is indicating...

# dig +norecurse @ns3.sci.fi. -x 62.142.220.5
;  DiG 9.6.1  +norecurse @ns3.sci.fi. -x 62.142.220.5
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 16475
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;5.220.142.62.in-addr.arpa. IN  PTR

;; AUTHORITY SECTION:
220.142.62.in-addr.arpa. 14400  IN  NS  ns5.sci.fi.
220.142.62.in-addr.arpa. 14400  IN  NS  ns6.sci.fi.
220.142.62.in-addr.arpa. 14400  IN  NS  ns3.sci.fi.

;; ADDITIONAL SECTION:
ns3.sci.fi. 14400   IN  A   195.74.0.10
ns5.sci.fi. 14400   IN  A   213.192.189.2
ns6.sci.fi. 14400   IN  A   195.74.0.59

;; Query time: 375 msec
;; SERVER: 195.74.0.10#53(195.74.0.10)
;; WHEN: Thu Jul 29 14:07:38 2010
;; MSG SIZE  rcvd: 151

# dig +norecurse @ns5.sci.fi. -x 62.142.220.5

;  DiG 9.6.1  +norecurse @ns5.sci.fi. -x 62.142.220.5
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 26753
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0

;; QUESTION SECTION:
;5.220.142.62.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
5.220.142.62.in-addr.arpa. 86400 IN PTR qnet.fi.
5.220.142.62.in-addr.arpa. 86400 IN PTR qntsrv2.qnet.fi.
5.220.142.62.in-addr.arpa. 86400 IN PTR ns1.qnet.fi.

;; AUTHORITY SECTION:
220.142.62.in-addr.arpa. 86400  IN  NS  ns3.qnet.fi.
220.142.62.in-addr.arpa. 86400  IN  NS  ns2.qnet.fi.
220.142.62.in-addr.arpa. 86400  IN  NS  ns1.qnet.fi.

;; Query time: 422 msec
;; SERVER: 213.192.189.2#53(213.192.189.2)
;; WHEN: Thu Jul 29 14:07:47 2010
;; MSG SIZE  rcvd: 154

# dig +norecurse @ns6.sci.fi. -x 62.142.220.5

;  DiG 9.6.1  +norecurse @ns6.sci.fi. -x 62.142.220.5
; (1 server found)
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 38750
;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0

;; QUESTION SECTION:
;5.220.142.62.in-addr.arpa. IN  PTR

;; ANSWER SECTION:
5.220.142.62.in-addr.arpa. 86400 IN PTR qnet.fi.
5.220.142.62.in-addr.arpa

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 15:21, Mark Andrews kirjoitti:

Yeah, this makes sense.  But my question still is, what is wrong in our
setup,
 


!!! NOTHING 
   


Well, then everything is good and I can go to my vacation... hopefully 
the clients whose IP addresses are NOT server correctly in the reverse 
DNS agree with this :o





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

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 15:43, Jukka Pakkanen kirjoitti:
Please everybody just forget the 62.142.220.0/24 network and 
62.142.220.5 address, the problem is not about them. It was just to 
inform that our servers are doing regular /24 reverse DNS just fine.


The problem is we are trying to set up and administer reverse DNS for 
62.142.217.128/25 IP network.





An update, now it seems to be working.

dig -x 62.142.217.200 from non-local network returns correct answer. 
Don't know if the upstream provider did something, ttl expired or something.


Anyway we also have 62.142.217.64/27 IP network (you know what I mean) 
which should be delegated to our servers, but that still doesn't work. 
But it's probably a delegation problem.




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

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 16:00, Mark Andrews kirjoitti:

Sorry about using 5 instead of something from 128 to 255 in the
examples.  That said there is nothing wrong here.
   


Now I can agree :)

However earlier our servers only answered to the local queries about 
those IP addresses, started working during this afternoon from non-local 
networks as well. My wild guess is there's a ttl in the original reverse 
DNS server for that (or parent) zone, which messed things??



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

Re: Subnet reverse delagation, RFC 2317

[Jukka Pakkanen]

29.7.2010 17:06, Niobos kirjoitti:

On 2010-07-29 15:00, Jukka Pakkanen wrote:
   

Anyway we also have 62.142.217.64/27 IP network (you know what I mean)
which should be delegated to our servers, but that still doesn't work.
But it's probably a delegation problem.
 

 From my point of view, 62.142.217.64 is served by ns3.sci.fi (and its
slaves) and is not delegated to you (ns1.qnet.fi).

;  DiG 9.7.0-P1  64.217.142.62.in-addr.arpa.
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 5200
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;64.217.142.62.in-addr.arpa.IN  A

;; AUTHORITY SECTION:
217.142.62.in-addr.arpa. 3600   IN  SOA ns3.sci.fi. hostmaster.sci.fi.
1280318067 3600 900 604800 3600

   


Thanks, looks the same here. Already contacted sci.fi hostmaster about this.


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

Re: MX and A

[Jukka Pakkanen]

Sounds like a problem with your smtp servers rather than dns. Setting up 
the A record for the domain should have no effect for the email delivery 
in properly configured system.


What mechanism those smtp servers use to deliever the message to the 
clients email server, and have you checked the logs at the smtp servers, 
probably find the problem right there.



11.4.2010 11:06, Mihamina Rakotomandimby kirjoitti:

Matus UHLAR - fantomasuh...@fantomas.sk  :
 

With this, the HTTP constraint is OK, but the domain owner
doesnt receive mails.
   

doesn't receive what mails?
 

Matus  Noel,

The zone is emip.mg

With these settings:

   $ttl 38400
   emip.mg. IN SOA ns.malagasy.com. postmaster.malagasy.com.
   (
2010040900
10800
3600
604800
38400
   )
   @   IN NSns1.mg.tambazotra.net.
   @   IN NSns2.mg.tambazotra.net.
   @   IN NSns1.fr.malagasy.com.
   @   IN MX 10 smtp1.mg.tambazotra.net.
   @   IN MX 20 smtp2.mg.tambazotra.net.
   @   IN MX 30 smtp3.mg.tambazotra.net.
   @   IN  A64.8.123.230 this the guilty
   but I dont know why
   www IN  A64.8.123.230

The @emip.mg dont receive any email message.

With these settings:

   $ttl 38400
   emip.mg. IN SOA ns.malagasy.com. postmaster.malagasy.com.
   (
2010040900
10800
3600
604800
38400
   )
   @   IN NSns1.mg.tambazotra.net.
   @   IN NSns2.mg.tambazotra.net.
   @   IN NSns1.fr.malagasy.com.
   @   IN MX 10 smtp1.mg.tambazotra.net.
   @   IN MX 20 smtp2.mg.tambazotra.net.
   @   IN MX 30 smtp3.mg.tambazotra.net.
   www IN  A64.8.123.230

The @emip.mg domain receives its messages correctly, after I suppressed
the @   IN  A64.8.123.230 line.

Dont bother on the serial it's a cut'n paste in order to show you my
configuration, I took the time to increase it after each change.

I really need to have that @   IN  A64.8.123.230 record because I
want the emip website to be reachabe on http://emip.mg too. (as well as
http://www/emip.mg).
And the MX should stay as it is.

Thank you for your help.


   


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

Re: Bind slave to Windows 2008 AD/DNS

[Jukka Pakkanen]

Chris Buxton kirjoitti:

On Dec 7, 2009, at 2:47 PM, Jukka Pakkanen wrote:
  

I have out Bind servers running as slaves to Windows 2008 DNS server, and it's 
working fine as far as I can see (except that the slaves after a period of 
times lose the data and never update it unless restart the Bind process, but 
that's another matter) but browsing the web I noticed there should be 6 zones I 
need to slave to have it correctly:



What zones are you slaving on your BIND server? There should be six:

DomainDNSZones.example.com
ForestDNSZones.example.com
_msdcs.example.com
_sites.example.com
_tcp.example.com
_udp.example.com

If you have these six zones slaved on your BIND server, and these zones are being 
transferred successfully, then there should be no problems. 
  

What exactly does this mean?  I only have this:

zone company.local {
  type slave;
  file company.local.cache;
  masters { 62.x.x.x; };
};

Should I instead have these six zones in the named.conf



That depends on whether they're declared as delegated subzones or included in 
the company.local zone. By default, the AD wizard will create just 
company.local and _msdcs.company.local as zones - the other subdomains are not 
separated into their own individual zones.
  
Thanks. Those 6 zones are subdomains to company.local so I guess they 
are covered.  What about the _msdcs.company.local, is that needed in slaves?




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

Bind slave to Windows 2008 AD/DNS

[Jukka Pakkanen]

I have out Bind servers running as slaves to Windows 2008 DNS server, 
and it's working fine as far as I can see (except that the slaves after 
a period of times lose the data and never update it unless restart the 
Bind process, but that's another matter) but browsing the web I noticed 
there should be 6 zones I need to slave to have it correctly:


What zones are you slaving on your BIND server? There should be six:

DomainDNSZones.example.com
ForestDNSZones.example.com
_msdcs.example.com
_sites.example.com
_tcp.example.com
_udp.example.com

If you have these six zones slaved on your BIND server, and these 
zones are being transferred successfully, then there should be no 
problems. 


What exactly does this mean?  I only have this:

zone company.local {
   type slave;
   file company.local.cache;
   masters { 62.x.x.x; };
};

Should I instead have these six zones in the named.conf, like:

zone DomainDNSZones.company.local {
   type slave;
   file domaindnszones.company.local.cache;
   masters { 62.x.x.x; };
};

zone ForestDNSZones.company.local {
   type slave;
   file forestdnszones.company.local.cache;
   masters { 62.x.x.x; };
};

zone _msdcs.company.local {
   type slave;
   file _nsdcs.company.local.cache;
   masters { 62.x.x.x; };
};

etc...??


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

Re: Non English Domain names

[Jukka Pakkanen]

Yeah, no problems with scandinavian letters either.

http://en.wikipedia.org/wiki/Punycode


Sener ATAS kirjoitti:

Hi,

We use bind with turkish characters. And it works perfectly.
for *www.bü.edu.tr* you must edit your zone like *www.xn--b-eha.edu.tr

*Alans wrote:


Hi,

 

I know this is a little bit off topic but I would like to know how 
BIND will handle non English domain names? How this effect Bind?


ICANN started working on non English domains from today as far as I know.

 

 


Regards,

Alans



___
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: Bind sometimes SERVFAIL

[Jukka Pakkanen]

 Hello,
 
 My Internet ISP give two nameservers address.
 But when I'm asking those two servers sometimes I get:
 [r...@linux ~]# host d.yimg.com ns.my.isp
 Using domain server:
 Name: ns.my.isp
 Address: ns.my.isp#53
 Aliases:
 Host d.yimg.com not found: 2(SERVFAIL)

I just saw the same thing:

metis% host d.timg.com
Host d.timg.com not found: 3(NXDOMAIN)
metis% !!
host d.timg.com
Host d.timg.com not found: 3(NXDOMAIN)
metis% host d.yimg.com 
d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net.
geoycs-d.gy1.b.yahoodns.net is an alias for 
fo-anyycs-d.ay1.b.yahoodns.net.
fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.88.88
metis% named -v
BIND 9.6.1-P1

Above executed in the space of about a minute...
---

timg  yimg




 
 but sometimes I get:
 
 [r...@linux ~]# host d.yimg.com ns.my.isp
 Using domain server:
 Name: ns.my.isp
 Address: ns.my.isp#53
 Aliases:
 d.yimg.com is an alias for geoycs-d.gy1.b.yahoodns.net.
 geoycs-d.gy1.b.yahoodns.net is an alias for 
fo-anyycs-d.ay1.b.yahoodns.net.
 fo-anyycs-d.ay1.b.yahoodns.net has address 98.137.80.54
 
 
 He explain me this thats a normal because of this:
 http://www.faqs.org/rfcs/rfc2308.html
 Some resolvers incorrectly continue processing if the authoritative
answer flag is not set, looping until the query retry threshold is
exceeded and then returning SERVFAIL.  This is a problem when your
nameserver is listed as a FORWARDER for such resolvers.  If the
nameserver is used as a FORWARDER by such resolver, the authority
flag will have to be forced on for NXDOMAIN responses to these
resolvers.  In practice this causes no problems even if turned on
always, and has been the default behaviour in BIND from 4.9.3
onwards.
 
 Is this true ?
 
 Thanks
 Pawel R.
 
 
 
 ___
 bind-users mailing list
 bind-users@lists.isc.org
 https://lists.isc.org/mailman/listinfo/bind-users

-
Gregory Hicks   | Principal Systems Engineer
| Direct:   408.569.7928

People sleep peaceably in their beds at night only because rough men
stand ready to do violence on their behalf -- George Orwell

The price of freedom is eternal vigilance.  -- Thomas Jefferson

The best we can hope for concerning the people at large is that they
be properly armed. --Alexander Hamilton

___
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 configuration help

[Jukka Pakkanen]

Sorry, but could You specify more accurately what is bad ? This is
my first bind configuration, so probably I've made some mistakes, but
I'd like to do it the right way in the end.:)

On Tue, Nov 10, 2009 at 11:19 PM, Laurent CARON lca...@lncsa.com wrote:
 allow-recursion { any; };

 bad

 allow-transfer { any; };

 bad


It's usually a bad idea to allow any to use your server recursively, or allow 
any transfer zone data. Like an open dns-server.




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

RE: bind configuration help

[Jukka Pakkanen]

 

 

From: Holger Honert [mailto:holger.hon...@signal-iduna.org] 
..



*Please be carefull when quoting, this was not me:


Jukka Pakkanen schrieb: 

Sorry, but could You specify more accurately what is bad ? This is
my first bind configuration, so probably I've made some mistakes, but
I'd like to do it the right way in the end.:)
 
On Tue, Nov 10, 2009 at 11:19 PM, Laurent CARON  mailto:lca...@lncsa.com
lca...@lncsa.com wrote:
  

allow-recursion { any; };
  

bad
 


allow-transfer { any; };
  

bad
 


*This was mine:
 
It's usually a bad idea to allow any to use your server recursively, or
allow any transfer zone data. Like an open dns-server.
 
 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Slave to Win2003 DNS

[Jukka Pakkanen]

bsfin...@anl.gov kirjoitti:

Jukka Pakkanen jukka.pakka...@qnet.fi wrote:

  
Our Bind 9.6.1-P1 Windows servers are slaves to a Windows 2003 DNS 
server, zone company.local.


For some reason t he slaves don't update the zone unless I restart the 
BIND service in the server, and after a while, fail to respond to queries.


Example, after a couple of days since the last restart, the BIND servers 
stops responding to queries to company.local (SERVFAIL), at the server 
I can see that the cache file is not updated since the service was 
previously started.  I restart BIND service, and immediately the cache 
file is updated, server again responses to queries etc.


I suspect this is not a problem in the BIND, but in the Windows 2003 
DNS, but any ideas anyway, what to look in the server?  Haven't been 
playing with the Windows DNS a lot...



I have seen the three replies to this, and I will add the following:

Is the W2003 DNS Server sending NOTIFY packets to the BIND slaves
when a zone is updated?  
I suppose it is, because earlier today when I checked the serial number 
was updated in the master since the weekend, and the two working slaves 
had the updated serial as well. And when made a change to the zone, they 
updated the zone file in a short time as well.  Also if you check the 
servers right now, they are already at 6278, so looks like the notify 
 zone transfers work ok.


But for still unknown reason the slaves at some point stop responding 
queries to this zone (servfail) and won't recover until service restart. 
Maybe after the zone data is expired (24hrs), if not refreshed/updated 
before that??


These same servers are slaves to a bind master, and have no problems there.


Do you have DNS logging enabled on the MS DNS Server?  I suggest that
full logging be enabled, and the dns.log file be made sufficiently
large so that you will be able to see what may be happening.  Note
that the dns.log file increases in size until it reaches its max
size; then it is cleared, and new entries are added.  The dns.log
file is NOT a syslog file, as we in the Unix community are used to
using.
  

I'll check that and enable if not already.


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

Re: Slave to Win2003 DNS

[Jukka Pakkanen]

Matus UHLAR - fantomas kirjoitti:

On 31.10.09 12:07, Jukka Pakkanen wrote:
  
Our Bind 9.6.1-P1 Windows servers are slaves to a Windows 2003 DNS  
server, zone company.local.


For some reason the slaves don't update the zone unless I restart the  
BIND service in the server, and after a while, fail to respond to 
queries.


Example, after a couple of days since the last restart, the BIND servers  
stops responding to queries to company.local (SERVFAIL), at the server  
I can see that the cache file is not updated since the service was  
previously started.  I restart BIND service, and immediately the cache  
file is updated, server again responses to queries etc.


I suspect this is not a problem in the BIND, but in the Windows 2003  
DNS, but any ideas anyway, what to look in the server?  Haven't been  
playing with the Windows DNS a lot...



Is the master updating SOA serial?
  

It is. And notify name servers  is  chosen.

Our slave servers are ns1.qnet.fi, ns2.qnet.fi and ns3.qnet.fi.  And the 
master win2003 server is xeon.merinova.fi.  The zone is merinova.local 
and example host xeonx.merinova.local.


At the moment ns3 is not responding to queries to merinova.local.

Also just made few updates to the zone, the serial in the master is 6240 
but the responding slaves ns1 and ns2 still report 6239.



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

Slave to Win2003 DNS

[Jukka Pakkanen]

Our Bind 9.6.1-P1 Windows servers are slaves to a Windows 2003 DNS 
server, zone company.local.


For some reason the slaves don't update the zone unless I restart the 
BIND service in the server, and after a while, fail to respond to queries.


Example, after a couple of days since the last restart, the BIND servers 
stops responding to queries to company.local (SERVFAIL), at the server 
I can see that the cache file is not updated since the service was 
previously started.  I restart BIND service, and immediately the cache 
file is updated, server again responses to queries etc.


I suspect this is not a problem in the BIND, but in the Windows 2003 
DNS, but any ideas anyway, what to look in the server?  Haven't been 
playing with the Windows DNS a lot...


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

Re: [SPAM] Win2k and bind

[Jukka Pakkanen]

Unfortunately W2K was dropped a while ago, no safe version available for it.


 I know this is a very lame question, But I have been out of the Bind loop
 for a number of years ( yes I went over to the dark side ...MS DNS) but I
 want to come back.  My question is this I have win2K servers what version
 of
 bind will run on this?

 Thanks
 Greg

 This message has been checked by the GDSI Barracuda SPAM/Virus Firewall.

 ___
 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: weight for RR

[Jukka Pakkanen]

Scott Haneda wrote:

Maybe cheat with round robin? Add 3 copies of one record and 1 of the
other. That should give you 75/25 roughly.


BIND won't let you do that, it'll throw away the duplicates when it
loads the zone.

You need some other piece of software or hardware that can do that
(insert vendor name here).  Or a BIND patch, e.g, to enhance rrset-order
{} functionality (I don't know of a public one).  Or use SRV records
instead if this is for an application you are developing.

Regards,
Mike


Or assign three IP:s to other server, and point them all to the www server.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: What are these entries in the log file - query: . IN NS +?

[Jukka Pakkanen]

Sorry remembered wrong, it's not free. But not that expensive either.

Yeah now I remember, I browsed for a free firewall for server platform for 
days, but didn't find any.


But have been very happy with the Net Firewall.

Jukka


Tony Toews [MVP] tto...@telusplanet.net kirjoitti 
viestissä:p3evn4t6r9spme6ardiqbohjvlt99vt...@4ax.com...

Jukka Pakkanen jukka.pakka...@qnet.fi wrote:

There are many free third party firewall packages that can be run in 
Window=

s =

2003 Server, we use the Net Firewall.

Do you have a URL?  I found http://www.ntkernel.com/wp.php?id=18 but it's 
not free.

I'm also going to ask my fellow MVPs as well.

Tony
--
Tony Toews, Microsoft Access MVP
   Please respond only in the newsgroups so that others can
read the entire thread of messages.
   Microsoft Access Links, Hints, Tips  Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
   Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
___
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: What are these entries in the log file - query: . IN NS +?

[Jukka Pakkanen]

Tony Toews [MVP] tto...@telusplanet.net kirjoitti 
viestissä:p2vsn4leohtc8dm4a7m8rt4g6d4kem2...@4ax.com...

Noel Butler noel.but...@ausics.net wrote:

Surely windows can block access to an inbound IP request from some IP
to local udp port 53 ?

Not the firewall software built into Windows 2003 Server.

If not, you know what my next reply will be don't you :)

chuckleYeah, well switching to Linux ain't gonna happen.  My friend and 
I have no

experience with Linux and no desire to learn it.


There are many free third party firewall packages that can be run in Windows 
2003 Server, we use the Net Firewall.



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

Re: Bind 9.6.0p1- Windows - The service did not respond to the startor control request in a timely fashion.

[Jukka Pakkanen]

Chiesa Stefano wrote:

Hi all.
Maybe it's not a new issue, but...

I have a Windows 2003 SP2 with a 9.4.2 release that worked fine for
years.
Today I wanted to upgrade my release to 9.6.
I installed it but when I try to start the service the system says:

Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7000
Date: 1/8/2009
Time: 1:45:55 PM
User: N/A
Computer: S-MI-DNS
Description:
The ISC BIND service failed to start due to the following error:
The service did not respond to the start or control request in a timely
fashion.

No other messages in Event Viewer. I reinstalled the 9.4.2 version and
everything returned to work...
Does someone know why (and the solution)?


Run named from the command line: named -g
and see what the output looks like. It sounds like a configuration
problem but it's hard to tell.


When I upgraded 9.5.1 - 9.6 I manually had to add user rights to the named 
directory, even they were there earlier.


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

RE: Bind 9.6.0p1- Windows - The service did not respond to the startor control request in a timely fashion.

[Jukka Pakkanen]

Jukka Pakkanen wrote:
 Chiesa Stefano wrote:
 Hi all.
 Maybe it's not a new issue, but...

 I have a Windows 2003 SP2 with a 9.4.2 release that worked fine for
 years.
 Today I wanted to upgrade my release to 9.6.
 I installed it but when I try to start the service the system says:

 Event Type: Error
 Event Source: Service Control Manager
 Event Category: None
 Event ID: 7000
 Date: 1/8/2009
 Time: 1:45:55 PM
 User: N/A
 Computer: S-MI-DNS
 Description:
 The ISC BIND service failed to start due to the following error:
 The service did not respond to the start or control request in a timely
 fashion.

 No other messages in Event Viewer. I reinstalled the 9.4.2 version and
 everything returned to work...
 Does someone know why (and the solution)?

 Run named from the command line: named -g
 and see what the output looks like. It sounds like a configuration
 problem but it's hard to tell.
 
 When I upgraded 9.5.1 - 9.6 I manually had to add user rights to the
 named directory, even they were there earlier.

Can you include details of what appears to have changed?

The assigned user doesn't have any rights in the named directory, also
happens often when installing to a clean machine. I don't know if the
install process is even supposed to grant rights but at least it often
(always?) is like that. This time it looks like the 9.6.0 install process
even removed the rights from the assigned user :o

I'm not 100% sure of that, but at least after the update there were no any
rights for the user, and it only started to working after manually adding
them (full rights for the named dir  subdirs).



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

ISC BIND Windows?

[Jukka Pakkanen]

Sorry I've lost track of the different versions, which works in Windows and 
which don't.


So... what is the latest version, working in W2K3?  And Is W2K still 
abandoned?



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