Re: Query failed (timed out)

2019-11-07 Thread Chris Thompson

On Nov 7 2019, Wilfred Sarmiento via bind-users wrote:


Hope this issue will reach Barclays Domain admin.


Don't hold your breath. The problem with these Barclays servers was already
being discussed on bind-users back in June, see the thread starting at

https://lists.isc.org/pipermail/bind-users/2019-June/101930.html

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



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

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


Re: Strange DNS problem

2019-06-10 Thread Chris Thompson

On Jun 10 2019, Jukka Pakkanen wrote:


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

[…]

An example, the client domain is raimoasikainenoy.fi.


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


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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a0ff0c014f65b471e0b8b271e7bab2718129c071 (bad)


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

I expect you could work around this by specifying 


 server 193.184.54.212 { send-cookie no; };

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

--
Chris Thompson
Email: c...@cam.ac.uk
___
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


When to use the "invalid" TLD

2019-04-09 Thread Chris Thompson

On Apr 8 2019, Matthew Pounsett wrote, in another thread:


RFC2606 reserves test, example, invalid, and localhost, for "testing
and documentation," which seems to fit this use-case.  'invalid'
doesn't seem to me to be intended for use as a generic private TLD
though, as was suggested up-thread. 


This reminded me of one use I did make of "invalid". The IPv4 addresses
192.153.213.[249-251] were reserved for a web probing service for which
it was desired to make them appear not to be on the university network
(although they were) to see whether the web sites responded differently
in that case. Partly this was done by using an unusual /24, but also by
supressing DNS entries for them.

Originally this was done by tagging them in the database with a "visibility"
option that supressed inclusion of both forward and reverse entries in
the DNS. I was quite keen to get rid of this option, which messed up the
database semantics in other ways, and they were the only remaining cases
of its use.

So instead I attached them to a database object with a name under "invalid".
Reverse lookup on the IPv4 addresses then gave that name (indeed, it still
does). That still made them appear to be "not in cam.ac.uk", and forward
lookup on the name would be guaranteed to give NXDOMAIN. Well, unless
we ever generated a forward zone for "invalid" from the database, which
obviously was not going to happen...

I still think this was a reasonable use of "invalid", and consistent with
the remarks in section 6.4 of RFC 6761 (also dating from 2013, incidentally). 


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

___
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: Cached negative responses

2018-12-21 Thread Chris Thompson

On Dec 20 2018, Marc Richter wrote:


When checking the BIND XML statistics I see the following in the "Cache DB
RRsets" section, which I think
could be the reason for the high memory usage:

!   18446744073709551559
!A6 18446744073709551607

Is this an overflow on the counter for these negative responses in Cache, or
could there really be that many objects in the cache ?


Assuming these were output as uint64_t but then reinterpreting them as
int64_t, they are very *small* negative numbers, -57 and -9 respectively.
I suspect something other than overflow is responsible.

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: DNSSEC: give KSK from my domain to parent zones

2018-10-05 Thread Chris Thompson

On Oct 4 2018, Mark Elkins wrote:


On 10/04/2018 05:03 PM, Roberto Carna wrote:

[...]

I have two DNS servers running BIND 9.10, they have delegated my own
domain, let's say "robert.com.uk <http://robert.com.uk>" and some
other domains from our clients, let's say:

client1.com.uk <http://client1.com.uk>
client2.edu.uk <http://client2.edu.uk>
client3.info.uk <http://client3.info.uk>

Can I sign theses client zones with my ZSK, or do I have to have a
different key for each domain?


I believe common practise is to create separate KSK and ZSK keys for
each domain - so each domain will have their own DS records in the
parent. This way, if one of the clients moves their domain to a new DNS
provider - there is no security conflict in the move from shared keys.


Even if you make the (RDATA of) the KSKs identical for the different zones
the DS records you will need to insert into the parent zones will be
different, because the hashing algorithm includes the KSK owner name
(i.e. the zone name) in its input. See RFC 4034 section 5.1.4.

Similarly using ZSKs with identical RDATA in the different zones will
not make any of the RRSIGs the same (e.g. for the www.[zonename] RRs
in different zones), because the full owner name is included in the
hashing input.


(Use a different Key)


Yes. Because there are no advantages whatsoever in doing otherwise!

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



___
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: NTP through DNS?

2018-09-26 Thread Chris Thompson

On Sep 24 2018, Danny Mayer wrote:
[...]

This is very simple to do. It does not require SRV records to implement.
Note that I am only answering for the ntp reference implementation.

In your domain file add entries like this:

locationntp CNAME ntp1.yourdomain
CNAME ntp2.yourdomain
CNAME externalntp.otherdomain
CNAME externalntp.someotherdomain


Assuming that you are running name server software that actually allows
you to have several CNAMEs with the same label, of course.

BIND8 with "multiple-cnames yes", perhaps? :-)

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: tool for finding undelegated children in your DNS

2018-07-27 Thread Chris Thompson

On Jul 27 2018, Timothe Litt wrote:

[...]

If you want to do this validation with zone files, then text tools (e.g.
a Perl, awk, etc) are a reasonable approach.  It would not be
particularly difficult - though you do have to handle include files. 
Rather than working from zone files, the easiest approach is to do a dig

axfr to get the actual zone...


If you do need to work from the zone files, I would strongly recommend
normalising them with "name-checkzone -o outfile zonename infile" or
an equivalent, before trying to unpick them with "Perl, awk, etc".

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Administrivia.

2018-04-23 Thread Chris Thompson

On Apr 23 2018, Ray Bellis wrote:


On 23/04/2018 14:18, Anand Buddhdev wrote:


If you repeat your query with the +cd option, you'll get a response.

DNSViz shows problems with the DNSSEC setup of this zone. The DS and
DNSKEY records don't match:

http://dnsviz.net/d/1.20.149.in-addr.arpa/dnssec/


Thanks for the heads up - I'll make sure our Ops team is aware.


To further increase our Schadenfreude, please do let the list know just
how ISC managed to let that happen! Or will you be able to blame ARIN?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Slow zone signing with ECDSA

2017-04-20 Thread Chris Thompson

On Apr 20 2017, Tony Finch wrote:


Mark Andrews <ma...@isc.org> wrote:


DSA requires random values as part of the signing process.


Traditionally, yes, but it isn't actually required -
https://tools.ietf.org/html/rfc6979


There is a great deal to be said for using deterministic DSA even if
your random number source is both trustworthy and fast.

The EdDSA standards (RFCs 8032 & 8080) mandate deterministic signatures
and this is certainly intentional. Of course, there are also many other
ways in which they are improvements on the earlier NIST-based ECDSA
standards, and we should all be looking forward to the time when BIND,
inter alia, supports them...

--
Chris Thompson
Email: c...@cam.ac.uk
___
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


Reply to digests [was: RE: bind-users Digest, Vol 1727, Issue 1]

2016-07-05 Thread Chris Thompson

On Jul 4 2016, G.W. Haywood wrote:


Hi there,

On Mon, 4 Jul 2016, Amit Kumar Gupta wrote:


[An entire digest message, which I've snipped]


It would be extremely helpful to those of us on the digest list, and
generally more polite, if you would NOT include in your posts to the
list, simply in order to save yourself the time and effort of typing
the list's address and thinking of a subject line, a complete digest
message, two and a half years old and apparently selected at random.


I have long thought that mailing lists should be configured to reject
messages with a Subject of "Re: [the subject format for the list's
digest messages]". Maybe a scan of the message content for a copy of
the digest prologue would be a good idea as well. 


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


___
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: g.root-servers.net not reachable anymore

2016-04-18 Thread Chris Thompson

On Apr 18 2016, Dave Warren wrote:


On 2016-04-14 03:02, 'Stephane Bortzmeyer' wrote:

On Thu, Apr 14, 2016 at 11:55:04AM +0300,
  Daniel Dawalibi <daniel.dawal...@idm.net.lb> wrote
  a message of 22 lines which said:


Do you think it is better to remove it from named.root?

Certainly not, your resolver removes it automatically from the list of
authoritative servers for the zone.


Also, named will add it right back to the in-memory cache (the one that 
matters) since it will reach out to one of the hints servers to find the 
up to date list of root servers.


The hints file is just a hint of how to find the roots, not an absolute 
list of root servers.


In any case, this was only(!) a 9.5 hour outage (2016-04-14 03:00-12:30 UTC).
Any kind of local manual configuration change would have been an inappropriate
response.

I think the only explanation we have seen so far is

https://lists.dns-oarc.net/pipermail/dns-operations/2016-April/014765.html

which is fairly tight-lipped!

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



___
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: response case in-sensitivity?

2015-07-30 Thread Chris Thompson

On Jul 30 2015, Barry Margolin wrote:


In article mailman.2375.1438232213.26362.bind-us...@lists.isc.org,
Mark Andrews ma...@isc.org wrote:
[... snip ...] 

Then iOS (or the application) is broken.  Domain names should always
be compared case insensitively.  Please report a bug to the app
vendor and / or Apple.


Isn't this the DNS 0x20 security enhancement? Clients send a random mix 
of case, and check that the response matches, to protect against spoofed 
responses.


https://tools.ietf.org/html/draft-vixie-dnsext-dns0x20-00


You must distinguish between the copy of the query in the reply packet,
which BIND (like nearly all implementations) does copy exactly from the
query, and the owner field used in the answer section, which recent
versions of BIND make the same as that loaded from zone file (when
authoritative), or as received from an authoritative nameserver (when
from the cache).

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



___
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: Future of BIND's built-in empty zone list

2015-05-17 Thread Chris Thompson

On May 14 2015, Rob Foehl wrote:
[...]
Adding empty.as112.arpa to the list seems like a good idea, but removing 
the existing empty zones does not -- they also prevent leaking internal 
queries, which is both more noise for the root/IANA/AS112 infrastructure 
to sink and a potential privacy concern.


Well, perhaps each case needs to be judged on its merits.

There's also the minor benefit of fast responses from local resolvers, 
which still matters for determinism in the initial query.  From where I 
sit, the nearest blackhole.as112.arpa is 90+ms and an ocean away (v4 or 
v6), and the existing AS112 nodes aren't much better.


As long as empty.as112.arpa is served locally, there would be no need
to access the as112 nameservers. It's the nameservers authoritative for
the DNAMEs pointing to it that are relevant, and of course one also
hopes these DNAMEs will have big TTLs so that they will remain cached.

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



___
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: Future of BIND's built-in empty zone list

2015-05-17 Thread Chris Thompson

On May 16 2015, Mark Andrews wrote:
[...]

When IANA and ARIN finally gets around to doing 64.100.IN-ADDR.ARPA
et al., which has been waiting over a year for the of DNSOP to write
up the last call of draft-ietf-dnsop-rfc6598-rfc6303 to be written
up, it should be done similar to this with a insecure delegation
to 64.100.IN-ADDR.ARPA, to allow the ISP's using this range and
others to server their own instances of 64.100.IN-ADDR.ARPA without
DNSSEC validation failures, and a DNAME to the AS112 traffic sink
for the leaked traffic.

64.100.IN-ADDR.ARPA  SOA ...
64.100.IN-ADDR.ARPA  NS ...
64.100.IN-ADDR.ARPA  NS ...
64.100.IN-ADDR.ARPA  DNAME EMPTY.AS112.ARPA

Note: there are no DNSKEY records.  This is deliberate.


I notice, however, that this is not what RFC 7535 suggests (e.g. for
the similar case of 2.0.192.IN-ADDR.ARPA). Instead a DNAME directly
in the (signed) parent zone is described.

Would this actually break a validating resolver with a locally defined
(unsigned) empty zone 2.0.192.IN-ADDR.ARPA ? The parent zone can produce
a proof that there is no signed delegation, but only by revealing the
signed DNAME.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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


Future of BIND's built-in empty zone list

2015-05-14 Thread Chris Thompson

Now that RFCs 7434  7435 have been published, how do ISC see the future
of the seemingly ever-expanding built-in empty zone list in BIND?

One possibility that seems plausible to me is to add EMPTY.AS112.ARPA
to the list now, and remove existing entries if and when the corresponding
names in the public DNS acquire DNAMEs pointing to that (hopefully ones
with large TTLs).  


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

___
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: Future of BIND's built-in empty zone list

2015-05-14 Thread Chris Thompson

On May 14 2015, I wrote:


Now that RFCs 7434  7435 have been published, how do ISC see the future ...


That should be 7_5_34  7_5_35 of course. Curses.

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


___
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: Automatic flushing of the jnl files

2015-01-21 Thread Chris Thompson

On Jan 21 2015, Howard, Christopher wrote:


