Re: Conflicting glue records?

[Matthew Pounsett]

On 08-Jan-2009, at 03:41 , Dawn Connelly wrote:


Right, but his question was regarding the host record for the name
server. You tell the registrar the name and IP address of the name
servers that are authoritative for the domain. The registrar then
pushes those glue records to the root servers. Root doesn't care what
the name and/or IP address of the name servers are. They are unrelated
across domains. There isn't any cross domain verification. If you say
that the FQDN and IP address of the authoritative name server is
something, the registrar believes you and tells root. Root believes
the registrar. The registrar and root don't do a lookup on the FQDN of
the name server that is provided- hence it being called a glue record.
You have to manually enter that data. At least that has been the case
with ever registrar I've dealt with.


Again, this is quite wrong, on several points.

Host records for his domain don't go into the root unless he's  
managing a TLD.. and if that's the case he's not dealing with a  
registrar.


Whether or not the registrar or the registry do a lookup on the host  
records being supplied is irrelevant to why the entry in the DNS is  
called glue.  In cases where a nameserver is a subdomain of the domain  
it is authoritative for, delegations can't happen without the parent  
zone supplying an IP address... without the address being supplied by  
the parent zone you'd have a catch-22 in the resolution process.   
Supplying that IP address glues the two zones together.. hence the  
name.


And finally to the poster's original question..

This is actually more of an issues of registr operations and/or EPP,  
rather than DNS.  According to the EPP spec only the registrar  
sponsoring the domain can register host records within it.  So, to  
borrow from someone else's example, only the domain holder for  
apple.com can register the host records ns1.apple.com and  
ns2.apple.com.  The orange.com registrant can't create a host record  
for ns1.apple.com and register an IP address with it.   The registrar  
*may* accept this data from the registrant anyway, but it shouldn't  
(according to the spec) be passed on to the registry.  I suppose the  
registry could also accept it from the registrar (though in the case  
of .com I doubt this violation is occurring) but it shouldn't be  
published into the DNS.  Only the host records registered by the  
apple.com domain holder should wind up there.


Matt


PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: unwanted delegations was: What to do about openDNS

[Matthew Pounsett]

On 21-Jan-2009, at 03:23 , Scott Haneda wrote:


On Jan 20, 2009, at 6:42 PM, Matthew Pounsett wrote:

Registries that implement host records (so, at least the gTLDs)  
could accept the word of the registrant of the zone that contains a  
name server (or the word of their registrar on their behalf) that  
the server is no longer authoritative for zone X.  Registries that  
haven't implemented host records could also do it, but it may be  
more complicated to implement, depending on their particular system.



This is actually an interesting idea to me.

However, the one thing that no one has chimed in on yet, is this  
seems to me to be an openDNS issue.  The current DNS system works  
pretty well.  It actually handles this case rather gracefully, with  
proper caching there is no real danger.  My issue is the relentless  
pounding openDNS does, and for reasons I am not able to even guess.


It does sound like they're doing something at least odd, if not  
completely wrong.  I suspect it's probably related to the way they  
substitute  opcode 3 (nxdomain) with their own answers -- they're  
probably making absolutely certain that the host doesn't exist, or  
something.  What you describe seems excessive, though.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: allow-query-cache and resolution time

[Matthew Pounsett]

On 22-Jan-2009, at 16:00 , LENA MATUSOVSKAYA, BLOOMBERG/ 731 LEXIN  
wrote:



Hello,

Thank you for answering my quesiton yesterday.

I have a new question about allow-query-cache and its effect on a  
dns server' response resolution time.


allow-query-cache specifies which hosts are allowed to get answers  
from the cache. I'm assuming this is refering to the memory cache.
If allow-query-cache is set to none in options/views statement  
does it mean that the DNS server's query response time would be less  
efficient/slower than with setting allow-query-cache to any?
If the answer is allow-query-cache is leff efficient, is it possible  
to override the setting for some zones and how? allow-query-cache  
cannot be used within zone statements.



I'm going to assume you're talking about a recursive server and not an  
authoritative server.


You generally do not want to restrict caching by zone, but rather by  
query source.  That is, you want the computers in your network to be  
able to do recursion (and get responses from cache) for all zones, but  
you do not want computers outside your network (outside of your  
control) using your recursive server at all, because that makes you a  
vector for denial of service against other people's networks.


Normally, the setting on a recursive server for allow-query-cache will  
match your restrictions on recursion.  That is, the same clients which  
are allowed to send recursive queries are allowed to get answers from  
cache.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal

[Matthew Pounsett]

On 25-Jan-2009, at 03:44 , Al Stu wrote:

When a domain name associated with an MX RR is looked up and the  
associated data field obtained, the data field of that response MUST  
contain a domain name.That domain name, when queried, MUST  
return at least one address record (e.g., A or  RR) that gives  
the IP address of the SMTP server to which the message should be  
directed.


Correct.  And when a that domain name is a CNAME pointing to an A RR  
the query returns not only the alias but also the real name and the  
IP address from the A RR.  Thus meeting the requirements to return  
at least one address record (e.t., A or  RR).  But yet ISC  
seems to find it necessary to throw a message that it is illegal,  
when it clearly is not.


You've added an additional step in your second paragraph that is  
prohibited by the section you quoted in the first.  The section from  
the RFC describes a situation where A is queried for and an MX record  
pointing to B is returned.  When B is queried for, an address record  
MUST be the answer.   The situation you have described is that A is  
queried for resulting in an MX record pointing to B.  When B is  
queried for, a CNAME pointing to C is returned, and that when C is  
queried an address record is returned.  Do you see the difference?


The RFCs are quite clear that CNAMEs are not permitted in the RDATA  
for an MX.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: BIND 9.6 Flaw - CNAME vs. A Record in MX Records are NOT Illegal

[Matthew Pounsett]

On 25-Jan-2009, at 13:15 , Al Stu wrote:


Yes, blah was supposed to be srv1.

I do receive both the CNAME and A records for the A mx.xyz.com  
query.  See attached capture file.


In the capture file three global search and replacements were  
performed to match the previous example.


1) domain name was replaced with xyz
2) server name was replaced with srv1
3) server ip address was replaced with 1.2.3.4

Requirements are met.


Al, I'm sorry, but you're wrong.  If you look closely at what you just  
typed, you'll see that's three steps.. not the two steps required by  
the MUST in the RFC.


Your attachment didn't make it through the list manager.  I suggest  
you paste in some dig output instead.  If you do, you'll notice that  
the IP address you're receiving is in the ADDITIONAL section of the  
DNS message, which does not qualify as an ANSWER.


I'm going to stop contributing to this thread now.. if you insist on  
ignoring the pointers people have given you to the text in the RFCs,  
and insist on reading your own interpretation into it, we cannot stop  
you.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Forcing a secondary update...

[Matthew Pounsett]

On 26-Jan-2009, at 17:50, Jeff Justice wrote:

Without getting into how I managed to accomplish this, I have wound  
up with a secondary DNS that has incorrect information in it but the  
serial numbers are the same as on the master.


So, my question is:  how can I get the secondary to sync up?  I  
presume all I would need to do is make a single change to the zones  
on the master, thus changing the serial number, and causing the  
secondary to update.


The info in the master is correct, so I really don't need to change  
anything, but I could add something then delete it.  Is there an  
automated way I can do this, or batch method?  There are just enough  
zones as to make this a real hassle if I were to do it one by one.


An update to the serial number is the indicator to the master, and  
then to the slaves, that some change has occurred and the zone should  
be re-loaded or transferred.. but an actual change to the data isn't  
required to make that happen.  You can just update the serial number  
on the master and tell it to reload without altering any other data...  
the rest will take care of itself.


Matt





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: my DNS not resolving

[Matthew Pounsett]

On 29-Jan-2009, at 13:49, S. Jeff Cold wrote:


BIND List,

I have a server running OpenSuse 11.1 with BIND 9.5.0P2-18.1.   
This server has a dedicated IP address from my ISP.  I want this  
server to resolve my registered domain jatec.us.  The server has  
internet connectivity.  If I dig jatec.us, I get:



[...]

;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 2074
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0


Your domain doesn't appear to have been registered yet (or, perhaps,  
is registered but is simply not yet in the .us zone):


;  DiG 9.5.0-P1  jatec.us @K.GTLD.BIZ
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 17247
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;jatec.us.  IN  A

;; AUTHORITY SECTION:
us.			900	IN	SOA	a.gtld.biz. hostmaster.neustar.biz. 2003490289 900  
900 604800 86400


;; Query time: 20 msec
;; SERVER: 156.154.72.65#53(156.154.72.65)
;; WHEN: Thu Jan 29 14:48:05 2009
;; MSG SIZE  rcvd: 91


When did you register the domain?
How often does .us update their zone?

Matt




PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: single-character host names

[Matthew Pounsett]

On 25-Feb-2009, at 16:46, Mike Bernhardt wrote:

So what is the accepted view on this currently? Is there another RFC  
that

has made it OK now?


I'm not going to say this definitively, because I'm not certain, but I  
think 952 may have been updated by a later RFC.  Certainly there are  
several examples of infrastructure, including the root name servers  
themselves, successfully using single-character host names.





PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: TSIG verify failure

[Matthew Pounsett]

On 28-Feb-2009, at 04:11, Jeremie Le Hen wrote:


AXFR fails invariably with the following error: tsig verify failure.
Do, by chance, TSIG packets use IP address during encryption?
I've been struggling to understand the problem for maybe 8 hours, but
I'm clueless now...  Any help would be welcome.


Check the clocks on your two machines, as they need to be in sync; the  
signatures are time-dependent. 
 


PGP.sig
Description: This is a digitally signed message part
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: named-xfer?

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 02-Apr-2009, at 18:33, Michelle Konzack wrote:


Hello,

I have to fetch some zones from http://www.zonedit.com/ but it   
seems,

named-xfer does not more exist in bind9.

How can I now manualy download a zone?


dig IN AXFR zone @server  file

that will do it.

HTH,
   Matt



-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAknVPjUACgkQmFeRJ0tjIxGScwCglUdG03D0kpBtAuo7i7tJ1PIk
kDUAmgN1qYmoGJWduaN0NcI9qYlj6oAs
=8CUR
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Delegation of DHCP blocks within same server?

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 20-May-2009, at 19:03, John Cole wrote:


For a concrete example:

10.0.0.0/16 is presently handled by a single zone file.
10.1.3.0/24 is DHCP issued
10.1.4.0/24 is DHCP issued


I haven't tested this... but I'm 99% certain that you can simply load  
them as three separate zones, exactly as you might expect.  BIND  
should recognize that the zone{} statements for 10.1.3/24 and  
10.1.4/24 are more-specific than what's in 10.0/16 and act  
accordingly.  Along those same lines, if you happen to have data for  
either 10.1.3/24 or 10.1.4/24 inside the 10.0/16 zone file, you should  
get an error.



-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAkoUmPAACgkQmFeRJ0tjIxGe4gCgkhfqzbwL9BcT4MtXtqQSMQ08
pmEAn2YNy86QLMcpPd8Rl09d965NskJc
=2nvo
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: proving a server doesn't have a zone

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 01-Jun-2009, at 15:42, Todd Snyder wrote:


I'm sure I'm just having a dumb moment, and that the return codes from
dig can give me what I need, but I can't figure it out.


Indeed, dig can help you here.  Send the server a non-recursive query  
for something in the zone in question (doesn't matter if what you  
query for actually exists or not).  The server will either respond  
with the AA bit set, or not, and that's how you know.


Note the absence of an 'aa' entry in the flags field, on the 6th line  
of the output, below.


% dig +norec @a.gtld-servers.net foo.rim.com

;  DiG 9.4.3-P1  +norec @a.gtld-servers.net foo.rim.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 44151
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; QUESTION SECTION:
;foo.rim.com.   IN  A

;; AUTHORITY SECTION:
rim.com.172800  IN  NS  xns01lhr.rim.net.
rim.com.172800  IN  NS  xns01ykf.rim.net.

;; ADDITIONAL SECTION:
xns01lhr.rim.net.   172800  IN  A   193.109.81.21
xns01ykf.rim.net.   172800  IN  A   206.51.26.10

;; Query time: 80 msec
;; SERVER: 192.5.6.30#53(192.5.6.30)
;; WHEN: Mon Jun  1 15:46:55 2009
;; MSG SIZE  rcvd: 114


In this second example, the server is authoritative for rim.com, and  
answers with the aa bit set:


% dig +norec @xns01lhr.rim.net foo.rim.com

;  DiG 9.4.3-P1  +norec @xns01lhr.rim.net foo.rim.com
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 51004
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;foo.rim.com.   IN  A

;; AUTHORITY SECTION:
rim.com.		600	IN	SOA	xns01ykf.rim.net. dnsadmin.rim.net. 2009052301  
7200 3600 1209600 600


;; Query time: 138 msec
;; SERVER: 193.109.81.21#53(193.109.81.21)
;; WHEN: Mon Jun  1 15:48:17 2009
;; MSG SIZE  rcvd: 90



-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAkokMKkACgkQmFeRJ0tjIxEf3gCfVHPc6VKX7xScMYeQXlsXI5Hu
3T4An3H6++LcSn0wW1D2hr4P25i3RO5H
=sI+e
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Dynamic DNS and Slave Servers

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 18-Jun-2009, at 14:25, Gregory Hicks wrote:



Kevin:

I'll bite!  What is the difference between a sub*domain* and a
sub*zone*?

