Re: automatic reverse and forwarding zones

2022-10-28 Thread Matus UHLAR - fantomas 

On 28.10.22 08:26, Ondřej Surý wrote:
BIND 9 have support for writing plugins, and we would accept a well written 
plugin that would allow generating the forward/reverse plugins on the fly.


There’s already a feature request for it here: 
https://gitlab.isc.org/isc-projects/bind9/-/issues/1586


this request for ipv4 too.

I really don't think making generic named for ipv6 addresses within range 
bigger then e.g. /112 (64Ki addresses) makes any sense.


prehaps it may for small subsets of IP addresses

/64 is 18446744073709551616 addresses, that can't be scanned in meaningful 
time and this number of DNS records would just mess up any DNS servers' 
memory.


making BIND resilient against overflowing memory this way would make more 
sense than creating generic addresses.




Am 27.10.2022 um 07:23:01 Uhr schrieb JAHANZAIB SYED:
Edit the corresponding REVERSE zone & add following line in the end

$GENERATE 1-255 $ IN PTR 10-11-11-$.example.com.

Dont forget to Reload bind config & you are done.



On 27.10.22 07:58, Marco wrote:
How is the syntax for IPv6?
Is it possible to do it for an entire /64?



On 27. 10. 2022, at 10:12, Matus UHLAR - fantomas  wrote:
this would create HUGE amount of records, they wouldn't fit into memory.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Boost your system's speed by 500% - DEL C:\WINDOWS\*.*
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: many log messages with 'already have ede' etc ?

2022-10-28 Thread Kurt Jaeger 
Hi!

Mark wrote:
> > We do have somewhat extensive logging on our auth DNS servers,
> > and currently, we see a load of messages like those:
> 
> > client @0x80357ad60 #5701 ( > 18 (null)

> They are debugging messages.  Stop running in debug mode.

Done, logging is quieter now. Thanks!

-- 
p...@opsec.eu+49 171 3101372Now what ?
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: automatic reverse and forwarding zones

2022-10-28 Thread Havard Eidnes via bind-users 
> Do wildcard records work with multiple labels? I was thinking that they
> didn't, but it's that wildcards in PKIX do not work with multple labels,
> alas.

As far as I understand, yes, wildcard "works with multiple labels", at
least in the meaning that a wildcard can expand more than one label in
the hierarchy.  Example:

If you have

*.0.0.0.0.e.d.0.c.d.a.b.0.1.0.0.2.ip6.arpa. IN PTR whatevername.your-domain.

in your DNSSEC-signed zone file and get a query for

1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.0.0.0.e.d.0.c.d.a.b.0.1.0.0.2.ip6.arpa.

you will get a signed reply with a PTR with the name

1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.0.0.0.0.e.d.0.c.d.a.b.0.1.0.0.2.ip6.arpa.