The journal files get flushed to the zone file periodically, but old
transactions don't get removed so the journal file will continue to grow
forever.  If you're like me and on virtual machines with limited hard disk
capacity, you can limit the journal file size with the max-journal-size
configuration statement. Just make sure that the size is large enough to
hold all of the transactions between flushes (I believe that's around
every 15 minutes).  Otherwise, after a crash you would be missing records.


I am fairly sure you are wrong on that last point. BIND will not flush
journal file entries that have not yet been committed to the master file,
even if they make the journal bigger than max-journal-size. If you specify
max-journal-size 512; you will find the journal gets emptied completely,
but only after the master file has been updated. (Of course, as Phil Mayers
points out, this would cause downstream IXFRs to become AXFRs,)

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

___
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 feature request: Directly set the signed zone's serial number

2014-10-18 Thread Chris Thompson

On Oct 17 2014, Darcy Kevin (FCA) wrote:


FYI,
If you had to do this all over again, and your tools are flexible
enough to handle arbitrary RRTYPEs, you might consider using a private
RRTYPE (in the 65280-65534 range). See 
http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-4

and/or http://tools.ietf.org/html/rfc6895.

Repurposing HINFO for something other than expressing host-related info,
is just downright confusing/surprising. Principle of Least Astonishment.


Well, yes ... in an ideal world. Which this is not!

It is perhaps only a convenience that BIND and its utilities (named-checkzone
and nsupdate, in this context) process HINFO records in a convenient-to-humans
text format.

But the isuue of having to support Windows DNS Server implementations as
stealth slaves was a very real issue for us. I am not clear that even the
most recent versions fully support unknown record types in the style of
RFC3597. The ones we were having to deal with at the time most certainly
did not!

As for the Principle of Least Astionishment, I could replace


1. No-one wants to use HINFO at a zone apex for any other reason.


with

1'. (Almost) no-one uses HINFO for its original purpose anywhere in
   the DNS.

and I think I might get away with it.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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 feature request: Directly set the signed zone's serial number

2014-10-17 Thread Chris Thompson

On Oct 8 2014, Tony Finch wrote:


Terry Burton t...@terryburton.co.uk wrote:


This is especially useful in bootstrapping scenarios where the zone
data is held under strict revision control or generated by some
provisioning system that owns the serial number.


Our provisioning system used to think it owned zone serial numbers, but
when we started signing we moved the version tag into an HINFO record.


In case anyone wonders why HINFO?, this was because

1. No-one wants to use HINFO at a zone apex for any other reason.
2. As a very ancient type, even early Windows DNS Server implementations
  didn't object to it when slaving the zones.
3. One can put arbitrary text strings in it.

... but also for the much less reputable

4. As a low numbered type, it got sorted immediately after the apex
  SOA and NS records in a zone file normalised by named-checkzone -D.

Well, it served me right when we later had to put an A record (sorts before
HINFO) at the apex of cam.ac.uk and I had to modify our normalised-zone-file-
comparsion program to allow for that! 


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

___
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


To DLV or not to DLV [was Re: recursive lookups for UNSECURE names ...]

2014-08-28 Thread Chris Thompson

On Aug 28 2014, Doug Barton wrote:


On 8/27/14 3:03 PM, Timothe Litt wrote:

So you really meant that validating resolvers should only consult DLV if
their administrator knows that users are looking-up names that are in
the DLV?  That's how I read your advice.


You're correct.


I don't see how that can work; hence we'll disagree.  I think the only
viable strategy for*resolvers*  is to consult the DLV - as long as it
exists.


So that leads to a Catch-22, as ISC has stated that they will continue 
to provide the DLV as long as it is used. You're saying that people 
should continue to consult it as long as it exists.


I agree with that. The line I have been taking is that we will continue
to use validation via dlv.isc.org (as well as via the root, of course)
on our recursive nameservers as long as we have to register signed zones
there ourselves.

It is quite disappointing that we haven't reached that stage yet ...

Now that the root is signed the traditional argument against continued 
indiscriminate use of the DLV is that it makes it easier for registries, 
service providers, etc. to give DNSSEC a low priority. You don't need 
me to provide DNSSEC for you, you can use the DLV. Based on my 
experience I think there is a lot of validity to that argument, although 
I personally don't think it's persuasive on its own.


Jim Reid used to make that point a lot (and probably still does) when
arguing against the mere existence of DLV. However, the organisation
blocking progress for us has never made an excuse as cogent as that.
We just can't get any communication going with them on the subject
at all. 


To come clean: as part of the UK higher education community, we really
are stuck with using JANET. The political problems of disassociating
ourselves from them (and it has been muttered about in the past, in
the context of their network charges) are sufficiently horrific that
we could never justify it simply on the basis of their absence of
DNSSEC support in the reverse zone context.

Which is where we are stuck. JANET did sign the primary forward zone
ac.uk in early 2011, and provided methods for getting DS records for
delegations into it. This was actually fairly good compared to many
similar organisations. But having achieved this, and despite verbal
assurances at the time that the other zones (including reverse ones)
they were responsible would get signed as well, they seem to have
taken their eye entirely off the DNSSEC ball now.

What makes this even more frustrating is that, as early users of
the Internet much of our IPv4 space is in legacy (ERX) allocations
and the reverse zones for it are directly delegated from the reverse
zones manged by the RIRs. Those got signed in early 2011 as well,
and the mechanisms to maintain DS records in them (which involve
the communication mechanisms between the RIRs) work well. (A lot
of thanks are due to members of the RIPE DNS working group in that
context.) So for these reverse zones we have had a chain of trust
from the root for over 3 years now.

But a significant chunk of IPv4 space, acquired later, and all of
our IPv6 space, have reverse zones delegated from ones maintained
by JANET, themselves delegated from the RIPE NCC ones. As the
intermediate parent zones are unsigned, these are the ones we
still have to register in dlv.isc.org.

It is sometimes argued that validating reverse zone contents is
unimportant, and that theyhave only the nature of hints in any case.
I have always taken the converse line that if something is in the
public DNS at all, it ought to be signed. But our tribulations
summarised above (and believe me, I could go on about it at *much*
greater length! you should be grateful) have occasionally made me
regret that.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Why the heck my NS are not working

2014-07-20 Thread Chris Thompson

On Jul 20 2014, Blason R wrote:


The domain is isnlab.in and host i am trying to ping is lbtest.isnlab.in


The glue for delegation isnlab,in is out of step with (various) in-zone
contents. The in servers give a referral to

;; AUTHORITY SECTION:
isnlab.in.  86400   IN  NS  nslb02.isnlab.in.
isnlab.in.  86400   IN  NS  nslb01.isnlab.in.

;; ADDITIONAL SECTION:
nslb01.isnlab.in.   86400   IN  A   216.69.185.51
nslb02.isnlab.in.   86400   IN  A   208.109.255.51

But 216.69.185.51 and 208.108.255.51 have a version of the zone (SOA serial
2014071908) which does not include lbtest.isnlab.in, although it does contain

nslb01.isnlab.in.   IN  A   61.16.199.3
nslb02.isnlab.in.   IN  A   59.185.105.73

and the latter two IP addresses have a version (SOA serial 2014071909) that
does know about lbtest.isnlab.in,

You are always going to get inconsistent results until you fix the
delegation. 


--
Chris Thompson
Email: c...@cam.ac.uk
___
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 9.10..0-P1 rndc: 'retransfer' failed: not found; other rndc commands are ok

2014-05-23 Thread Chris Thompson

On May 23 2014, Doug Barton wrote:


On 05/22/2014 09:33 PM, Teerapatr Kittiratanachai wrote:

Sorry for jumping in, so from your information I understand that when I
have updated zone file at the master I should use `rndc reload
zone-name` instead `rndc retransfer zone-name` to transfer the new
zone file to other slaves, is it right ?


Yes, you reload the zone on the master which should cause the master to 
send notifies to the slaves which cause them to retransfer the zone.


The 'rndc retransfer zone' command is something you run on the slave 
if it doesn't transfer.


Note that rndc retransfer zone is fairly brutal. It tells the slave
to forget everything about its current copy of the zone, including its
SOA serial, and attempt a full zone transfer from the master(s).

In normal circumstances, a missed notify would be better dealt with by
rndc refresh zone, which just expedites what would normally happen
when the refresh interval expires. That is, it will do an SOA query
against the master(s), and if the serial has increased attempt an
(if possible incremental) zone transfer. 


--
Chris Thompson
Email: c...@cam.ac.uk
___
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: a note on 9.10.0rc2: eleven, twelve; dig and delv(e)

2014-04-27 Thread Chris Thompson

On Apr 25 2014, Doug Barton wrote:


On 04/25/2014 02:25 PM, Evan Hunt wrote:


So, after consultation with the bottoms of one or two bottles, and
consideration of several alternative names (including dredge, bore,
shovel and -- taking it in a slightly different direction --
groove) we decided to simply send the second 'e' in delve off to
wherever the one from creat() went.  The tool will now be called
delv.  (I plan to continue pronouncing it the same way.)


First, thanks for being considerate to the Xapian folks. However IMO 
that's not a good solution. To start with, the delve name was a bit 
silly, and didn't really trip off the tongue. Your proposed solution is 
suboptimal from both a product differentiation and a tab completion 
perspective.


I rather liked delve, but the truncation to delv does indeed seem
suboptimal in those respects, and quite ugly as well. 

If you(collectively) really cannot come up with a better name, why not 
crowd-source it on the ISC home page? I'm not terribly good at clever 
names for things like this, but I would vote for 'dq' (as in, DNS query) 
which has the virtue of not matching anything in the Ubuntu did you 
mean? database.


Oh please, not another two-letter command for the benefit only of the
digit-ally challenged...

Not to mention what http://en.wikipedia.org/wiki/DQ has to say...

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



___
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: Windows dig resolv.conf

2014-04-11 Thread Chris Thompson

On Apr 11 2014, Frederic Woodbridge wrote:


Apologies if this has been discussed; I searched the archives and didn't find 
anything.

I'd like to know why the search and domain settings in the Windows 
%systemroot%\system32\drivers\etc\resolv.conf don't seem to make a difference.
Anyone know?


If you are asking why doesn't dig take any notice of these settings,
that's not Windows-specific. From the dig man page:

+[no]search
Use [do not use] the search list defined by the
searchlist or domain directive in resolv.conf (if any).
The search list is not used by default.

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


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

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


Re: What do you do when the Root records are wrong?

2014-04-03 Thread Chris Thompson

On Apr 3 2014, /dev/rob0 wrote:


On Thu, Apr 03, 2014 at 07:19:03PM +0800, Maren S. Leizaola wrote:
It seems that UDRTLD.NET is not equal across all DNS server on the 
Root zone and it is affecting all the hosts that we are hosting.


Note that because net is delegated from the root, your question is 
wrongly posed. UDRTLD.NET is not in the root zone.


It's traditional that any reference to the root on this mailing
list is probably wrong.

[...]

some DNS servers are responding with this:

ns2432.ztomy.com
ns1432.ztomy.com


Which ones? Are they authoritative for .net?


No, they are authoritative for udrtld.net, self-consistently claiming
themselves as the only NS records for it.

This looks like a simple case of a change of nameservers for a zone not
propagating too well, because the old ones haven't stopped serving it.

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: What do you do when the Root records are wrong?

2014-04-03 Thread Chris Thompson

On Apr 3 2014, Maren S. Leizaola wrote:


It seems that the problem is with Network solutions. The 208.91.197.132
(ztomy.com) is one of their DNS names that they use for parking. Somehow
this has been pushed out to some of the gtld-servers.net for udrtld.net
and some of the gtld-servers.net are.

.ztomy.com are authorative for anything you query them about...


Not *quite* everything (e.g. not net, which confused me before) - there
seems to be a short exclusion list including some (not all) TLDs.


I've tried changing the IP of the name servers on Networksolutions,
hence e.udrtld.net has 4 ip addresses, though it is only one. They have
removing the NS records of udrtld.net and then adding them to fix it, it
has not helped but they are escalating it.


I don't see any evidence that the servers for net are not all in
step and have the right delegation for udrtld.net, in which case such
changes aren't going to help at all.

Once a recursive nameserver gets the NS records pointing to
ns{1,2}432.ztomy.com into its cache, it can be hard to ever make
it let them go, other than by explicitly flushing the cache. This
is the standard make sure your old nameservers stop serving the
zone, or at least serve a version with the new NS records in
situation. but the (highly anti-social, by the way) behaviour
of these nameservers makes that impossible to arrange.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: nsec3 opt-out confusion (bug report)