I don't see how you could have the one w/o the other.  But that could
be because I'm feeling especially slow today.


foo.example.com is a subdomain of example.com.  It is only a subzone  
if there's a delegation from example.com to foo.example.com (if  
there's a zone cut).




-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAko6hykACgkQmFeRJ0tjIxFOKACfREn+EkxLDUByLlpUdu2e1PL9
t74AnREgfx5+eGz1eh1Dl1XWa/HDQPy+
=VSPv
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Glue record miunderstanding

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 01-Oct-2009, at 16:03, Scott Haneda wrote:

Is it also correct, I only need a NS glue record for the actual NS  
itself.  There does not need to be a glue record for very zone that  
I am providing DNS for?


The only case where glue *must* be present is when a nameserver name  
is a subdomain of the zone it's authoritative for.


So,  if ns1.example.com is one of the nameservers for example.com,  
then there must be glue in the com zone.  In all other cases it is not  
required.  However, some registries may include glue even when its not  
necessary, since it simplifies the logic of generating their zone.


To check if glue is present, ask your parent's nameservers for some  
record inside your zone.  When you get back the delegation response,  
if glue is present it'll be included in the ADDITIONAL section.


Here's a real-world example.  In this case, glue is unnecessary in the  
com zone, but Verisign is including it anyway:


18:24:04 % dig +norec IN A www.example.com @a.gtld-servers.net

;  DiG 9.4.3-P3  +norec IN A www.example.com @a.gtld-servers.net
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 55065
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

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

;; AUTHORITY SECTION:
example.com.172800  IN  NS  a.iana-servers.net.
example.com.172800  IN  NS  b.iana-servers.net.

;; ADDITIONAL SECTION:
a.iana-servers.net. 172800  IN  A   192.0.34.43
b.iana-servers.net. 172800  IN  A   193.0.0.236

;; Query time: 65 msec
;; SERVER:
;; WHEN: Thu Oct  1 18:24:13 2009
;; MSG SIZE  rcvd: 113

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAkrFLHkACgkQmFeRJ0tjIxF8qwCeILXgTweMvfy5/44oA3PTV//G
z5YAoJBBRer7pj1RE9xfUdGG2GugFUfM
=crTH
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Glue record miunderstanding

[Matthew Pounsett]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On 01-Oct-2009, at 19:03, Scott Haneda wrote:

So I see my NS is listed in the additional section.  This to me  
tells me there is in fact glue, so I should consider the report at http://intodns.com/hostwizard.com 
 to be inaccurate?


Yeah, I just ran a few queries and can't figure out what exactly it's  
complaining about.


Matt



-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.11 (Darwin)

iEYEARECAAYFAkrFTN4ACgkQmFeRJ0tjIxHkYwCfdIo1dfhDzGov84ouWPviqWrk
5IIAnAy44CUqm7gfX43PQ88KOdUQv47K
=XnOk
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Nslookup not showng TTL

[Matthew Pounsett]

On 15-Oct-2009, at 16:03, John Horne wrote:


On Thu, 2009-10-15 at 13:15 -0400, Kevin Darcy wrote:


Removing features from nslookup gets us that much closer to KILLING  
and

BURYING it. Forever.


So why does the ISC still distribute it?
(Although I guess the answer may simply be because people still use
it.)


There was a while there that nslookup printed a big warning banner  
telling you not to use it because it'd been deprecated and would go  
away any day now.   That doesn't seem to be there anymore, sadly.   I  
kinda wish it would just vanish.




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

Re: isc.org has signed delegation

[Matthew Pounsett]

On 22-Oct-2009, at 01:16, Loren M. Lang wrote:


I just noticed that isc.org has a signed delegation from the .org name
servers.  I am curious what registrar you went through to get this.


.org is doing a limited production release of DNSSEC right now,  
referred to as Friends  Family.   There are a small number of  
secured delegations which were arranged directly between the registry  
and the registrants involved; ISC is one of those registrants.  A full  
production rollout, where you can supply DS records to your registrar,  
will be coming later.


Matt



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

Re: BIND9 slave

[Matthew Pounsett]

On 07-Dec-2009, at 08:37, George wrote:


Is there a way to make the slave server automatically get and update
any new domains that are added to the master server?


This question pops up about once every two months on the list.  There  
are several other discussions on the subject that you could search for  
and read.


In short, though:  There's nothing in the protocol for doing that, and  
BIND does not currently have a proprietary way of doing this.


Previous discussions on the list have covered a number of different  
ways of implementing this yourself.  Most are pretty simple  
descriptions of perl scripts that modify your master sever's  
named.conf to work on the slave so that it can be automatically scp'd  
over when it's updated.  My personal favourite is Paul Vixie's  
'federated domains' example, described here:


https://lists.isc.org/mailman/htdig/bind-users/2008-February/069304.html 



If you search the list you'll find many, many others.

Matt




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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 12:57, Rick Dicaire wrote:

 If I understand this correctly, the lack of an ANSWER section for 
 query would denote there is no ipv6 glue at the TLD?

No, that would indicate that the name server you queried is not authoritative 
for the record you queried about.  Glue, by definition, is non-authoritative 
data, and so appears in the ADDITIONAL section, as in the example you pasted.

By contrast, Verisign's servers have long included glue in the ANSWER section.  
This is widely considered to be at best suboptimal, and by many (or most) to be 
a bug.  Verisign has indicated that this behaviour is coming to an end, 
although I don't recall off the top of my head if they've announced a date.

Matt


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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 12:29, Mathew J. Newton wrote:

 Specifically, the Dig tool at http://www.kloth.net/services/dig.php seems
 unable to resolve my records and I can't help but feel it's a problem at
 my end rather than theirs!

The problem may be at Kloth.. but at least one of the many possible problems 
they might be having could be corrected by a slightly different configuration 
at your end.

According to RFC you must have at least two name servers on different networks 
for each delegation.  I interpret this as two name servers *per address 
protocol* that you want to support.  So, if you want to support queries from 
the v4 Internet (there may be reasons you don't) then you should have at least 
two name servers responding to queries over v4.

Koth may be having network trouble on v4 which prevents them from getting at 
77.103.161.0/24.  If that is the problem, a second v4 name server in a 
different subnet (at a different site) might present them with a path to a name 
server that can answer their query.  This is the reason why there is a 
redundancy requirement in the RFC.


That said.. there is nothing wrong with a name server that only answers using 
one address protocol or the other.  And there is functional precedent in 
infrastructure for name servers that are only on v6.  j.gtld.biz, which is 
authoritative for the us. zone only has a v6 address.  While this occasionally 
confuses an operator here and there, the DNS likes it just fine.

Matt


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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 14:48, Mathew J. Newton wrote:

 FWIW, at least one of the afilias hosts had the same IPv4 address for
 ns[12].v6ns.org.
 
 ns1.v6ns.org.   86400   IN  A   77.103.161.36
 ns1.v6ns.org.   86400   IN  2a01:348:133::a1
 ns2.v6ns.org.   86400   IN  A   77.103.161.36
 ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2
 
 Hmm.. That's interesting. I know for a fact that my registrar wouldn't
 allow me to enter two servers with the same address, however within my
 zone I may have had ns[12] set with IPv4 records set for a period (a few
 days ago). This makes me wonder where .org is getting its records from - a
 combination of glue provided by the registrar and cached results from my
 zone?

The org. name servers are authoritative-only.. no caching takes place.

Also, the registry is contractually prevented from modifying zone data supplied 
by the registrars, which would preclude it from cloning the v4 address from one 
name server to the other.  Besides, as database objects, the relationship 
between one name server and the other would be pretty loose, and there'd be no 
reasonable way to assume that ns2.v6ns.org is authoritative for everything that 
ns1.v6ns.org is authoritative for.

I suspect that, even though they threw an error, your registrar went ahead and 
passed on the same IPv4 address for both name servers to the registry.

Matt



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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 15:16, Matthew Pounsett wrote:

 By contrast, Verisign's servers have long included glue in the ANSWER 
 section.  This is widely considered to be at best suboptimal, and by many (or 
 most) to be a bug.  Verisign has indicated that this behaviour is coming to 
 an end, although I don't recall off the top of my head if they've announced a 
 date.

Following up my own email.. someone pointed me to the specific reference to the 
vague memory I had floating around in my head:

https://lists.dns-oarc.net/pipermail/dns-operations/2010-January/004838.html

To summarize, the behaviour I mentioned above is scheduled to go away on March 
1st, 2010.. at which point the com/net servers should start answering with glue 
in the ADDITIONAL section.

Matt



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

Re: Notify storms

[Matthew Pounsett]

On 2010/01/20, at 13:03, Dave Sparro wrote:

 We would like to make this better.
 Can anyone help with ideas on this?  Are we missing something obvious?
   
 
 In that situation I'd consider using CVS on all of the servers to maintain 
 the DNS data.
 Just make all of the servers masters, and forget about slaves.

Agreed .. that's definitely one solution.  With your data already in a version 
control system, and that many name servers, you might benefit from replacing 
zone transfers with a configuration management tool (cfengine, bcfg2, etc.) 
which can take care of noticing that there's new data in the version control 
system, getting it onto the slaves, and then telling them to reload or reconfig 
as appropriate (depending on whether it's zone files or named.conf that 
changed).


Another option if you want to stick with the master/slave approach is to tier 
your slaves.   Reduce the masters to just two or three, and then assign 10 or 
so of the slaves to be intermediate masters.  The intermediates slave from the 
real masters, and then every other server slaves from, at most, two or three of 
the intermediates each.  If you group these appropriately, then you can get it 
down to a maximum of 10 or so slaves talking to any one upstream master, with a 
nice mesh to maintain redundancies.  How you divide them up is up to you ... 
regionally works well though.

Matt


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

Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled

[Matthew Pounsett]

On 2010/03/28, at 18:48, Roy Badami wrote:

 configured).  The queries are resulting in SERVFAIL, and I'm pretty
 sure the failures are DNSSEC-related, as when I've seen problems as
 they occur (dig failing from the command line) then repeating the
 query with the CD bit allowed it to succeed.

It looks to me like your example, freebsd.org, is insecure.  

There are no DS records for freebsd.org in the org zone, so BIND can't follow 
the trust chain from the org.dlv.isc.org DLV record.

;  DiG 9.6.0-APPLE-P2  +norec +dnssec IN DS freebsd.org 
@a0.org.afilias-nst.info
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 52863
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1
[...]

There also appears to be no DLV record for freebsd.org:

;  DiG 9.6.0-APPLE-P2  +norec +dnssec IN DLV freebsd.org.dlv.isc.org 
@ns.isc.afilias-nst.info
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 23858
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;freebsd.org.dlv.isc.org.   IN  DLV

;; AUTHORITY SECTION:
dlv.isc.org.3600IN  SOA ns-int.isc.org. 
hostmaster.isc.org. 2010032802 7200 3600 2419200 3600
dlv.isc.org.3600IN  RRSIG   SOA 5 3 3600 20100427130003 
20100328130003 64263 dlv.isc.org. 
IbRdfwxFInY6FuHtsfVatqrNvMIoifQTrohzEZF1UsTx9XAowU1Zz57L 
YcHPu3ReAdYOL+IwkG8syNQ/LSLnpZY3K3Av/HSmPV524KWbm39J+k+G 
BMmIIsnvC4I40UUr7f/AXF14JgdAu9eokvvLvqR0CcAY0dq9HGHjdXC1 HbI=
flame.org.dlv.isc.org.  3600IN  NSEC863.freenum.org.dlv.isc.org. 
RRSIG NSEC DLV
flame.org.dlv.isc.org.  3600IN  RRSIG   NSEC 5 5 3600 20100427130003 
20100328130003 64263 dlv.isc.org. 
KZRZadIqTS8p6V3fRz7bsOrP3A/gTqJzeVtWTOqhrRbChLt0jVbhY4fR 
1pBogkhc84xcv7i0odHMzWCIpmQdv4Q/ODnophPdgrfPcxB93s3dMQ/D 
j0o2KTYsx1qJo0O1RWqhicUdwGoVYm5rZFLxy/uBV0dJe0KGrSmY21Gw U/c=
org.dlv.isc.org.3600IN  NSEC1mg.org.dlv.isc.org. RRSIG NSEC 
DLV
org.dlv.isc.org.3600IN  RRSIG   NSEC 5 4 3600 20100427130003 
20100328130003 64263 dlv.isc.org. 
YCe9L3iuJ5YD5hj7s1Z9wGsDkhLhqchNki+bSffHGxoYZVaQnMZXgWpS 
fYJZsFyJA3h1uEs5FvuLeLv1Poej2EhDyXucMHAgTJy4fbDjaw3Q8/MP 
et17Ki0TSNvMFdusCJl93aSZBnKponKR67ofvb8wwt5SDCYrR41EgvzE WZs=

;; Query time: 58 msec
;; SERVER: 199.254.63.254#53(199.254.63.254)
;; WHEN: Mon Mar 29 04:22:48 2010
;; MSG SIZE  rcvd: 721

Note both the NXDOMAIN status and the NSEC record covering 
flame.org.dlv.isc.org through 863.freenum.org.dlv.isc.org.  The NSEC record is 
used to prove that no domains which sort between those two names exist in the 
dlv.isc.org zone.

Just to make sure, I looked for RRSIGs in the freebsd.org zone, wondering if 
maybe the DLV record has simply disappeared from the dlv.isc.org zone somehow.. 
but it doesn't look like freebsd.org has been signed at all:

;  DiG 9.6.0-APPLE-P2  +norec +dnssec IN  mx2.freebsd.org 
@ns2.isc-sns.com
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 17599
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 11

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;mx2.freebsd.org.   IN  

;; ANSWER SECTION:
mx2.freebsd.org.3600IN  2001:4f8:fff6::35

Note the absence of an RRSIG in the ANSWER section.  If freebsd.org were 
signed, you'd expect to see an answer similar to this:

;  DiG 9.6.0-APPLE-P2  +norec +dnssec IN  ns1.isc-sns.net 
@ns1.isc-sns.net
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 52801
;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 3, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;ns1.isc-sns.net.   IN  

;; ANSWER SECTION:
ns1.isc-sns.net.3600IN  2001:470:1a::1
ns1.isc-sns.net.3600IN  RRSIG    5 3 3600 2010042620 
2010032720 10377 isc-sns.net. 
qk8txlEYx6d8Mor155Rz0Te2vdQSPDoaJZM5FaXLfyNpruv7z3gdwtAI 
BrmDCKhzmyYni4GQmqZPYmceVjp1rcD17B5O+2/NET+obm3pcHKuzRZs 
e0PyP1LITahboUZzBoIyd7/jqs2+EwFKJgUs7v41UNp5oIz2vs0YuBo6 1Hc=


Have you checked the other domains you're having problems with to see that 
they're actually secured?
If you supply some info from your resolver configuration, someone here might be 
able to help debug the problem.

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

Re: MX records for new additional domain on existing authoritative name servers

[Matthew Pounsett]

Hi Karen.

Please don't start a new thread by replying to an email in an existing 
discussion -- your message can get lost in that other discussion, rather than 
appearing as a new topic for anyone who threads their email.


On 2010/03/30, at 16:30, Lear, Karen (Evolver) wrote:

 I'm adding a new domain to my existing authoritative name servers, and need 
 to add an MX record for a device on the existing domain.  That device will 
 serve both domains until we get a new box in and then we will have separate 
 MX records/devices for each domain.  I have created a new zone file and 
 modified named.conf to include the new zone.  When I run named-checkzone, I 
 get a message about the MX record being out of zone and not having an A 
 record.  However, at the end of my named-checkzone output, I get OK.  Can I 
 restart named as is without causing problems or do I need to address these 
 messages?

It sounds like you're including a record for mx1.olddomain.gov in the 
newdomain.gov zone.  It's hard to be sure without seeing specifics from your 
configuration though.



 
 Thx,
 
 [kl...@mynameserver]$ sudo named-checkzone -t /dns/chroot/conf -D 
 NEWDOMAIN.gov MYNEWZONEFILE
 zone NEWDOMAIN.gov/IN: NEWDOMAIN.gov/MX 'MX1.OLDDOMAIN.gov' (out of zone) has 
 no addresses records (A or )
 zone NEWDOMAIN.gov/IN: NEWDOMAIN.gov/MX 'MX2.OLDDOMAIN.gov' (out of zone) has 
 no addresses records (A or )
 OK
 ___
 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: Using an MX record from a different domain

[Matthew Pounsett]

On 2010/03/30, at 16:57, Lear, Karen (Evolver) wrote:

  
 I'm adding a new domain to my existing authoritative name servers, and need 
 to add an MX record for a device residing on existing domain.  When I run 
 named-checkzone, I get a message about the MX record being out of zone and 
 not having an A record.  However, at the end of my named-checkzone output, I 
 get OK.  Can I restart named as is without causing problems or do I need to 
 address these messages?
  
 [kl...@dns1 conf]$ sudo named-checkzone -t /dns/chroot/conf -D usptoenews.gov 
 db.usptoenews
 zone usptoenews.gov/IN: usptoenews.gov/MX 'smtpedge1.uspto.gov' (out of zone) 
 has no addresses records (A or )
 zone usptoenews.gov/IN: usptoenews.gov/MX 'smtpedge2.uspto.gov' (out of zone) 
 has no addresses records (A or )

Ah, I see.  On my previous read I mistook this for complaining that there was a 
uspto.gov owner name in the usptonews.gov zone.  

named-checkzone doesn't only check the internal consistency of a zone, it also 
tries to see that it is externally consistent.  e.g. that names referred to in 
other zones also exist.  If for some reason it can't resolve 
smtpedge1.uspto.gov and smtpedge2.uspto.gov it will give you the above errors. 

Since I can resolve those names from here, I suspect there's some problem with 
the resolver on the host where you're running named-checkzone.  Perhaps 
uspto.gov zone is only visible on a view on the outside of the network, and 
you're inside?  

What happens if you try to resolve those two names by hand on that server using 
'host' or 'dig'?

I see this:
 host smtpedge1.uspto.gov
smtpedge1.uspto.gov has address 151.207.243.76
smtpedge1.uspto.gov mail is handled by 5 smtpedge1.uspto.gov.

 host smtpedge2.uspto.gov
smtpedge2.uspto.gov has address 151.207.247.81
smtpedge2.uspto.gov mail is handled by 5 smtpedge2.uspto.gov.

If those are the only errors you're seeing, then the zone is internally 
consistent, and BIND will load it.  However, it's probably worth investigating 
why named-checkzone can't resolve those names, so that you can make sure that 
anyone who needs to reach those MX servers will be able to.

Matt


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

Re: Subdomain delegation only returns SOA on dig

[Matthew Pounsett]

On 2010/03/29, at 15:34, Prabhat Rana wrote:

 
 Hello all,
 I'm running BIND 9.6.1-P1 on a Solaris box. This DNS (ns1.spx.net) is 
 authoritative to domain spx.net (this is just example). And I'm trying to 
 delegate nse.spx.net to ns1.nse.spx.net. I think I have configured correctly 
 but when I run a dig from a different DNS node for a subdoamin within 
 nse.spx.net like mil.nse.spx.net, it responds only SOA in the Auth section. 
 Its missing the NS from the zone files. The snapshot of my named.conf file
 
 zone spx.net {
type master;
file /opt/named/db.spx.net;
 };
 
 zone nse.spx.net {
type master;
file /opt/named/db.nse.spx.net;
 };

Do these both appear on the same name server (ns1.spx.net)?  If so, then 
ns1.spx.net thinks it is authoritative for nse.spx.net, and isn't going to hand 
out a referral.

If you want ns1.spx.net to refer queries for nse.spx.net to ns1.nse.spx.net, 
then you need to add this record to the spx.net zone, and remove the 
nse.spx.net zone from ns1.spx.net:
nse IN NS ns1.nse.spx.net

Matt


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

Re: how to read and answer to this mailing list

[Matthew Pounsett]

On 2010/03/30, at 19:04, Markus Feldmann wrote:

 Warren Kumari schrieb:
 In the footer of every message lurks the following link:
 https://lists.isc.org/mailman/listinfo/bind-users
 Yes ... i read this but you can not answer a mail this way.

You can answer an email this way.  I'm not sure if the list is open-post or 
not.. but if it is then you can get the posting address from there and send 
email to it.  If it isn't, then from that page you can subscribe to the list, 
and then send email to it.

 And i mean not this mailing list but the dhcp-users mailing list.

Then you're probably looking for 
https://lists.isc.org/mailman/listinfo/dhcp-users.

Matt


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

Re: how to read and answer to this mailing list

[Matthew Pounsett]

On 2010/03/31, at 04:08, Markus Feldmann wrote:

 Matthew Pounsett schrieb:
 On 2010/03/30, at 19:04, Markus Feldmann wrote:
 Warren Kumari schrieb:
 In the footer of every message lurks the following link:
 https://lists.isc.org/mailman/listinfo/bind-users
 Yes ... i read this but you can not answer a mail this way.
 You can answer an email this way.  I'm not sure if the list is open-post or 
 not.. but if it is then you can get the posting address from there and send 
 email to it.  If it isn't, then from that page you can subscribe to the 
 list, and then send email to it.
 Thanks Matthew it works, but it is not very comfortable. therefore i need 2 
 programs. first to read and the second to write/answer. The modern computer 
 technique says hello. :-)

I read and post from the same program.  You asked about mail, so I assumed you 
meant mail.

On 2010/03/30, at 18:43, Markus Feldmann wrote:

 normally i am using the gmane mailing list server to post and read mails from 
 mailing lists, but this mailing list doesn't appear in gmane.


Matt



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

IXFR size limit?

[Matthew Pounsett]

Is there, by any chance, a maximum size to the IXFRs BIND will send?  I've 
noticed an upstream server I slave from is being suspiciously consistent in the 
number of records it sends per IXFR (86,450 plus or minus ~10 records).  The 
upstream server is part of an appliance, but fingerprints as BIND 9.2.3rc1 -- 
9.4.0a0.  

I don't see anything in the ARM for configuring a limit on the number of 
records per zone transfer, but I'm curious if there's something hard-coded 
somewhere...


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

Re: IXFR size limit?

[Matthew Pounsett]

On 2011/02/14, at 10:47, Matthew Pounsett wrote:

 Is there, by any chance, a maximum size to the IXFRs BIND will send?  I've 
 noticed an upstream server I slave from is being suspiciously consistent in 
 the number of records it sends per IXFR (86,450 plus or minus ~10 records).  
 The upstream server is part of an appliance, but fingerprints as BIND 
 9.2.3rc1 -- 9.4.0a0.  

Nevermind.. I spoke too soon.  It turns out the appliance in question is not 
actually doing IXFRs.  I should have checked out the zone size in the first 
place.



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

Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses

[Matthew Pounsett]

