ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2018-05-23T10:32:22Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/176Test build BIND 9 against openssl-1.1.1-pre32018-05-23T10:32:22ZMark AndrewsTest build BIND 9 against openssl-1.1.1-pre3https://gitlab.isc.org/isc-projects/bind9/-/issues/262Add a RPZ mode to named-checkzone2018-05-23T12:57:58ZMark AndrewsAdd a RPZ mode to named-checkzoneIt might be useful to have a RPZ mode added to named-checkzone to check that the contents are valid for use by RPZ.It might be useful to have a RPZ mode added to named-checkzone to check that the contents are valid for use by RPZ.https://gitlab.isc.org/isc-projects/bind9/-/issues/283ensure there is a blank line before a changes entry and a release marker.2018-05-24T00:59:38ZMark Andrewsensure there is a blank line before a changes entry and a release marker.Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/287in-view Zones are only recognized if defined in previous view in named.conf2018-05-24T13:19:22ZGhost Userin-view Zones are only recognized if defined in previous view in named.conf### Summary
BIND Version : 9.10.6-P1
This assumes that different views are defined, e.g. in this order restricted1, restricted2, default in named.conf.
View default has match-clients set to any and therefore is the last in the list.
W...### Summary
BIND Version : 9.10.6-P1
This assumes that different views are defined, e.g. in this order restricted1, restricted2, default in named.conf.
View default has match-clients set to any and therefore is the last in the list.
When defining a zone within a view to reference the zone definition in another view (using "in-view name-of-view") the zone
in the other view is only recognized if the referenced view was defined earlier in the configuration file.
Example for above views: view "restricted2" references a zone in view "restricted1" using "in-view restricted1"
When referencing zones in a view that is defined after the view that contains the reference those zones are not recognized
and BIND logs
/opt/named/current/conf/named.conf:NNN: zone 'name-of-zone' not defined in view 'name-of-view'
Example for above views: view "restricted2" references a zone in view "default" using "in-view default"
### Steps to reproduce
see configuration file below
### What is the current *bug* behavior?
named does not recognize "forward" references for the views referenced by the in-view statement for a zone.
named cannot be started due to a failure to load the configuration file.
### What is the expected *correct* behavior?
It is expected that named does recognize "forward" references to allow to reference zones in the default (match-clients any) view.
### Relevant configuration files
```
acl "restricted1" {
10.10.10.0/24;
};
acl "restricted2" {
172.16.10.0/24;
};
options {
directory "/opt/named/current/conf";
pid-file "/opt/named/current/etc/named.pid";
session-keyfile "/opt/named/current/conf/session.key";
};
view "restricted1" {
match-clients { restricted1; };
zone "restricted1.internal" {
type master;
file "db.restricted1.internal";
};
};
view "restricted2" {
match-clients { restricted2; };
zone "restricted2.internal" {
type master;
file "db.restricted2.internal";
};
// default view zones
zone "default.test" {
in-view default;
};
};
view "default" {
match-clients { any; };
zone "default.test" {
type master;
file "db.default.test";
};
};
```
### Relevant logs and/or screenshots
Log Message:
May 24 14:52:55 XXXXX named[17257]: /opt/named/current/conf/named.conf:33: zone 'default.test' not defined in view 'default'https://gitlab.isc.org/isc-projects/bind9/-/issues/290Documentation error - missing "};"2018-05-25T06:03:15ZGhost UserDocumentation error - missing "};"Hi, I wasn't sure where else to report this. The documentation at:
http://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.html#logging_statement
In the logging section, explaining the Channel phrase, shows the following:
```
There...Hi, I wasn't sure where else to report this. The documentation at:
http://ftp.isc.org/isc/bind9/cur/9.10/doc/arm/Bv9ARM.ch06.html#logging_statement
In the logging section, explaining the Channel phrase, shows the following:
```
There are four predefined channels that are used for named's default logging as follows. How they are used is described in the section called “The category Phrase”.
channel default_syslog {
// send to syslog's daemon facility
syslog daemon;
// only send priority info and higher
severity info;
channel default_debug {
// write to named.run in the working directory
// Note: stderr is used instead of "named.run" if
// the server is started with the '-f' option.
file "named.run";
// log at the server's current debug level
severity dynamic;
};
```
As a person new to BIND, this confused me - I didn't know if there was something special about the channel name "default_syslog" or not that made it so that it didn't need a closing curly brace and semicolan (};).Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/292bind-9.13.0: three new performance issues2018-05-25T07:19:41ZGhost Userbind-9.13.0: three new performance issues```
[bind-9.13.0/unit/atf-src/tools/user.cpp:55]: (performance) Function parameter 'ids' should be passed by const reference.
[bind-9.13.0/unit/atf-src/tools/parser.cpp:43]: (performance) Function parameter 'msg' should be passed by cons...```
[bind-9.13.0/unit/atf-src/tools/user.cpp:55]: (performance) Function parameter 'ids' should be passed by const reference.
[bind-9.13.0/unit/atf-src/tools/parser.cpp:43]: (performance) Function parameter 'msg' should be passed by const reference.
[bind-9.13.0/unit/atf-src/atf-sh/atf-check.cpp:592]: (performance) Function parameter 'oc' should be passed by const reference.
```https://gitlab.isc.org/isc-projects/bind9/-/issues/184Lock bucket mapping is broken in rbtdb.c when DNS_RBT_USEHASH is not defined2018-05-25T16:29:57ZGhost UserLock bucket mapping is broken in rbtdb.c when DNS_RBT_USEHASH is not definedLock bucket mapping is broken in `rbtdb.c` when `DNS_RBT_USEHASH` is not defined. It does case-sensitive hash computation in error, and so "Foo" and "foo" names map to different locks.Lock bucket mapping is broken in `rbtdb.c` when `DNS_RBT_USEHASH` is not defined. It does case-sensitive hash computation in error, and so "Foo" and "foo" names map to different locks.https://gitlab.isc.org/isc-projects/bind9/-/issues/245rpz test fails to launch ns2 on openbsd2018-05-25T20:02:27ZCurtis Blackburnrpz test fails to launch ns2 on openbsdon openbsd61-64 the rpz test emits errors when ran with `sh run.sh rpz`
tested on master, v9_12, and the 9.12.1-P1 tarball
```
---output---
$ sh run.sh rpz
tput: not enough arguments (3) for capability `setaf'
tput: not enough argu...on openbsd61-64 the rpz test emits errors when ran with `sh run.sh rpz`
tested on master, v9_12, and the 9.12.1-P1 tarball
```
---output---
$ sh run.sh rpz
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
S:rpz:Thu May 3 20:05:18 PDT 2018
T:rpz:1:A
A:System test rpz
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
tput: not enough arguments (3) for capability `setaf'
I:Couldn't start server ns2 (pid=29602)
I:failed
kill: 29602: No such process
R:FAIL
E:rpz:Thu May 3 20:05:38 PDT 2018
---end output---
```
upon investigation, the setup.sh script is not successfully completing,
which leads to ns2 failing to launch.https://gitlab.isc.org/isc-projects/bind9/-/issues/293Follow-up from "Remove ECS authoritative implementation from BIND"2018-05-28T23:07:21ZOndřej SurýFollow-up from "Remove ECS authoritative implementation from BIND"The following discussions from !219 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/219#note_10748):
> Could we either use a `#define` from the header or `sizeof(n...The following discussions from !219 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/219#note_10748):
> Could we either use a `#define` from the header or `sizeof(node_num)/sizeof(node_num[0])` for all occurrences of `2` meaning the number of elements in this particular array?
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/merge_requests/219#note_10749): (+1 comment)
> Since the data stored here are being simplified, why can't we have:
>
> - `ipv4_node_num` and `ipv4_data`
> - `ipv6_node_num` and `ipv6_data`
>
> I don't have the full picture here, but the generic names are confusing to me (especially when used in `acl.c`).
>
> The other reader-friendly option (requiring less code changes) would be to add:
>
> ```
> #define IPV4_INDEX 0
> #define IPV6_INDEX 1
> ```
>
> and use it consistently in the code using `radix.h`Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/289random_test is very slow since isc_random change2018-05-29T21:08:53ZEvan Huntrandom_test is very slow since isc_random changeBefore change 4947:
```
$ kyua test random_test
random_test:isc_rng_binarymatrixrank_16 -> passed [1.503s]
random_test:isc_rng_binarymatrixrank_bytes -> passed [0.918s]
random_test:isc_rng_blockfrequency_16 -> passed [0.718s]
r...Before change 4947:
```
$ kyua test random_test
random_test:isc_rng_binarymatrixrank_16 -> passed [1.503s]
random_test:isc_rng_binarymatrixrank_bytes -> passed [0.918s]
random_test:isc_rng_blockfrequency_16 -> passed [0.718s]
random_test:isc_rng_blockfrequency_bytes -> passed [0.134s]
random_test:isc_rng_monobit_16 -> passed [0.706s]
random_test:isc_rng_monobit_bytes -> passed [0.130s]
random_test:isc_rng_runs_16 -> passed [1.151s]
random_test:isc_rng_runs_bytes -> passed [0.580s]
```
After change 4947:
```
$ kyua test random_test
random_test:isc_random_binarymatrixrank_16 -> passed [57.969s]
random_test:isc_random_binarymatrixrank_bytes -> passed [4.127s]
random_test:isc_random_blockfrequency_16 -> passed [58.222s]
random_test:isc_random_blockfrequency_bytes -> passed [3.374s]
random_test:isc_random_monobit_16 -> passed [59.008s]
random_test:isc_random_monobit_bytes -> passed [3.351s]
random_test:isc_random_runs_16 -> passed [59.605s]
random_test:isc_random_runs_bytes -> passed [3.649s]
```
Even worse, when running a full "make unit" with other unit tests being run in parallel, these are the grepped-out lines for random_test:
```
random_test:isc_random_binarymatrixrank_bytes -> passed [16.648s]
random_test:isc_random_monobit_bytes -> passed [15.136s]
random_test:isc_random_blockfrequency_bytes -> passed [25.718s]
random_test:isc_random_runs_bytes -> passed [18.061s]
random_test:isc_random_monobit_16 -> passed [171.179s]
random_test:isc_random_binarymatrixrank_16 -> passed [177.380s]
random_test:isc_random_blockfrequency_16 -> passed [176.568s]
random_test:isc_random_runs_16 -> passed [166.775s]
```
Of greatest concern: the unit test doesn't appear to have been significantly changed, other than switching to the new `isc_random` API. It isn't running more iterations or anything. This suggests that `isc_random` performs less than a tenth as well as `isc_rng` did, which is alarming. If true, I'd expect it to impact on resolver performance.BIND-9.13.1Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/297Determine the require PRNG properties per use case2018-05-29T21:09:48ZOndřej SurýDetermine the require PRNG properties per use caseThere are several places we use random numbers in BIND, and we need to determine the required qualities of RNG for each use case. I'll try to list the general categories here, along with initial layman's classification:
* DNS cookies (...There are several places we use random numbers in BIND, and we need to determine the required qualities of RNG for each use case. I'll try to list the general categories here, along with initial layman's classification:
* DNS cookies (nonce): CSPRNG
* query ID (nonce): CSPRNG
* random NS selection: PRNG
* various jitter: PRNG, uniform
* RNDC nonce: CSPRNG
* NSEC3 Salt: CSPRNG
* view->secret, server->sctx->secret (???): ???
* GSS (nonce?): CSPRNG
* rndc.c serial (nonce?): CSPRNG(?)
* srtt in adb.c: PRNG
* task attach: PRNG
* port numbers (nonce?): ???
* HMAC generate: MUST use cryptolib
* Public Key Crypto: MUST use cryptolib
* expiring rbtdb nodes: PRNG (but really should use LRU or something as suggested in XXX)
* shuffling RDATA: PRNG
* "guessing" RTT in resolver.c: PRNG
* TKEY: CSPRNG
* isc_hash initialize (nonce): PRNG
* (task)pool(.c) selection: PRNG, uniform
* isc_file_renameunique(): PRNG, maybe use mkstemp()https://gitlab.isc.org/isc-projects/bind9/-/issues/280Master does not start on Centos7 or Debian72018-05-29T21:10:39ZStephen MorrisMaster does not start on Centos7 or Debian7On both Debian7 and Centos7 Jenkins systems, BIND "master" (f6c213c87d684060b51754d5a384758da8db77a8) fails to start, outputting the message:
random.c:167: fatal error: RUNTIME_CHECK(RAND_bytes(buf, buflen) < 1) failed
* https://jenkin...On both Debian7 and Centos7 Jenkins systems, BIND "master" (f6c213c87d684060b51754d5a384758da8db77a8) fails to start, outputting the message:
random.c:167: fatal error: RUNTIME_CHECK(RAND_bytes(buf, buflen) < 1) failed
* https://jenkins.isc.org/view/BIND/job/bind9-master-centos7-amd64-1/631/
* https://jenkins.isc.org/view/BIND-jobs_testing/job/bind9-master-debian7-amd64-1/1/
This may be an issue with the version of the library used for the random functions (the code runs OK on other systems, including Debian 9) but if so, a check should be made for the correct version in "configure".https://gitlab.isc.org/isc-projects/bind9/-/issues/301output of the rpzrecurse test is incorrect on windows2018-05-30T02:14:13ZCurtis Blackburnoutput of the rpzrecurse test is incorrect on windowssee this snippet for example:
```
A:rpzrecurse:System test rpzrecurse
I:rpzrecurse:PORTRANGE:5300 - 5399
I:rpzrecurse:testing that l1.l0 exists without RPZ (1)
I:rpzrecurse:testing that l2.l1.l0 returns SERVFAIL without RPZ (2)
I:1a:sto...see this snippet for example:
```
A:rpzrecurse:System test rpzrecurse
I:rpzrecurse:PORTRANGE:5300 - 5399
I:rpzrecurse:testing that l1.l0 exists without RPZ (1)
I:rpzrecurse:testing that l2.l1.l0 returns SERVFAIL without RPZ (2)
I:1a:stopping resolver
I:1a:starting resolver using named.1a.conf
I:1a:testing q01.l2.l1.l0 doesn't recurse (3)
I:1b:stopping resolver
I:1b:starting resolver using named.1b.conf
I:1b:testing q01.l2.l1.l0 doesn't recurse (4)
I:1b:testing q02.l2.l1.l0 recurses (5)
I:1c:stopping resolver
```
1a, 1b, 1c, etc should all be "rpzrecurse"https://gitlab.isc.org/isc-projects/bind9/-/issues/72Defined a list of supported platforms for BIND 9.132018-05-30T02:33:31ZOndřej SurýDefined a list of supported platforms for BIND 9.13As we start the new development cycle, we need to define a list of supported platforms that will get supported for the life-time of the release cycle.
As decided by CCB, the list will include:
* Supported
* Linux distributions support...As we start the new development cycle, we need to define a list of supported platforms that will get supported for the life-time of the release cycle.
As decided by CCB, the list will include:
* Supported
* Linux distributions supported by their respective vendors at the start of the release cycle (excluding such that are near EOL date)
* BSD -"-
* Windows -"-
* Mac OS X
* Best Effort
* Commercial Unixes
* Not-Supported
* Anything past it's EOL or shortly before the EOL date
This doesn't define the supported list for BIND 9.14, we would revisit the list for 9.14 before we turn 9.13 to 9.14. However I don't expect much difference.Ondřej SurýOndřej Surý2018-02-23https://gitlab.isc.org/isc-projects/bind9/-/issues/104[RT#43640] Tool to gather all necessary files to accompany a core dump2018-05-30T23:53:20ZVicky Riskvicky@isc.org[RT#43640] Tool to gather all necessary files to accompany a core dumpWhen customers or others report a crash to us, they often don't understand what we need to be able to analyze the coredump file.
Evan said 'it would be cool to be able to run a tool that collects all the necessary file and tars them up ...When customers or others report a crash to us, they often don't understand what we need to be able to analyze the coredump file.
Evan said 'it would be cool to be able to run a tool that collects all the necessary file and tars them up ready to be submitted'.
Such a tool would need to be able to identify the binary from the core dump (or, optionally be told which is is), run ldd against the binary, collect all the libs, collect the debug symbols/package if these are separate and so on.
(There may be some contributed scripts around that are more generic we could use as the basis for this?)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/30Update the default for dnssec-validation to auto2018-05-31T16:40:45ZOndřej SurýUpdate the default for dnssec-validation to autoOr even better make the `yes` behave like `auto` and deprecate `auto`.
Also related to #6.Or even better make the `yes` behave like `auto` and deprecate `auto`.
Also related to #6.BIND-9.13.1Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/209Glue is no longer included for non-DNSSEC-signed zones since CHANGE 45962018-05-31T19:34:37ZCathy AlmondGlue is no longer included for non-DNSSEC-signed zones since CHANGE 4596BIND behaviour changed in a DNSSEC-validating resolver between 9.9.10-S2 and 9.9.11-S2 with whether or not glue for NS RRsets is included in the query response from a resolver. Responses from a resolver no longer includes glue that woul...BIND behaviour changed in a DNSSEC-validating resolver between 9.9.10-S2 and 9.9.11-S2 with whether or not glue for NS RRsets is included in the query response from a resolver. Responses from a resolver no longer includes glue that would previously have been included in the earlier version.
This occurs when the query response is for a zone that is not DNSSEC-signed. If the zone is DNSSEC-signed (and the answer and authority sections validate), then the glue is included.
named.conf contains "minimal-responses no;"
The likelihood is that this is a result of the following CHANGE:
```
4596. [bug] Validate glue before adding it to the additional
section. This also fixes incorrect TTL capping
when the RRSIG expired earlier than the TTL.
[RT #45062]
```
There is a lot of discussion in the bug ticket about whether or not it's appropriate to include non-DNSSEC-validated RRsets in the Additional section of a query response that is marked 'AD', but it did not appear that a decision was made not to include those RRsets in the response. It seems as if this change accidentally causes the additional section to be omitted from unsigned zones.
For example:
Querying a server running 9.9.10-S2:
```
$ dig @127.0.0.1 +dnssec 123-reg.co.uk NS
; <<>> DiG 9.8.3-P1 <<>> @127.0.0.1 +dnssec 123-reg.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49360
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;123-reg.co.uk. IN NS
;; ANSWER SECTION:
123-reg.co.uk. 3600 IN NS ns2.123-reg.co.uk.
123-reg.co.uk. 3600 IN NS ns.123-reg.co.uk.
;; ADDITIONAL SECTION:
ns.123-reg.co.uk. 172800 IN A 212.67.202.2
ns2.123-reg.co.uk. 172800 IN A 62.138.132.21
;; Query time: 204 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 12 18:25:29 2018
;; MSG SIZE rcvd: 109
```
Querying the server (with the same named.conf), but now running 9.9.11-S2:
```
$ dig @127.0.0.1 +dnssec 123-reg.co.uk NS
; <<>> DiG 9.8.3-P1 <<>> @127.0.0.1 +dnssec 123-reg.co.uk NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5299
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;123-reg.co.uk. IN NS
;; ANSWER SECTION:
123-reg.co.uk. 3600 IN NS ns.123-reg.co.uk.
123-reg.co.uk. 3600 IN NS ns2.123-reg.co.uk.
;; Query time: 179 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 12 18:25:11 2018
;; MSG SIZE rcvd: 77
```
I don't see the same effect when querying for a zone that is DNSSEC-signed, in both cases the additional section is included:
```
$ dig @127.0.0.1 +dnssec isc.org NS
; <<>> DiG 9.8.3-P1 <<>> @127.0.0.1 +dnssec isc.org NS
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23805
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 13
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;isc.org. IN NS
;; ANSWER SECTION:
isc.org. 7200 IN NS ns.isc.afilias-nst.info.
isc.org. 7200 IN NS sfba.sns-pb.isc.org.
isc.org. 7200 IN NS ord.sns-pb.isc.org.
isc.org. 7200 IN NS ams.sns-pb.isc.org.
isc.org. 7200 IN RRSIG NS 5 2 7200 20180509233246 20180409233246 19923 isc.org. lpHLy5TtOXoGo35vmGlyEbfBczZnbQQh581KmJsKSeWZPkAFuKZ9tVy1 dyS0AXGWF3Gk55AyEOo3wBf7qAXkgcFZTGVd0pXtvMAd8A0uhBEGuY8g LfW8JiPLPvMmVwt2niyyCB8fc9/9Bo6QMm65lH1qRsGqzBoqp8EmNz4t hLw=
;; ADDITIONAL SECTION:
ams.sns-pb.isc.org. 7197 IN A 199.6.1.30
ord.sns-pb.isc.org. 7197 IN A 199.6.0.30
sfba.sns-pb.isc.org. 7197 IN A 149.20.64.3
ams.sns-pb.isc.org. 7197 IN AAAA 2001:500:60::30
ord.sns-pb.isc.org. 7197 IN AAAA 2001:500:71::30
sfba.sns-pb.isc.org. 7197 IN AAAA 2001:4f8:0:2::19
ams.sns-pb.isc.org. 7197 IN RRSIG A 5 4 7200 20180509233246 20180409233246 19923 isc.org. tJh+AJes3F3tCe32YCuWX/oxvdAq41Aqu5pRJ3sjsxqrznJ3+eIeVjMn Nh1s7MMVVYPGps5Gg97+SwfnNZepTUsanryJNAVzO6Ss7eZazPyKFEXp scIIz5lDQybVhE18xH9SE6XNL3Ax8a9/Sd2ptqxUb+P3TsIHoZb8wvuw s08=
ams.sns-pb.isc.org. 7197 IN RRSIG AAAA 5 4 7200 20180509233246 20180409233246 19923 isc.org. vdZQ2BPieiDNjOIXc/8xDbITtApY8asfhTthj1c7SIBKYYqMqTsNU6ip ylXjAyv2bG34e5qaE9QcJEDBdqrl4sZsRFuFhJL7l344tKZ5lA4Iiva6 YdACLQ06HwcCN40LbISvamrgyvHeG4HDhGzY0gcDPCIJqT4IqQrj8ZHk m+M=
ord.sns-pb.isc.org. 7197 IN RRSIG A 5 4 7200 20180509233246 20180409233246 19923 isc.org. KWY5r1dvUA8XcSGw9VChkhlSBc0k3qRfPKUxX1MVSKWrOfOOod8AIj2S SelWLtSsvb/I78Yi3j4aPX8JAsrDIhYJ2ZWmsq7ogyV62zdL8l7mANdG cxzhLZwwYeFYlFsWlLvsuQguHw+5LHORaVJm3YwgXS61J1jpJWdd5CYD dME=
ord.sns-pb.isc.org. 7197 IN RRSIG AAAA 5 4 7200 20180509233246 20180409233246 19923 isc.org. Xan/9muSnSTzFdA1k4ytUT4lkJk+lLn6Ckp7TqRsFhdzT8dwIBoR1NtN sGjknwU8vQ9J9Wof3YHnfPfjZFmUnpUVFfJD1n9FeaAm/YVzVeOWjL7u Q4EnrVUF9FS77CumediqCkZw6AmzSq1oCDcoWMHDJojQZ6o+GOLftW1F JJ8=
sfba.sns-pb.isc.org. 7197 IN RRSIG A 5 4 7200 20180509233246 20180409233246 19923 isc.org. xcCP7sgIaYj5zSiiFVUVHRz0FUTg5Sb/baeNw2LqtMWcqrfkhYOUQRrc jZHkDgoRM4edqWisjWWmU84EoK25vi2ybH/zzi9nqhU/+JJHcVUk67su FpkFceU1/FN5vwhmzcjv8zkSD/PXUF2a4uh4xKvyC2/mVi5ucgSXp+le zZ0=
sfba.sns-pb.isc.org. 7197 IN RRSIG AAAA 5 4 7200 20180509233246 20180409233246 19923 isc.org. bTTiVlux7m3n4Qzil6YvNqvRwwwdnEY/aKauFrqHzLMe70TaUb1X8CT+ xnsdp917NYUBZ8apE4S3gSnUSP+cLA1H6a57vdWskIS0Zol1otisoDgW 5qVou6RCy0zhhXBDQ7bmqpGSo31lXeW3hI0ezTaXrAAMR/0UxHORZy/y j9w=
;; Query time: 3204 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Apr 12 16:59:05 2018
;; MSG SIZE rcvd: 1436
```
https://gitlab.isc.org/isc-projects/DNS-Compliance-Testing/-/issues/6IDN domains do not work2018-06-01T09:02:30ZPetr Špačekpspacek@isc.orgIDN domains do not workExamples:
* háčkyčárky.cz
* öko.de
* różyczka.pl
* 艶やかコンパクト.comExamples:
* háčkyčárky.cz
* öko.de
* różyczka.pl
* 艶やかコンパクト.comhttps://gitlab.isc.org/isc-projects/DNS-Compliance-Testing/-/issues/7redirect to results sometimes does not work2018-06-04T06:50:21ZPetr Špačekpspacek@isc.orgredirect to results sometimes does not workIt seems that some zones are broken enough to break ednscomp web tool.
E.g. testing zone `mfcr.cz` using https://ednscomp.isc.org/ednscomp/ leads at first to incomplete page. JSON API returns empty document for this site.
Please improv...It seems that some zones are broken enough to break ednscomp web tool.
E.g. testing zone `mfcr.cz` using https://ednscomp.isc.org/ednscomp/ leads at first to incomplete page. JSON API returns empty document for this site.
Please improve the behavior, it breaks workflow and confuses people who try to test their domains.https://gitlab.isc.org/isc-projects/bind9/-/issues/310check-changes needs to be called for v9_112018-06-05T02:43:31ZMark Andrewscheck-changes needs to be called for v9_11