2014-04-01 Thread Chris Thompson

On Apr 1 2014, Klaus Darilion wrote:

[...]

Nevertheless, it seems there are still two bugs:
1. The NSEC3 chain is not properly cleared when switching from 
non-opt-out to opt-out
2. The NSEC3PARAM record always has the opt-out flag clear, even if 
opt-out is activated.


That last, at least, is not a bug. It is mandated by RFC 5155 - see
section 4.1.2.

This was really nic.at (and not example.com), wasn't it? Your domain
obfustication was half-hearted! I tried looking at it, but things
were changing too fast for me to get consistent results...

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: localhoast A record?

2014-03-24 Thread Chris Thompson

On Mar 21 2014, SM wrote:


Hi Chris,
At 11:18 21-03-2014, Chris Thompson wrote:

We used to create lots of localhost.[subdomain].cam.ac.uk records, even
to the extent of adding an  record just for those institutions that
had IPv6 enabled on their networks. But we have pretty much given up doing
that for new subdomains. It still seems to me potentially useful to keep
localhost.cam.ac.uk itself, to terminate the probable iteration described
above before it goes any further.


It can be used to exploit web application vulnerabilities.


Would you like to expand on that?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: localhoast A record?

2014-03-21 Thread Chris Thompson

On Mar 21 2014, Marco Davids (SIDN) wrote:


On 21-03-14 14:03, Casey Deccio wrote:


I've adopted a number of zones and most of them contain localhost in
a 127.0.0.1 records. I'm curious what current RFC standards state and
what the community considers best practice.



I would take a look at the query logs for the zones in question.  You
might be surprised at how many queries are being made by systems that
are applying a suffix from the search list because of the lack of of an
entry for localhost in the hosts file or the mishandling thereof.


To me, an NXDOMAIN-reply seems better than an answer with an A-record to
127.0.0.1 (because that won't be an incentive to fix an apparently
broken situation).


But in the context of search lists an NXDOMAIN will just make the resolver
go on to try the next entry. So in the case of search lists automatically
generated from a domain entry, if localhost.astrology.cam.ac.uk doesn't
exist, localhost.cam.ac.uk will be tried, and then localhost.ac.uk ...


My advice: forget about localhost entries in your zone files, unless it
concerns a special situation, such as domains that are part of your
search-list.


Ah, but whose search lists? The resolvers using a particular recursive
nameserver may have many different variants.


You may want to consider adding it in such a case (although
I don't do so). But if you do, don't forget to add an -record for
::1 as well ;-)


We used to create lots of localhost.[subdomain].cam.ac.uk records, even
to the extent of adding an  record just for those institutions that
had IPv6 enabled on their networks. But we have pretty much given up doing
that for new subdomains. It still seems to me potentially useful to keep
localhost.cam.ac.uk itself, to terminate the probable iteration described
above before it goes any further.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Converting an inline-signed zone to unsigned

2014-03-06 Thread Chris Thompson

On Feb 19 2014, Alan Clegg wrote:


On 2/19/14, 8:59 PM, Chris Thompson wrote:

What is the right way ... or maybe I should be asking IS there a right
way ... to change a zone that has been signed by inline signing (i.e. with
inline-signing yes; auto-dnssec maintain; in it zone statement) to
unsigned?

When I change the zone statement to remove the inline signing part, and
update the SOA serial in the zone file for good measure, and then do
either rndc reload or rndc reconfig, I get messages like

named[22954]: general: error: zone playground.test/IN:
  journal rollforward failed: journal out of sync with zone
named[22954]: general: error: zone playground.test/IN:
  not loaded due to errors.

and the zone goes into SERVFAIL state.

The only way I found out of this was to remove the [zone-file].signed
and [zone-file].signed.jnl files manually, and *then* do rndc reconfig.
Surely there must be something better than that?



Have you tried setting dnssec-secure-to-insecure then setting all of
the keys to deleted?


Thanks - I have now tried that (set the deletion date to now with
dnssec-settime), and it does work. You end up with a [zone-file].signed
which is not actually signed being served, but being maintained from
[zone-file] in an incremental way.

I suppose this is indeed the way to go with the flow of inline signing.
You don't even have to have any keys for the zone in the key directory
initially. It's the transition between having inline-signing yes and
inline-signing no in the zone definition that seems to expose rough
edge cases. 


I still have to investigate the problem that Graham Clinch reported,
and see whether that might be a show-stopper for the application of
inline signing that I have in mind.

More generally: it's a pity that there isn't any real documentation
of inline signing in the ARM, just the examples in ISC's KB articles.
Some clearer explanation of which options inline-signing yes is
(in)compatible with would be helpful. For example, it obviously turns
on some sort of moral equivalent of ixfr-from-differences yes on
the unsigned version of the zone, but would turning inline signing
on (or off) work better if this were specified explicitly? And the
examples have auto-dnssec maintain, but would auto-dnssec allow
work?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Converting an inline-signed zone to unsigned

2014-03-06 Thread Chris Thompson

On Mar 6 2014, Graham Clinch wrote:




Thanks - I have now tried that (set the deletion date to now with
dnssec-settime), and it does work. You end up with a [zone-file].signed
which is not actually signed being served, but being maintained from
[zone-file] in an incremental way.

I suppose this is indeed the way to go with the flow of inline signing.
You don't even have to have any keys for the zone in the key directory
initially. It's the transition between having inline-signing yes and
inline-signing no in the zone definition that seems to expose rough
edge cases.


Is [zone-file].signed really being maintained?  When I took an unsigned 
zone and enabled inline-signing without generating any keys, the zone 
content became 'frozen in time' until keys were generated (at least with 
versions

'9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu3' 
'9.9.5-2-Ubuntu').

In short, these messages are logged:

info: zone test1.local/IN (unsigned): loaded serial 2014030615
info: zone test1.local/IN (signed): serial 2014030615 (unsigned 2014030615)
error: zone test1.local/IN (signed): could not get zone keys for secure 
dynamic update

error: zone test1.local/IN (signed): receive_secure_serial: not found


Oh, . You are right. Using 9.9.5, I get messages exactly like that
when updating the unsigned zone file while there are no keys. I am not
sure how I previously managed to convince myself otherwise.

I think I am going to have to retreat hurt from this attempt to use
inline signing, and find some other way of achieving what I want.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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


Converting an inline-signed zone to unsigned

2014-02-19 Thread Chris Thompson

What is the right way ... or maybe I should be asking IS there a right
way ... to change a zone that has been signed by inline signing (i.e. with
inline-signing yes; auto-dnssec maintain; in it zone statement) to unsigned?

When I change the zone statement to remove the inline signing part, and
update the SOA serial in the zone file for good measure, and then do
either rndc reload or rndc reconfig, I get messages like

named[22954]: general: error: zone playground.test/IN:
  journal rollforward failed: journal out of sync with zone
named[22954]: general: error: zone playground.test/IN:
  not loaded due to errors.

and the zone goes into SERVFAIL state.

The only way I found out of this was to remove the [zone-file].signed
and [zone-file].signed.jnl files manually, and *then* do rndc reconfig.
Surely there must be something better than that?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: changing NSEC3 salt

2014-02-12 Thread Chris Thompson

On Feb 11 2014, David Newman wrote:

[...]

That's interesting. It seems to contradict Lucas' advice to always use
'1 0 10' for these [NSEC3] flags, as fewer aren't secure enough and more
aren't any more secure.


It's difficult to see how that can make sense. Increasing the number of
iterations simply gives a linear increase in the computational cost of
testing names against NSEC3s (and the same factor in the overheads in
authoritative and validating nameservers, of course).

Moore's law wipes out a factor of 10 before very long ...

It's not often mentioned, incidentally, that using more iterations increases
the probability of a collision. Of course, it's pretty damn small to begin
with, so that doesn't really matter. But the algorithm, described in RFC 5155
section 5, could have been better designed from that point of view.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Case-Insensitive Response Compression May Cause Problems With Mixed-Case Data and Non-Conforming Clients

2014-02-06 Thread Chris Thompson

On Feb 3 2014, Michael McNally wrote:
[...]

The remainder of this posting explains the potential issue,
which we believe will not affect most operators, but you
should be aware of the potential in case you are one of
those affected.  This explanation is also provided in our
Knowledge Base:  https://kb.isc.org/article/AA-01113


I can't help feeling that the title of that article ought to be
Case-Sensitive Response Compression May Cause Problems With
Mixed-Case Data and Non-Conforming Clients (rather than
Case-Insensitive ...), as that is what BIND 9.9.5 etc. do.

There an aspect of this change which may delay the reporting of
any problems that it causes. As long as nearly all authoritative
nameservers use the old (case-insensitive) compression rules,
recursive nameservers will receive and cache RRs with whatever
name casing they were first queried with. So even when they use
the new (case-sensitive) compression rules themselves, they will
only respond to clients with different casing in the question
and answer sections if they have themselves been queried for
the same name with different casings (possibly by different
clients, of course).

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Insecurity proof failed resolving newsletter.postbank.de - but why?

2014-01-20 Thread Chris Thompson

On Jan 20 2014, Graham Clinch wrote:

I'm seeing a dnssec validation error that I can't pin down, for the 
domain: newsletter.postbank.de.


Neither of http://dnsviz.net/ and 
http://dnssec-debugger.verisignlabs.com/ report finding a problem, but 
two (ubuntu packaged) versions of bind report a failure validating the 
delegation as intentionally insecure.


I've tried versions:

BIND 9.9.3-rpz2+rl.13214.22-P2-Ubuntu-1:9.9.3.dfsg.P2-4ubuntu1.1
[...] 

and

BIND 9.8.1-P1 built with '--prefix=/usr' '--mandir=/usr/share/man'

[...]

I can reproduce the effect with BIND 9.9.4, 9.9.4-P2, 9.9,5b1.

I think the problem is as follows. The nameservers for postbank.de
generate a referral for newsletter.postbank.de which includes a
minimally enclosing NSEC3 like this:

o27g5ei98muhh7iemoihmbn83qndjsv1.postbank.de. 3600 IN NSEC3 1 0 1 \
 8BB5BA1AF57572EE O27G5EI98MUHH7IEMOIHMBN83QNDJSV2

The salt is generated dynamically (different each time) and doesn't
match postbank.de's NSEC3PARAM, but that shouldn't matter. What
*does* matter is that the NSEC3 proves that there are no NS
records as well (as no DS ones) for newsletter.postbank.de
(despite the fact that the NS records are included in the referral).
Note the absence of opt-out in the NSEC3.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Sites that points their A Record to localhost

2014-01-14 Thread Chris Thompson as IP Register

On Jan 14 2014, Joseph S D Yao wrote:


On 2014-01-12 10:04, Chris Thompson wrote:

[...]

That would be more plausible if www.p3net.net actually resolved to
something, rather than giving NXDOMAIN ...



How interesting.  From here I see (and saw before I posted):

;; ANSWER SECTION:
www.p3net.net.  0   IN  A   199.101.28.20


I continue to get NXDOMAIN for www.p3net.net from both of
dns1.namesecure.com [205.178.190.56]  dns2.namesecure.com [206.188.198.56].

199.101.28.20 seems to be search.dnsassist.verizon.net. Are you
sure that the nameservers you are using aren't doing friendly
rewriting of NXDOMAIN responses for you?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Sites that points their A Record to localhost

2014-01-12 Thread Chris Thompson

On Jan 11 2014, Joseph S D Yao wrote:

[...snip...]
(2) There is no requirement that a domain name refer to the Web site 
for that domain.  I personally don't like that (for no special reason), 
and neither apparently does the owner of this domain, who forces people 
to go to the trouble of typing in www.p3net.net to get to his or her Web 
site.


That would be more plausible if www.p3net.net actually resolved to
something, rather than giving NXDOMAIN ...

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Serial numbers for inline signing

2013-12-18 Thread Chris Thompson

On Dec 18 2013, Alan Clegg wrote:



On Dec 18, 2013, at 10:17 AM, Thomas Schulz sch...@adi.com wrote:


I have a question about the serial number as modified by inline signing.
I have a static zone, adi.com, that I am setting up for dnssec. I added
   inline-signing yes;
   key-directory dnssec;
   auto-dnssec maintain;
to my named.conf file after generating the keys and then did a rndc restart.
After that I did a
rndc signing -nsec3param 1 0 10 aef7db3a adi.com
to switch to nsec3. Checking the resulting serial number, I find that it is
2013120423. The serial number in the static zone file is 2013120400.
Why did it bump it up to 23? I expected something like 02.