While it's possible you have encountered a bug with BIND, it's generally a bad 
idea to mix recursive and authoritative service in the same process. The RFCs 
that define the resolution algorithms were never written with mixed service in 
mind, and there are conflicts that can result in undefined, and therefore 
unpredictable, behaviours.   It will be hard to determine which you're seeing 
without more specific information about the configuration of the servers in 
question (e.g. which zones they're actually authoritative for).  

You will particularly run into problems if you ever intend to do DNSSEC 
validation on these name servers.. it just won't work.

I maintained the cross-posting for this reply because of the general DNS 
service advice, but my suggestion would be to limit the thread to the 
bind-users until you identify or rule-out a bug.


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

Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses

[Matthew Pounsett]

On 2011-05-20, at 00:35, Carlos Vicente wrote:

 That's news to me.  What's the failure mode? Does the server return SERVFAIL, 
 or does it not set the AD flag, or...?

It's another undefined condition in the RFCs, and so the outcome is 
implementation specific.  I believe in the case of BIND the authoritative 
algorithm wins out, and so you get RRSIGs and no AD flag.  I haven't tested 
this one out personally, but I vaguely recall the problem coming up on one of 
the DNS operations lists several months ago, so someone else may have a more 
detailed answer.



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

Re: [dns-operations] Bind 9.8.0 intermittent problem with non-recursive responses

[Matthew Pounsett]

On 2011-05-19, at 21:58, Michael Sinatra wrote:

 If you're saying that you shouldn't *offer* recursive and authoritative 
 services on the same box, then I generally agree.  If you're saying that you 
 shouldn't ever prime your cache with a zone, or have a recursive server be a 
 slave to anything, then I'd say it gets kind of hairy there.

Indeed.  Hairy is an apt description of the situation.  There are many cases 
where it can work fine, and there are also plenty of cases where it won't, and 
the ones where it won't will be difficult for most operators to figure out.  If 
one must run the two services on the same machine, it's much safer to split 
them into separate processes.  

If, for some reason, you can't wait for your TTLs to expire, then forwarding 
the relevant zones to your authoritative servers is a better solution than 
slaving the zones. 

 Moreover, the recommended RPZ configuration as of BIND 9.8.0 is to have your 
 recursive servers slave your RPZ zone, so your recursives will have to slave 
 something if they run RPZ.

RPZ is an entirely different situation.  Nobody's going to be querying your RPZ 
zones, and so there's no case where the server will get confused about which 
resolution algorithms to use.

 You will particularly run into problems if you ever intend to do
 DNSSEC validation on these name servers.. it just won't work.
 
 Yes.  In that case, static-stub or forwarding is your friend.  Although, we 
 should be clear: It won't work on the zones that are slaved by the recursive 
 server.  Presumably one is protecting those zones some other way (TSIG, 
 SIG(0)).  It *will* (and does) work for signed zones for which the recursor 
 is not authoritative.

I'm not even sure forwarding helps here.  But yes, you're right, it breaks only 
for the zones you're slaving... but the fact that they're being slaved suggests 
they're the most important ones.

I don't know of many organizations larger than a few dozen people using SIG(0) 
or TSIG between stub and caching servers... certainly none where the stubs are 
on random student computers.  I'd be rather surprised to find any universities 
at all doing that outside of the machines operated by the computer labs.


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

Re: big improvement in BIND9 auth-server startup time

[Matthew Pounsett]

On 2011/07/13, at 11:15, Evan Hunt wrote:

 
 People who operate big authoritative name servers (particularly with
 large numbers of small zones, e.g., for domain hosting and parking),
 and have had trouble with slow startup, may find this information
 useful:
 
 http://www.isc.org/community/blog/201107/major-improvement-bind-9-startup-performance

Thanks Evan.  I'll also point out to people this PDF which has some more detail 
on the actual performance improvements: 
http://www.isc.org/files/imce/startup-performance.pdf

Was there any work done on measuring the impact on 'reconfig' times, or is that 
an entirely separate piece of code?  I'm curious if the change makes any 
difference to adding large numbers of zones to an already-running server.  e.g. 
if I've got a server handling 500,000 zones and add another 20k, 50k, or 100k 
via 'reconfig'.

Thanks to the ISC folk for doing that work!
   Matt


___
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

OpenSSL problem: bind98-base FreeBSD port

[Matthew Pounsett]

I upgraded my OpenSSL and BIND ports on one of my machines yesterday afternoon, 
and ended up with BIND being unable to start due to some problem with OpenSSL.  
Unfortunately, it's not giving me any real information to go on about what the 
problem is.  

 openssl version
WARNING: can't open config file: /usr/local/openssl/openssl.cnf
OpenSSL 1.0.1c 10 May 2012

 sudo named -g -t /var/named/authoritative/ -u bind -d 100
08-Jul-2012 16:45:00.347 starting BIND 9.8.3-P1 -g -t /var/named/authoritative/ 
-u bind -d 100
08-Jul-2012 16:45:00.347 built with '--localstatedir=/var' 
'--disable-linux-caps' '--disable-symtable' '--with-randomdev=/dev/random' 
'--with-openssl=/usr/local' '--with-libxml2=/usr/local' '--with-idn=/usr/local' 
'--with-libiconv=/usr/local' '--enable-largefile' 
'STD_CDEFINES=-DDIG_SIGCHASE=1' '--enable-ipv6' '--enable-threads' 
'--sysconfdir=/etc/namedb' '--prefix=/usr' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info/' '--build=x86_64-portbld-freebsd8.2' 
'build_alias=x86_64-portbld-freebsd8.2' 'CC=cc' 'CFLAGS=-O2 -pipe 
-fno-strict-aliasing' 'LDFLAGS= -rpath=/usr/local/lib' 'CPPFLAGS=' 'CPP=cpp' 
'CXX=c++' 'CXXFLAGS=-O2 -pipe -fno-strict-aliasing'
08-Jul-2012 16:45:00.347 
08-Jul-2012 16:45:00.347 BIND 9 is maintained by Internet Systems Consortium,
08-Jul-2012 16:45:00.347 Inc. (ISC), a non-profit 501(c)(3) public-benefit 
08-Jul-2012 16:45:00.347 corporation.  Support and training for BIND 9 are 
08-Jul-2012 16:45:00.347 available at https://www.isc.org/support
08-Jul-2012 16:45:00.347 
08-Jul-2012 16:45:00.347 found 4 CPUs, using 4 worker threads
08-Jul-2012 16:45:00.349 using up to 4096 sockets
08-Jul-2012 16:45:00.349 Registering DLZ_dlopen driver
08-Jul-2012 16:45:00.349 Registering SDLZ driver 'dlopen'
08-Jul-2012 16:45:00.349 Registering DLZ driver 'dlopen'
08-Jul-2012 16:45:00.351 decrement_reference: delete from rbt: 0x802467058 .
08-Jul-2012 16:45:00.352 initializing DST: openssl failure
08-Jul-2012 16:45:00.352 exiting (due to fatal error)

I found multiple versions of libgcrypt installed, which was generating some 
compile warnings, but cleaning that up didn't help.  There is only one version 
of openssl installed, so no conflicts there..

 ls -d /var/db/pkg/*ssl*
/var/db/pkg/openssl-1.0.1_3

I can recompile without SSL to get my name servers running again, but that's 
not really sustainable.  Does anyone have any suggestions for how to get more 
information out of BIND about what exactly is failing?


___
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: OpenSSL problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 15:04, Michael Sinatra wrote:

 What makes me doubt what I just said is that this has been an issue for more 
 than a year now, so I am not sure why you have escaped it for so long.  I 
 assume you had openssl 1.0.x installed before you upgraded it--or was it an 
 earlier version?

I keep things pretty up to date, and this machine isn't that old anyway.  It's 
possible that due to order of operations when I was building things that bind 
was previously linked against the system openssl libraries, rather than the 
ports version.  

 At any rate, if you run make config in /usr/ports/security/openssl, it gives 
 you the option of compiling the libraries statically.  I have successfully 
 done this in the past and it has worked.  However, anything else that is 
 currently depending on the openssl shared library from ports (as opposed to 
 the bundled system) will need to be recompiled before it will work, as will 
 bind 9.8.

I'll give that a shot.. thanks, it sounds promising.

 Doug Barton may have some better ideas as to how best to make it all work.

Yeah, I have to wonder if there's something that can be done in ports to 
prevent this from being an issue.


___
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: OpenSSL problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 17:46, Doug Barton wrote:

 On 07/08/2012 13:40, Matthew Pounsett wrote:
 Yeah, I have to wonder if there's something that can be done in ports to 
 prevent this from being an issue.
 
 You need to ask the nice openssl people to turn gost into a library
 instead of an engine. Meanwhile, copying the file into the chroot will
 patch over the problem.

Statically linking openssl seems to have fixed it.

But, what file are you talking about?

___
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: OpenSSL problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 20:26, Mark Andrews wrote:

 
 One can also build named w/o GOST support if one wants.  We statically
 link all the engines when building named on Windows.

Unfortunately the port doesn't provide the config hooks to disable GOST support.



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

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

Re: OpenSSL problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 20:29, Matthew Pounsett wrote:

 
 On 2012/07/08, at 20:26, Mark Andrews wrote:
 
 
 One can also build named w/o GOST support if one wants.  We statically
 link all the engines when building named on Windows.
 
 Unfortunately the port doesn't provide the config hooks to disable GOST 
 support.

Actually.. how do you go about doing that anyway?  I was just taking a look at 
writing a patch for the port to allow GOST to be turned off, but BIND's 
configure script doesn't have any information in it about disabling individual 
ciphers.



___
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: OpenSSL problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 20:40, Doug Barton wrote:

 On 07/08/2012 17:33, Matthew Pounsett wrote:
 
 On 2012/07/08, at 20:29, Matthew Pounsett wrote:
 
 
 On 2012/07/08, at 20:26, Mark Andrews wrote:
 
 
 One can also build named w/o GOST support if one wants.  We statically
 link all the engines when building named on Windows.
 
 Unfortunately the port doesn't provide the config hooks to disable GOST 
 support.
 
 Actually.. how do you go about doing that anyway?  I was just taking a look 
 at writing a patch for the port to allow GOST to be turned off, but BIND's 
 configure script doesn't have any information in it about disabling 
 individual ciphers.
 
 I wouldn't accept it anyway. For better or worse, GOST is part of the
 protocol.

Okay.  

So to answer my earlier question, what file were you talking about copying into 
the chroot environment for BIND?



___
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: OpenSSL problem: bind98-base FreeBSD port

[Matthew Pounsett]

On 2012/07/08, at 22:25, Barry Margolin wrote:

 In article mailman.Okay.  
 
 
 So to answer my earlier question, what file were you talking about copying 
 into the chroot environment for BIND?
 
 The shared library. When you link dynamically, all the libraries have to 
 be in $chroot/usr/lib.

No, they don't.  Shared libraries are picked up at runtime. Chrooting happens 
after that, once the libraries have already been read.



___
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

dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)

[Matthew Pounsett]

I'm trying to debug an IXFR problem with a client, and using dig in its place 
to compare IXFR requests between it and the misbehaving client.  I noticed that 
when I do an IXFR with dig it defaults to TCP rather than UDP.  I tried forcing 
it over with +notcp but I still get a TCP query.

From the man page:
   +[no]tcp
   Use [do not use] TCP when querying name servers. The default
   behavior is to use UDP unless an AXFR or IXFR query is requested,
   in which case a TCP connection is used.

This implies to me that it is simply the default to use TCP for *XFR, but one 
should be able to override it.  Is that the correct interpretation of the man 
page?

Even if that is not the correct interpretation, it seems to me that since IXFRs 
can and do happen over UDP, it should be possible to tell dig to do that.

Is this a bug, or a design flaw?

- Matt
___
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: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)

[Matthew Pounsett]

On 2013-12-04, at 21:22 , Mark Andrews ma...@isc.org wrote:

 
 The options are processed left to right so the +notcp has to be
 after the ixfr=serial.

There are two reasons I don't understand why this is the case.

1) Since there is only one query in the command, I don't understand why left 
to right matters.  If you could do something like
dig IN IXFR=serial example.com +notcp IN A www.example.com +tcp
then sure.. because changing the order of options would be ambiguous, but you 
can't do that.

2) dig is generally very forgiving of argument order, so I don't see why the 
location of +notcp would be any different.

 dig +short @8.8.8.8 IN A cbc.ca
159.33.3.85

 dig @8.8.8.8 IN A cbc.ca +short
159.33.3.85

 dig IN A cbc.ca +short @8.8.8.8
159.33.3.85


 Note, named will for the use of TCP in its UDP response.

What verb is missing from this sentence?


___
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: dig ignores +notcp when doing IXFR (DiG 9.5.0-P2)

[Matthew Pounsett]

On 2013-12-06, at 12:11 , Chris Thompson c...@cam.ac.uk wrote:

 
 The sense in which BIND forces use of TCP is that when it gets an
 IXFR request over UDP, it always just replies with the current SOA.
 It doesn't bother to work out whether an incremental transfer is
 possible and if so whether it would fit into the UDP payload.
 
 Of course, if the client's supplied SOA serial is the same, this
 response indicates that no zone transfer is needed.

Yeah, the mechanism is clear.  I was curious about the why rather than the how.

___
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: 'succesful' nsupdate of remote server not persistent across nameserver restart?

[Matthew Pounsett]

On 25 April 2016 at 13:53,  wrote:

>
>
> I suspect that there's something wrong with what is/isn't copied , and
> maybe when, in that chroot build/destroy script.
>

It's not clear to me why one would want to destroy/rebuild the chroot every
time you restart the process.  However, as long as you're doing that you
should make sure that all the important files are preserved.  As you noted
earlier, it looks like your journal file is probably not preserved.  I'd
start there, and if that doesn't fix it, then have a careful look at what's
in your chroot tree before you shut down the server, and compare that to
what's in the chroot after you start it up again.
___
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: 'succesful' nsupdate of remote server not persistent across nameserver restart?

[Matthew Pounsett]

On Sunday, 24 April 2016,  wrote:

> > This zone would not pass named-checkzone, which interestingly, is the
> same code which named itself uses when initially loading a zone.
>
> It appears to
>
> named-checkzone -t /var/chroot/named example.com
> /namedb/master/example.com.zone
> zone example.com/IN: loaded serial 1461540029
> OK
>
>
> cat /tmp/nsupdate.txt
> server ns01.example.com
> debug yes
> zone example.com.
> update add test.example.com. 300 in TXT "TEST STRING"
> show
> send
>
> $NSUPDATE /tmp/nsupdate.txt
>
> @ server
>
> Apr 24 16:24:02 ns01 named[14954]: 24-Apr-2016 16:24:02.350
> update-security: info: client 10.0.0.17#26427/key jason-key: view external:
> signer "jason-key" approved
> Apr 24 16:24:02 ns01 named[14954]: 24-Apr-2016 16:24:02.350
> update: info: client 10.0.0.17#26427/key jason-key: view external: updating
> zone 'example.com/IN': adding an RR at 'test.example.com' TXT "TEST
> STRING"
>
> TBH I don't understand WHAT to 'expect' from dig to test/verify this^.
> What do I dig to get an answer with "TEST STRING" in it?


dig in txt test.example.com @ns01.example.com

>
> Jason
> ___
> 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: 'succesful' nsupdate of remote server not persistent across nameserver restart?

[Matthew Pounsett]

On 25 April 2016 at 13:44, <jaso...@mail-central.com> wrote:

>
>
> On Mon, Apr 25, 2016, at 10:19 AM, Matthew Pounsett wrote:
> > > TBH I don't understand WHAT to 'expect' from dig to test/verify this^.
> > > What do I dig to get an answer with "TEST STRING" in it?
> >
> > dig in txt test.example.com @ns01.example.com
>
> Thanks.
>
> Unfortunately, that^ returns no TXT record either.  Which to me suggests
> the problem's 'earlier'.
>

Yeah.  I think you need to solve the problem with the vanishing journal
file first.   But, the above dig is what you *should* do to get back the
TXT record that you're adding.  If it's not getting you the record, then
there's a problem with your server somewhere.


>
> Jason
>
___
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: 'succesful' nsupdate of remote server not persistent across nameserver restart?

[Matthew Pounsett]

On Monday, 25 April 2016, <jaso...@mail-central.com> wrote:

>
>
> On Mon, Apr 25, 2016, at 10:58 AM, Matthew Pounsett wrote:
> > It's not clear to me why one would want to destroy/rebuild the chroot
> every
> > time you restart the process.
>
> Well, here
>
> (1) Because I inherited it this way, and
> (2) The notes' quoted examples did that too, and
> (3) I'd not yet gotten any/good advice NOT to (security?)


Unless you have a clear reason to do it (perhaps there's some security
consideration I haven't thought of) it seems to me it's unnecessary
complexity that would lead to problems just like this.

>
> TBH, I'm not even sure whether "these days", chroot is still recommended.
> Apparmor or Docker instead? Is privsep taken care of in current bind so we
> don't have to worry about it anymore (e.g., the openntpd vs ntpd case)?
> I'm not clear on it.


Although BIND 9 has never had a remote code execution exploit that I'm
aware of, it's still advisable to run it in a chroot environment.
___
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: Compiling BIND9 on CentOS 7

[Matthew Pounsett]

On 27 April 2016 at 08:34, Sean Son 
wrote:

> Thank you for your response. Basically what I am trying to do is migrate
> the BIND server from a Centos 5.11 machine to a CentOS 7.2 machine.  The
> BIND on CentOS 5.11 was compiled manually by source and its named.conf file
> looks very different than what CentOS/Red Hat provides in the RPM package
> named.conf file. Any tips on how I should go about migrating successfully
> from the 5.11 machine to the 7.2 machine?
>

Your best approach is to have a careful look at the named.conf you're
migrating from and understand what options are required by your DNS needs,
and which are just related to how the Centos 5 machine is organized.  You
can then merge the former set (your requirements) into the default config
of the Centos 7 machine.


>
>
> As for the named.service unit file that Reindl provided, will I need to
> call upon any RNDC services? I saw that in the named.service file that
> comes with the RPM/YUM package contains a call to some RNDC service which
> calls up some generate-rndc-key.sh script.. I am not too sure of what the
> names of the files are.
>

rndc is the command line interface to a running BIND server.  (BIND ==
berkeley internet name domain, rndc == remote name domain controller (or
something to that effect)).  The rndc.conf file must agree with the
named.conf file on where BIND's controller interface is (the controls{};
clause in named.conf) and what key to use for authentication, if any.

For example, named.conf might have something like this:
controls {
inet 192.0.2.1 port 953 allow { 192.0.2.100; } keys {"rndc-key"; };
};
While your rndc.conf might have:
options {
default-key "rndc-key";
default-server 192.0.2.1;
default-source-address 192.0.2.100;
default-port 953;
};


It sounds to me like the named.service file you mention is probably
generating a default rndc.conf file if one doesn't already exist.
___
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: 'succesful' nsupdate of remote server not persistent across nameserver restart?

[Matthew Pounsett]

On 27 April 2016 at 03:07, Tony Finch <d...@dotat.at> wrote:

> Matthew Pounsett <m...@conundrum.com> wrote:
> >
> > Privsep doesn't actually fix the same problem chroot does.   As I
> > understand it, privsep reduces the attack surface for remote execution
> > exploits by shuffling off privileged operations to a separate process,
> but
> > if that process isn't chrooted and it has a remote code execution flaw
> then
> > your entire system is opened up to attack.
>
> Actually it is normal for privsep processes to chroot themselves, usually
> to /var/empty - e.g.
>

Right, so "no chroot necessary" (which is what I was responding to) isn't
accurate.
___
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: Adding CNAME for the root domain issue

[Matthew Pounsett]

On 27 April 2016 at 07:42, Baird, Josh  wrote:

> Any thoughts on a service like Cloudfare's 'CNAME Flattening' [1]?
>
> [1]
> https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/


It's possible.  We do a similar thing at eNom... we allow end-users to
insert CNAME records at the apex of the zone in the UI, but then we replace
those with synthesized records.  It's far from ideal, however.  It means
you've either got to act partly like a recursive server and do back-end
lookups every time a CNAME query comes in, or you have to periodically
re-query every authoritative CNAME at the apex of your zones in order to
refresh the synthesized replacement records before the queries come in.
The former introduces latency, and the latter risks serving out-of-date
records and is a huge workload when you're our size.. or worse..
Cloudflare's size.
___
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: Adding CNAME for the root domain issue

[Matthew Pounsett]

On 27 April 2016 at 07:40, Stephane Bortzmeyer <bortzme...@nic.fr> wrote:

> On Wed, Apr 27, 2016 at 07:32:48AM -0700,
>  Matthew Pounsett <m...@conundrum.com> wrote
>  a message of 49 lines which said:
>
> > One of these days I'd like to lead a serious lobbying effort against
> > the browser developers at the W3C to have SRV records for HTTP
> > standardized.
>
> I fully agree and, if you're brave enough to propose it to the DNSOP
> working group at IETF, I volunteer for reviewing/etc.
>
> There is a starting point:
>
> https://datatracker.ietf.org/doc/draft-andrews-http-srv/


Unfortunately, the problem is not one that can be easily fixed at the IETF.
   I'll go have a look at Mark's draft, but here's the core problem as I
see it:

RFC 2782 (SRV) says:

Applicability Statement

   In general, it is expected that SRV records will be used by clients
   for applications where the relevant protocol specification indicates
   that clients should use the SRV record. Such specification MUST
   define the symbolic name to be used in the Service field of the SRV
   record as described below. It also MUST include security
   considerations. Service SRV records SHOULD NOT be used in the absence
   of such specification.


This means that SRV records will not (can not) be used for the web until
the HTTP spec says they can.  This requires W3C action.

At the same time, the browser developers, almost without exception, refuse
to implement SRV because they don't like the idea that they might have to
do another DNS lookup prior to displaying a web page.  And they lobby the
W3C pretty hard to not standardize SRV for HTTP.

That's a pretty serious impasse .. and one that I think is only going to be
overcome by an equally strong lobbying movement from the DNS hosting
industry, when we get tired of trying to educate end users on why CNAME at
apex won't work (end users who don't–and shouldn't need to–care), and get
tired of maintaining messy record synthesis processes.

But this is getting way off topic for BIND-users, and should probably be
moved to dns-operati...@dns-oarc.net if we want to continue.
___
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: 'succesful' nsupdate of remote server not persistent across nameserver restart?

[Matthew Pounsett]

On 25 April 2016 at 11:44,  wrote:

>
>
>
> I completely gave up on chroot'd ntpd because of the endless weirdness.
> Finally just moved to openntpd as (1) it had safe privsep, (2) no chroot
> req'd, and (3) did the job I need.
>

Privsep doesn't actually fix the same problem chroot does.   As I
understand it, privsep reduces the attack surface for remote execution
exploits by shuffling off privileged operations to a separate process, but
if that process isn't chrooted and it has a remote code execution flaw then
your entire system is opened up to attack.  Likewise, the unprivileged
process still has access to your entire system, and may still be used to
execute unprivileged code in the event of a remote execution
vulnerability.  Combined with other flaws in the system, both can still
lead to a privileged remote attack.   By contrast, chroot contains the
results of a successful remote execution to the environment of that
process, preventing a successful remote execution attack from touching the
filesystem outside the chroot... which limits the possible damage to the
exploited process.  Both things together are better than either one alone.
___
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: Forward zone not working

[Matthew Pounsett]

On 17 May 2016 at 09:29, Woodworth, John R 
wrote:

> >
> > > >Ideally every machine should be registering its own PTR record in the
> > > >DNS and addresses without machines shouldn't have PTR records.
> > > >The only reason ISP did this is that they were too lazy to manage PTR
> > > >records for their customers.
> > >
> > > And because no ISP wants "you.suck.isp.com" to show up in their DNS.
> > >
> > > Same fight, different address space.
> >
> > Agreed. Nice in theory, not going to happen in practice for the ISP
> where I'm working.
>
>
> Ditto here, great feature for smaller shop but not an ISP for a number of
> reasons.
>
> I would also add based on business perspective sometimes "lazy" is
> consumer or market
> driven and can't be simply dismissed. How popular would a brand new 60"
> television be
> without a remote control?
>
> Indeed.  When a business appears "too lazy" to do a thing you want them to
do, what that really means is that there is no business case that makes it
worth their while to spend the money on doing it.
___
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: Logging question about message 'update-security: error: client update denied'

[Matthew Pounsett]

On 16 May 2016 at 19:03, Josh Nielsen  wrote:

> Thank you for the response Mark. I'm still a little confused at what this
> might mean though. Clearly the originating address is my slave DNS server
> (every single one of the messages say "error: client 10.20.0.101").
>
> Are you saying that some process other than named on the same server
> (10.20.0.101) is responsible for these messages (and is there a 'for
> instance' of what could do such a thing?), or that somehow other hosts are
> relaying their update requests (again: from what possible processes?)
> through my slave dns server? What can I look for to figure this out on my
> network?
>

Your DHCP daemon would be one thing that could be generating those
messages.  Often it's configured to update the DNS with the addresses it's
handing out (either forward, reverse, or both).
___
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: Shared libraries loaded after chroot

[Matthew Pounsett]

On 16 May 2016 at 04:38, Marc Haber  wrote:

> I have filed Debian Bug #820974 (http://bugs.debian.org/820974)
> accordingly. The Debian bind people suggest that I copy the respective
> libraries to the chroot so that bind can find them.
>

Yeah, this has been the fix on a lot of systems since GOST was included in
OpenSSL.  It's something to do with the GOST algorithm being implemented
differently from everything else... as a plugin instead of a module, if
memory serves (it probably doesn't).IMHO it's a bug in OpenSSL, not
BIND.

Another option is to compile BIND with GOST support disabled... but that is
awkward for a lot of people using binary package distribution from the OS
vendor.


>
> This, however, would take possibly security relevant libraries from
> the automated update mechanisms of the distributions, and would
> therefore greatly reduce ease of upgrades. It is also not mentioned in
> Chapter 6 of the ARM.
>
> What is the official upstream remedy to this situation?
>
> Frankly, I think this is a bug in bind 9.10, it should load all
> necessary libraries before chrooting itself. I am aware that this
> would probably need parsing of the configuration before chrooting.
>
> What is the recommended way to run bind 9.10 in a chroot?
>
> Greetings
> Marc
>
> --
>
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Leimen, Germany|  lose things."Winona Ryder | Fon: *49 6224 1600402
> Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421
> ___
> 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: 'succesful' nsupdate of remote server not persistent across nameserver restart?

[Matthew Pounsett]

On 2 May 2016 at 10:05,  wrote:

> General question --
>
> When I want to change a zone file's data manually, say to add an A record,
> what's the right procedure:
>
> If the zone is set up for dynamic updates, like the examples you've given,
then in order to touch the zone file directly you need to temporarily tell
BIND to stop managing the file.

The general procedure is
1) use 'rndc freeze ' to stop dynamic updates to the zone
2) edit the file
3) use 'rndc thaw ' to re-enable dynamic updates

If the zone is not set up to use dynamic updates, then:
1) edit the zone file
2) 'rndc reload '
___
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: also-notify and nsupdate doesnt work

[Matthew Pounsett]

On 1 May 2016 at 23:57,  wrote:

> hi,
> i have a setup with one normal and some hidden slaves.
> i set up a zone with also-notify and all worked fine.
> all slaves got notifies and updates.
> now i added a key and policy to remote update the zone.
> the updates with nsupdate woks fine.
> but the notify is only sent to the slave, but not to the hidden slaves.
> so just the master and official slave is up to date.
>
> how can i change that?
>
> i use BIND 9.8.4-rpz2+rl005.12-P1 on debian wheezy...
>

What you're describing sounds wrong.  It shouldn't work that way.
Can you share your configuration so that we can see what's actually
happening?
___
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: Forward record for WWW

[Matthew Pounsett]

On 5 May 2016 at 11:55, Stephane Bortzmeyer  wrote:

> On Thu, May 05, 2016 at 03:42:24PM +,
>  Cuttler, Brian R. (HEALTH)  wrote
>  a message of 29 lines which said:
>
> > External record in the zone file is actually
> > wadsworth.org. 300 IN A 199.184.16.22
>
> None of the three name servers for wadsworth.org serve this A record.
>
> It seems the master was *not* reloaded. Did you check its BIND logs to
> see? May be the new zone with the A record at the apex was rejected
> for some reason.
>

Or perhaps the record was added to a hidden master without the serial
number being updated, and so a zone transfer hasn't happened?
___
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: Nsupdate usage scenario

[Matthew Pounsett]

On 2 May 2016 at 16:38,  wrote:

>
>
> On Mon, May 2, 2016, at 12:15 PM, Jeremy C. Reed wrote:
> > What about using a specific zone file just for the purpose of the single
> > A record you want to maintain using dynamic updates?
>
> Well, this is a timely idea for another issue I've been working on ...
>
> Could you expand on this a bit? Maybe an example?
>
> I'm not clear how you go about maintaining a 'different' zone for a record
> that belong in the 'original', parent zone.
>
> He's suggesting something like having example.com and dynamic.example.com
as separate zones, where the A record at the apex of the dynamic.example.com
zone is the host you want to maintain.   That'll let you have different
configurations for both zones (one dynamic, one manual).

example.com. IN SOA (...)
 IN NS ns1.example.com.
 IN NS ns2.example.com.

www  IN A  192.0.2.1
dynamic  IN NS ns1.example.com.
 IN NS ns2.example.com.
---

dynamic.example.com. IN SOA (...).
 IN NS ns1.example.com.
 IN NS ns2.example.com.
 IN A  192.0.2.1  ; use nsupdate to change me
---
___
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: also-notify and nsupdate doesnt work

[Matthew Pounsett]

On 2 May 2016 at 10:09,  wrote:

> hi,
>
> What you're describing sounds wrong.  It shouldn't work that way.
>>
> what do you mean by "wrong" and which "it" should not work? :-)
>
>
What I mean is, given a typical configuration, the brokenness you're
observing shouldn't be broken.


> Can you share your configuration so that we can see what's actually
>> happening?
>>
>
> sure :-)
> samples:

Can you share your whole config?  It's possible there are options outside
the zone stanzas that could affect the behaviour of  notifies.
___
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: Adding CNAME for the root domain issue

[Matthew Pounsett]

On 27 April 2016 at 07:26, Stephane Bortzmeyer  wrote:

> On Wed, Apr 27, 2016 at 05:05:50PM +0300,
>  Daniel Dawalibi  wrote
>  a message of 52 lines which said:
>
> > our setup requires a CNAME record.
>
> Bad setup. (And has always been bad.)
>
>
This isn't really his fault.  The OP's goal should be achievable (using the
apex domain name to reach a host that is not an A/ record at the apex),
it just can't be done with CNAME.   One of these days I'd like to lead a
serious lobbying effort against the browser developers at the W3C to have
SRV records for HTTP standardized.   That would completely fix this
problem.   The end user gets to do what they want to do, and the DNS
standards aren't violated.
___
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: Delegation questions

[Matthew Pounsett]

On 11 August 2016 at 09:13, Bob McDonald  wrote:

> I have a child domain that is delegated to a second site. Pretty
> straightforward situation. In the parent zone I have NS records that point
> to the DNS servers at the second site.
>
> The issue comes up when a slaved copy of the parent domain is running at a
> third site and that third site doesn't have a rule in their firewall
> allowing DNS access to the second site (where the child domain is
> delegated).
>
> The question is this; can I use stub zones to reference the child domain
> on the master server (instead of delegation) and the use forwarding at the
> third site to direct queries for the child domain through the master
> server?
>
> I hope the picture I've tried to describe is somewhat clear.
>

If the setup is exactly as you describe, then there's probably no reason
for a name server authoritative for the parent zone to ever need to contact
a server authoritative for the child zone.  Delegation from A to B doesn't
imply direct communication between A and B.

That said, you never know where on the Internet queries for a zone will
arrive from.  If you want the Internet at large to be able to resolve names
in your zone, then you can't firewall yourself off from parts of the
Internet.

If any of the servers in this scenario are also acting as recursive
servers, then you have the same problem;  you never know where on the
Internet an authoritative server you need to speak to is going to be, so
you can't firewall your recursive server off from speaking to parts of the
Internet and expect it to work reliably.




>
> Regards,
>
> Bob
>
> ___
> 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: Delegation questions

[Matthew Pounsett]

On 11 August 2016 at 10:14, Bob McDonald  wrote:

>
> Currently, clients sending queries for domain child.example.com. to
> server A get good results.
> However, clients sending queries for domain child.example.com. to server
> C get SERVFAIL because server C has no access to server B. (I'm guessing
> there is a firewall issue)
>

Your problem here is not directly related to the delegation.  Your problem
is that you have a recursive server (C) which is blocked from reaching a
part of the Internet where there is an authoritative server (B) it needs to
contact.

If these servers are not listed in the stub resolvers of systems as their
local recursors, then turn off recursion on the servers.  Otherwise, open
up your firewall rules to allow your recursive servers to reach the entire
Internet, and the entire Internet to reach your authoritative servers.


>
> The question is if I get rid of the delegation and put in a stub zone on
> server A pointing to child.example.com. on server B, can I use forwarders
> for child.example.com. on server C to point at server A for resolution of
> child.example.com.? (Will server A get answers directly from server B or
> will server A simply refer me to server B?)
>

That's a very convoluted way of fixing what is simply a bug in your
firewall configuration.
___
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: named and use of resolv.conf? - how to "learn" this

[Matthew Pounsett]

On 2 August 2016 at 12:25, Spumonti Spumonti  wrote:

> (I've done several searches for this first but the general nature of some
> of these terms returned way too many non-relevant responses)
>
> I was recently told that named does not use resolv.conf when resolving
> names. This was not something I was aware of but at this point I accept
> that. The system in question is an authoritative only server, no recursion
> enabled, that for some zones it hosts, lists secondary name servers in
> other organizations (in other words these name servers are in zones NOT
> hosted on this server)
>
> My real question is: where is this documented? I've read DNS books and
> scoured different sites but couldn't find anything stating this was how
> named behaved. Maybe I just suck at searching for things or was using
> imprecise terms.
>

The fact that named doesn't use resolv.conf wouldn't be documented anywhere
because they're unrelated.   Particularly for an authoritative server,
there's not reason for BIND to consult the system stub config, which is
what resolv.conf is (primarily) for.

To use a somewhat exaggerated comparison, documenting anywhere that BIND
doesn't consult resolv.conf would be like documenting that your car doesn't
need a ladder.

In the authoritative configuration, BIND has no need to do DNS lookups of
its own, so it wouldn't be any use there.   And BIND in recursive mode has
a hints list which tells it where the root servers are.  It will use those
to follow delegations to the correct authoritative server for whatever
lookup it's attempting to do.

resolv.conf configures the stub resolver (and occasionally other software
that behaves like a stub resolver) to tell it where the local recursive
servers are.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Loading all zone files in a directory

[Matthew Pounsett]

On 23 July 2016 at 15:25, Danilo  wrote:

> Is there a way to get Bind to automatically include config files in a
> directory? If not, might it make sense to place a feature request for
> this with the Bind developers? If yes, what would the process be for
> such a request? Or is there a better alternative to this approach?
>

The relevant paragraph in the BIND 9.10 ARM doesn't say it, but I *think*
you can use at least some of the usual shell wildcard characters in the
include statement.

If so, something like:
include "/path/to/config/*.conf";
should work.

You don't say in your email whether you've tested this, but it'd be fairly
easy to check.   If that doesn't work, then no, there is no way to
accomplish what you want. (It seems to me this would be a fairly easy
feature request to grant... Mark?  Evan?)

If include doesn't do that, you should be able to get Ansible to assemble a
single config file from a template though, and include all of your zone
definitions in that.   It might require reorganizing your ansible roles
though, so that your complete zone list is given as variable input into a
role that handles the entire configuration for BIND.
___
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: named and use of resolv.conf? - how to "learn" this

[Matthew Pounsett]

On 2 August 2016 at 17:01, Ray Bellis <r...@isc.org> wrote:

> On 02/08/2016 19:47, Matthew Pounsett wrote:
>
> > In the authoritative configuration, BIND has no need to do DNS lookups
> > of its own, so it wouldn't be any use there.
>
> That's not strictly true - BIND will in some circumstances use its own
> internal resolver to handle the host lookups for NOTIFYs and XFRs if
> they're using hostnames instead of IP lists.
>

Yes it will.  But, as far as I understand, it uses the recursive code paths
to do that, and won't consult resolv.conf.  Yes?


>
> Ray
>
>
> ___
> 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: named and use of resolv.conf? - how to "learn" this

[Matthew Pounsett]

On 2 August 2016 at 19:50, Evan Hunt <e...@isc.org> wrote:

> On Tue, Aug 02, 2016 at 05:04:33PM -0400, Matthew Pounsett wrote:
> > Yes it will.  But, as far as I understand, it uses the recursive code
> paths
> > to do that, and won't consult resolv.conf.  Yes?
>
> Correct. However, an option to use the system resolver for this instead
> is a feature request we've been considering.
>
> The reason: Whenever we find a security bug that affects recursive
> operation only, someone who runs an auth-only server inevitably asks
> whether their system is affected, and we always have to say, "well,
> *probably* not, but recursive code *is* sometimes used in authoritative
> servers in order to blah blah etc" and it might be nice to just say no.
>

I'd suggest another reason:  the auth server should be subject to the same
resolution path/rules as other software in the network.  If, for example,
I've got some resolution exception configured in my local recursive servers
(such as a per-zone forwarding rule) it seems likely I'd want the
authoritative server to follow that without having to also configure it
into the authoritative server.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Enforce EDNS

[Matthew Pounsett]

On 6 February 2017 at 19:59, Mark Andrews  wrote:

>
> Unfortunately we then need to decide what to do with servers that
> don't answer EDNS + DNS COOKIE queries.  Currently we fall back to
> plain DNS which works except when there is a signed zone involved
> and the server is validating.
>
> I really don't want to add new automatic work arounds for broken
> servers but it requires people being willing to accepting that
> lookups will fail.  That manual work arounds will now have to
> be done. e.g. "server ... { send-cookie no; };"


I fully support breaking resolution for such servers.  I'd rather have a
hard failure on my end that I can investigate, and work around if
necessary, than have my server wasting cycles trying to guess what sort of
broken state there is on the far end.   It would also give me the heads up
I need to contact the admin on the far end and report their servers' broken
behaviour.
___
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: Graphing BIND 9.11/9.10 Queries

[Matthew Pounsett]

On 19 January 2017 at 10:16, Phil Mayers  wrote:

> On 19/01/17 15:12, John W. Blue wrote:
>
>> Daniel,
>>
>> Thanks for sharing.  I like the HTTP statistics channel but trying slice
>> up the XML has been challenging.  Going to be checking this combo out.
>>
>
> We moved to the JSON stats recently to get around a memory leak in our XML
> based script. Far nicer IMO.
>
> Yeah, I find processing the JSON stats much easier.. the tools for
importing JSON into  tend to be
pretty straightforward to use.
___
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: Multiple IPs Associated With A Single Name

[Matthew Pounsett]

On 29 September 2016 at 12:02, Tim Daneliuk  wrote:

> In the dark and dusty reaches of my elderly DNS experience, ISTR a way to
> set up A records so that the request to resolve a name returns a *list
> of associated IPs*.  This is distinct from DNS RR (I think?) which
> simply returns a different *single* IP for each call (I may well be wrong).
>
> Can some kind soul point me to a relevant explanation of how to do the
> hostname -> multiple IP mapping?
>

Just include multiple A resource records (RRs).   It's up to the client how
it uses those records, and what makes sense there is largely application
specific: round robin, try them in series, etc.


>
> Thanks,
> --
> 
> 
> Tim Daneliuk tun...@tundraware.com
> PGP Key: http://www.tundraware.com/PGP/
>
> ___
> 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: dig +trace = Bad Referral orBad Horizontal referral

[Matthew Pounsett]

On 20 September 2016 at 12:50, project722 <project...@gmail.com> wrote:

> I've reverted my configuration back to before we started using views. But,
> if this was a delegation issue, wouldn't we expect to see it regardless of
> using views or not? Works fine without views.
>

It's entirely possible you introduced some error in your zone structure
when you changed configurations for views.  Again, it's impossible to tell
since you've (poorly) substituted all of the zone names and file name in
your configuration.   If you want help from someone in the list, you're
going to have to share details of your configuration.


>
> On Tue, Sep 20, 2016 at 8:58 AM, Matthew Pounsett <m...@conundrum.com>
> wrote:
>
>>
>>
>> On 16 September 2016 at 11:12, project722 <project...@gmail.com> wrote:
>>
>>> I have an interesting problem. I started noticing that when I do a dig
>>> +trace against one of the domains we are authoritative for, we get errors
>>> from our nameservers for "Bad Referral" and you can see where it forwarded
>>> the request back up the namespace tree instead of giving the answer.
>>> Unfortunately I am unable to reproduce this problem at the moment. However
>>> I can reproduce the Bad (HORIZONTAL) referral. Basically once the query is
>>> referred to our name server I see this:
>>>
>>> ;; BAD (HORIZONTAL) REFERRAL
>>> ;; Received 187 bytes from x.x.x.x#53(ns.example.com in 2 ms
>>>
>>
>> A horizontal referral is when one authoritative zone (the parent)
>> delegates a subdomain to a server that responds out of the same parent
>> zone, rather than a subzone.  The DNS is an inverted tree structure, and
>> delegations are always supposed to be "down" the tree toward the leaves.
>> If a delegation ends up being across, then you get a horizontal referral
>> error.
>>
>> Since you obfuscated your configuration nobody is going to be able to
>> provide you with specific advice on where the problem is.  If you can find
>> the error in your authoritative data (or share which zone is giving you
>> problems so that someone here can point it out) that should clear up your
>> issue.
>>
>
>
___
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: dig +trace = Bad Referral orBad Horizontal referral

[Matthew Pounsett]

On 16 September 2016 at 11:12, project722  wrote:

> I have an interesting problem. I started noticing that when I do a dig
> +trace against one of the domains we are authoritative for, we get errors
> from our nameservers for "Bad Referral" and you can see where it forwarded
> the request back up the namespace tree instead of giving the answer.
> Unfortunately I am unable to reproduce this problem at the moment. However
> I can reproduce the Bad (HORIZONTAL) referral. Basically once the query is
> referred to our name server I see this:
>
> ;; BAD (HORIZONTAL) REFERRAL
> ;; Received 187 bytes from x.x.x.x#53(ns.example.com in 2 ms
>

A horizontal referral is when one authoritative zone (the parent) delegates
a subdomain to a server that responds out of the same parent zone, rather
than a subzone.  The DNS is an inverted tree structure, and delegations are
always supposed to be "down" the tree toward the leaves.  If a delegation
ends up being across, then you get a horizontal referral error.

Since you obfuscated your configuration nobody is going to be able to
provide you with specific advice on where the problem is.  If you can find
the error in your authoritative data (or share which zone is giving you
problems so that someone here can point it out) that should clear up your
issue.
___
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: Question about dynamic IPv6-PTR-Generation

[Matthew Pounsett]

On 26 August 2016 at 13:45, Matus UHLAR - fantomas 
wrote:

> On 26.08.16 07:34, Tom Tom wrote:
>
>> I'm searching a way to respond to IPv6-PTR-Queries like the
>> "$GENERATE"-mechanism for IPv4 has done it.
>>
>
> why? configuring single IP addresses or taking them from DHCP is easier
> than
> creating new useless mechanism.
>

That's not necessarily true for IPv6, where even a modest network could
have trillions of addresses that may need 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: Question about dynamic IPv6-PTR-Generation

[Matthew Pounsett]

On 26 August 2016 at 15:41, Matus UHLAR - fantomas <uh...@fantomas.sk>
wrote:

>
>>> On 26.08.16 14:01, Matthew Pounsett wrote:
>
>> That's not necessarily true for IPv6, where even a modest network could
>> have trillions of addresses that may need PTR records.
>>
>
> that's exactly why using $GENERATE and/or creating new mechanism for that
> is
> useless.
>

$GENERATE is useless in that situation, yes.  But something that provides
rules to a name server to synthesize responses (vs actually generating all
18446744073709551616 PTRs in a /64) is not.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Multiple IPs Associated With A Single Name

[Matthew Pounsett]

On 29 September 2016 at 15:07, Tim Daneliuk  wrote:

>
>
> No, not really.  It's for a private cloud microservices system we're
> thinking through.  We already run most/many of the various service
> backends in user space so that the app devs and support folks can control
> their own universe without having to constantly invoke someone with sudo
> or root or firecall permissions.   Because of very strict audit and
> regulatory constraints, there is zero chance they'll ever get root/sudo
> access to the DNS config, so running our private DNS just for this
> subset of private client/cloud users may make sense.
>
> I suppose you could leave yourself an unprivileged config file... have
them put you in group 'dns' or something, and make all the configs and zone
files writable by that group.   At least that way all you need your
sysadmins for is to issue the 'rndc reconfig' command.
___
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: semicolons in dig output

[Matthew Pounsett]

On Fri, Nov 4, 2016 at 13:51 Robert Edmonds <edmo...@mycre.ws> wrote:

> Matthew Pounsett wrote:
> > Was this actually a change between BIND 9.8 and 9.9?  Was it deliberate,
> or
> > an accident that might be reversed at some point?
>
> It's this change:
>
> 3953.   [bug]   Don't escape semi-colon in TXT fields. [RT
> #37159]
>
> The corresponding git commit is here:
>
>
> https://source.isc.org/cgi-bin/gitweb.cgi?p=bind9.git;a=commitdiff;h=9a36fb86f5019f25705d25ea729d03fcf8ecaa95
>
> --
> Robert Edmonds
>

Thanks for the pointer!
___
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: acl

[Matthew Pounsett]

On 8 October 2016 at 09:57, Pol Hallen  wrote:

> 192.168.1/24 is not a valid netmask
>>
>
> huh?
> In linux and BSD I always use 192.168.1/24 (how shortcut of 192.168.1.0/24)
> and so on...


You're confusing network configuration with ACL syntax.

Where you're using 192.168.1.50/24 in your OS configuration, what you're
really saying is 192.168.1.50 netmask 255.255.255.0.
When you use it in an ACL, you're saying "the entire /24 that contains
192.168.1.50"


> hint: using /24 everywhere is nonsense
>>
>
> why?
>
> My goal is allow 192.168.1.0/24 (net) and deny 192.168.1.50 (host)
>
> thanks
>
> Pol


It sounds like what you want is to permit 192.168.1.0/24 and deny
192.168.1.50/32.



>
> ___
> 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: Wildcard SRV record?

[Matthew Pounsett]

On 31 October 2016 at 12:35, Stephen Pape  wrote:

> Is there a better way for me to do this, or do I have to generate a
> whole lot of specific CNAME records?
>

If your subdomains follow a predictable pattern, then this seems like a
prime use of the $GENERATE statement.  You could either use it to generate
the CNAMEs, or directly generate the SRV records themselves.
___
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 transferring zones with incorrect view

[Matthew Pounsett]

On 20 December 2016 at 16:45, Asai  wrote:

> Greetings,
>
> Quick question.  Using BIND 9.9.4.  I have 2 zones.  One for LAN traffic,
> and one for WAN traffic.  My secondary server is transferring the wrong
> zones, so that my WAN zone has all the A records for my LAN zone.
>
> Any insights on this?
>
> Most likely you've misconfigured your master server such that the slave
(secondary) sees the wrong zone when doing zone transfers.  But, because
you haven't provided any real detail about your configuration, no one is
going to be able to provide much in the way of advice about how to fix it.

You should read the article that Mark Andrews linked, and if you still are
not able to solve the problem you should return with some details about
your setup.
___
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 transferring zones with incorrect view

[Matthew Pounsett]

On 22 December 2016 at 13:05, Asai <a...@globalchangemusic.org> wrote:

> Still trying to figure this out, still am not doing something right.  I’m
> still getting REFUSED when trying to do transfers from Master to Slave.
> Not sure what I’m doing wrong, so please point out my errors here.  I have
> two views, but neither are getting any transfers so I’ve only included one
> in the config.
>

It would help if you included your entire config.  You're likely editing
out important things.
At the very least, your supplied config is missing the server{} statements
necessary to use TSIG in your zone transfer requests.


>
> Here’s my part of my config for Master and Slave:
>
> MASTER (10.233.0.198):
>
> key WAN-key {
> algorithm hmac-md5;
> secret “FsrWAd2G5saYSd3bOx0mw==";
> };
>
> key LAN-key {
> algorithm hmac-md5;
> secret “4hKGvi4BDswdTD2f1sEE2i==";
> };
>
> acl lan_hosts { key LAN-key; !key WAN-key; 192.168.0.0/16; 10.233.0.0/24;
> localhost; };
> acl wan_queries { key WAN-key; !key LAN-key; !192.168.0.0/16; !
> 10.233.0.0/24; };
>
> include "/etc/rndc.key";
> controls {
> inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
>  };
>
> view "LAN” {
>
> match-clients { lan_hosts; };
> allow-transfer { key LAN-key; };
> also-notify { 10.233.0.189 key LAN-key; };
>
> zone “intranet.site" {
> type slave;
> masters {
> 10.233.0.198;
> };
> file "/var/named/slaves/intranet.site.LAN.hosts";
> };
> }
>
>
>
>
> SLAVE (10.233.0.189):
>
> key WAN-key {
> algorithm hmac-md5;
> secret “FsrWAd2G5saYSd3bOx0mw==";
> };
>
> key LAN-key {
> algorithm hmac-md5;
> secret “4hKGvi4BDswdTD2f1sEE2i==";
> };
>
> acl lan_hosts { key LAN-key; !key WAN-key; 192.168.0.0/16; 10.233.0.0/24;
> localhost; };
> acl wan_queries { key WAN-key; !key LAN-key; !192.168.0.0/16; !
> 10.233.0.0/24;  };
>
> include "/etc/rndc.key";
> controls {
> inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
>  };
>
> view "LAN” {
>
> match-clients { lan_hosts; };
>
> zone “intranet.site" {
> type slave;
> masters {
> 10.233.0.198;
> };
> file "/var/named/slaves/intranet.site.LAN.hosts";
> };
> }
>
>
>
> On Dec 21, 2016, at 10:59 AM, Asai <a...@globalchangemusic.org> wrote:
>
> Yes, thank you.  I think Mark’s link to the article is the proper
> solution.  Thank you for your reply.
>
>
> On Dec 21, 2016, at 10:55 AM, Matthew Pounsett <m...@conundrum.com> wrote:
>
>
>
> On 20 December 2016 at 16:45, Asai <a...@globalchangemusic.org> wrote:
>
>> Greetings,
>>
>> Quick question.  Using BIND 9.9.4.  I have 2 zones.  One for LAN traffic,
>> and one for WAN traffic.  My secondary server is transferring the wrong
>> zones, so that my WAN zone has all the A records for my LAN zone.
>>
>> Any insights on this?
>>
>> Most likely you've misconfigured your master server such that the slave
> (secondary) sees the wrong zone when doing zone transfers.  But, because
> you haven't provided any real detail about your configuration, no one is
> going to be able to provide much in the way of advice about how to fix it.
>
> You should read the article that Mark Andrews linked, and if you still are
> not able to solve the problem you should return with some details about
> your setup.
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
>
>
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Can bind works without defining root servers

[Matthew Pounsett]

On 15 August 2017 at 11:29, King, Harold Clyde (Hal)  wrote:

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

Yes. :)

BIND has a compiled-in root hints list that is kept up to date at each
release, which can be overridden with a zone of type 'hint'.   It also does
what's calling "priming queries", which is to contact one of the known root
servers from the hints list, and retrieve and up-to-date authoritative NS
set for the root zone from the root zone itself.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Strange recursor response time pattern

[Matthew Pounsett]

On 5 September 2017 at 11:56, Havard Eidnes  wrote:

> Hmm...
>
> some further local discussion has made me aware that us running
> "collectd" for monitoring BIND may be contributing to the
> problem; collectd fetches data each 10s by using the BIND-
> configured statistics-channel, thus BIND is processing a TCP
> connection to deliver the statistics data.
>
> It's still somewhat surprising and disappointing that this should
> interfere this much with DNS query processing...
>
> Is that pulling the old-style stats file, or the HTTP-based stats channel?


If the latter... the zone list (and by extension the root document) seems
to take a long time to process, and involves some sort of locking that
blocks all query processing while the list is being generated.  We
encountered this on a 3+ million zone instance.. BIND would stop answering
queries for several minutes if anyone requested the root stats document or
the zone list.

As Ray says, you may be better off individually querying each of the other
documents and processing those rather than polling the root doc to get them
all in one shot.
___
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: botched KSK rollover

[Matthew Pounsett]

On 21 August 2017 at 07:18, Phil Mayers  wrote:

>
> Gandi are another excellent registrar that I can recommend. They have a
> comprehensive API for all their features, including uploading DNSSEC public
> keys and consequent creation of the DS record.
>
> I'm hoping CDS eventually makes this all obsolete.
>
> Gandi also has a beta implementation of
 draft-ietf-regext-dnsoperator-to-rrr-protocol, which requires CDS/CDNSKEY
support, and provides registrars with a way to bootstrap DNSSEC ... so you
may get your wish sooner than later.
___
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: Query for newly added/modified data in zone fails at random

[Matthew Pounsett]

On 12 October 2017 at 11:03, Nikkilä, Tommi  wrote:

> Hi!
>
>
>
> My BIND (version 9.9.4-RedHat-9.9.4-51.el7) is displaying some odd
> behavior. When updating a zone, BIND randomly refuses to return the newly
> added  and/or modified data for client. In my named.conf I have dozens of
> views, main interest in the following
>

Each view keeps its own internal state for its zones.  The way you appear
to have this configured, for any zone in 'common-slave.conf' you have
several versions stored (one per view) each trying to write to the same
state file (e.g. slave/db.207.31.172.in-addr.arpa).

If I were to speculate (you'd want to do some more troubleshooting to
confirm), I would suspect you're running into problems with your views
stomping on each other's slave files.
___
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: Email & PTR Issues

[Matthew Pounsett]

On 7 November 2017 at 10:31, James Pifer  wrote:

> Hello. I'm looking for help with an issue I've been fighting for some time.
>
> Background:
> Running BIND 9.9.
> Forwarding UDP & TCP Port 53 through firewall.
>
> I have issues emailing to certain domains. I use my own mail server to
> deliver mail. It is currently not sending through SMTP Relay. The failure
> says that I have a missing PTR record. For example:
>

You may have configured reverse DNS on your DNS server, but that reverse
DNS zone is not delegated to you, so nobody else's DNS server will ever
query yours for that PTR record.  It's being managed by swbell.net, who
returns NXDOMAIN for that lookup.

I'm presuming swbell.net is your ISP.  You either need to get them to
delegate reverse DNS for your address block to you, or have them set up the
PTR record(s) you require in their DNS.

; <<>> DiG 9.11.2 <<>> +trace -x 108.212.144.25
;; global options: +cmd
. 223262 IN NS h.root-servers.net.
. 223262 IN NS a.root-servers.net.
. 223262 IN NS c.root-servers.net.
. 223262 IN NS g.root-servers.net.
. 223262 IN NS i.root-servers.net.
. 223262 IN NS m.root-servers.net.
. 223262 IN NS d.root-servers.net.
. 223262 IN NS e.root-servers.net.
. 223262 IN NS k.root-servers.net.
. 223262 IN NS j.root-servers.net.
. 223262 IN NS l.root-servers.net.
. 223262 IN NS b.root-servers.net.
. 223262 IN NS f.root-servers.net.
. 223262 IN RRSIG NS 8 0 518400 2017111921 2017110620 46809 .
OL3PH3LpCrgzyohVZas9X42iwOpXsYD8CRkNiJZ1Oy6jwIfb8Shy57XN
5noPxtghdHBLutGBIdMwL2rA5AR2yaaVgRC6TM0eSqeixFFeETu6EV89
ZpBgSDNSVL1fmwnSoni1mZRj+F0iLT+Q+t/DveqVwh4o/2czWsnfiqTk
89jZRB30W3Ja9E4EMNW1+WNCkib1KTFvnwwgfYGPtjyFSUIQrv1vOByN
R3Yu11YYkgauY0Q5C7vcUkchwsDlkaWIgnvEZQXRUM3Ibi1QX6kq1g6Q
JW9mSzf7YqrPfU90HId+TSfuvTL4MrkN81iQXSl37+sldtJzDSKOKQij 7Wj1hg==
;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 7 ms

in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 86400 IN DS 53696 8 2
13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa. 86400 IN DS 63982 8 2
AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa. 86400 IN DS 47054 8 2
5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 2017112012 2017110711
36264 arpa. VMG4mxJ1Kdcm4QsK/i8qP+EzIubfzl2Hlo9hG1aDAZ8/y+GIKz+bYGVG
f1wZKCZAfFPMrDBIVAhghK3eTQooY12oUEGICksbtSukvDQcL6LwqZKf
yfPuSW29Qj+hsdmeDZAwRiaCjAeMf5tucgX7yr9SD08gCTJcaPltjdlv QuM=
;; Received 740 bytes from 198.41.0.4#53(a.root-servers.net) in 18 ms

108.in-addr.arpa. 86400 IN NS r.arin.net.
108.in-addr.arpa. 86400 IN NS u.arin.net.
108.in-addr.arpa. 86400 IN NS x.arin.net.
108.in-addr.arpa. 86400 IN NS y.arin.net.
108.in-addr.arpa. 86400 IN NS z.arin.net.
108.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net.
108.in-addr.arpa. 86400 IN DS 42060 5 1
DCD6C8C3D6F68C6A4495EA2C1C5DA76BBCB466E2
108.in-addr.arpa. 86400 IN RRSIG DS 8 3 86400 20171114073514 20171024172923
50761 in-addr.arpa.
l8UaM1j4VZ14OnIdBoH7b3xgFPyueh6A82423FAp53ohpOf+enHrh26s
O0Vaq3LnIk3fTED6bspZCour38srNTmWWKvYRSzAQ+vAsarAo//Cma4U
nCLAQAJqQRrUzQ2ZXC/AZoC+E0jfyA0saXC3mQb76+iwPx8hLJnw6wD1 Vhj/mwU=
;; Received 387 bytes from 203.119.86.101#53(e.in-addr-servers.arpa) in 236
ms

212.108.in-addr.arpa. 86400 IN NS ns1.swbell.net.
212.108.in-addr.arpa. 86400 IN NS ns3.sbcglobal.net.
212.108.in-addr.arpa. 86400 IN NS ns2.swbell.net.
212.108.in-addr.arpa. 10800 IN NSEC 213.108.in-addr.arpa. NS RRSIG NSEC
212.108.in-addr.arpa. 10800 IN RRSIG NSEC 5 4 10800 20171121173125
20171107163125 14796 108.in-addr.arpa.
aTXD4vS9gVjOP9uzozcUdXhSFuCXKqKUKUpZnHuStZO7QPqXKnB8EOoj
F0lRJDkdvGNng/BwMLj22EFC3kWtFhOTLl2l6oq7tjb+fhGJCWCY5Pbp
Cyc3VSiIU7wCPa2HDJbYMTLKLm4UZOBA1Mlp+0rcGDosGcnqmRl7oGNh Y6A=
;; Received 348 bytes from 192.82.134.30#53(y.arin.net) in 18 ms

212.108.in-addr.arpa. 3600 IN SOA ns1.swbell.net. rm-hostmaster.ems.att.com.
21 10800 900 604800 7200
;; Received 131 bytes from 65.68.49.6#53(ns3.sbcglobal.net) in 92 ms
___
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: Proper use of keyid in allow-transfer

[Matthew Pounsett]

On 7 December 2017 at 07:41, MURTARI, JOHN  wrote:

>
>
> The slave server defines the same key and is located at
> 192.168.1.1.  When we use the above on the master, transfers for any zone
> work fine.  If we remove the IP address and try a transfer we get
> ‘denied’.  What are we missing?  Thought we might have to associate the
> keyid with zones on the slave, but couldn’t find any options for that??? We
> don’t use TSIG on these servers.
>

The keys you've defined above are TSIG keys, so yes you're using TSIG–or
trying to at any rate. :)

I'm going to assume you're creatively redacting your key data, and that it
isn't actually "BippityBop", because that isn't a valid hmac-md5 hash.

You don't include your slave config, so I'll point out a couple of common
errors there you can look for:
1) the keys must have not only the same secret, but also the same name on
both the master and slave
2) make sure you've got a server{} clause on the slave which tells it to
use the key when speaking to that server.  And note that server{} is a
root-level directive in BIND... it doesn't go inside the options{} block.
For example, if your master is 192.168.1.2, your slave needs:
server 192.168.1.2 {
   keys { bongo; };
};
Alternatively, there's a config syntax for specifying the key to use on a
per-zone basis by adding it to each server in the masters list in a slave
zone definition.  I think the TSIG section of the BIND ARM (Administrator
Reference Manual) discusses that, and for sure the zone syntax description
will.

If it's not one of those things, then I'd suggest you include a more
complete configuration in your next email (from both sides), possibly with
some log entries showing the failed zone transfer attempts (also from both
sides).
___
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: [Question] zone transfer issue with multiple views

[Matthew Pounsett]

On 8 December 2017 at 17:37, Eoin Kim  wrote:

> Hi,
>
>
> Thanks for your help. But is it possible to do it without additional IP
> address? I thought that I am not really bad with BIND but as soon as I
> started using views, I'm going nowhere [image: ]
>
>
> In order for the slave's View A to transfer from the master's View A, and
the slave's View B to transfer from the master's view B, there has to be
some way for the master to differentiate the two views on the slave and
answer their queries from the correct view.   Source IP address is the
typical way to do that.

You could probably select on source port instead, by setting the slave's
transfer-source to a particular port for each view.  I've never set this up
myself, but I just checked the ARM and it looks like you can use any legal
address_match_list in the view's match-clients list, so you could also
select on TSIG key used, if you assign per-view TSIG keys.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: BIND source distribution missing?

[Matthew Pounsett]

On 4 May 2018 at 12:23, Evan Hunt  wrote:

> On Fri, May 04, 2018 at 04:19:43PM +, Evan Hunt wrote:
> > You're right, something's broken.  I see it too, and not just on chrome.
> > I'll escalate.  Thanks for bringing this to our attention.
>
> It's fixed now.
>
>
Thanks Evan!  That looks a lot more like what I'm used to seeing. :)
___
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: Release Strategy Clarification

[Matthew Pounsett]

On 26 April 2018 at 13:42, Victoria Risk  wrote:

>
>
> You have correctly interpreted the chart in the blog post, but you don’t
> have to update in January, just when there is a bug you need a fix for.  If
> that bug is a security bug, the red block means, we will issue a security
> patch even though we are no longer issuing regular maintenance on that
> branch. So, effectively there is a quarter, 3 months, of overlap.
>
> Thanks for the clarification, Vicky.   It sounds like ISC and I have
different definitions of "no longer supported." :)Perhaps I could
suggest that the descriptive text for that stage be updated to indicate
that there is limited support (for security related bugs) during that stage.

Matt
___
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 source distribution missing?

[Matthew Pounsett]

Hi ISC!

I'm writing to let you know there seems to be a bug on the ISC web site.
Coming from MacOS Chrome, I'm only being offered the binary Windows
distribution of BIND for download from  and
from .

Browser-detection bug aside.. I think only offering only the binary version
to *anyone* is a mistake.  Regardless of what platform I'm using to
download BIND, I may be deploying it to any number of different places.  It
shouldn't matter what browser I'm using at all, or what my desktop OS is, I
should be able to easily access *all* (current) distributions... not just
the one you think matches the browser I'm using.  So, please dump the
browser detection entirely, and just offer me all the distributions.

Also,  needs an update to its 'welcome' file, because
BIND doesn't seem to be distributed from there anymore.

Thanks!
   Matt
___
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 source distribution missing?

[Matthew Pounsett]

On 4 May 2018 at 08:18, Anand Buddhdev  wrote:

> > Also,  needs an update to its 'welcome' file, because
> > BIND doesn't seem to be distributed from there anymore.
>
> I can see all the BIND downloads at:
>
> ftp://ftp.isc.org/isc/bind9/
>
> Ah yes, there they are!  Thanks.
I will blame the hour and the lack of caffeine for missing that one. :)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: Can we define masters as hostsname?

[Matthew Pounsett]

On 23 May 2018 at 07:37, Blason R  wrote:

> Hi Guys,
>
> Can we define masters as hostname instead of IP address? I guess its not
> possible but wondering if community can shed come light on this?
>
>
The short answer.. no, you can't do that. The definition for the slave zone
statement's 'masters' option (BIND 9.11 ARM pp 139) is pretty clear that
you can only use IP addresses and named masters lists.  You could fake it
by defining a named master list (pp. 70) but I suspect that isn't going to
do what you want.

I think the rationale for not allowing hostnames there is that you can
easily put yourself in a unresolvable (pardon the pun) situation where your
slave can't reach the master until your slave reaches the master and gets a
copy of a key zone.   I can also see the potential for complication even if
there weren't a catch-22 in the configuration, such as what to do if the
hostname referenced has multiple addresses associated with it; that would
have implications for things like how complex it is to track whether a
master is available or not.  I'm sure there are other complexities I
haven't thought of.
___
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: Intermittent "failure trying master... operation canceled" on zone refresh

[Matthew Pounsett]

On 17 May 2018 at 17:05, Rob Moser  wrote:

> We're running a series of RHEL 7.4 machines (kernel version
> 3.10.0-693.1.1.el7.x86_64) running bind version 9.9.4-RedHat-9.9.4-51.el7.
> Our configuration consists of a hidden master and three hidden
> slave/recursive resolvers.  I'm getting a LOT of errors on the slaves that
> look like:
>
> 17-May-2018 13:27:28.421 general: info: zone 
> 34.22.10.in-addr.arpa/IN/internal-view:
> refresh: failure trying master 10.20.30.3#53 (source 0.0.0.0#0): operation
> canceled
>
> In addition to checking for firewalls and other stateful network devices
as Tony mentions, you should also have a look at the condition of the
network in between the hosts.  That feels a lot like moderate packet loss,
or extreme latency, to me.

Are these machines all on the same LAN?  Are there multiple networks in
between them?
___
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: also-notify and allow-notify

[Matthew Pounsett]

On 17 May 2018 at 13:30, Blason R  wrote:

> Hi,
>
> I have RPZ installed on server and its acting as a master server but
> somehow port setting is not working on master
>
> [...]

>
> So here I am sending notification  to 192.168.5.49 on port 4545; my
> queries are
>
> How do I configure port on slave 4545 so that slave server can start
> listening on that port.
>

Your slave needs to be listening on the correct IP/port to receive the
NOTIFY.  In the current BIND Administrator's Reference Manual[0], the
discussion on Interfaces starts at page 98.


> And my master is failing  after restarting the services due to notify-them
> statement.
>

You don't indicate what the error is, but I'm willing to bet it's the fact
that you're trying to specify a masters list by name as well as a port.  If
you look at the 'also-notify' statement definition, you can see that you're
able to use a 'masters' list OR an IP address and port combination, but not
both (ARM pp. 71).  You should specify the port number as part of the
definition of the masters list, not where you use the masters list.

[0]: 
___
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 rejecting key to update a zone

[Matthew Pounsett]

On 8 June 2018 at 11:01, Mark E. Jeftovic  wrote:

> I've started a fresh install here and started over and still having the
> same issue, even when I crank the debug trace up to 5, I'm not seeing
> anything additional in the logs:
>
> Another long shot... any chance there is an overlapping ACL in the
config?  Maybe an overly-restrictive allow-query?  Something would need to
be overriding your allow-update in order to get a REFUSED response, I
think.
___
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: inline-signing: SOA serial out of sync

[Matthew Pounsett]

On 7 June 2018 at 07:36, Axel Rau  wrote:

> Hi all,
>
> occasionally named 9.11.3 fails to increment SOA serial like here:
>
> file: 2018060605 dns: 2018060604
>
> zone file was edited by script and a rndc reload given.
>
[...]

> Manual fixing requires another cycle with zone file editing:
>
>
You don't say this clearly, but it sounds like you're reporting more than
just the serial not updating.  Is that correct?  Are there actual updates
to the zone that are not being picked up?  As Tony says, the serial number
can differ from the file to what's served by the name server when the name
server is doing automatic signing.

Can you clarify which it is?
___
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: inline-signing: SOA serial out of sync

[Matthew Pounsett]

On 14 June 2018 at 06:27, Axel Rau  wrote:

>
> Am 07.06.2018 um 13:36 schrieb Axel Rau :
>
>
> occasionally named 9.11.3 fails to increment SOA serial like here:
>
> file: 2018060605 dns: 2018060604
>
>
> It just happened again. An included zone file has been changed from 2 TLSA
> RRs to one:
> - - -
> _443._tcp.git.nussberg.de. 3600 IN TLSA 3 0 1
> DAE0AC343A6694DEAF0BAB42FC8A6B1F82E42799654BD667B458DC91655C6AB4
> - - -
> After reload no TLSAs are picked up by the server:
> - - -
> [hermes:local/etc/rc.d] root# dig AXFR nussberg.de. @localhost | grep TLSA
> [hermes:local/etc/rc.d] root#
>

This now sounds very different from the original report.  Are you saying
that the zone started with two TLSA records, you changed it to have only
one, reloaded the zone, but then none were present?

That's a very different problem from just not picking up a zone update.

Have you checked the logs for errors during zone loading?
___
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: inline-signing: SOA serial out of sync

[Matthew Pounsett]

On 14 June 2018 at 10:16, Axel Rau  wrote:

>
> Am 14.06.2018 um 16:12 schrieb Alan Clegg :
>
> Additionally, I read this as "the records changed are in an included
> file" -- is the serial number in the "including" zone being incremented?
>
> Yes.
>
> I think at this point you're going to need to provide a lot more detail
about your configuration, and what's special about these zones.  It sounds
like this is not a straightforward configuration, and it's hard to figure
out from the bits and pieces you've provided what could be going 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