and the value of the PTR record as given above in the zone file.
However, in the RRSIG record supplied with the answer, the "labels"
field will indicate 16+2 = 18 for the 16 nibble labels + ip6.arpa in
the original PTR record in the zone, not the 32 + 2 labels in the
query and the response, so that a validator can see that it's only
that part of the name which is signed. ("number-of-labels field in
RRSIG is smaller than number-of-labels in answer, so must be the
result of a wildcard expansion.")

This is pretty clearly spelled out in the approximate half-page
"The Labels field" section on

https://www.rfc-editor.org/rfc/rfc4034.html#page-8

Regards,

- Håvard
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: dig +norecurse behaviour changed with 9.16.33

2022-10-28 Thread Nick Tait via bind-users 

Hi Veronique.

I'm not an expert, but to me the 9.16 behaviour is what I would expect 
to happen, based on:


 * When you issue the non-recursive query for "spectrum.cern.ch", it is
   answered from the "cern.ch" zone, which only knows the CNAME
   (returned in the ANSWER section) and the NS records for the zone
   that the CNAME points to (presumably returned in the ADDITIONAL
   section?).
 * A [hypothetical] subsequent non-recursive query for
   "spectrum-lb.cern.ch" would be answered from the
   "spectrum-lb.cern.ch" zone which contains the A records (which
   should be returned in the ANSWER section of that query).

(A recursive resolver would be expected to make both of the queries 
above to give a complete answer to the query for "spectrum.cern.ch".)


But aside from the observation that the responses from 9.11 and 9.16 
aren't the same, what is the actual problem you are trying to solve? 
i.e. Why does it matter if the A record is or isn't returned in a 
/non-recursive/ query for "spectrum.cern.ch"?


Nick.


On 28/10/22 01:28, Veronique Lefebure wrote:

Well,

So here a bit more details.
Sorry, I cannot take an example with a DNS server accessible to you 
(*)  because they have all been upgraded to 9.16.


The .cern.ch contains:

spectrum-lb IN NS ip-dns-1.cern.ch.
spectrum-lb IN NS ip-dns-2.cern.ch.
spectrum IN CNAME spectrum-lb.cern.ch.

and

spectrum-lb.cern.ch contains:

$ORIGIN .
$TTL 60 ; 1 minute
spectrum-lb.cern.ch IN SOA ip-dns-1.cern.ch. internal-dns.cern.ch. (
273 ; serial
3600 ; refresh (1 hour)
300 ; retry (5 minutes)
360 ; expire (5 weeks 6 days 16 hours)
60 ; minimum (1 minute)
)
NS ip-dns-1.cern.ch.
NS ip-dns-2.cern.ch.
A xxx.xxx.xx.140



named configuration file is identical between 9.11 and 9.16 except for 
the following options that we have added for 9.16:


#BIND916 options
qname-minimization disabled;
stale-answer-enable no;
stale-refresh-time 0; #default is 30
max-stale-ttl 1w;
dnssec-policy none;
synth-from-dnssec no;
min-cache-ttl 0;
min-ncache-ttl 0;
minimal-responses no;





(*) On an external DNS server you can try with the following similar 
case:


Running DiG 9.11.21 on a linux client
ext-dns-1 (192.65.187.5) runs BIND9.16:
dig @ext-dns-1 foundservices.cern.ch | grep flags | grep ANSWER
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
dig @ext-dns-1 foundservices.cern.ch *+norecurse* | grep flags | grep 
ANSWER

;; flags: qr aa ra; QUERY: 1, ANSWER: *1*, AUTHORITY: 0, ADDITIONAL: 1
Full output:
dig @192.65.187.5 foundservices.cern.ch +norecurse
; <<>> DiG 9.11.21 <<>> @192.65.187.5 foundservices.cern.ch +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9899
;; flags: qr aa ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 8786b980a1a80a790100635a7898a512a21aa6138faf (good)
;; QUESTION SECTION:
;foundservices.cern.ch. IN A
;; ANSWER SECTION:
foundservices.cern.ch. 900 IN CNAME db-lb-1234.cern.ch.
;; Query time: 2 msec
;; SERVER: 192.65.187.5#53(192.65.187.5)
;; WHEN: Thu Oct 27 14:24:56 CEST 2022
;; MSG SIZE rcvd: 103
ip-dns-0 runs BIND9.11:
dig @ip-dns-0 foundservices.cern.ch | grep flags | grep ANSWER
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4
dig @ip-dns-0 foundservices.cern.ch *+norecurse* | grep flags | grep 
ANSWER

;; flags: qr aa; QUERY: 1, ANSWER:*2*, AUTHORITY: 2, ADDITIONAL: 4


Does that help ?

Greg, can I send you a pcap file in a private email ?


Thanks,
Veronique
On 27/10/2022 10:09 Greg Choules 
 wrote:



Hi Veronique.
No, we cannot easily reproduce this behaviour because we have no 
knowledge of the configs of either of those servers, the details of 
the zones you have configured, the contents of those zones or of the 
system on which you are running the dig command.


As I said, we need to see everything please:
- Full digs, not +short
- you have specified @ip-dns0 and @ip-dns1 - the full configs of both 
of those servers please, including zone definitions and contents for 
where "spectrum.cern.ch " lives as it is 
not a name that can be resolved from the public Internet
- a binary pcap file, using the -w option of tcpdump, capturing all 
port 53 traffic (UDP and TCP) between this machine and both DNS servers.


By the way, when using the @ option of dig please use 
explicit IP addresses, not names. If you use a name, then dig first 
has to resolve that name and the place it will go to do that is 
resolv.conf. So it is now dependent on your system DNS setup to get 
an IP address to send the dig to.
Also, you have specified @ not @. This 
suggests to me that in resolv.conf you have a 'search' list. 
Personally I don't like search lists because they potentially 
increase the workload of the DNS system generally, lengthen query 
times and mean that you can't be sure exactly where an answer came from.


Thanks, Greg


On Thu,