I can't tell you why you got an exact number, but the best rule about this
is don't worry about the signed serial number, as BIND will take care of
it for you.  As long as you continue to increment the static zone serial
number as you always have, the serial in the signed zone will be maintained
correctly.

There are a number of things that are happening all the time with the signed
zone that you are not aware of, for example, re-signing as signatures reach
expiration, re-signing when you change from NSEC to NSEC3, etc.

All of these will keep the signed serial number 'bumping up' even when your
zone isn't changing.


You can look at the sequence of changes to the signed zone by using 


 dig ixfr=2013120400 adi.com @[yourauthserver]

or by applying named-journalprint to the .signed.jnl file, unless the
journal has been pruned as a result of exceeding the max-journal-size
setting. But this won't tell you *when* each increment happened.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: rndc refresh fails for signed zones

2013-12-12 Thread Chris Thompson

On Dec 12 2013, Thomas Schulz wrote:


Sorry for the bad advice.

Am I correct in thinking that in the case of a hidden master and a chain
of slaves, that the first publicly acessable slave would do the signing
and that in any case only one instance of bind should do the signing?


It would be strange to have signing done in more than one place, yes.

The sort of scenario when you want to do signing on a slave is that
in Example 2 in https://kb.isc.org/article/AA-00626/

--
Chris Thompson
Email: c...@cam.ac.uk
___
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)

2013-12-06 Thread Chris Thompson

On Dec 5 2013, Matthew Pounsett wrote:



On 2013-12-05, at 01:37 , Mark Andrews ma...@isc.org wrote:




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


s/for/force/


Always? Regardless of response size?  Interesting.  What's the rationale
for doing it that way?


Just to clarify, RFC 1995 says

| Transport of a query may be by either UDP or TCP.  If an IXFR query
| is via UDP, the IXFR server may attempt to reply using UDP if the
| entire response can be contained in a single DNS packet.  If the UDP
| reply does not fit, the query is responded to with a single SOA
| record of the server's current version to inform the client that a
| TCP query should be initiated.

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.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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


Non-recursive nameserver response to DS request

2013-11-14 Thread Chris Thompson

A user here was confused by the fact that

 dig -t DS cam.ac.uk @authdns0.csx.cam.ac.uk

gives an (authoritative!) nodata response. (Well actually he was using
host rather than dig, but the principle is the same.)

The server is authoritative-only and gives REFUSED when queried about
other zones, so my first thought was that it ought to have deduced
that the DS record for cam.ac.uk lives in ac.uk, and that is not one
of the zones it is authoritative for, and so REFUSED would be the right
response.

If the nameserver is authoritative for both parent and child, and
the DS record for the child is requested, it correctly returns the
one from the parent zone. Well, obviously this must work, as the
situation is common.

So is this a BIND bug? Or is it somehow allowed by small print in
the RFCs somewhere?

[Adding +dnssec provides a response that proves there is no DS
record for cam.ac.uk in the zone cam.ac.uk, which of course is true.]

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: TXT Record Format with multiple records?

2013-10-13 Thread Chris Thompson

On Oct 12 2013, John Levine wrote:


Please forgive my ignorance, and sorry about all the details. I have
not been able to find a detailed specification.


TXT records haven't changed since RFC 1034 and 1035.

You can have multiple strings per record, and multiple records per
name.  At the application level, some applications glom multiple
strings per record together, some treat them separately.  There are a
few obscure designs that combine multiple TXT records at the same
name, but you're unlikely to run into any of them.


If you do use multiple TXT records, rather than multiple strings within
a single record, bear in mind that the order that the user/application
will see them is TAIAP unpredictable. You don't want to end up with

message.example.  TXT  is displayed in the right
message.example.  TXT  only makes sense when it
message.example.  TXT  order!
message.example.  TXT  A paragraph of text that

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Occasional SERVFAILs from dig NS iq.

2013-09-25 Thread Chris Thompson

