Re: eia.gov chokes on edns options

[Mark Andrews]

They fail when presented with EDNS version 1 queries and unknown
edns options.  EDNS version 1 behaviour has been documented for
nearly 15 years.  Is it that hard to return BADVERS rather than
FORMERR?  It's like the vendor never read RFC 2671 or RFC 6891 which
obsoletes RFC 2671.

How are these servers passing acceptance testing?  It takes two
simple tests to show a problem.

dig +edns=1 zone @server (expect BADVERS to be returned)
dig +nsid zone @server   (expect the unsupported option to
  be ignored or NSID to returned)

dig +ednsopt=code[:content] zone @server 
(send a arbitary EDNS option with specfied content)

eia.gov need to go back to their nameserver vendor and get these
issues fixed.

Mark

In message <1404963274.28553.42.ca...@ns.five-ten-sg.com>, Carl Byington writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> dig phantom.eia.gov. @205.254.135.9 +dnssec +norecur
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30660
> ;; flags: qr aa ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
> 
> 
> 
> dig phantom.eia.gov. @205.254.135.9 +dnssec +nsid +norecur
> ;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 20
> ;; flags: qr ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> 
> 
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.14 (GNU/Linux)
> 
> iEYEARECAAYFAlO+CZMACgkQL6j7milTFsH/bgCfbDb2WinhfC6mY4epKr5rlro/
> l3wAnREhW3tJptOhBDB+02V/BoiseAdv
> =oJ7i
> -END PGP SIGNATURE-
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

eia.gov chokes on edns options

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

dig phantom.eia.gov. @205.254.135.9 +dnssec +norecur
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30660
;; flags: qr aa ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1



dig phantom.eia.gov. @205.254.135.9 +dnssec +nsid +norecur
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 20
;; flags: qr ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1


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

iEYEARECAAYFAlO+CZMACgkQL6j7milTFsH/bgCfbDb2WinhfC6mY4epKr5rlro/
l3wAnREhW3tJptOhBDB+02V/BoiseAdv
=oJ7i
-END PGP SIGNATURE-


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

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

Re: slave zone files unreadable

[Evan Hunt]

On Wed, Jul 09, 2014 at 03:16:04PM +0200, Reindl Harald wrote:
> however, i wonder what takes 90 seconds to load 5000 zones

It scales with both the number of zones and the number of records per
zone.  Some of those zones are probably quite large.

When you're reading text, it takes time to do the lexical analysis and
parsing.  When reading text *or* raw, it takes time to examine each node in
the zone file, determine its name, walk down through the nodes of a growing
red-black tree, allocate memory, and add the data.

A map file is a memory image of a fully-formed red-black tree; it can
be zapped into memory in one go, then we walk through the tree validating
checksums and updating the pointers, which is obviously much quicker.