I have reported this problem to bind9-bugs [ISC bug #34839].

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

___
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


Occasional SERVFAILs from dig NS iq.

2013-09-24 Thread Chris Thompson

I have noticed that I get occasional (fast) SERVFAIL responses from
dig NS iq., e.g.

$ dig ns iq.

;  DiG 9.9.4  ns iq.
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 7919
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;iq.IN  NS

;; Query time: 413 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 24 15:06:55 BST 2013
;; MSG SIZE  rcvd: 31

but that trying again immediately gives the right result:

$ dig ns iq.

;  DiG 9.9.4  ns iq.
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 60361
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 7

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;iq.IN  NS

;; ANSWER SECTION:
iq. 86400   IN  NS  nsp-anycast.cmc.iq.
iq. 86400   IN  NS  sns-pb.isc.org.
iq. 86400   IN  NS  ns1.cmc.iq.
iq. 86400   IN  NS  iq.dns.cocca.org.nz.

;; ADDITIONAL SECTION:
iq.dns.cocca.org.nz.172798  IN  A   203.119.84.235
ns1.cmc.iq. 172798  IN  A   194.117.57.100
sns-pb.isc.org. 74136   IN  A   192.5.4.1
sns-pb.isc.org. 74136   IN  2001:500:2e::1
nsp-anycast.cmc.iq. 172798  IN  A   194.117.58.42
nsp-anycast.cmc.iq. 172798  IN  2001:500:14:8001:ad::42

;; Query time: 33 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Sep 24 15:06:57 BST 2013
;; MSG SIZE  rcvd: 260

The nameserver at 127.0.0.1 is running BIND 9.9.4 (the same effect was
observed with beta and rc versions earlier, and I can provoke it with
9.9.3-P2 on another server as well).

iq is partially signed, in the sense that some of its nameservers
deliver a signed version, and some an unsigned one, but I don't see
how that leads to the effect observed.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Occasional SERVFAILs from dig NS iq.

2013-09-24 Thread Chris Thompson

On Sep 24 2013, Tony Finch wrote:


Chris Thompson c...@cam.ac.uk wrote:


I have noticed that I get occasional (fast) SERVFAIL responses from
dig NS iq., e.g.

iq is partially signed, in the sense that some of its nameservers
deliver a signed version, and some an unsigned one, but I don't see
how that leads to the effect observed.


It seems to happen when named gets a signed NS response then gets NODATA
when it asks for the DNSKEY RRset. If it gets an unsigned NS response it
is happy; if it gets signed NS and DNSKEY responses it is happy.


Yes, that seems to be right. But that's a bug, because absence of DNSKEY
records is not an error unless the zone is in the must-be-signed state.
BIND should go into in that case I must prove the zone not required to
be signed mode (top-down rather than bottom-up).

Quite a number of TLDs have been deploying DNSSEC in the same ultra-cautious
way as iq recently. I am surprised this bug hasn't drawn itself to our
attention before now. It surely can't have been there in the 2010 DURZ era,
when some root zone servers were serving (fake) signed versions and some
unsigned ones.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: nxdomain

2013-08-29 Thread Chris Thompson

On Aug 29 2013, Mark Andrews wrote:


The fix will be to only go onto the next element of the search list
on nxdomain.  Searches really should stop on REFUSED, SERVFAIL,
NOERROR, NOTIMP.


Regardless of the stopping rule, host and nslookup ought to display
the FQDN they are claiming to get (say) an NXDOMAIN for, rather than
the unqualified one. The OP would probably have been a lot less
mystified if the message had been

Host www.undernet.org.my-domain.example not found: 3(NXDOMAIN)

rather than

Host www.undernet.org not found: 3(NXDOMAIN)

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: internal network PTR records, necessary?

2013-08-14 Thread Chris Thompson

On Aug 14 2013, SM wrote:


Hi James,
At 19:06 13-08-2013, James Chase wrote:
I noticed if I do a reverse lookup on an internal IP it seems to 
reference an iana server. Do we have a misconfiguration to be going 
out there for an answer? Could it be that this iana server was not 
responding monday morning?


See RFC 6303 and RFC 6305.


Also see the BIND documentation on automatic empty zones.

In BIND 9.9, empty reverse zones for RFC1918 ranges will be defined
by default. In earlier versions, since  9.6-ESV-R6, 9.7.5 or 9.8.1
respectively, the same will happen only if you include the option
empty-zones-enable yes; explicitly.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: writing .jnl files to another path possible?

2013-07-29 Thread Chris Thompson

On Jul 29 2013, Christoph Anton Mitterer wrote:


Is it possible to have BIND writing the .jnl files from a dynamic update
or that may be created on rndc reload to another place, e.g. when the
zones are in /etc/bind/zones not placing them there but in
e.g. /var/cache/bind/zones...


Sure. Look at the journal option in the zone statement.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Rate-Limit Question

2013-06-14 Thread Chris Thompson

On Jun 14 2013, Evan Hunt wrote:


On Fri, Jun 14, 2013 at 03:36:19PM +0100, Phil Mayers wrote:

It's not built into bind (yet).


Correct.  For the record, it'll be in 9.10.0 by default and 9.9.4 as a
compile-time option (--enable-rrl).


The latter is particularly good news in view of the ESV status of the
BIND 9.9 series.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: New Versions of BIND Are Now Available

2013-05-29 Thread Chris Thompson

On May 29 2013, Michael McNally wrote:


BIND 9.9.3, BIND 9.8.5, and BIND 9.6-ESV-R9 have been released


Before anyone asks why does rndc status show lots more zones after
I upgrade to [any of these versions]?, it's because of this change:

3395.   [protocol]  Add RFC 6598 reverse zones to built in empty zones
   list, 64.100.IN-ADDR.ARPA ... 127.100.IN-ADDR.ARPA.
   [RT #31336]

That doesn't apply if you have automatic empty zones disabled, e.g.
by recursion no in options, of course.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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 9.9.3b2

2013-05-10 Thread Chris Thompson

On May 10 2013, ixlo...@sent.at wrote:


Is there some specific reason you want to test an old, pre-release
version, versus the current RC1 release candidate?


Actually, 9.9.3rc2 is there at ftp://ftp.isc.org/isc/bind/9.9.3rc2
although it doesn't seem to have been announced on bind-announce yet.

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


___
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: resolver, search command....

2013-05-08 Thread Chris Thompson

On May 8 2013, John Williams wrote:


my resolv.conf looks  like

nameserver 10.10.10.10
nameserver 10.10.10.20
search path1.mydomain.com path2.mydomain.com

I would expect if I type the following:

dig myhost

It would search for that host in path1 or path2 listed above.  It does not,
a +trace shows the resolver querying the root servers for myhost.  
So it appears the search command does not work in environment.


[root@server1 # dig myhost +trace

;  DiG 9.8.2rc1-RedHat-9.8.2-0.10.rc1.el6_3.2  myhost +trace
;; global options: +cmd
.98386INNSk.root-servers.net.
.98386INNSm.root-servers.net.
.98386INNSb.root-servers.net.
.98386INNSi.root-servers.net.
.98386INNSe.root-servers.net.
.98386INNSf.root-servers.net.
.98386INNSa.root-servers.net.
.98386INNSd.root-servers.net.
.98386INNSj.root-servers.net.
.98386INNSc.root-servers.net.
.98386INNSg.root-servers.net.
.98386INNSl.root-servers.net.
.98386INNSh.root-servers.net.
;; Received 512 bytes from 10.176.156.20#53(10.16.16.20) in 9 ms


[Presumably 10.16.16.20 is in your resolv.conf, rather than what you
said above.]


^C[root@server1]# vi /etc/resolv.conf ^C


Any idea why?  Thanks in advance...


You are (probably) under two misapprehensions. First, dig does not use
the search path by default - you have to use the +search option for that.
See the man page.

Secondly, +trace always goes to the root nameservers and works its way
down from there. That's what it is intended for - it's not some sort
of debugging option as you seem to think. The only thing it uses the
nameservers specified in resolv.conf, or by an @ option, for is to look
up the nameservers for . to get it started.

It isn't actually useful to combine +trace and +search - dig could start
all over again with the search path(s) added after a negative result,
but it doesn't.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Simple question about zone and CNAME

2013-04-05 Thread Chris Thompson

On Apr 5 2013, John Wobus wrote:


DNAME? runs away, giggling…


Or SRV records.  Surely browsers are adding support
in the next day or two?


Come on, April 1 has been over for too long for this.

Incidentally, we have just been asked for an A record for cam.ac.uk to
duplicate www.cam.ac.uk because, and I quote, all the publicity material
sent out by the nominator [for an award for the web site] gave the URL
as http://cam.ac.uk/ and this has been retweeted around.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: queries aborted due to quota

2013-03-19 Thread Chris Thompson

On Mar 19 2013, Stephen Wood wrote:


We are measuring the performance of our bind9 cache  forward servers.
Under ++ Resolver Statistics ++, we see a high number of queries aborted
due to quota.


These are queries discarded because the limit on outstanding recursive
queries (recursive-clients in options) has been exceeded. You may
need to increase the default of 1000, or there may be some other problem.

Use rndc status and check how the recursive-clients values are
behaving. If the queues are regularly long, snapshot them by using
rndc recursing and see what you can make of the ones that are taking
longest.


I can't find information regarding this number in the documentation.
Overall, the SERVFAIL numbers are low. Are aborted queries simply retried?


When the limit is exceeded, the oldest outstanding query is discarded,
without giving any response to the client. The client may retry, of course.

Note that BIND gives up on recursive queries that have not completed
after 30 seconds, in any case.


Do I need to make any kernel level changes, like allowed sockets or open
files? How do I troubleshoot this message?


If you have to increase recursive-clients a lot, you may also need to
increase  named's -S option, or it may run out of sockets before query
queue slots.

I have to say I am a bit suspicious of your reference to forward servers.
There are all sorts of possible misconfigurations using forwarders that
might provoke problems of this sort.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: a lot of transfer when slave start

2013-03-05 Thread Chris Thompson

On Mar 5 2013, Felix New wrote:


we have one master server and several slave servers with Bind 9.9.2-P1, and
service for about 50K zones.

i shutdown one slave,start it, then a lot of transfer between the slave and
server:

[... snip ...]

the check transfer(maybe this is usefull for consistency) will take a lot
of time, for example several hours. in the meantime, if the master added
new RR and send notify to the slave, the transfer not start(may be added to
the end of transfer queue, new Inconsistency).

Can i skip the check transfer after slave start? if not ,can speed up?


Are you specifying a file value for the zones on the slave server?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: lame-servers: error (FORMERR) resolving [something]

2013-01-15 Thread Chris Thompson

On Jan 14 2013, Shane Kerr wrote:

[...]

You may want to try:

dig +trace www.isc.org


[...]

The next step may be to try:

dig +trace +dnssec www.isc.org


Beware that if you have a dig(1) from BIND 9.9.x, +dnssec has become the
default with +trace. In that case replace the first attempt with

dig +trace +nodnssec www.isc.org

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: set directory for auto key files

2013-01-07 Thread Chris Thompson

On Jan 7 2013, Phil Mayers wrote:

[...]
I've never tried it but there's a journal option on the zone; maybe 
this takes paths, like so:


 zone foo {
   type master;
   # zone lives outside working dir
   file /etc/zones/foo;
   # ...but journal lives inside it
   journal data/journals/foo;
 };

Note: I've never tested this; it is a wild guess.


We have been using it for years - it works fine. We have e.g.

zone cam.ac.uk {
type master;
file master/cam.ac.uk;
journal master-jnl/cam.ac.uk;
...
}
zone 111.131.in-addr.arpa {
type master;
file master/111.131.in-addr.arpa;
journal master-jnl/111.131.in-addr.arpa;
...
}
...
zone cl.cam.ac.uk {
type slave;
file slave/cl.cam.ac.uk;
journal slave-jnl/cl.cam.ac.uk;
...
};
zone 232.128.in-addr.arpa {
type slave;
file slave/232.128.in-addr.arpa;
journal slave-jnl/232.128.in-addr.arpa;
...
};
...

One slight niggling disadvantage is that you can't tell
named-checkzone / named-compilezone with the -j option where
to find the journal is it isn't in the default location.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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


Noisy messages from BIND about root hints change

2013-01-07 Thread Chris Thompson

One (but only one) of our recursive nameservers, running BIND 9.8.3-P4
we got a whole lot of messages in the log as a result of last week's change
of address for d.root-servers.net:

Jan  4 06:24:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
Jan  4 06:24:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints
Jan  4 06:24:09 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
Jan  4 06:24:09 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints

[... 1972 pairs of messages omitted ...]

Jan  4 08:50:05 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
Jan  4 08:50:05 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints
Jan  4 08:50:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (128.8.10.90) missing from hints
Jan  4 08:50:08 recdns1.csx.cam.ac.uk named[9496]: general: warning:
  checkhints: d.root-servers.net/A (199.7.91.13) extra record in hints

And then they stopped.

Now I can more or less work out what provoked the first message. We had
already changed our root hints file the previous day (and done an rndc
reconfig) but the old A record for d.root-servers.net was still in the
cache (and was still there much later on 4 January as I explicitly did
an rndc flushname on it for other reasons). One of our regular checking
jobs at 06:24 will have used this recursive nameserver to look up the
NS records for . and the address records for the *.root-servers.net
names so referenced.

But why did it keep going on and on about it? And what made it stop?
Has anyone else seen anything similar?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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 and DNSSEC

2012-11-01 Thread Chris Thompson

On Nov 1 2012, Jan-Piet Mens wrote:


I do as well, and this will be documented in the next version of
this document.


I believe you've mentioned that here before. Several times. Today. ;-)


 What I tell you three times is true.”

 The Bellman, pp Lewis Carroll

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Delegations

2012-10-31 Thread Chris Thompson

On Oct 31 2012, Phil Mayers wrote:


On 10/31/2012 06:51 PM, Doug Barton wrote:


It may or may not be strictly necessary to do this depending on
everything else you have in the zone, but it's safer in the long term to
do it this way.


Are you suggesting it's best of the OP creates l2.example.com as a 
sub-zone?


Why it this necessary / safer?


It certainly isn't necessary. We have plenty of zone cuts more than one
label deep into the parent zone. And of course such delegations are
*extremely* common in the reverse lookup trees, with the IPv6 one
probably providing records for the number of labels between cuts.

I don't see how safer would apply, either.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Delegations

2012-10-31 Thread Chris Thompson

On Oct 31 2012, Kevin Darcy wrote:

[...snip...]

I know of at least 2 commerically-available DNS maintenance systems
that, by default, do not allow what they call dotted hostnames, by
which they mean a name which is at least 2 labels below a zone cut, e.g.
foo.bar in the example.com zone. Their underlying assumption seems
to be that *every* level of the hierarchy will, in the
usual/typical/default case, be delegated.

I don't agree with this assumption in the slightest, but some people are
afraid of changing default behaviors...


What default behavior? The default behavior of (seriously) defective
DNS maintenance systems? (You wouldn't like to name-and-shame, I suppose?)

The end-point of that sort of logic is that, for example, the SRV record
for _someservice._tcp.somename.example.com has to have separate zones
for somename.example.com and _tcp.somename.example.com, probably
containing nothing but the names mentioned.  I've seen people actually
do this, and it's painful to watch.

We were never in that mess as regards the DNS itself, but we did have
an IP registration database that delegated control over names on the basis
of a domain part taken to be all but the first label. It was hard work
to change it to allow the domain part for authorisation purposes to be
any trailing set of labels, but by ${DEITY?} it was necessary!

--
Chris Thompson
Email: c...@cam.ac.uk
___
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


Using BIND-DLZ for a hidden master [was: Re: dns master-slave transfer]

2012-10-31 Thread Chris Thompson

On Oct 29 2012, Feng He wrote:


于 2012-10-29 9:58, kavin 写道:

Now,I want transfer the zone data from the master dns serverto slave
dns server ,the master dns use bind-dlz+mysql and the slave dns server
use bind+file.


AFAIK, BIND DLZ doesn't send a notify message to slave, so both your
master and slave should be able to use the DLZ backend and run a mysql
replication for data sync.


That exchange prompts me to ask whether anyone has managed to use
BIND-DLZ in something like the following scenario.

We have a hidden master for vanity zones (we call them something else
for the punters) that runs in a small footprint virtual machine
together with the web server providing the updating interface. The
latter stores the data in a MySQL database.

At the moment there is a crontab that extracts data from that database
and updates zone files (if they need changing - there are some neat-o
optimisations) and does an rndc reload on the hidden master daemon.
That NOTIFYs the public nameservers for the zones, which are are in fact
our regular authoritative-only ones.

It seems that one ought to be able to use BIND-DLZ to cut out a step
there, but none of the how-to's for it seem to address this sort of
scenario, and the NOTIFY issue is particularly relevant. Fast responses
from the hidden master to queries are certainly *not* a requirement here,
and indeed we expect to be able to operate with it (and its MySQL database)
down for significant periods.

On the other hand, there is also a possibility that we might want to sign
the vanity zones (we use JANET, Nominet and Gandi for their registrations,
who all support signed delegations now), and how that would interact with
BIND-DLZ might also be an issue. Can one use BIND 9.9 inline signing
with the unsigned version provided by a DLZ interface?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Disable log message

2012-10-21 Thread Chris Thompson

On Oct 20 2012, David Miller wrote:

[...]

Does this log message provide any information that the -V option doesn't
provide?


Given the number of times that problems brought up on this list turn out
to be due to people not actually running the named binary they thought
they were running, the more that the actually executing named says about
itself, the better.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Disable log message

2012-10-18 Thread Chris Thompson

On Oct 18 2012, Jeremy C. Reed wrote:


On Thu, 18 Oct 2012, Jack Tavares wrote:


I  am running bind9.8.x built from source and I see this message in the logs
built with '--prefix=/blah' '--sbindir=/blah' '--sysconfdir=/blah' '--localstatedir=/var' '--exec-prefix=/usr' '--libdir=/usr/lib' '--mandir=/usr/share/man' '--with-openssl=/blah' '--enable-fixed-rrset' '--enable-shared' '--enable-threads' '--enable-ipv6' '--with-libtool'  etc etc etc 


I would prefer to not have that show up in the log.

Short of modifying the source, is there an easy way to disable that?


No way to disable just it. It is in the general catch-all category.


Also, it is output before the configuration logging directives have been
processed, so it comes out with the internal defaults for category and
priority (daemon.notice). Any suppression would need to be done at the
syslog level.

But I have some difficulty understanding why anyone would want it suppressed.
It's true that BIND is a bit noisier than it used to be at this stage, but
can this really be a problem? Do you let the black hats see your system logs?

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: about the wild record

2012-10-15 Thread Chris Thompson

On Oct 15 2012, pa...@riseup.net wrote:


no SOA for test.cloudns.tk IMO. see:

PromatoMacBook-Pro:~ pro$ dig test.cloudns.tk soa

;  DiG 9.7.6-P1  test.cloudns.tk soa
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 60320
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;test.cloudns.tk.   IN  SOA

;; AUTHORITY SECTION:
cloudns.tk. 300 IN  SOA ns0.cloudwebdns.com. 
support.cloudwebdns.com. 1048
7200 1800 604800 300

;; Query time: 860 msec
;; SERVER: 211.136.192.6#53(211.136.192.6)
;; WHEN: Mon Oct 15 21:13:04 2012
;; MSG SIZE  rcvd: 96


The SOA is presented in AUTHORITY SECTION, not in ANSWER SECTION, so it's
meaningless.


Indeed, Warren's use of +nostats +ncomments to conceal that was
disingenuous, to say the least.

But you should notice that the above response - rcode NOERROR with
an empty data section - is what RFC 2308 calls NODATA, and not an
NXDOMAIN. This is because test.cloudns.tk is an empty non-terminal
in the name tree within the zone, and it is that which prevents
*.cloudns.tk from applying to anything under it.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: error (unexpected RCODE REFUSED) resolving

2012-10-12 Thread Chris Thompson

On Oct 12 2012, Kevin Darcy wrote:

OK, so your nbc.com/A resolving error doesn't really have anything to do 
with the nameservers you included in your original post.


It does appear, however, that ns2.netbcp.net (205.173.93.213) is 
refusing requests generally for the nbc.com domain:


And so is ns1.netbcp.com [205.173.95.216]. The ultradns servers are
behaving more sensibly. The SOA.mname is ns.ge.com [156.154.67.6],
a hidden[*] master which also gives sensible and authoritative answers.

[*] not *very* hidden :-)

Incidentally, I get a SIGSEGV when going host -C nbc.com, which does
seem to happen when the nameservers for a zone behave abnormally. This
time I have got around to reporting it to bind9-bugs.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Listen-on per view?

2012-08-11 Thread Chris Thompson

On Aug 11 2012, sasa sasa wrote:


Is it possible to tell each view to listen on certain interfaces?
I know Listen-on is in general options so i was wondering if views
have something similar.


You should use match-destinations in the view definition. (The match
is on the destination of the query, i.e. on which of the the nameservers's
own addresses it arrived on.)

Thinking in terms of listen-on was a category error. Views don't
have separate listening apparatus. Instead the queries that come
in are farmed out to the views on the basis of their matching
conditions.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Journal File Question

2012-07-25 Thread Chris Thompson

On Jul 25 2012, wbr...@e1b.org wrote:


Chris Buxton chris.p.bux...@gmail.com wrote on 07/25/2012 12:07:22 PM:

 It doesn't sync the files to make two equal copies. It applies all of 
the 
 outstanding transactions in the journal file to the zone file and then 



 empties the journal.

I don't believe that is entirely correct. The journal file needs to 
be retained to support ixfrs. My understanding is that it will be 
automatically trimmed to max-journal-size, if that option is set.


Do you know how it determines what is kept?


When the journal file reaches the max-journal-size value, roughly the
first half of it is discarded. But there are other actions that can
discard the whole journal file, such as rndc freeze on a type master
zone, rndc retransfer on a type slave one, etc.

To find out if a journal file goes back far enough for your purposes,
use the named-journalprint utility distributed with BIND. Although I
have to say I would hate to be dependent on this way of recovering a
lost zone file: you should probably be rethinking your whole backup
and recovery strategy.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: rndc stats command

2012-07-18 Thread Chris Thompson

On Jul 18 2012, Ben wrote:


Hi,

As per man page and my understanding rndc stats writes a current named 
statistics into defined file in named.conf


so suppose, if i run rndc stats command and then i take required 
information from named statistics file.


And after some time, ( after 5 minutes or approx.) when i do again rndc 
stats , so that times it provides new statistics.?


My understanding is that while running rndc stats , it writes current 
named statistics to defined file and internally it flush named 
statistics ( which wrote into file as per named.conf )


And while second time run same command , again it append fresh/new named 
statistics to defined fiel, is it so?


Or is there any interval for rndc / named to generate fresh/new statistics.?

Kindly correct me if I am missing something...


I think you are missing at least the following:

rndc stats *appends* to the statistics file. It doesn't overwrite
any previous contents.

rndc stats does not reset the internal statistics counters (I take
it that was what you meant by flush). They are always accumulative
from when named was last started.


From two successive set of ststistics written by rndc stats, you

can deduce what happened during the interval by taking the difference
in the values of corresponding counters, and to deduce rates you
divide by the length of the interval which you can deduce from
the difference in their timestamps

+++ Statistics Dump +++ (1342566900)
...
--- Statistics Dump --- (1342566900)
 ^^
which are in time_t format (seconds since the Unix epoch).

[What's annoyingly missing, by the way, is the time when named was
in fact started. That's present in the XML on the statistics channel,
but not in the file written by rndc stats.]

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: check-names via command line

2012-07-11 Thread Chris Thompson

On Jul 10 2012, Evan Hunt wrote:


Well, I have to take that back. As far as I can see the -k option of
named-checkzone has no effect at all, despite the man page, at least
with BIND 9.8.3-P1.

Thank you. Maybe this will be fixed?

It would be great to have named-checkzone be an authoritative tool as 
far as zone: Syntax, rules and other error checking goes.


It works for me.  What errors are you trying to check for that
named-checkzone -k isn't finding?


Well, it worked for me once I did the tests with the right zone file
(and remembered that check-names doesn't check CNAME labels) ... :-(
Apologies for the FUD.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: check-names via command line

2012-07-10 Thread Chris Thompson

On Jul 10 2012, Gary Wallis wrote:

Is there a way to check names via the command line (like with a 
named-checkzone type tool.)


I need to validate zone info BEFORE trying to load, log frag:

10-Jul-2012 11:36:02.199 general: zone growXeg.com/IN/external: loading 
master file master/external/g/growXeg.com: bad name (check-names)
10-Jul-2012 11:38:01.815 general: dns_rdata_fromtext: 
master/external/g/growXeg.com:3: near 'uk.hostmas...@telxxity.com.': bad 
name (check-names)


(X added for some privacy.)


Check out the -k option of named-checkzone. It defaults to warn anyway,
but you may want to use fail.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: check-names via command line

2012-07-10 Thread Chris Thompson

On Jul 10 2012, I wrote:


On Jul 10 2012, Gary Wallis wrote:

Is there a way to check names via the command line (like with a 
named-checkzone type tool.)

[...]

Check out the -k option of named-checkzone. It defaults to warn anyway,
but you may want to use fail.


Well, I have to take that back. As far as I can see the -k option of
named-checkzone has no effect at all, despite the man page, at least
with BIND 9.8.3-P1.

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

___
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: Recommended value for max-cache-size for cache-only shared hosts..

2012-06-01 Thread Chris Thompson

On Jun 1 2012, Michael Graff wrote:


[...] The default of 32 MB is actually a fairly new thing.


Surely the default went back to 0 (effectively unlimited) long ago?

2253.   [func]  max-cache-size defaults to 32M.
   max-acache-size defaults to 16M.

got into BIND 9.5.0, but

2457.   [tuning]max-cache-size is reverted to 0, the previous
   default.  It should be safe because expired cache
   entries are also purged. [RT #18684]

was there before 9.5.1, and AFAICS it has been like that ever since.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Checking for zone expiration?

2012-05-21 Thread Chris Thompson

On May 21 2012, Alan Batie wrote:


We had a rather key zone mysteriously expire on a slave this morning -
the log files show a transfer a couple weeks ago, but it hadn't been
updated so there was no reason for one since and there were no log
entries about failed connection attempts.


Do you have try-tcp-refresh no in your named.conf options? If so,
and the slave had lost connectivity with the master, the SOA lookups
failing would not have triggered a transfer attempt and so you would
not see any xfer-in errors.


I was wondering if there's a
way to check the remaining time on a zone for monitoring?  If you fetch
the SOA, you get the full ttl, for obvious reasons, not the server's
timer...


As Barry Margolin posted, check the mtime on the slave's zone file,
as BIND updates this each time it determines a new zone transfer is
not required.

Often, a good check for there being any zones verging towards
expiring is to look at the end of an ls -ltr listing of the
directory in which zone files are stored. For automation, use
something like find [directory] -name [pattern] -mtime +3.
This works better if the files for type slave zones are kept
in a separate directory (or directories) from the type master
ones, if any.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Interaction of -S and recursive-clients?

2012-05-18 Thread Chris Thompson

On May 17 2012, Daniel Deighton wrote:


On 05/17/2012 12:20 PM, Chris Thompson wrote:

[... snip ...]

named: general: error: socket: file descriptor exceeds limit (4096/4096)
last message repeated 1194 times
named: general: error: socket: file descriptor exceeds limit (4096/4096)
last message repeated 780 times

[... snip...]


It looks like you are reaching an OS limit for open files. On linux, you
can check this with 'ulimit -n'. Determining the limit will vary for
other operating systems. On what OS are you running BIND?


It is Solaris 10_x86, but I don't think it is an OS-mediated resource limit
at all. named increases all those limits to unlimited when it starts up,
and plimit(1) applied to the running process confirms that. This is a limit
being imposed by named itself. When it starts up it announces

named: [ID 873579 daemon.info] using up to 4096 sockets

which I take to be the same self-imposed limit, changed only via -S, as
that message occurs just *before*

named: [ID 873579 daemon.info] loading configuration from {pathname}

--
Chris Thompson
Email: c...@cam.ac.uk
___
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


Interaction of -S and recursive-clients?

2012-05-17 Thread Chris Thompson

Our local university-wide recursive nameservers have

 options { /* ... */
  recursive-clients 5000;
  }

This is meant to be reached only at very bad times indeed. During a recent
network partition incident, I noticed that named logged

named: general: error: socket: file descriptor exceeds limit (4096/4096)
last message repeated 1194 times
named: general: error: socket: file descriptor exceeds limit (4096/4096)
last message repeated 780 times

a few seconds before it started on

named: client: warning: client 131.111.***.***#*: recursive-clients
  soft limit exceeded (4901/4900/5000), aborting oldest query

As far as I can see, the only way to increase the socket limit is to use
-S in the named argument list. Should one always set this (at least as)
high as the recursive-clients setting? (Actually, I am more tempted to
try decreasing recursive-clients from 5000 to 4000 as these numbers are
reached only when the network has gone pear-shaped anyway.)

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: records via GENERATE

2012-05-14 Thread Chris Thompson

On May 14 2012, hugo hugoo wrote:


Is there a difference between the configuration of a set of A records using:

1) GENERATE command like:   $GENERATE 0-255 $-1.2.3  A3.2.1.$
2) Defining all the records one by one.

- difference in the amount of memory used?
- difference in the speed to retrive the answer.

If GENERATE command is used  == is the answer calculated at the query
incoming or are all the records already present in memory?


The in-store representation of the zone is entirely the same (and hence
the memory usage and access speed). The macro-generation occurs while the
zone file is being read, at startup or after e,g, an rndc reload [zone].
	   		  
--

Chris Thompson
Email: c...@cam.ac.uk
___
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: Configuring CNAME for nosslsearch.google.com

2012-05-08 Thread Chris Thompson

On May 8 2012, Barry Margolin wrote:


In article mailman.713.1336489020.63724.bind-us...@lists.isc.org,
Tobias Krais tux-s...@design-to-use.de wrote:


Hi Phil,

 4. Create a zone for www.google.com and instead of CNAME, put an A
 record at the apex with the same IP as nosslsearch.google.com. Run a
 script FREQUENTLY to re-resolve the host, as Google do short-TTL
 DNS-based loadbalancing.

For unbound has no solution Inow want to try your suggestion no. 4. My
db file now looks like this:
-%-
@   IN  SOA localhost   root@localhost. (
2012041100
7200
1800
1209600
300 )
IN  A   216.239.32.20 #nosslsearch.google.com.
-%-

But this does not work. Can you tell me whats wrong?

Greetings,

Tobias


# isn't the comment character in DNS zond files, ; is.


Also, you need at least one NS record (maybe for localhost.).
named-checkzone would have told you about both these problems.

Less serious problems:

It's better to use a $TTL directive than rely on it defaulting to
the SOA.MINTTL value (or specify all TTLs explicltly).

You probably meant root.localhost. for the SOA.rname.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Secondary Zone 'Raw' File format

2012-05-04 Thread Chris Thompson

On May 4 2012, Evan Hunt wrote:


A new option was added in 9.9 to cache slave zones in 'raw' format rather
than text format.


That's actually always been an option (masterfile-format raw;)


Well, if always is taken to mean since BIND 9.4 :-)


and is
recommended for servers with a lot of slave zones because it reduces
startup time considerably--it takes about half as long to load a zone
if you don't need to parse text.

What changed in 9.9 is that it's now the default behavior, and you have
to specify masterfile-format text; if you want to save a slave zone in
text format.


Is there any specific documentation on what the format of this 'raw' format
actually is?


It's just DNS wire format, not much different from what you'd see if
you ran a sniffer during a zone transfer.  You can convert it to text
format to see what's in the file with:

   named-checkzone -D -f raw zonename filename


The other things that changed in BIND 9.9 is that there is a new version
of the raw format (as in -F raw=1 versus -F raw=0 in named-checkzone,
q.v. its man page). What was the motivation for that change?

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Exclude a domain from DNSSEC validation, like Unbound's domain-insecure.

2012-04-30 Thread Chris Thompson

On Apr 30 2012, Warren Kumari wrote:


On Apr 26, 2012, at 2:51 PM, Jan-Piet Mens wrote:

[...]

From a Comcast talk at SATIN 2012 I believe they called that a negative
trust anchor, and IIRC, the author wanted to publish a draft of its
operation. Haven't seen it yet though, and it's probably off topic as
regards BIND.


http://tools.ietf.org/html/draft-livingood-negative-trust-anchors-01

Being actively discussed on DNSOP list  


It *was* being actively discussed there, up until about 10 days ago. Since
then the participants seem to have stopped, maybe from sheer exhaustion, as
it was pretty clear that there were irreconcilable opinions on the subject.

It may be worth noting in the bind-users context that ISC's [quick check -
what is he these days - ah yes...] Chairman  Chief Scientist expressed
fairly, well, negative opinions about negative trust anchors, which maybe
does not bode well for them ever appearing in BIND.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Exercising RFC 5011 rollovers

2012-04-21 Thread Chris Thompson

On Mar 8 2012, I wrote:

[...]

One experiment I have been doing is to see whether a rollover done
as described in https://www.iana.org/dnssec/icann-dps.txt (which is
only approximately RFC 5011-like) would cause BIND's managed-keys to
do the hoped-for thing or not. That isn't complete yet - I will report
on the results in due course.


The answer is (as one might expect) that it only approximately does
the hoped-for thing ... :-)

Refer to Figure 2 in section 6.6 of the IANA document.

Assume one starts off with a managed-keys entry for KSK(n) and that
there are no compromised keys. During time slots 2-6 (a 50-day
period) KSK(n) and KSK(n+1) are published, signed with KSK(n).
BIND starts the 30-day add hold-down time for KSK(n+1) the first
time it sees this, and after that trusts both KSKs.

[If the BIND instance has been offline for a while and its 30 days
has not yet elapsed by the end of slot 6, BIND will not yet trust
KSK(n+1) and SERVFAILs result thereafter. But only until the BIND
instance is restarted, because of the bug(?) I described in the
previous posting.]

During time slot 7, KSK(n) and KSK(n+1) are published signed with
KSK(n+1), and BIND is happy with that.

During time slot 8, KSK(n) is published as revoked, but the keyset
is signed only by KSK(n+1). BIND doesn't like that, reporting

general: warning: managed-keys-zone ./IN: Active key for zone
  '[test-zone]' is revoked but did not self-sign; ignoring.


From time slot 9 onwards, KSK(n) is removed from the published

keyset. As BIND still has both KSK(n) and KSK(n+1) as valid trust
anchors, never properly revoked, it unhappily keeps reporting that
KSK(n) has unexpectedly disappeared.