(In fact it could be almost instant if we did the checksums-and-pointers
bit lazily, as the data was accessed rather than immediately at load time.
That introduces a lot of complexity, though; if a zone file is corrupt,
BIND expects to discover the fact right away, not at some random time
later on.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
Please visit https://lists.isc.org/mailman/listinfo/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: slave zone files unreadable

[Phil Mayers]

On 09/07/14 14:16, Reindl Harald wrote:


however, i wonder what takes 90 seconds to load 5000 zones


Depends how big they are.


the records-sql table has 3000 entries for all zones (backend


That is not very big. We've got zones with nearly 1M records in them, 
including NSEC/RRSIG.

___
Please visit https://lists.isc.org/mailman/listinfo/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: slave zone files unreadable

[Reindl Harald]

Am 09.07.2014 14:13, schrieb Reindl Harald:
> Am 09.07.2014 14:07, schrieb Anand Buddhdev:
>> On 09/07/2014 13:21, Reindl Harald wrote:
>>
>>> dunno, but i perfer text-format anyways
>>>
>>> * masterfile-format text; * delete the zone file on the slave *
>>> restart the slave
>>
>> Plain text zone files are fine if you have a small number of zones, or
>> small zones. But for servers with large numbers of zones, or large
>> zones, reading back from text files when starting the server can take
>> a long time. The "raw" format helps by speeding up load time. The
>> newer "map" format in BIND 9.10 is even better, and can improve zone
>> load time over the "raw" format by a factor of 3.
>>
>> As an example, on one of my BIND slaves with over 5000 zones, reading
>> from plain text zone files takes about 90 seconds, from raw files, it
>> takes 45 seconds, and from map files, just 15 seconds
> 
> agreed, but in case of debugging temporary switch to text
> makes thins easier to watch including sniff the traffic
> of zone-transfers - made it as example possible for me
> to *really* find out that the master was sending expected
> zone content and the cisco router between mangeled it

however, i wonder what takes 90 seconds to load 5000 zones

our master has 533 zones, zone files generated with self written
scripts as plaintext and loads them due a hard restart within
0.3 seconds and all notifies to the slave happen in the same second

the records-sql table has 3000 entries for all zones (backend
generates the zone-files in another table as text-field and
that content is fetched in case of changes from cronobs on the
nameservers and written down to zonefiles in case of changes)

[root@ns2:~]$ cat named.log | grep "loaded serial" | wc -l
533

09-Jul-2014 15:06:30.734 general: exiting
09-Jul-2014 15:06:30.827 general: managed-keys-zone: loaded serial 0
09-Jul-2014 15:06:30.948 general: all zones loaded
09-Jul-2014 15:06:30.968 notify: zone ***/IN: sending notifies (serial 
2014070201)

last message on the slave - all happens at 15:06
09-Jul-2014 15:06:57.961 general: zone ***/IN: notify from 10.0.0.16#15394: 
zone is up to date



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

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

Re: Checking proper SPF record

[G.W. Haywood]

Hi there,

On Wed, 9 Jul 2014, Alex wrote:


Thought I'd try this again. ...


You'll get much better help on the right list.

spf-h...@listbox.com

--

73,
Ged.
___
Please visit https://lists.isc.org/mailman/listinfo/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: slave zone files unreadable

[Reindl Harald]

Am 09.07.2014 14:07, schrieb Anand Buddhdev:
> On 09/07/2014 13:21, Reindl Harald wrote:
> 
>> dunno, but i perfer text-format anyways
>>
>> * masterfile-format text; * delete the zone file on the slave *
>> restart the slave
> 
> Plain text zone files are fine if you have a small number of zones, or
> small zones. But for servers with large numbers of zones, or large
> zones, reading back from text files when starting the server can take
> a long time. The "raw" format helps by speeding up load time. The
> newer "map" format in BIND 9.10 is even better, and can improve zone
> load time over the "raw" format by a factor of 3.
> 
> As an example, on one of my BIND slaves with over 5000 zones, reading
> from plain text zone files takes about 90 seconds, from raw files, it
> takes 45 seconds, and from map files, just 15 seconds

agreed, but in case of debugging temporary switch to text
makes thins easier to watch including sniff the traffic
of zone-transfers - made it as example possible for me
to *really* find out that the master was sending expected
zone content and the cisco router between mangeled it



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

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

Re: slave zone files unreadable

[Anand Buddhdev]

On 09/07/2014 13:21, Reindl Harald wrote:

> dunno, but i perfer text-format anyways
> 
> * masterfile-format text; * delete the zone file on the slave *
> restart the slave

Plain text zone files are fine if you have a small number of zones, or
small zones. But for servers with large numbers of zones, or large
zones, reading back from text files when starting the server can take
a long time. The "raw" format helps by speeding up load time. The
newer "map" format in BIND 9.10 is even better, and can improve zone
load time over the "raw" format by a factor of 3.

As an example, on one of my BIND slaves with over 5000 zones, reading
from plain text zone files takes about 90 seconds, from raw files, it
takes 45 seconds, and from map files, just 15 seconds.

Regards,

Anand
___
Please visit https://lists.isc.org/mailman/listinfo/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: slave zone files unreadable

[Reindl Harald]

Am 09.07.2014 10:29, schrieb Manuel Ramirez Montero:
> since i have upgraded to 9.9.5-P1 is not possible to read slave zone files.
> I have read an article about this :
> 
> https://kb.isc.org/article/AA-00608/0/Converting-Zone-Files-Between-Text-and-Raw-Formats.html
> 
> convert raw zone file "example.net.raw", containing data for zone example.net 
> , to text-format
> zone file "example.net.text"
> named-compilezone -f raw -F text -o example.net.text example.net 
>  example.net.raw
> 
> *
> This is the configuration for one of the slaves zone i´m having problems in 
> the named.conf :
> 
> zone "movilmap.es " in {
> type slave;
> file "/var/named/slaves/movilmap.es.hosts";
> masters { 10.1.29.179; };
> allow-update-forwarding { dns; };
> };
> 
> What should be the correct syntax for the named-compilezone in my case?

dunno, but i perfer text-format anyways

* masterfile-format text;
* delete the zone file on the slave
* restart the slave

P.S.: please don't post HT;L on mailing-lists, you see above what happens with 
quotes



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

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

slave zone files unreadable

[Manuel Ramirez Montero]

Hi,

since i have upgraded to 9.9.5-P1 is not possible to read slave zone files.
I have read an article about this :

https://kb.isc.org/article/AA-00608/0/Converting-Zone-Files-Between-Text-and-Raw-Formats.html

convert raw zone file "example.net.raw", containing data for zone
example.net, to text-format zone file "example.net.text"
named-compilezone -f raw -F text -o example.net.text example.net
example.net.raw

*
This is the configuration for one of the slaves zone i´m having problems in
the named.conf :

zone "movilmap.es" in {
type slave;
file "/var/named/slaves/movilmap.es.hosts";
masters { 10.1.29.179; };
allow-update-forwarding { dns; };
};


What should be the correct syntax for the named-compilezone in my case?

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

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