I cannot fault BIND's implementation of RFC 5011 here.

The end result is half-satisfactory in that BIND now trusts the
new KSK(n+1) and is validating successfully. But it also still
trusts KSK(n), and complains about its absence, until one
intervenes manually. Which, incidentally, isn't particularly
easy to do except by e.g. stopping the BIND instance, editing
its managed-keys.bind file to remove the noxious entry, and
then restarting it.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: www.glb.hud.gov

2012-04-19 Thread Chris Thompson

On Apr 19 2012, Richard Laager wrote:


Are others timing out trying to resolve www.glb.hud.gov? This seems
(though I haven't done extensive testing) to only happen to me with
BIND.

http://dnsviz.net/d/www.glb.hud.gov/dnssec/ shows a couple of DNSKEY
warnings, so maybe that's it. I always suspect DNSSEC when I have
problems with .gov domains, but I commented out dnssec-enable yes in
my named.conf and it didn't help.


There is no DS record in the parent zone, so the zone contents could
not be validated anyway.

The main problem seems to be that the nameservers for glb.hud.gov
never respond to requests for its DNSKEY records (even if EDNS is
turned off in the query). They also don't respond to queries over
TCP about anything.

Specifying dnssec-enable no doesn't stop BIND setting the DO bit
on the queries it sends out. However, if validation is off, I am
not sure why it would be bothering to (try to) fetch the DNSKEY
records.

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: How to reset the serial number?

2012-03-27 Thread Chris Thompson

On Mar 27 2012, wbr...@e1b.org wrote:


Chuck Swiger wrote on 03/26/2012 02:35:24 PM:


Shut down the slave server(s).
Use scp or rsync to copy over the zone file, one with a corrected serial 

#.

Restart the slave server(s).


If I have access to the slave, I just deleted slave zone and issue rndc 
reload.  It will transfer the missing zone.


Several advantages:

No need to shut down slave.
Less typing/less chance to mis-type something.


If you have control over all the slaves, then using rnds retransfer [zone]
on them for each zone with serial number trouble is easier still.

If you don't have such control, you are more or less stuck with using
serial number wrapround in the style of RFC 1982. Even if you do that
right, you may find DNS server implementations on the slaves that don't.
As we discovered in September 2009, when we did the last stage of wrapping
our serials round from MMDDNN style to seconds-since-1970, the
stealth-slaving Windows DNS servers of that time (even the 2008
ilk) just could not cope, and went into a tizzy continuously trying
to fetch the zones and then rejecting them for their smaller serials.

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: How to reset the serial number?

2012-03-27 Thread Chris Thompson

On Mar 27 2012, wbr...@e1b.org wrote:


Chuck Swiger wrote on 03/26/2012 02:35:24 PM:


Shut down the slave server(s).
Use scp or rsync to copy over the zone file, one with a corrected serial 

#.

Restart the slave server(s).


If I have access to the slave, I just deleted slave zone and issue rndc 
reload.  It will transfer the missing zone.


Assuming you mean delete the slave zone *file*, this doesn't actually
work (unless you restart BIND as well). Tested with 9.8.2rc2, but it
seemed innately unlikely. Why would BIND on the slave ever look at the
file contents except on startup?

Or did you mean something like (1) remove the zone from the slave's
configuration and rndc reconfig (reload is overkill) (2) delete the
slave zone file (3) add the zone to the slave's configuration again
and rndc reconfig ?

That would work, but rndc retransfer [zone] is a lot simpler! 


--
Chris Thompson
Email: c...@cam.ac.uk
___
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: rndc reconfig vs. rndc reload

2012-03-22 Thread Chris Thompson

On Mar 16 2012, Mark Pettit wrote:

[...]

We have an antiquated push process that copies files into the zonefile
directory and then tells BIND rndc reload.  For various reasons,
rndc reload takes about 120 seconds to complete.  BIND is not answering
queries for a very large part of that time.


It may be worth noting that recent versions of BIND (at least) only re-read
the zone files whose modification times have changed, on an rndc reload.
It does still have to stat() them all, though, which could be bad enough.


I recently started experimenting with a different process: instead of
rndc reload after updaing some of the zone files, I loop through the
list of updated zone files and run rndc reload zone for each one.


This is better, of course, if you can do it.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: NS record for subzone definition

2012-03-13 Thread Chris Thompson

On Mar 13 2012, hugo hugoo wrote:


Thanks for this clear feedback.

I understand the problem if the subdomain is not on the same name servers
as the domain. The NS record is needed to could find the subdomain on the
other name server.

You said that the NS is not mandatory (it will work fine in the short term)
in case of the same name server for the domai nand the subdomain. But how
does it work then if no NS is found?


When asked about tutu.titi.toto.be, the be nameservers give a referral
to the nameservers for toto.be. When *they* are asked, if they are already
authoritative for the zone titi.toto.be, they can answer the question
without giving another referral.

But as has been pointed out, such a configuration is horribly fragile. The
set of nameservers (official *and* unofficial) for the zones have to be
the same, and it won't work anyway if the zones are signed, and so on.

One question to ask is: if the set of nameservers for toto.be and
titi.toto.be are now and for evermore going to be the same, why would
you want to make them separate zones at all? A single zone can have
domain names nested as deep as you like[*] without you needing to make
a zone cut.

[*] subject to the overall limit of 253 characters on the fully
   qualified name

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Exercising RFC 5011 rollovers

2012-03-08 Thread Chris Thompson

Continuing a thread from November  January (these experiments do
take a long time, absent a fake clock)...

One experiment I have been doing is to see whether a rollover done
as described in https://www.iana.org/dnssec/icann-dps.txt (which is
only approximately RFC 5011-like) would cause BIND's managed-keys to
do the hoped-for thing or not. That isn't complete yet - I will report
on the results in due course.

However, I have found one oddity/bug/whatever. I had one testing BIND
instance offline for a while so that it had not yet seen new-KSK for
30 days when the test zone transitioned

 from  (old-KSK,new-KSK,ZSK)-signed-with-old-KSK
   to  (old-KSK,new-KSK,ZSK)-signed-with-new-KSK

At that point it correctly started giving SERVFAILs for the test zone.
However, the entry in managed-keys.bind for new-KSK kept the same
(time-first-seen)+30days value for when it was going to start trusting
it. Even when this time arrived, it didn't start trusting new-KSK, as
I think BIND was acting on this from the RFC

  Once the timer expires, the new key will be added as a trust anchor
  the next time the validated RRSet with the new key is seen at the
  resolver.

(Emphasis on next time and validated!)

But now I restarted the BIND instance. It sees in managed-keys.bind that
the time it was going to start trusting new-KSK has passed, so it thinks
it must be OK now. It adds it to the trust anchors (e.g. as seen by
rndc secroots) and the SERVFAILs no longer occur.

I think this may indicate that the data structure in managed-keys.bind
cannot quite capture all the complexities of RFC 5011.

The BIND version used in the later part of this experiment was (early-access)
9.8.2rc2 but I doubt that is particularly significant.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: fermat primes and dnssec-keygen bug?

2012-03-07 Thread Chris Thompson

On Mar 6 2012, Paul Wouters wrote:


See part of the dicsussion Miek and I had at the golang group:

http://code.google.com/p/go/issues/detail?can=2start=0num=100q=colspec=ID%20Status%20Stars%20Priority%20Owner%20Reporter%20Summarygroupby=sort=id=3161

The bug seems to be that dnssec-keygen upgraded the fermat prime that
is used per default from F0 to F4, but did not change that -e would
get you the next fermat number.


This is wrong (although I have seen the same thing stated in a number
of other places). When the default public exponent was changed from
3 to 2^16+1 (change 2088) the one selected by -e was changed from
2^16+1 to 2^30+3 ... *not* 2^32+1. And so it remains today.

As it happens, 2^30+3 is prime while of course 2^32+1 is not, although
that isn't really an issue.

I believe that the DNSKEY records (e.g. in a few TLDs) that do use
2^32+1 as the public exponent come from HSMs, not from dnssec-keygen.

In any case, there is no bug involved in any of this, other than
in validating code that cannot cope with large exponents.


  The result is that people who upgrade
bind and don't notice this changed behaviour are not changing their
scripts that explicitely use -e.

I would recommend that dnssec-keygen starts ignoring the -e parameter
that everyone has put in their scripts to prevent exponent 3 keys, who
are not getting keys with exponent 4294967296 + 1 (F5)

Alternatively, if this is done on purpose, I guess we should all
migrate the 64 bit machines :)

You can detect these starts, as they start with BQE


And you will find that the ones generated by dnssec-keygen -e start
BE...

My personal opinion is that we should stop worrying about people
using buggy pre-2006 versions of OpenSSL and go back to using RSA
public exponents of 3 again most of the time. I notice that this
is what VeriSign do for the DNSKEY records in com, net  edu.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: fermat primes and dnssec-keygen bug?

2012-03-07 Thread Chris Thompson

On Mar 7 2012, Bill Owens wrote:


On Wed, Mar 07, 2012 at 12:13:35PM +, Chris Thompson wrote:

This is wrong (although I have seen the same thing stated in a number
of other places). When the default public exponent was changed from
3 to 2^16+1 (change 2088) the one selected by -e was changed from
2^16+1 to 2^30+3 ... *not* 2^32+1. And so it remains today.


...


And you will find that the ones generated by dnssec-keygen -e start
BE...


Umm, no:

[littledebian:~/dns] owens% dnssec-keygen -e example.com
Generating key pair++ .++ 
Kexample.com.+005+43304

[littledebian:~/dns] owens% cat Kexample.com.+005+43304.key
; This is a zone-signing key, keyid 43304, for example.com.
; Created: 20120307140855 (Wed Mar  7 09:08:55 2012)
; Publish: 20120307140855 (Wed Mar  7 09:08:55 2012)
; Activate: 20120307140855 (Wed Mar  7 09:08:55 2012)
example.com. IN DNSKEY 256 3 5 
BQEBw3A8Wji6BjyanbOXUtIH1UcroHZKh06qRKXASbxHAQHJogaw 
6m2wYX77KvtzVSto/nbHXM/53Vbu/Ar8CAXC/+r/R5BOHw73qA12LqXr 
7utMeLmBPjq4RUqluurlVTHt5/FD85tr0yr8mu7h39gVmMY0bnRpgx6p aj2zjpv3O3U=

The code definitely uses 2^32+1:

[littledebian:bind-9.9.0/lib/dns] owens% grep -A 3 -B 5 F5 opensslrsa_link.c
if (exp == 0) {
/* RSA_F4 0x10001 */
BN_set_bit(e, 0);
BN_set_bit(e, 16);
} else {
/* F5 0x10001 */
BN_set_bit(e, 0);
BN_set_bit(e, 32);
}


Oh, damn. I have to retract. Or indeed, grovel. It all depends on which
version of OpenSSL it is linked with, not on the code in dnssec-keygen
itself. Older versions do indeed generate 2^30+3, but newer ones 2^32+1.

You can see the BE (2^30+3) ones in the DNSKEYs for dlv.isc.org as
well as in a number of our own zones (which says either that the keys
are oldish or that the versions of OpenSSL used are not as up to date
as they probably ought to be).

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: fermat primes and dnssec-keygen bug?

2012-03-07 Thread Chris Thompson

On Mar 7 2012, Bill Owens wrote:

[...]

As Miek discovered, the hard way, .us also uses 2^32+1; my list didn't
include TLDs so there may be others. I'll do another run over lunch today. . .


Based on a scan I did yesterday:

 All DNSKEYs in all TLDs use an RSA public exponent of 2^16+1 except for
 the following:

 com, net  edu  use 3 for all DNSKEYs
 gov uses 3 for its KSK and active ZSKs, 232+1 for an idle ZSK
 cz  uses 2^16+1 for its KSK, 2^32+1 for its ZSK
 la my  us  use 2^32+1 for all DNSKEYs

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: RFC 6303 and bind 9.9.0

2012-03-01 Thread Chris Thompson

On Mar 1 2012, Spain, Dr. Jeffry A. wrote:

[...]

Also I see that bind 9.9.0 uses built-in root hints if those are not
explicitly configured.


That has been true since BIND 9.2.


If the root hints are updated on ftp://rs.internic.net/domain/, would it
require a new build of bind to incorporate them, or is bind able to update
its built-in root hints by some other means?


No, it requires a rebuild after changing lib/dns/rootns.c. But using a
mildly out-of-date hints file is usually harmless - it is only a *hint*.

[Having said that, I admit I specify an explicit root hints file and
keep it up to date in most of my own nameserver configurations.]

--
Chris Thompson
Email: c...@cam.ac.uk
___
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 issue with bind

2012-02-16 Thread Chris Thompson

On Feb 16 2012, Phil Mayers wrote:


On 02/16/2012 09:48 AM, Raven wrote:

Hi guys.
I am currently trying to setup query logging with bind on a debian
server, but I seem unable to.
I have the exact same setup on another debian box and it works
flawlessly. I've been scratching my head all morning..

My configuration:
/etc/bind/named.conf:

logging {
   channel munin_log {
 file /var/log/bind9/query.log versions 30 size 15m;
 severity dynamic;


severity dynamic starts at 0 i.e. off.


No 0 is equivalent to info, except in one case:

ARM The default_debug channel has the special property that it only
ARM produces output when the server's debug level is nonzero.

It's actually quite a pain that one can't define one's own channels
with that special property.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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 Regarding NSEC RR in DNSSEC

2012-02-15 Thread Chris Thompson

On Feb 14 2012, Gaurav kansal wrote:


We have a Authenticated Response in DNSSEC through trust chain.

Now my question is why we itself need a NSEC when we get response from
DNSSEC enabled server authentically.

Means, if a Record exist in DNSSEC, then it replies the answer along with
RRSIG of that RR. 


AND if domain doesn't exist, then it can simply give NXDOMAIN and our job
will be done as we trust that nameserver through trust chain.

So what's the need of NSEC??


I think what you have failed to understand here is that there is no idea
in DNSSEC of trusting a nameserver. The security functions end-to-end,
between the zone administrator (she who generates its contents and signs
it) and the validator, not point-to-point.

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: CVE-2012-1033 (Ghost domain names) mitigation

2012-02-09 Thread Chris Thompson

On Feb 9 2012, Peter Andreev wrote:


2012/2/9 John Hascall j...@iastate.edu

[...snip...]


(2) It also looks like restarting bind flushes the cache
   and that prevents the repopulation of the local cache
   with names which are ghosts (new different ghost names
   could, of course, be created).Is this correct?



AFAIK 'rndc flush' will do the same.


If you know the domain name in question, rndc flushname ghost.example
should be enough. (BIND 9.9 has rndc flushtree as well, but I think
clobbering the cached NS records for the ghost domain should be enough.)

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Unknown RR in .in domain

2012-02-06 Thread Chris Thompson

On Feb 6 2012, Gaurav kansal wrote:


Thanks Alan.
I got it.


But why I am getting two NSEC3 records for .in domain?? Shouldn't I
get one NSEC3 RR only


Because the in servers are denying the existence of a signed delegation
for nknsec.in, while (because the zone uses opt-out) allowing the
possibility that there is an unsigned one - which of course there is.
(This makes the DNSSEC records in the authority section of the referral
response look rather like those for a NXDOMAIN one.)

Picking an authoritative server for in at random:

$ dig +dnssec +norec +multi nknsec.in @c0.in.afilias-nst.info.
[...]
;; QUESTION SECTION:
;nknsec.in. IN A

;; AUTHORITY SECTION:
nknsec.in.  86400 IN NS ns1.nknsec.in.
nknsec.in.  86400 IN NS ns3.nknsec.in.
9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN NSEC3 1 1 1 D399EAAB (
   9SJ987F06N7BLS7MRN2KR9252S6281C7

   NS SOA RRSIG DNSKEY NSEC3PARAM )
9sf2fomuor72m596ccsodg86639e6odr.in. 86400 IN RRSIG NSEC3 7 2 86400 (
   20120227205111 20120206195111 19608 in.
   LU3eRPCkAGVTAaSsCmg99OYtfrl6vxWu2d0p9LEp9Pw/
   H9LxAGy1owSx9a0FXOjL+iNb7QOQntdAcqcscgDeBLdS
   1i2XcMxOhyR5DvZ8BluYOCLEgM14yGBnmy23JB1CTtUo
   DAGceFp9CijygorEIZbA6EYum3IRkk38o0EMLiA= )
9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN NSEC3 1 1 1 D399EAAB (
   9RLLTFRS0PA4VCFC17QMBM4SU59P6Q6F

   A RRSIG )
9qqeme0jjmhqq2p0d3l9ic7viafdqan4.in. 86400 IN RRSIG NSEC3 7 2 86400 (
   20120225164542 20120204154542 19608 in.
   RHCtdth93BOuuTNMUOU6u/Y/EsYKo1LpZ9vfF+f8C6Vc
   Q+ajkr8zqi3Cg8gA2kqho6QY55FE4PeLcfo5yFPkO/S+
   dK+5mRB5zenw6/HL4QllyyLcviwW1tJ+nNF4M7vTemPI
   LLAQvWOl1j3McdJAvgoiFfNn4JRii91RxNxLGUI= )

The first NSEC3 record validates facts about the name in:

$ nsec3hash D399EAAB 1 1 in
9SF2FOMUOR72M596CCSODG86639E6ODR (salt=D399EAAB, hash=1, iterations=1)

[Note the match to the start of the NSEC3 range]

The second NSEC3 record validates facts (the non-existence for DNSSEC
purposes, in fact) about the name nknsec.in:

$ nsec3hash D399EAAB 1 1 nknsec.in
9QUOB43RU88DVJLS8B6SB52OQVD8BH80 (salt=D399EAAB, hash=1, iterations=1)

[That hash value is in the range 9QQEME... - 9RLLTF... of the NSEC3]

Read RFC 5155 section 7.2 in all its horrid detail, especially 
understanding the whole business of closest encounters, if

you want to know more.

As Alan said, you will never, *ever* get anywhere trying to analyse
DNSSEC problems with (quite seriously) out-of-date tools. Also if
you see strange things in dig +trace output, concentrate on the
specific iterative stage it was working through at the time - in
your example, the response of the authoritative in servers.
  
--

Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


Re: 9.9 query log change

2012-01-16 Thread Chris Thompson

On Jan 16 2012, Phil Mayers wrote:


On 01/15/2012 08:11 PM, Evan Hunt wrote:

Looking at some query log output from BIND 9.9.0rc1, e.g.

15-Jan-2012 18:24:45.358 client 131.111.11.47#58644 (www.playground.test):
^
query: www.playground.test IN A +E (131.111.9.112)

the indicated parenthesized item is new, but seems always to be the same
as the later query name. What is it for? If it meant to be the name of the
client it has got it horribly wrong!


3199.   [func]  When logging client information, include the name
 being queried. [RT #25944]


I'm confused. The name being queried is already in the line. Why is it 
now in there twice?


Obviously I'm not understanding something...


I think Evan is saying that the change applies to all messages in which
the client info appears, not just the query log ones.

But it does look mighty strange in that case. And maybe people will want
the class and type (and even flags) of the query added in the general case,
which would sort of reduce the query log specific info to just it happened.

--
Chris Thompson
Email: c...@cam.ac.uk
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


9.9 query log change

2012-01-15 Thread Chris Thompson

Looking at some query log output from BIND 9.9.0rc1, e.g.

15-Jan-2012 18:24:45.358 client 131.111.11.47#58644 (www.playground.test):
   ^
query: www.playground.test IN A +E (131.111.9.112)

the indicated parenthesized item is new, but seems always to be the same
as the later query name. What is it for? If it meant to be the name of the
client it has got it horribly wrong!

The ARM for 9.9.0rc1 still describes the old format.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: RFC 6303 vs. BIND: NS ... has no address records (A or AAAA)

2012-01-11 Thread Chris Thompson

On Jan 10 2012, Tony Finch wrote:


Irwin Tillman ir...@princeton.edu wrote:


What's the recommended approach?


My empty zone is:

@ SOA   localhost. root.localhost. 1 1h 1000 1w 1h
 NS localhost.

I also have a localhost. zone (RFC 2606) which is:

@ SOA   localhost. root.localhost. 1 1h 1000 1w 1h
 NS localhost.
 A  127.0.0.1
    ::1

In the reverse direction I have 1.0.0.172.in-addr.arpa and
1.0.0.ip6.arpa zones with the predictable contents:

@ SOA   localhost. root.localhost. 1 1h 1000 1w 1h
 NS localhost.
 PTRlocalhost.


Here is what we use on our central nameservers:

empty zone:

@ 86400 SOA  localhost. . 0 28800 7200 604800 86400
@ 0 NS   localhost.

localhost:

@ 86400 SOA  localhost. . 0 28800 7200 604800 86400
@ 0 NS   localhost.
@ 86400 A127.0.0.1
@ 86400  ::1

1.0.0.127.in-addr.arpa  1.0.0.[etc].0.0.ip6.arpa:

@ 86400 SOA  localhost. . 0 28800 7200 604800 86400
@ 0 NS   localhost.
@ 86400 PTR  localhost.

These are deliberately designed to look as much like BIND's automatic
empty zones as is reasonable, and to increase the similarity we also
use empty-server localhost; in options.

RFC 6303 specifies using nobody.invalid as the SOA.rname, but BIND
still uses . for empty zones (apparently even in 9.9.0rc1). I imagine
we will change that if/when BINS does.

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Exercising RFC 5011 rollovers

2012-01-09 Thread Chris Thompson

Back in November, I started a thread about testing BIND's managed-keys
code for tracking trust anchor rollovers. Since then I have been doing
some experiments which, as pointed out then, can take quite some time
due to the 30-day hold-down times specified in RFC 5011.

Recently I thought I had discovered my first bug in this area, but I have
since downgraded it to an infelicity, and maybe even that is putting it
too strongly. I wonder what others think.

If a new DNSKEY-with-SEP record is published, and fairly soon after
removed (without ever appearing as revoked), RFC 5011 specifies

| If the resolver ever sees the DNSKEY RRSet without the new key but
| validly signed, it stops the acceptance process for that key and
| resets the acceptance timer.

What BIND does is to retain the entry for the new key in managed-keys.bind
but every time it notices that it is no longer published it sets the
KEYDATA.addhd field 30 days in the future. Thus it will never get accepted
as a trust anchor.

That seems to satisfy the letter of the law, but it does mean that
managed-keys.bind remains cluttered with such keys. Would it not be
better for it simply to drop the entry whenever is sees a (properly
signed) DNSKEY RRSet without the key, if the KEYDATA.addhd time has
not yet been reached? If the key subsequently re-appeared, it would
get added again, with the 30-day hold-down period started again, which
seems equally compatible with RFC 5011.

I might add that I hadn't really meant to perform this experiment
at this time... it happened as a result of specifying a set of key
publication and activation times in January 2011 when January 2012
was intended :-)

--
Chris Thompson
Email: c...@cam.ac.uk
___
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: Fwd: Re: .TLD minimum number of nameservers rule

2011-12-15 Thread Chris Thompson

On Dec 15 2011, Kevin Darcy wrote:

To settle the question of are 2 nameservers required by the RFCs?, I'm 
surprised you guys missed this text in RFC 1034, Section 4.1:


   A given zone will be available from several name servers to insure
   its availability in spite of host or communication link failure. By
   administrative fiat, we require every zone to be available on at
   least two servers, and many zones have more redundancy than that.


This is an administrative fiat, you can't get much clearer than that.


Indeed, that's a better quote than my one from RFC 1035. How did I miss it?
Well, it turns out that the word two above occurs at the beginning of a
line in rfc1034.txt, and I was searching for the string  two ...  :-(

[Too many false drops if you search for just the three-character string,
because of network.] 


--
Chris Thompson
Email: c...@cam.ac.uk
___
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


  1   2   3   >