Re: Problems with (unsigned) forward zones, dnssec-validation auto and validate-except on BIND 9.16 and 9.17

2022-01-27 Thread Tony Finch
Gehrkens.IT GmbH | Heiko Wundram  wrote:
>
> From what I gather, this behaviour sounds almost like what RFC 8020 proposes
> (NXDOMAIN cut), but at least according to the corresponding ticket, that
> isn't implemented in BIND.

The other things that can cause the behaviour you observed are
synth-from-dnssec and qname-minimization.

It might make sense to forward the whole of .lan and .local to your
Windows resolvers, assuming you have one set of servers that knows the
whole namespace.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Bailey: Northwest 5 or 6, backing southwest 6 to gale 8, perhaps
severe gale 9 later. Very rough, becoming rough for a time. Showers,
rain later. Good, becoming moderate or poor later.

___
Please 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: AW: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)

2022-01-24 Thread Tony Finch
egoitz--- via bind-users  wrote:
>
> These are the contents of a cat of the private file I have renamed to
> samename.private-OLD :
>
> Created: 20211031230338
> Publish: 2020220241
> Activate: 2020220341
> Inactive: 20211215230338
> Delete: 20211217230338

Yes, it can be confusing when the state of the key files doesn't match the
state of the zone.

I think you said you have renamed all your key files back to their usual
non-OLD names. Good; that is necessary if named is still looking for a key
file even if it shouldn't need it any more.

Then, try running `rndc sign `, to make named reload the keys. I
think that should also get it to make whatever updates might be necessary.

Then look at the logs to see if there are errors, and look at the DNSKEY
RRset (with its RRSIGs) to make sure it matches what you expect.

If that doesn't get things straightened out then, um, dunno :-)

I guess it is possible to get into a muddle if you try to move a key out
of the way very soon after its delete time. By default, named does key
maintenance infrequently, so I guess if you move the key after its
deletion time but before the next key maintenance cycle, things will get
out of sync. But I have not checked whether my guess is right or not.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel:
Variable 2 to 4. Smooth or slight. Fair. Good.

___
Please 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: Best practice for forwarding Dnstap (unix socket) traffic to another address

2022-01-12 Thread Tony Finch
Fred Morris  wrote:
>
> What I'm looking at is trying to build a BIND kernel, like a nanokernel. Socat
> won't work in this case, because because there's no "IPC" layer, because there
> is only one process in the kernel.

Sounds fun. I think your solution must be to modify BIND's dnstap sender
so that it can use a TCP socket as an alternative to a unix domain socket.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and
North Channel: Southwesterly 3 to 5. Mainly slight or moderate, but
smooth or slight in Firth of Clyde. Fair. Good.

___
Please 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: your mail

2022-01-12 Thread Tony Finch
Diego Garcia  wrote:
>
> Each 20/30 minutes and lasting about 5 minutes i got 'timeout' in bind
> querys. After that time everything works fine again.
>
> My bind server got response (from 0.1 to 2 seconds) but reply with a ICMP
> 'port unreachable'.
>
> Any idea the problem or what i can check?
>
> Firewall is off while testing.
>
> My bind server is a NAT router.

It sounds like the NAT is interfering with BIND's resolver. In general,
NAT (as well as stateful firewalls) do not work well with the DNS, because
UDP port randomization uses a lot of (mostly useless) connection-tracking
state. So it's best to put a full service resolver outside a NAT if
possible.

In your case, I guess there are several possible IP addresses that BIND
can use as the query source address. Try setting the query-source option
in named.conf to an IP address that's outside the NAT. You will need to
use tcpdump to verify that the right packets with the right addresses are
appearing on the wire.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Portland, Plymouth: Northeast, veering east or southeast, 3 or 4.
Slight or moderate, occasionally rough at first in Plymouth. Fog
patches at first in south. Moderate or good, occasionally very poor at
first in south.

___
Please 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: How to show run the active configuration on bind

2022-01-05 Thread Tony Finch
Mik J via bind-users  wrote:

> How can I check which variables are loaded in memory and considered as active.

As Ray said, usually it isn't ambiguous.

But there are a couple of semi-relevant tools that are worth knowing
about:

You can use `named-checkconf -p` to canonicalize your configuration (so
you don't have to chase down include files, etc.), plus the -x option
strips out secrets (TSIG keys) which is handy for tech support cases.

And the statistics channel has loads of details, some of which are
config-related. `curl http://SERVER:8053/json/v1 | gron | less` is a
good way to get an idea of what it contains.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Humber, Thames: Northwest 7 to severe gale 9, decreasing 5 later.
Rough or very rough, becoming moderate or rough later. Showers. Good.

___
Please 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: transfer-source / notify-source warnings if a port is specified

2021-12-29 Thread Tony Finch
Duncan  wrote:
>
> Is there any option to suppress warnings if using transfer-source /
> notify-source specifying ports ?

There are good reasons for these warnings.

NOTIFY uses UDP, and source port randomization in UDP is important to
protect against spoofing. Spoofing NOTIFY is relatively harmless, but it
does create more work for the target server than other requests, so you
don't want to make it easy.

Zone transfers use TCP. A TCP connection is identified by its 4-tuple: its
source and destination addresses and ports. Multiple concurrent TCP
connections to the same server require differing source ports, because the
rest of the 4-tuple must be the same. If you fix your zone transfer TCP
source port, then every zone transfer to your server from its upstream
(primary/master) will have the same 4-tuple. This means you will only be
able to perform one zone transfer at a time because there can only be one
TCP connection at a time with the same 4-tuple. You are also probably
going to have an unhappy encounter with the various TCP connection
shutdown timers (FIN_WAIT, CLOSE_WAIT, etc.) that prevent successive TCP
connections with the same 4-tuple from getting muddled up.

So you can suppress the warnings, and avoid the problems they are warning
you about, by not specifying the source ports.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Southwest Forties, Cromarty, Forth, Tyne, Dogger: Southwesterly 5 to
7, occasionally gale 8 at first except in Cromarty, then decreasing 4
at times. Moderate or rough in southwest Forties and Dogger, but
elsewhere slight or moderate. Rain or showers. Good, occasionally poor
for a time.

___
Please 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: Spurious failures in a dynamically updated to a sub /24 reverse DNS domain P.S.

2021-12-29 Thread Tony Finch
Mirsad Goran Todorovac  wrote:

> Please excuse me, as I am a bit confused ...
>
> I have tried to verify your findings, but I've found something awkward:

Something has changed, because earlier I got:

; <<>> DiG 9.10.6 <<>> soa 192/27.186.198.193.in-addr.arpa @193.0.9.6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25229
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

and now instead I get a referral:

; <<>> DiG 9.10.6 <<>> soa 192/27.186.198.193.in-addr.arpa @193.0.9.6
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26187
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;192/27.186.198.193.in-addr.arpa. INSOA

;; AUTHORITY SECTION:
186.198.193.in-addr.arpa. 14400 IN  NS  dns1.carnet.hr.
186.198.193.in-addr.arpa. 14400 IN  NS  dns2.carnet.hr.

;; Query time: 22 msec
;; SERVER: 193.0.9.6#53(193.0.9.6)
;; WHEN: Wed Dec 29 23:35:20 GMT 2021
;; MSG SIZE  rcvd: 107

And the SOA serial number for 198.193.in-addr.arpa has bumped to
2021122901.

The actual delegation that was missing was for 186.198.193.in-addr.arpa,
not the delegation for your zone 192/27.186.198.193.in-addr.arpa

This error was partially hidden because of the shared carnet.hr
nameservers.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
partnership and community in all areas of life

___
Please 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: Spurious failures in a dynamically updated to a sub /24 reverse DNS domain

2021-12-29 Thread Tony Finch
Mirsad Goran Todorovac  wrote:
>
> I have recently implemented dynamic updates to a sub /24 reverse DNS
> domain, 193.198.186.192/27.
> I had upstream domain 192/27.186.198.193.in-addr.arpa. delegated from
> authoritative servers.
>
> However, something still isn't right. In some reverse PTR addresses, the
> resolver sees first redirection, and the second redirection, but somehow
> fails to connect them in a reverse lookup:

It looks to me like someone forgot to update the serial number on the zone
198.193.in-addr.arpa so your new delegation failed to propagate as it
should have,

The servers for 198.193.in-addr.arpa are:

dns1.carnet.hr
dns2.carnet.hr
ns.ripe.net

The first two know about the delegation for your zone
192/27.186.198.193.in-addr.arpa but ns.ripe.net does not.
This is the cause of the inconsistencies that you observed.

The SOA serial number for 198.193.in-addr.arpa is the same
2021052502 on all its nameservers.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
the market alone does not distribute wealth or income fairly

___
Please 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: DNS cache poisoning - am I safe if I limit recursion to trusted local networks?

2021-12-29 Thread Tony Finch
Danilo Godec via bind-users  wrote:
>
> I have an authoritative DNS server for a domain, but I was also going to
> use the same server as a recursive DNS for my internal network, limiting
> recursion by the IP. Apparently, this is a bad idea that can lead to
> cache poisoning...

Sort of. It's complicated.

Of course DNSSEC can prevent cache poisoning, but there is more to this
particular question.

In older DNS software (BIND 8 and before) there was not much separation
between the recursive cache and authoritative data. It was possible for
recursive clients to get data into the cache that could leak into
authoritative responses, e.g. glue addresses, and addresses of CNAME or MX
targets that pointed out-of-zone. This could lead to cache poisoning of
other recursive servers, especially those that trusted additional data too
much (before RFC 2181).

BIND 9 keeps its authoritative and recursive data more separate. As a user
you can see this in the ACL options, allow-recursion, allow-query-cache,
etc. It is possible to configure BIND 9 so that remote clients see an
authoritative-only view, and local clients have access to a recursive
view, but it isn't entirely straightforward. Best practice is still to
configure servers that appeaar in NS records to be authoritative-only.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Trafalgar: Variable 4 or less, but southerly 5 or 6 in northwest.
Moderate or rough in southeast, rough or very rough in northwest. Fog
patches. Moderate or good, occasionally very poor.

___
Please 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: Millions of './ANY/IN' queries denied

2021-12-17 Thread Tony Finch
Ondřej Surý  wrote:

> FTR RRL will not help on this case. There’s no difference between
> response with TC and response with REFUSED.

Yes and no :-) RRL uses a mixture of "slip" (i.e. truncation) and dropping
responses, so it will attenuate REFUSED spam. (The documentatin is not
very clear about when it drops, tho...)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Utsire: Variable 4 or less becoming westerly or northwesterly 3
or 4. Moderate. Drizzle. Good, occasionally poor.
___
Please 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: Recommendations for replacing a master server without breaking DNSSEC

2021-11-24 Thread Tony Finch
Ralph Seichter via bind-users  wrote:
>
> How would you go about moving all functionality from Alpha to Beta,
> ideally with minimal downtime, and with the hard requirement of not
> breaking DNSSEC? How would one need to handle key material, zone
> signatures, journals, etc.?

There was this time when we had a hardware failure that took out our
primary DNS server. It looked like it was going to take a long time to
fix the failure, so I stood up a replacement primary on different
hardware, which was relatively quick using our Ansible playbooks.

So the new server had a copy of all the relevant secrets (DNSSEC private
keys, TSIG keys, ssh keys, ...) installed by Ansible, which meant that the
new server's zones would all validate OK. So it was able to rebuild all
the zones and sign them from scratch, then take over from the dead server.

Using the same keys makes the process much easier than trying to do a
key rollover at the same time. Don't make delicate ops work needlessly
tricky!

We also use `serial-update-method unixtime`, so I did not have to worry
about SOA serial number resets. If you are currently using the default
`increment` method you can switch to unixtime without having to worry
about wraps (tho `date` is problematic). Do this before the migration, to
remove another hazard.

When you are standing up a new primary, there are a few things you can do
to check that the new zones are OK: use https://dotat.at/prog/nsdiff/ to
verify that the non-dnssec zone contents are identical; use
`dnssec-verify` to check the DNSSEC parts.

A minor downside of rebuilding from scratch like this is that your
secondaries will have to retransfer the complete zone contents, but that
was not a problem at our scale (cam.ac.uk is 150,000 records and we have
similarly sized private and reverse DNS zones).

Basically, I ignored the journals as ephemeral, and I knew that re-signing
from scratch would generate working signatures even though they are all
different from the old signatures. Even if you are running both old and
new in parallel before the switchover, unixtime means you don't have to
worry about serial numbers either.

(The biggest mistake I made with this operational surprise was to rebuild
the primary on the same IP addresses rather than promote its sibling to
take over on different addresses. I chose to do it in place so I did not
have to reconfigure the other servers to point to the alternate primary;
instead I had to do some delicate and unscripted firewall adjustments to
stop the other servers from pulling down incomplete zones while the
rebuild was in progress. In retrospect that was the wrong choice. But
since you are moving to a new location I suspect you don't have this
hazard.)

I think a procedure like this is a good way to migrate a primary server if
the old and new servers are run by the same people, though I recommend
that you don't do it very quickly after a hardware failre if you can avoid
it.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Lundy, Fastnet, Irish Sea: West or northwest 3 to 5, veering north or
northeast 6 to gale 8. Smooth or slight, becoming slight or moderate,
then moderate or rough in Fastnet and later elsewhere. Showers. Good,
occasionally moderate.

___
Please 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: named failed to resolve forwarding queries(with global forwarders specified with "forward only") when "server section statement" has forwarder IP

2021-11-24 Thread Tony Finch
Nagesh Thati  wrote:
>
> Can anyone tell me why I am getting tsig errors and SERVFAIL errors for
> non managed zones? Why named using the "server statement" TSIG key in
> forwarding queries instead of using this TSIG only for ixfr/axfr?

TSIG is a bit confusing to set up because there are a bunch of options
and the use-cases and pros and cons can be unclear.

The `server` clause has a grab-bag of options that you can specify about
other nameservers that your server might communicate with for whatever
reason. If you configure a TSIG key in a `server` clause, it is used for
all traffic with that server. (There will normally be a corresponding
config on the other server for traffic in the opposite direction.) It's
convenient to use for traffic between authoritative servers, because it
gives you one place to secure refresh queries, notifies, and zone
transfers. But in a more complicated configuration like yours it can have
an unwanted effect on other traffic.

Another approach is to configure TSIG for each kind of traffic separately.
More explicit, but more verbose. The way I like to do this is to have
`acl` clauses with helpful names, which can then be used in allow-notify
and allow-transfer options to require TSIG for incoming requests; and
corresponding top-level `primaries` clauses for use in per-zone
`primaries` and/or `also-notify` clauses for outgoing requests. I can put
all this access control stuff into a shared config file used on all my
servers, and the authoritative TSIG stuff will not affect recursive
queries.

(For example, at Cambridge we have a mutual secondarying arrangement with
Imperial College with TSIG and IPv6 and DNSSEC and all that good stuff;
our recursive servers don't know anything special about the Imperial
zones, and we don't need or want recursive queries between us to use TSIG.
Our recursive servers still have the same shared access control config,
but the Imperial parts are not used there, because none of the zone
clauses refer to the Imperial acl/primaries names.)

This kind of explicit TSIG configuration doesn't work in all cases: for
instance, you can't specify TSIG keys in the `forwarders` clause, so you
have to use a `server` clause to configure TSIG for forwarding.

I haven't answered your specific questions because I'm not sure I
understand the details of your setup properly, but I hope this more
general answer is helpful.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
harness technological change to human advantage

___
Please 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: DNSSEC implementation on IPv6 PTR Zones

2021-11-22 Thread Tony Finch
Divya  wrote:

> How to create DS for 2409::/28 

The fun / maddening part of managing reverse DNS is getting to know how
your RIR handles it, and the weird differences from common-or-garden
forward domain registrations. In your case, 2409::/28 is allocated by
APNIC. They have a bit of documentation at the link below, tho I can't
find anything about DS records or DNSSEC. Perhaps it's more obvious once
you have logged into their resource management web pages.

https://www.apnic.net/manage-ip/manage-resources/reverse-dns/

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Sole, Lundy, Fastnet: Northeast 4 to 6. Slight or moderate in Lundy,
otherwise moderate or rough, becoming slight or moderate in Fastnet.
Showers. Good.

___
Please 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: Possible to condition a view based on the interface the query comes in on?

2021-11-18 Thread Tony Finch
Fred Morris  wrote:
>
> Didn't see any reason that it had to be separate instances of BIND,
> thought maybe I could do it with views, but I've run into a couple of
> roadblocks:
>
> 1. listen-on isn't supported in views.

Right, listen-on is for the server as a whole.

To control which view is used to answer a query based on the server
address, use the `match-destinations` option. For details see
https://bind9.readthedocs.io/en/v9_16_23/reference.html#view-statement-grammar

> 2. internet wisdom augurs that response-policy isn't supported either.

Don't believe everything you read on the internet :-)

Yes, you can have different RPZ configurations in different views.

Another trick that's useful for the kind of setup you are planning is to
use the `attach-cache` option so that your views can share the same cache.
This improves performance and reduces memory usage. It still works with
differing RPZ policies because RPZ only affects the responses sent to
clients; RPZ doesn't change how recursion works or what records are saved
in the cache.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Fair Isle, Faeroes: Westerly or southwesterly 7 to severe gale 9,
occasionally storm 10 for a time in Faeroes, decreasing 5 to 7 later.
Rough or very rough, becoming high for a time. Occasional rain.
Moderate, occasionally poor.

___
Please 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: RPZ rule to apply to NS record requests?

2021-11-16 Thread Tony Finch
John Thurston  wrote:

> If I have a Reverse Policy Zone (RPZ) defined, I can define a specific answer
> to be sent for a specific record-type for a specific name:
>
>foo.bar.com  IN  A  10.11.12.13
>foo.bar.com  IN TXT "Hello World"
>
> But I can't seen to define one for the record-type NS
>
> Is this possible?

The RPZ documentation doesn't say you can't include NS records as "local
data", but I guess you might trip over BIND's checks for what makes sense
at a zone cut: in a normal zone you can't have A and TXT and NS at the
same name (unless it's the zone apex).

But even if it did work, it's unlikely to do what you want. (You didn't
say why you want NS records so that's a somewhat risky assumption...)
In typical setups, RPZ is deployed on recursive servers, whose clients are
basically all stub resolvers. Stubs don't do anything special with NS
records, and they almost never make NS queries. So normally, using RPZ to
substitue NS records will not have any useful effect.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and
North Channel: Southwesterly veering westerly, 5 or 6. Slight or
moderate, occasionally rough near Mull of Kintyre. Rain then showers.
Good, occasionally moderate at first.

___
Please 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: host your subdomain on your own ?

2021-11-13 Thread Tony Finch
Grant Taylor via bind-users  wrote:
> On 11/13/21 7:29 AM, Tony Finch wrote:
> > You should make sure that your public nameservers return a definite nodata
> > or NXDOMAIN reply for your private names, not REFUSED, nor a referral to an
> > RFC 1918 address. The latter two will cause resolvers to retry, and the
> > retries can become a large proportion of your total authoritative query
> > traffic.
>
> Please elaborate on the mechanics behind returning a ""private IP
> causing resolvers to retry?  Is it the resolvers rejecting the ""private
> IP and retrying?

Yes, because they get a referral to nameservers that don't respond or that
respond incorrectly.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Forties: East or southeast, veering south later, 4 to 6. Moderate. Fog
patches at first. Moderate or good, occasionally very poor at first.

___
Please 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: host your subdomain on your own ?

2021-11-13 Thread Tony Finch
A couple of generaal points about private names and addresses:

If you have a private subdomain, e.g. private.cam.ac.uk, and a
non-negligible number of users, the names *will* leak into the outside
world and your public nameservers will get queries for them. You should
make sure that your public nameservers return a definite nodata or
NXDOMAIN reply for your private names, not REFUSED, nor a referral to an
RFC 1918 address. The latter two will cause resolvers to retry, and the
retries can become a large proportion of your total authoritative query
traffic.

I have some vague unease about the interaction between the web security
model and names that resolve to RFC 1918 addresses outside their home
network. And some more specific unease about risks of ssh, if you are ever
careless about accepting ssh unknown host warnings. So I guess if you are
careful and you know what you are doing (and by implication, if you don't
have many users) you can put RFC 1918 addresses in public zones, but I
wouldn't recommend it. Assign yourself an IPv6 ULA prefix and use that
instead :-)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Plymouth, Biscay: Northwest veering north or northeast, 3 to 5.
Moderate or rough. Occasional drizzle or showers later. Moderate or
good, occasionally poor later.

___
Please 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: A record for @?

2021-11-05 Thread Tony Finch
@lbutlr via bind-users  wrote:

> I have a domain that I hot DNS and email for, but not web. I set the A
> record for www.example.com to the IP of the web server with nsupdate,
> removing the old CNAME the pointed to the local webserver, but the web
> monkey for the new website is saying that www has to be a CNAME and the
> @ record should be the A record pointing to the IP.

You can do that, but it might have weird effects if someone tries to send
email to someth...@www.example.com. I generally think it's neater for both
the zone file origin (aka @) and the www subdomain to have A/ records
pointing at the web server.

> I don't think this is right, and if it is I am not sure how to use
> nsupdate to make this change.

@ is just an abbreviation for (in this case) example.com (it's handy for
writing instructions or zone file that work the same for any domain name).

In cases where there isn't an implicit origin, such as nsupdate, you need
to write the records out in full instead, e.g.

www.example.com. CNAME example.com.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Foreland to Selsey Bill: Northwesterly, backing westerly or
southwesterly 3 or 4, increasing 4 to 6 later. Smooth or slight,
occasionally moderate later. Showers later. Good.

___
Please 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: consolidating Reverse Zones

2021-10-21 Thread Tony Finch
Edwardo Garcia  wrote:
>
> I guess bind can not consolidate like this and we have to put up with a
> million /24 zone files ?  I was thinking because we can do classless dele
> with smaller than /24, it would work on bigger  :)

It is possible! The basic idea (very briefly) is:

With classless reverse DNS for prefixes longer than /24, you need a CNAME
in the /24 zone pointing at each address in the classless zone.

For shorter prefixes, you need a DNAME in the /16 zone pointing at each
/24 in the classless zone.

There are some documents explaining how we use this trick in production
at https://www.dns.cam.ac.uk/domains/reverse/ with links to the less
Cambridge-specific explanations in the last two paragraphs of that page,
viz:

https://www.dns.cam.ac.uk/domains/reverse/technical.html

https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Lundy, Fastnet: Northwest 4 or 5, occasionally 6 in Lundy. Rough or
very rough, becoming moderate or rough, then moderate later. Showers.
Good, occasionally moderate.

___
Please 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: CNAME query

2021-09-23 Thread Tony Finch
Sonal Pahuja  wrote:
>
> We are sending a CNAME query but currently we don't have any CNAME
> record, just have NS info. What should be the Bind9 response for this
> CNAME query? Will it return NS Record in Authority/Answer section?

In general, applications should not make CNAME queries because then they
have to implement their own CNAME-chasing logic which is fraught with
peril. Instead they should query for the final type the application needs,
and let the DNS server handle CNAMEs. (In fact, DNS resolvers also should
not make CNAME queries if they are looking for another type.)

If you query for CNAME at a delegation point, the result you get depends:

  * If the server is authoritative for the parent zone, but not the child
zone, and does not offer recursive service, you will get a referral in
response.

  * If it is a recursive server, and your query has RD=1 (recursion
desired) you should get a NODATA/NOERROR response from the child zone.
The exact contents of the response can depend on the server's
implementation and/or configuration; see RFC 2308 for details.

  * If it is a recursive server, and your query has RD=0, then the
response will depend on the contents of the server's cache.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Humber, Thames: West 4 to 6, occasionally 7 at first in Humber. Slight
or moderate, occasionally rough. Showers. Good.

___
Please 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: How to measure use of forwarders?

2021-09-23 Thread Tony Finch
Parkin, Richard (R.)  wrote:
>
> I’d like to understand how much traffic is flowing to each forwarder
> (QPS, etc) and monitor that for any issues.  Is there a way to do that
> effectively in Bind without putting some kind of network device on the
> outbound path to measure it?  If not, does anyone have any suggestions?

One option is dnstap, though you will need to do your own scripting to get
the numbers you are interested in. You can configure dnstap to log only
forwarded queries so it doesn't have to drink the whole firehose.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Irish Sea, Shannon: West or southwest 4 to 6. Moderate or rough in
Shannon, slight or moderate in Irish Sea. Occasional drizzle. Good
occasionally poor.
___
Please 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: KSK signing zone records

2021-09-01 Thread Tony Finch
raf via bind-users  wrote:
> On Mon, Aug 30, 2021 at 10:13:05AM -0700, Chris Buxton 
>  wrote:
>
> > What algorithm(s) are you using for ZSK and KSK? If they’re not the
> > same algorithm, then both will be used to sign the entire zone.
>
> Just out of curiosity, why is that?
> Isn't having the KSK sign the ZSK enough?

As well as what Mark said, the reason signing is per-algorithm is to do
with downgrade protection: if there's a situation where validators support
different algorithms (e.g. some have deprecated a bad algorithm but some
have not yet deployed its replacement) then a signer can support all the
validators by signing with both algorithms, without causing problems for
the newer validators that want to distrust the old algorithm. A validator
can decide whether a zone is secure or not based purely on the algorithms
listed in its DS RRset.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Northwest Bailey: Southwesterly 3 to 5. Slight. Showers. Good.
___
Please 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: debian11 + bind-9.16.15 + dnssec-policy = lost zonefiles + crashes

2021-08-15 Thread Tony Finch
raf via bind-users  wrote:
>
> But that means that it applies to all of the zones in
> /etc/bind/named.conf.default-zones which is not helpful. It also applies
> to the zones in /etc/bind/zones.rfc1918 if that is included in
> /etc/bind/named.conf.local (which a comment there suggested). That's not
> helpful either.

A tangential point, but I think this kind of setup (with lots of empty
zones) isn't necessary, if you are doing DNSSEC validation and you turn on
synth-from-dnssec - much less configuration clutter.

> Can you sign 127.in-addr.arpa and 168.192.in-addr.arpa?

You can: it's harmless but pointless and wasteful.

> I've come to the conclusion that putting dnssec-policy in the options {}
> stanza, so that it applies to all zones, is a terrible idea. It only
> makes sense (to me) to add dnssec-policy to each individual (real)
> authoritative zone {} stanza.

It makes sense to configure dnssec-policy in one place if you have an
authoritative-only primary server, which is configured with just the zones
that it is signing. (The extra zones in the Debian config are only
suitable for a recursive server.)

> What I found more upsetting, was that my carefully crafted, well
> documented zonefiles in /var/cache/bind had been overwritten by bind so
> as to include the DNSSEC records. It might seem obvious to anyone who
> uses DNS updates that that was going to happen, but I wasn't expecting
> it. It would be great if the DNSSEC guide could be updated to mention
> that this happens, and include advice to keep your zonefile sources
> somewhere other than where bind looks for them.

Yes, this is a relatively common gotcha. You can avoid overwritten zone
files by turning on inline-signing mode, so that your source zone files
are separate from the signed zone files maintained by named. If your
configuration uses dynamic updates or DNSSEC then the zone files are
normally owned by named and will be rewritten, and you are right that
there isn't much warning of this in the documentation.

> But the real problem is that bind crashed, and dumped core, and couldn't
> start at all.

There should be something in the logs to indicate why this might have
happened; failing that a stack trace from the core dump would have been
helpful.

> I have a new question about the process of updating zonefiles when
> dnssec-policy is in use. From now on, I'll have my zonefile sources
> somewhere other than /var/cache/bind (e.g. /etc/bind/zone). When I make
> changes, I'll install them to /var/cache/bind and reload bind9. Bind9
> will replace them with the signed versions. Is it OK for me to modify my
> unsigned sources, install them over the top of bind's signed versions,
> and will bind happily recreate all of the DNSSEC records each time?

No, I'm afraid it's more complicated than that.

You can do what you suggest if the server uses inline-signing mode. If
not, your process will go wrong horribly: you need to use `rndc freeze`
and `rndc thaw` if you are manually editing a zone file that is owned by
named, BUT if you do that with a signed zone, you will lose all the
signatures and it will have to be re-signed from scratch. Not good.

Another alternative is to enable `update-policy local`, and use nsdiff and
nsupdate to make the live zone match your source files.
http://dotat.at/prog/nsdiff/

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Fitzroy, Sole: Westerly or northwesterly 4 to 6 veering
northerly or northwesterly 3 to 5. Rough becoming moderate. Showers
then fair. Good, occasionally moderate.

___
Please 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: Switching key types for authorizing updates

2021-08-12 Thread Tony Finch
John Thurston  wrote:
>
> But as far as I can tell, the name of the key needs to match the hostname in
> the update-policy statement. I can define a new aes-256 key, but it can't have
> the name "foo.bar.baz.com" while the current md5 key is defined. Nor can I
> find a way to craft an update-policy statement line to let a new key with a
> different name manipulate the desired TXT records, while letting the current
> key continue to work.

I think you want something like:

update-policy {
grant "foo.bar.baz.com_aes256" subdomain "foo.bar.baz.com" TXT;
};

i.e. using the "subdomain" rule type instead of "selfsub", so the
domain name (second foo...) doesn't need to match the keyname (first
foo...)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
work to the benefit of all

___
Please 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: AW: AW: Deprecating auto-dnssec and inline-signing in 9.18+

2021-08-10 Thread Tony Finch
Klaus Darilion via bind-users  wrote:
>
> By reading this KB I do not know how the user will be informed which DS
> (or DNSKEY) must be submitted to the parent zone. I know you to convert
> a DNSKEY to DS, but IMO the KB is very good but missest hat point.

I would expect the zone's apex CDS and CDNSKEY records to change, but
neither are mentioned in the KB article.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
a fair voting system for all elections

___
Please 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: Bind doesn't stop contacting global ROOT DNS servers after commenting(#) the the root hint zone in named.conf

2021-08-02 Thread Tony Finch
Ramesh  wrote:
>
> I commented the root hint zone section(default) in the named.conf file to
> stop bind from communicating to the global root DNS servers and it should
> only use the internal forwarders available in the options{} section.

I think the config option you want is `forward only`. The default is
`forward first` which has the fallback behaviour that you observed.

On my servers I don't configure a hint zone: using BIND's built-in hints
and trust anchor reduces the amount of configuration that needs to be
deployed in the chroots and which can go stale.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
the market alone does not distribute wealth or income fairly


___
Please 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: response policy zones (rpz) and views - memory consumption

2021-07-31 Thread Tony Finch
Jiri Hromadka  wrote:
>
> Is there any way to reuse already loaded rpz zone in memory for other
> views ? I know in-view is not an option for rpz, using one master /
> slave zones has same memory effect.

Yeah, in-view would be perfect, if only :-)

You might try setting up a view that only does recursive resolution and
RPZ, and configure the per-client views to forward to the RPZ view.
It's probably also worth configuring a small cache size limit in the
per-client views to avoid too much duplication.

Self-forwarding won't have amazingly good performance but you only need to
worry about that if you are running at many thousands of queries per
second.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Forth, Tyne: North or northeast 3 to 5. Slight or moderate. Showers.
Good.

___
Please 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: named UDP retransmit timeouts ?

2021-07-23 Thread Tony Finch
Jason Vas Dias  wrote:
>
>  Please can anyone advise the best way to optimize named's
>  UDP timeout settings for caching-only local resolver usage
>  over a slow network link - I can't seem to find any in the
>  Bv9ARM document specifically describing how named
>  implements UDP re-transmits - please could someone
>  point me at the right pages or place to look, besides
>  the source code, which I am reading now, if there are any ?

I remember being surprised a while back that the retry intervals
and timeouts were more hard-coded than I expected. (But, be warned! I have
not refreshed my memory.)

The rough idea is that there's a certain amount of co-design between the
libc stub resolver (which back in the day came from BIND) and the
recursive server. IIRC, the libc resolver has a query timeout of 10s and
retries three times (so the overall timeout is about half a minute), and
named's resolver has a timeout of about 3s and also retries 3 times, which
neatly fits inside libc's 10s timeout.

At least that's what my memory tells me, but it may be wrong.

But, I think you will not be successful fixing your problems by tweaking
DNS software. One of the problems with DNS as a protocol is that its
transport layer is very simple and very stupid, so if the underlying
network has problems, the DNS isn't able to fight its way through.

>  My problem is that at home my whole internet goes through
>  one 100M CAT-6 ethernet cable to a GSM 3G/4G modem (90% 3G WCDMA) ,
>  it seems no more than about 128 kilobyte/sec download & less upload
>  bandwidth is available, whenever my browser decides to download
>  something large (like a JavaScript blob) , then DNS requests
>  start timing out, the browser keeps re-issuing its requests,
>  and similar nasty feedback situations occur when the GSM
>  modem's DHCP lease expires and it has to re-setup its NAT for
>  the ethernet link, so all UDP requests time out for about
>  10 seconds, building up quite a backlog.

Ugh, that sounds horrible.

I think the basic problem is that TCP is very aggressive about filling up
whatever bandwidth it thinks might be available, but the DNS is not, and
TCP's congestion control algorithms will happily overwhelm a comparatively
reticent protocol like the DNS.

You probably also have buffer bloat, which makes these problems worse.
(check out https://www.bufferbloat.net/ for LOTS of information)

I am lucky enough that I haven't needed to deal with your problems myself,
so the best I can do is give you a few hints, but no specific advice. The
main idea is to prevent your TCP flows from overwhelming your uplink,
and/or from interfering with DNS traffic. You can (with the right
know-how) do this with some stunt network configuration on your Linux
gateway.

* Use traffic classification and priority queueing to ensure that DNS
  packets can jump ahead of everything else. This probably won't be enough
  by itself because of buffer bloat.

* You can use traffic shaping to ensure that the aggregate traffic from
  your Linux box never tries to over-fill your uplink. Years and years
  ago a friend of mine did this to avoid buffer bloat in their cable
  modem.

* Configure FQ-CoDel on your Linux gateway. This is a queueing algorithm
  specifically designed to avoid buffer bloat and to make TCP back off
  before everything becomes terrible.

That's approximately everything I know about tackling your problem, so I
hope it points you in the right direction...

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Biscay: Cyclonic in far north, otherwise westerly or southwesterly, 4
to 6, occasionally 7 in north. Slight or moderate becoming moderate or
rough. Squally thundery showers. Good, occasionally poor.

___
Please 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: named-checkzone as library?

2021-06-30 Thread Tony Finch
Felipe Gasper  wrote:
>
> Is there any public code interface that exposes named-checkzone’s 
> functionality?
> I’d specifically like to have numeric error codes rather than strings.

It isn't easy to do that, I'm afraid.

There are two places that don't do what you want. The source for
named-checkzone is in
https://gitlab.isc.org/isc-projects/bind9/-/tree/main/bin/check

The file named-checkzone.c has the setup and option handling, and
check-tool.c has some of the zone checks - but not all. It deals with
things like using the system resolver to check CNAME or MX records that
point out of the zone.

There are also a load of checks in lib/dns/zone.c - look for
integrity_checks() and the various zone_check_*() functions.
https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/dns/zone.c

Both lib/dns/zone.c and bin/check/check-tool.c report their findings by
logging; there isn't an intermediate error code that might describe the
problem. And BIND's error codes are simple errno-style numbers: they can't
say multi-parameter things like "foo.dotat.at/MX points to bar.dotat.at
which is a CNAME".

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Utsire, South Utsire: Variable 2 to 4. Slight or moderate. Fog
patches later. Moderate or good, occasionally very poor later.
___
Please 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: Managing localhost

2021-06-25 Thread Tony Finch
Grant Taylor via bind-users  wrote:
> On 6/21/21 11:00 AM, Tony Finch wrote:
> > That advice is out of date: nowadays you should not put any localhost
> > entries in the DNS, because it can cause problems for web browser security.
> > Modern software should suppress queries for localhost so they never reach
> > the DNS.
>
> If I'm understanding the problem correctly, it seems to come down to anything
> involving localhost /except/ fully qualified localhost.(implicit null).

Correct.

As I mentioned in the blog post (link repeated below), I did some data
collection to verify that dropping the localhost subdomains would be safe:
answer, yes, there were basically no localhost queries.

I used to have a bunch of zones related to special-use domain names and IP
addresses, but after BIND 9.12 added support for DNSSEC-based NXDOMAIN
synthesis, I deleted them all. This means that (strictly speaking) my
servers don't conform to RFC 6761's requirements for localhost, but (a) I
can say that it is BIND's bug rather than mine, and (b) it doesn't matter
anyway because the query traffic is negligible.

> > https://www.dns.cam.ac.uk/news/2017-09-01-localhost.html
> > https://datatracker.ietf.org/doc/html/rfc6761#section-6.3


Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Faeroes: Variable 2 to 4, becoming southwest 5 to 7. Slight or
moderate, becoming moderate or rough. Occasional rain later. Good,
occasionally moderate later.

___
Please 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: Managing localhost

2021-06-21 Thread Tony Finch
techli...@phpcoderusa.com  wrote:
>
> This book  :
> https://www.oreilly.com/library/view/dns-and-bind/0596100574/ch04.html  says I
> should manage the localhost within my zone (SOA) and reverse lookup / PTR.

That advice is out of date: nowadays you should not put any localhost
entries in the DNS, because it can cause problems for web browser
security. Modern software should suppress queries for localhost so they
never reach the DNS.

https://www.dns.cam.ac.uk/news/2017-09-01-localhost.html

https://datatracker.ietf.org/doc/html/rfc6761#section-6.3

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
no one shall be enslaved by poverty, ignorance, or conformity

___
Please 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: BIND RPz with IPv6

2021-06-20 Thread Tony Finch
Manish Rane  wrote:
>
> Would be keen to know if BIND RPZ supports IPv6?

Yes, see https://bind9.readthedocs.io/en/v9_16_6/reference.html#rpz

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
sovereignty rests with the people and authority
in a democracy derives from the people

___
Please 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: Using RRL to for TC=1 on all queries

2021-06-20 Thread Tony Finch
John Kristoff  wrote:

> Has anyone configured BIND to force TC=1 responses on all queries using
> RRL?I'd like to do this for some experimentation and measurement
> work, but maybe this just isn't the right tool for that job?
>
> I've tried a number of configurations (e.g. slip=1, rate=0) and I can't
> seem to make this work.  Perhaps it is not possible.

As far as I know, RRL will only truncate responses that exceed the limit,
and the minimum limit is 1. (Zero is interpreted as no limit.) So RRL will
leak at least one non-truncated response per second.

RPZ has a tcp-only action which truncates UDP responses, so if you set up
an RPZ that matches everything, that should allow you to do what you want.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Shannon, South Rockall: Northeasterly 5 or 6, occasionally 7 in
Shannon. Moderate or rough. Showers at first. Good.

___
Please 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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

2021-06-16 Thread Tony Finch
PGNet Dev  wrote:
>
> With a NOTIFY, something like _your_ old listener
>
>  nsnotifyd: handle DNS NOTIFY messages by running a command
>   https://dotat.at/prog/nsnotifyd/
>
> Don't know yet how dusty that is, or relevant to current bind 9.16+, etc. --
> -- but the general 'respond immediately to a NOTIFY' sounds quite useful.

Maaybe. Bare NOTIFY can say which zone's keys have changed, but not
what the state transition is, so it isn't what I would consider to be a
complete solution.

However, NOTIFY as specified is a slightly odd protocol - I say "as
specified" because no-one implements the odd parts, for good reasons. It
allows the initiator to include records in the answer section as a "hint"
about what has changed. There's no security, and no provision for
transmitting more than one rrtype at a time, or for transmitting the new
serial number, so it's fairly useless :-) It also says that future
revisions might specify what it means to have a non-zero number of records
in the authority and/or additional section.

So I think it might be worth using these odd parts for a more complete
NOTIFY-for-keys, something like

opcode = NOTIFY
; question section
qtype = DNSKEY
qname = 
; additional section
name = 
type = TXT
rdata = 

And nsnotifyd would need a little hacking to grab the state transition
code out of the packet. (nsnotifyd is adequate as it is - it works, its
users have not reported bugs - but it is based on very old C resolver APIs
for parsing DNS packets, so it should only be allowed to talk to friends.)

https://datatracker.ietf.org/doc/html/rfc1996

(I remember NOTIFY's RFC number because it is the RFC whose number matches
its year of publication.)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
an equitable and peaceful international order

___
Please 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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

2021-06-15 Thread Tony Finch
Matthijs Mekking  wrote:
>
> A brief summary. Folks that are interested in the reasons why can read
> up and discuss here:
>
>https://gitlab.isc.org/isc-projects/bind9/-/issues/1890#note_220217

So the fundamental design issue here is related to edge-triggered vs.
level-triggered activities, and which is easier to implement both for
named and for the hostmaster's scripts.


With an edge-triggered design you have to avoid falling into the trap of
assuming that exactly-once is possible (it isn't!) so you need a closed
feedback loop with retries. Specifically, for key management, named needs
to be able to say, I have changed the state of this key, and keep saying
that at every key refresh interval until some script confirms that it has
done what it needs to do, before named moves on to the next state. (This
applies to changes like newly created keys that need to be saved, as well
as CDS state changes.)

How should named say that a key has changed? It's a multithreaded program
so it can't fork (not without a single-threaded helper process) so maybe
it should fire off a message to a socket that the script machinery can
listen to. (Maybe abuse NOTIFY for the purpose?) The feedback loop can be
closed using an rndc command.


The questions for a level-triggered design are more to do with
introspection and performance. Introspection: how can I find out the state
of the keys and the state of the world, detect if there is a mismatch,
and know what needs to be done to get the world to match the keys?
Performance: do I have to do this check every hour (or whatever the key
maintenance interval is) for every zone, or is there some way to avoid
futile repeated work?

In a level-triggered design it must still be possible to configure named
not to move on to the next state without confirmation from the script that
it is safe to do so, e.g. using rndc, same as is needed in an
edge-triggered design.


In my case I'm storing keys in a git repository, encrypting the private
parts with gpg, so I need to know about all key state changes, not just
CDS changes. I can implement a level-triggered design using something like
`git status` and/or `git diff` to detect mismatches (assuming my script
only commits to the git repository when it is sure it has updated the
world as required). That will perform OK at my small scale, but I'm not
sure if I have the necessary introspection tools - I guess I'll have to
grovel around in the guts of the key files to find out what needs doing?

An edge-triggered design would be a bit easier since my script would just
receive an instruction and act on it in an idempotent manner. No need for
it to woek out what has changed or what needs doing, and it would clearly
scale per change rather than per zone.


Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
St Davids Head to Great Orme Head, including St Georges Channel: South
or southwest 4 or 5, occasionally 6 near Anglesey, becoming variable 2
to 4 later. Slight, occasionally moderate. Fair at first, then
occasional rain or drizzle. Moderate or good, occasionally poor.

___
Please 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: DOH or DOT Forwarder in BIND and is DOH GA?

2021-06-13 Thread Tony Finch
Walter H. via bind-users  wrote:
>
> DOH/DOT is dead;
>
> use DNSSEC instead and no troubles;

No.

DNSSEC is about data integrity. It allows me to host my zones with a
collection of semi-trusted third parties without having to worry about
them changing my DNS records. It allows clients to be sure they got the
correct data when querying my zones. But DNSSEC does not provide any
confidentiality, and it doesn't protect the protocol parts of DNS packets
such as the RCODE and the EDNS options.

DoH and DoT are the opposite. They provide better confidentiality
(network middleboxes can't see your queries) and better transport
integrity (active attackers can't mess with things like EDNS options), but
they don't authenticate the contents of DNS records.

It is wrong to say that one is better than the other: they are orthogonal.
It's good to deploy either of them, and better to deploy both.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Viking, North Utsire: Southwesterly, veering westerly later, 4 to 6.
Moderate, occasionally rough later. Rain, showers later. Good,
occasionally poor.

___
Please 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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

2021-06-10 Thread Tony Finch
PGNet Dev  wrote:
>
> fyi, perhaps keep an eye on this:
>
>   https://gitlab.isc.org/isc-projects/bind9/-/wikis/BIND-9-PKCS11

hmm, maybe, but it's my Spock eye with a single arched eyebrow

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Thames, Dover: Southwest 4 to 6. Smooth or slight becoming slight,
occasionally moderate later in Thames. Fog banks. Moderate to very
poor.

___
Please 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: hooks in bind's DNSSEC automation to trigger external scripting of DS RECORDS updates, when CDS/CDNSKEY polling is (still) not available?

2021-06-10 Thread Tony Finch
PGNet Dev  wrote:
>
> Has anyone here on-list figured out how to hook bind's internal signing
> process to *trigger* and external script to exec those API pushes?

I have not, and I also want to be able to do this, and I also want
scripting hooks for whenever any keys change so that I can stash them
somewhere safer.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Rockall, Malin, Hebrides: Southwest veering west, 4 to 6, occasionally
7 at first. Rough, but slight or moderate in southeast Malin and
southeast Hebrides. Rain with fog patches, showers later. Moderate or
good, occasionally very poor at first.

___
Please 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: reverse lookup for RFC1918 in view failed

2021-06-06 Thread Tony Finch
MAYER Hans  wrote:
>

I can see why the behaviour of your server is confusing! I'll explain what
is happening in detail below, but here's the basic idea:

Each view in a configuration is separate from the others: `named` first
chooses which view to use (based on match-clients etc.) then handles the
query purely within that view. If a zone is only configured in one view
then that zone configuration will not be used to answer queries that are
handled by another view.

By itself, that basic idea isn't enough to explain what's happening with
your server, so let's look at the details, then I'll outline some
solutions.

> Now the behaviour is the following: When I query from the local IPv6 or
> IPv4 network with „dig -x“ for an IP address I get back „status:
> NXDOMAIN“

In this case your query is matching the "intern" view, which doesn't know
about your RFC 1918 reverse DNS zone, so it resolves the query using the
public DNS, which says NXDOMAIN.

> But when I do the same on the server itself using the loopback addresses
> for IPv6 or IPv4 it works fine. It also works, if the query comes from
> the Internet over IPv4 with NAT or with the public IPv6 address.

In these cases your query is reaching the "fueralle" view, which does know
about your reverse DNS zone.

> If I query „normal forward“ for an IP with a given name then it works in
> any case and from every location. This is interesting because the
> reverse lookup zone and the normal forward zone are both in the same
> view „fueralle“.

This is where it gets complicated! There are two cases:

When you query your forward zone from an external IP address, or from a
loopback IP address, the query is handled by the "fueralle" view, which
knows about your forward zone, so it can answer the query.

When you query from an internal IP address, it is handled by the "intern"
view which doesn't know about your forward zone. So it does normal
recursive resolution, which (I guess!) eventally tells the server to query
itself via the public NAT or IPv6 addresses, so the recursive query is
answered by the "fueralle" view.

If you turn on query logging (and if my guess is right) you should see
two entries in the query log for this last kind of query, one in the
"intern" view, and a matching one in the "fueralle" view.

To make your views behave more consistently, the solution is to make sure
that each view knows about all the zones that it needs to.

So your "intern" view should have your forward zone and your RFC 1918
reverse zone, and your "fueralle" view should only have your forward zone
(because you don't want to publish a private zone on a public server).

There are a couple of ways to make the forward zone appear in both views.

You can use the "in-view" zone configuration option, which makes this view
re-use a zone configuration from another view.

You can continue to rely on the resolver, but that is less reliable
because it will not work if/when your network loses external connectivity.

What you must not do is simply copy the same primary or secondary zone
configuration into multiple views: if you do that, you will have multiple
zone configurations trying to use the same files, and they will conflict
with each other.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Plymouth, Biscay: Variable 2 to 4. Slight or moderate. Mainly fair.
Moderate or good.
___
Please 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: BIND9 Feature Request: inheritance-policy

2021-05-27 Thread Tony Finch
JW λ John Woodworth  wrote:

> Greetings, I would like to request a new feature which I hope will make
> management of the 'allow' match-lists a tad easier.In short, an option
> such as 'allow-transfer' in view or zone contexts could extend the
> match-list as defined in the options section.

You can sort of do what you want already, by defining named ACLs. ACLs can
refer to named ACLs: you can include a named ACL or exclude it. For
example, in my production config, I have some acl clauses roughly like the
ones outlined below.

I like named ACLs and named "masters" lists because they allow our config
generation scripts to use symbolic names to describe a zone's config:
query and xfer ACLs, upstream xfer sources, downstream notify targets. And
when I look at the generated config I see the same symbolic names, so I
have a reasonably consistent and simple vocabulary from the source of all
knowledge through to the run-time config. (And the logs when I have
persuaded the other end to do TSIG!)

acl cudn {
# cambridge university data network address ranges
};

acl mythic {
# mythic beasts xfer and auth servers
};

acl secondaries {
cudn;
mythic;
# some xfers allowed by key instead of address
key tsig-maths;
key tsig-imperial;
};

zone cam.ac.uk {
# blah blah
allow-query { any; };
allow-transfer { secondaries; };
};

zone private.cam.ac.uk {
# etc usw
allow-query { cudn; };
allow-transfer { cudn; };
};

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
work to the benefit of all___
Please 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: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.

2021-05-11 Thread Tony Finch
Stoffel, John (TAI)  wrote:
>
> And it does dump some errors too, which hopefully will give me an idea
> of where my crappy bad record is located, and no use hiding crap:

yuck, this looks like no fun...

> www.cisco.toshiba.com.  3600IN  CNAME   redirect.toshiba.com.
> www.cisco.toshiba.com.  3600IN  RRSIG   CNAME 8 4 3600 20210517093721 
> 20210507083721 38628 t
> oshiba.com. OEmGkGWSPtbjlCGVt5Ejkgncg2wRcbnfCMSm2By6Fl4gN8R1uXx/ucdN 
> hVrdiiP8BHWTIte/fvoMrMXbMHxarPJ
> C6zJn9HHdC9o2dwBoGpknTwJM 
> DYsy8wA5byhT9f8RVLi0WxLDmncWl2vJcZM6wsKfJ5HWAklGh9YxhOar nCM=
> ;; Got bad packet: bad bitmap
> 16358 bytes

does it print more hexdump? who knows where the problem might be in 16KB
of wire-format DNS...

I would try another DNS AXFR client that might not give up so easily, e.g.
if you have a handy copy of perl and Net::DNS, put your Windows DNS server
IP address into this one-liner instead of 127.0.0.1

perl -MNet::DNS -wE 'my $r = Net::DNS::Resolver->new(); 
$r->nameservers("127.0.0.1"); for my $rr ($r->axfr("toshiba.com")) { $rr->print 
}'

The bit of the hexdump you pasted shows another similar CNAME and its
RRSIG, so it isn't very enlightening.

> 46 98 80 00 00 01 00 97 00 00 00 00 07 74 6f 73  Ftos
  headerRR counts qname = zone name
> 68 69 62 61 03 63 6f 6d 00 00 fc 00 01 08 63 69  hiba.com..ci
  00fc = axfr
> 74 69 62 61 6e 6b c0 0c 00 05 00 01 00 00 0e 10  tibank..
backpointer to zone = c00c 0005 = cname

citibank looks like it follows cisco alphabetically which suggests the
zone transfer might be in canonical order, which could perhaps make it
easier to find the stray NXT / TYPE30 record(s)

> 00 0b 08 72 65 64 69 72 65 63 74 c0 0c c0 1d 00  ...redirect.
   cname target  c01d = backpointer to citibank
> 2e 00 01 00 00 0e 10 00 9f 00 05 08 03 00 00 0e  
  2e = rrsig   type covered = 0005 (cname)
> 10 60 a2 39 51 60 94 fc 41 96 e4 07 74 6f 73 68  .`.9Q`..A...tosh
> 69 62 61 03 63 6f 6d 00 83 b6 df 32 9f d9 2a 54  iba.com2..*T
> 65 16 1b 28 09 ac aa b3 41 f0 85 60 e6 e2 18 ae  e..(A..`

etc.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Fisher, German Bight: Variable, becoming mainly west, 2 to 4. Slight
or moderate in Fisher, smooth or slight in German Bight. Showers, fog
patches. Moderate, occasionally very poor.

___
Please 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: ISC Bind as secondary to Windows Server: bad bitmap error on named xfer.

2021-05-11 Thread Tony Finch
Stoffel, John (TAI)  wrote:

> failed while receiving responses: bad bitmap
>
> None of my googling has given me any hints on what this error could be.

I had to look at the source, which told me it's to do with NXT records
which are super obsolete, so I wonder what weird stuff is in the zone that
might cause this.

(The NXT record was a predecessor of NSEC; NXT was badly designed so it is
unable to support all possible DNS RR types, which is why it needed
replacing.)

$ rg 'bad bitmap'
lib/dns/result.c:137:   "bad bitmap",/*%< 94 DNS_R_BADBITMAP */
$ rg BADBITMAP
lib/dns/include/dns/result.h:132:#define DNS_R_BADBITMAP
(ISC_RESULTCLASS_DNS + 94)
lib/dns/rdata/generic/nxt_30.c:154: return (DNS_R_BADBITMAP);
lib/dns/result.c:137:   "bad bitmap",/*%< 94 DNS_R_BADBITMAP */
lib/dns/result.c:278:   "DNS_R_BADBITMAP",

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Viking, North Utsire, South Utsire: Southerly or southeasterly 3 to 5
becoming variable 2 to 4, then northerly 5 to 7 later in Viking and
northern North Utsire. Moderate or rough in Viking and northern North
Utsire, slight or moderate elsewhere. Showers, fog patches. Moderate
or good, occasionally very poor.

___
Please 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: Inline signing fails dnsviz test.

2021-05-10 Thread Tony Finch
Dan Egli  wrote:
>
> Still not working for me. The dig doesn't report anything, and I don't HAVE a
> keyfile since i'm using inline signing. Or does inline signing still require a
> key to be generated?

Yes, you need to do your own key management with inline-signing using
dnssec-keygen. The new dnssec-policy feature can do automatic key
management for you.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Lundy, Fastnet: Southwest 5 to 7, backing southeast 4 to 6 for a time.
Moderate or rough, occasionally very rough in southwest Fastnet.
Thundery rain. Good, occasionally poor.

___
Please 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: Inline signing fails dnsviz test.

2021-05-10 Thread Tony Finch
Dan Egli  wrote:
>
> Where do I get the DS record, since i'm using bind's inline signing?

Use the dnssec-dsfromkey tool, e.g. from a key file (make sure it's the
KSK file)

$ grep This Kcam.ac.uk.+013+32840.key
; This is a key-signing key, keyid 32840, for cam.ac.uk.
$ dnssec-dsfromkey -2 Kcam.ac.uk.+013+32840.key
cam.ac.uk. IN DS 32840 13 2 
2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85

or from your DNSKEY RRset (safest to run this on your primary to be sure
the keys aren't mangled)

$ dig cam.ac.uk dnskey | dnssec-dsfromkey -2 -f - cam.ac.uk
cam.ac.uk. IN DS 32840 13 2 
2BDAF21907420CE792AF02B55071953BC2BDB64B5126710E12AF89F711322B85

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Berwick upon Tweed to Whitby: South backing southeast, 3 to 5,
occasionally 6 at first. Slight or moderate becoming slight. Showers,
perhaps thundery later. Good occasionally moderate later.

___
Please 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: Update DNSSEC Zone

2021-05-10 Thread Tony Finch
Peter Fraser  wrote:
>
> I am using bind-9.14.x and here are the DNSSEC related entries in the zone.
>
> auto-dnssec maintain;
> update-policy local;
> key-directory “zones/domain-keys”;

How you go about this depends on whether your configuration enables
`inline-signing` or not.

If it has inline-signing, you should see in the filesystem that each zone
file has .signed (and possibly .jnl) files alongside. You can update the
zone using

(edit the non-.signed zone file)
rndc reload

If it does not have inline-signing I prefer to use `nsupdate` to update
the zones, usually with my `nsdiff` or `nsvi` tools. Or you can,

rndc freeze
(edit the zone file)
rndc thaw

https://dotat.at/prog/nsdiff/

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Biscay: Southwest 3 to 5 increasing 5 to 7. Rough, occasionally
moderate in east, becoming very rough in west. Thundery showers. Good,
occasionally poor.
___
Please 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: Log queried forwarder IP address

2021-05-06 Thread Tony Finch
Levente Birta  wrote:
>
> I have a caching resolver. Is it possible to log the IP address of the queried
> forwarder without too much overhead?

dnstap might be what you want, but it's a bit intricate.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Irish Sea: Northwesterly 4 to 6, occasionally 7 in north. Slight or
moderate. Showers. Good.
___
Please 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: where are the testing docs ?

2021-05-06 Thread Tony Finch
Dennis Clarke via bind-users  wrote:
>
> Hey there. I looked in the README and I dont see an INSTALL file at all
>  so I have to assume that the testing docs exist somewhere.

Have a look at

https://gitlab.isc.org/isc-projects/bind9/-/tree/main/bin/tests/system

There are some more notes in:

https://gitlab.isc.org/isc-projects/bind9/-/blob/main/doc/dev

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
disperse power, foster diversity, and nurture creativity

___
Please 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: How to return REFUSED

2021-05-06 Thread Tony Finch
Axel Rau  wrote:

> I have,
>
>   allow-query { any; };
>   allow-query-cache { recursive-users; };
>   allow-recursion { recursive-users; };
>
> How can I make sure that none recursive-users get a REFUSED if query is 
> recursive?

Weird! I think your config should do what you want so I wonder why it
isn't working. Your server is responding to the problem queries with a
referral from the root zone, so have you configured your server with a
local authoritative copy of the root?

There's a broader issue here:

Usually when you have a server that is providing recursive service to
anyone, it is best to set the allow-query ACL to cover just your users, so
everyone else gets REFUSED.

This means that your recursive server cannot also be used as an
authoritative server advertised in NS records. Your public authoritative
servers should be authoritative-only and not offer recursion to anyone.

> PS: I want to minimize the responses to this amplification attack:

Ooh, RRSIG queries are fun. They are like a stealth ANY query.

BIND has several tools for dealing with this kind of junk:

  * RRL is very effective

  * minimal-any also minimizes responses to RRSIG queries

  * minimal-responses can also help to reduce packet sizes

Your server is responding with a referral from the root, so minimal-any
won't have any effect on the response. And because it's a referral, the
glue etc. is not optional, so there's nothing that minimal-responses can
omit. So in your situation the most useful things to do would be:

  * tighten up your allow-query ACL

  * if you can't do that, use RRL (you can add recursive-users to the
exempt-clients list)

  * configure separate views for recursive-users and others; do not
include the root zone in your external view

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
The Minch: North 6 or 7, backing northwest 3 to 5. Rough or very rough
at first northeast of skye, otherwise slight or moderate. Wintry
showers. Good, occasionally poor.

___
Please 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: REST API for recursive queries

2021-05-05 Thread Tony Finch
Roee Mayerowicz  wrote:

> I have ~700k (and growing) domain names that should be resolved daily.
> I'm trying to make it efficient as possible using the recursive BIND
> server (do you know a better option?), the goal is to get 2000 queries
> per second with minimum server\s cost.

I do bulk lookups on that kind of scale when I am preparing a recursive
server to go into production. I use this small (250 line) program as a
front end to adns that works the way I like. It can easily manage
thousands of queries per second.

https://git.uis.cam.ac.uk/x/uis/ipreg/adns-masterfile.git

(That URL may stop working within the next few months because we're moving
to GitLab and my old git server will be shut down, though I would like to
find somewhere to host redirection tombstones...)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Foreland to Selsey Bill: Westerly 5 or 6, decreasing 3 or 4,
becoming variable 2 to 4 later. Slight or moderate, becoming slight
later. Showers, occasional rain later. Moderate or good, occasionally
poor.

___
Please 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: REST API for recursive queries

2021-05-04 Thread Tony Finch
Petr Menšík  wrote:

> Because BIND uses DNS protocol only and not any dbus or former lwres
> protocol, you can count only querying -t ANY for single name as
> something similar.

ANY queries don't necessarily give you all the records :-)

In situations where a DNS client wants to do multiple queries at once, it
can either send a load of UDP queries then wait for the answers, or if it
has a TCP connection open, write all the queries in one go, then read the
answers. There's not really much need for fancy features to support
multiple questions when you can do hundreds of concurrent queries with one
or two sockets.

Happy Eyeballs version 2 requires concurrent DNS queries
https://tools.ietf.org/html/rfc8305#section-3

I like to use `adns` for bulk concurrent queries
http://www.chiark.greenend.org.uk/~ian/adns/

Much newer is getdns which has a more JSON-friendly design.
https://getdnsapi.net/

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Biscay: West or northwest 5 or 6, becoming variable 2 to 4 later.
Moderate or rough, becoming moderate. Rain at first. Good,
occasionally moderate.
___
Please 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: DNSSEC upgrade

2021-05-01 Thread Tony Finch
Edwardo Garcia  wrote:
>
> So you mean to say when it print out
>
> IN DS 45701 13 1 5422E9...
> IN DS 45701 13 2 qwertyE9...
>
> we never needed 45701 13 1 5422E9   only   45701 13 2 qwertyE9  ?

Exactly, yes!

> and we only need run
>
> dig @ns0 dnskey guiltyparty.net | dnssec-dsfromkey -2 -f - guiltyparty.net
>
> and enter  in just that one entry?  45701 13 2 qwertyE to the DS in domain
> reg?

Correct!

> and we have been upload both all this years was wrong ?

Well, not wrong, but unnecessary. The tools generally encouraged everyone
to publish both SHA1 and SHA2 DS records even though just SHA2 has been
enough for more than 10 years and SHA1 has had known weaknesses for even
longer.

> hrmm, now I start to understand why not many use DNSSEC so confusing to
> those who not do this every day, or so many instructions around nobody
> knows what works
>
> But we getting there :->

Yes, slowly...

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Shannon, Rockall: Variable 4 or less, becoming southwest 3 to 5 later.
Slight, occasionally moderate in Rockall and at first in Shannon.
Showers. Good.

___
Please 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: DNSSEC upgrade

2021-05-01 Thread Tony Finch
Edwardo Garcia  wrote:

> One thing I note, all check say everything is good, but when using dnsviz,
> it says secure, shows the ecd...  but also puts up warnings that I am using
> alg 13 but digest 1 (sha1), which is not allowed,

I guess the "digest 1" is referring to your DS records. In my guide I
said, get the DS record for the new algorithm like this:

dnssec-dsfromkey -2 Kbotolph.cam.ac.uk.+013+Y

The -2 option forces SHA-2 and avoids the deprecated SHA-1 hash.

Old versions of BIND by default print both SHA1 and SHA2 DS records, and
it's relatively common for zones to have both kinds of DS record in their
delegation.

SHA1 DS records are now discouraged so it's best to replace them with
SHA2, or just delete them if you have both kinds of DS record.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
harness technological change to human advantage

___
Please 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: DNSSEC upgrade

2021-04-30 Thread Tony Finch
@lbutlr  wrote:
>
> I update the last of my zones over a month ago and they are still
> showing alg-7.
>
> I'm sure I missed a step on these specific domains, but there are only a
> handful that are still using alg-7 and many more that are now on alg-13
> only.

Hmm, curious!

If you have swapped the DS records already, then all that is left to do is
remove the remains of the old algorithm. Have a look at the keys for the
problem zones like this:

grep ^ Kexample.com.*.key

The algorithm 7 keys should all have inactive and delete times. If some of
the times are missing then you can fix it by re-doing the "decommission
old algorithm" step in my notes. It should get cleaned up immediately.

https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

If that doesn't fix it, then the problem is elsewhere...

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Forties, Cromarty, Forth: North or northeast 2 to 4. Slight
occasionally moderate. Showers. Good.

___
Please 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: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

2021-04-30 Thread Tony Finch
Robert M. Stockmann  wrote:
>
> Does bind 9 need C11 atomics ?

Yes. BIND used to have its own atomic implementation but that kind of code
is tricky and arcane, so it's better to use the standard implementations
in the C library.

It is not just a matter of the hardware BIND runs on: atomics rely on
memory barriers that the compiler needs to know about, so that it does not
move code out of a critical section when reordering things for
optimization. And BIND is always multi-threaded and pre-emption can
happen at any time even on a single CPU.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
champion the freedom, dignity, and well-being of individuals

___
Please 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: DNSSEC upgrade

2021-04-30 Thread Tony Finch
Edwardo Garcia  wrote:
>
> One question however it talk about longest TTL, does this mean also root
> TLD zones (.com, .net) which from memory are 48 hours, so before we delete
> old keys we need wait 48 hours, even though our zone TTL was 24 ?

When you are waiting after adding and signing with the new keys and before
swapping the DS records, it's only the longest TTL in your own zone that
matters. In my notes I call this the "child TTL" because the root and TLD
etc. don't matter.

https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

When you're waiting for the DS TTL it's only the TTL of that particular
record that matters. (It's in the parent zone so I called it the parent
TTL.) To be sure you are getting the right number you will need something
like:

dig +ttlunits example.com ds @$(dig +short com ns | head -1)

i.e. pick one of the nameservers of the parent zone and ask it for your
zone's DS record, so you don't get mislead by decremented cached TTLs.
Note the DS TTL is often not the same as the parent NS or glue TTL.

> Thank you, wow much much easy than I hoped for :-)

I'm happy it helped!

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Biscay: North, backing northwest later, 2 to 4, occasionally 5 later
in east. Slight. Showers. Good.

___
Please 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: DNSSEC upgrade

2021-04-27 Thread Tony Finch
Edwardo Garcia  wrote:
>
> Many year ago we set up DNSSEC, our key were generated with sha1 as was
> recommended way back all them years. We too are not DNSSEC guru, so some
> answer may be simple

Well, you are going to do an algorithm rollover, which is one of the more
tricky things you can do with DNSSEC. So, plan to do some testing, a trial
run, with a spare zone that you can break without worrying.

If you like to understand things by getting an idea of the wider context
then there are a couple of RFCs on the general subject of key rollovers.
The parts that are most relevant are the algorithm rollover section in RFC
6781 and the double-KSK section in RFC 7583.

https://tools.ietf.org/html/rfc6781
https://tools.ietf.org/html/rfc7583

DNSSEC has got easier since those RFCs were written, so you might as well
just skip to the howto bits below :-) It turns out, I wrote most of this
reply over a year ago...

> Also we use ZSK -b 1024 and KSK -b 4096
> even modern google from apnic show example  ZSK of only 1024? is this still
> secure?

The current recommendation for DNSSEC algorithms is:

  * you already know you want to choose something based on sha256 - it's
secure enough, so there's no need for bigger hashes

  * ecdsa-p256-sha256 (13) is the best choice, because it is widely
supported and produces small signatures

  * if you must use RSA, use 2048 bit keys for both zsk and ksk. 1024 bits
is not secure; 2048 has a roughly comparable security level to sha256
(112ish bits vs 128 bits); 4096 is big and slow and probably not worth
the cost

  * I would like to be able to deploy ed25519 (a better elliptic curve
than p256) but it is not yet supported well enough

> Is best practise for doing this, replacing the keys completely, more or
> less like start fresh again?
>
> We do use inline signing and automatic maintain.

I did a wholesale algorithm rollover from RSASHA1 to p256 around the end
of 2019 and I wrote an algorithm rollover guide for colleagues in other
parts of our university who run their own DNS. It's basically three steps
with lots of waiting in between:

https://www.dns.cam.ac.uk/news/2020-01-15-rollover.html

The "Semi-automated DS updates" section probably isn't relevant to you,
and the "Future" section has been made obsolete by dnssec-policy. But the
rest of it should guide you through the essentials.

(Also, the RIPE NCC does now support CDS records.)

And use these DNS checking services to verify that it is working as
expected:

https://dnsviz.net/

https://zonemaster.net/

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Rattray Head to Berwick upon Tweed: North or northeast 4 or 5,
occasionally 3 later. Slight or moderate. Showers. Good.

___
Please 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: Per server instance vs central / shared / redundant instances of BIND

2021-04-27 Thread Tony Finch
Grant Taylor via bind-users  wrote:
>
> Do you think that per (mail) server instances of BIND are worth the additional
> administrative overhead as compared to more central shared instances?

Yes, that's what I did when I was doing mail things. There are a few
reasons: reduce load on the shared central resolvers; reduce the latency
of anti-spam blocklist lookups; better fate-sharing between the SMTP and
DNS parts of the mail service.

There's not much overlap between the kinds of queries done by mail servers
and other DNS users, so there's limited benefit from sharing a single
cache. There probably is benefit from sharing a DNS cache between multiple
mail servers, but from my point of view it was easier to have one kind of
machine that does SMTP + DNS than two different flavours of machine. (The
admin effort is per flavour, not per server.)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Cape Wrath to Rattray Head including Orkney: Northeast 3 to 5 backing
north 3 or 4. Slight or moderate. Showers. Good.

___
Please 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[2]: Configuring the location of named .jnl files

2021-04-27 Thread Tony Finch
Anders Löwinger  wrote:
> Ivan Avery Frey  wrote:
> >
> >We are only using update to provision the acme challenge as described
> >by RFC 8555 8.4. Nothing else.
>
> Acme follows CNAMEs. I've redirected all challenges to my domains to a
> separate subdomain, which allows dynamic updates. Works great!

Yes, there's an item about this on the EFF blog:
https://www.eff.org/deeplinks/2018/02/technical-deep-dive-securing-automation-acme-dns-challenge-validation

I wrote a followup which might be of interest on this list even though it
isn't relevant to this specific problem:
https://fanf.dreamwidth.org/123294.html

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression
___
Please 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: Configuring the location of named .jnl files

2021-04-26 Thread Tony Finch
Ivan Avery Frey  wrote:

> I'm trying to obtain certificates from Let's Encrypt using the DNS-01
> challenge method.
>
> I just want to confirm that there is no option to configure the
> directory for the .jnl files independently of the zone files.

You have had a bunch of helpful replies already, but your question
suggests to me that you might be making things more difficult than they
need to be. I have tried out configurations with non-default journal names
and I've decided it's more trouble than it is worth. For example, I added
the -J option to named-compilezone to improve support for custom journal
names, but the -j option for default journals is significantly more
convenient. And it's much nicer when I don't have journal options in every
zone{} clause in my config.

I know what they say about assuming, but I'm going to guess that you want
to put the jounal in a different directory because `named` complained that
it did not have write access to the directory containing your zone file.
If I'm right, you will soon find that `named` also wants to overwrite your
zone file, and the message I sent yesterday will probably be helpful:

https://lists.isc.org/pipermail/bind-users/2021-April/104472.html

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Dover, Wight, Portland, Plymouth, North Biscay: Easterly or
northeasterly 5 to 7, decreasing 3 or 4 later, then becoming variable
later. Slight or moderate, becoming smooth or slight, occasionally
rough at first in Plymouth and north Biscay. Fair. Good.

___
Please 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: Using RNDC to control remote access to my BIND server

2021-04-26 Thread Tony Finch
Anand Buddhdev  wrote:
>

Anand's advice is good, as usual :-)

But a small pedantic point:

> The DNS protocol itself has recently been updated to allow for
> encryption, using DTLS (DNS-over-TLS).

DTLS usually means "datagram TLS", i.e. TLS-over-UDP (RFC 6347). There's a
spec for DNS-over-DTLS (RFC 8094) but I have not seen much enthusiasm for
deploying it: DTLS combines all the disadvantages of UDP with all the
disadvantages of TLS. (Or worse: DTLS has a more complicated state machine
than normal TLS so there have been a bunch of DTLS-specific
vulnerabilities which makes me very reluctant to deploy it.)

There is a lot more enthusiasm for DNS-over-TLS (aka DoT) and
DNS-over-HTTPS (aka DoH), and maybe in the future DNS-over-QUIC.

But right now, none of these are particularly easy to get working as
transports for UPDATE, and as Anand said, it usually isn't necessary.

I'm looking forward to zone transfers over TLS, because public key
authentication (with client certificates) is a bit easier to deploy
between different organizations than TSIG secret key authentication.
There's not such a clear benefit for UPDATE-over-TLS where I'm sitting,
apart from the neatness of having all authenticated traffic over TLS.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Bailey: Northeast 5 to 7. Moderate or rough. Showers at first. Good.

___
Please 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: nsupdate and zone files, was Re: Using RNDC to control remote access to my BIND server

2021-04-25 Thread Tony Finch
Paul Kosinski via bind-users  wrote:

> A couple of years ago, I tried using nsupdate to modify a dynamic (DHCP)
> IP address for my very simple domain. It worked, except that it totally
> messed up the organization of the zone file. Since the file only has 44
> active lines (which are organized logically), I maintain it by hand.
> After nsupdate made the one line change, the zone file became
> unmaintainable.
>
> Was this a bug in nsupdate, or does nobody try to understand their zone
> files.

When you have a zone that accepts dynamic updates, then its zone file is
owned by `named`, and `named` will rewrite the file to incorporate
updates, which (as you saw) also strips out comments and canonicalized the
formatting. This is often surprising and upsetting to people who are new
to dynamic updates - you are not alone!

Basically, if you are doing dynamic updates, then the source of truth for
your zone needs to be somewhere else, not the zone file used by `named`.
(For example, at my work our zones are stored in a database and edited
with a web front end.)

I have some scripts which allow you to maintain your zone file however you
want, and push any differences into `named` using `nsupdate`, so you never
need to touch the zone files that it owns. https://dotat.at/prog/nsdiff/

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Lyme Regis to Lands End including the Isles of Scilly: Easterly or
northeasterly 5 to 7, occasionally 4 in east. Moderate or rough. Fair.
Good.

___
Please 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: Using RNDC to control remote access to my BIND server

2021-04-22 Thread Tony Finch
Greg Donohoe  wrote:

> I have created a CI/CD pipeline in order to amend zone files using nsupdate
> based on a front end user request. This portion of the pipeline is working
> as expected so now I want to be able to connect from my pipeline runner to
> my remote BIND staging server and update the zone files on there with my
> newly updated zone file.

If you want to make the same change on the remote server that you made
locally, can't you use nsupdate again but point it at the remote server?
Or is there something more complicated going on?

Use ddns-keygen to create a TSIG authentication key and add the key to the
allow-update ACL on the remote server.

(You can also add your own TSIG keys to allow remote control with `rndc
-s`, but it sounds to me like rndc is a red herring.)

There's also my `nsdiff` program https://dotat.at/prog/nsdiff/
which can make a zone on a remote server look like a local zone
file using nsupdate.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Utsire, South Utsire: Northerly or northwesterly 4 to 6,
occasionally 7 at first in eastern South Utsire. Rough at first in
eastern South Utsire, otherwise moderate. Showers. Good.

___
Please 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: Ask for automated KSK roll with DS checking

2021-04-15 Thread Tony Finch
Matthijs Mekking  wrote:
> On 15-04-2021 16:35, Bob Harold wrote:
> >
> > If BIND holds both the child and parent zone, will it add the DS record
> > at the correct time?  Or do I still need to write scripts to update the
> > DS records in all my sub-zones?  And is there some signal from BIND at
> > the time the DS record should be written, or do i need to calculate the
> > right time?
>
> Currently you still have to write scripts to update DS records in all
> your parent zones.
>
> The CDS/CDNSKEY records are published in the child zones that indicate
> the DS should be published, so I would script against that.
>
> Then when the DS is seen in the parent, call the rndc dnssec -checkds
> published/withdrawn command.

dnssec-cds can tell you what the parental DS record(s) should be. It
can maintain a dsset file for each child zone that you can $INCLUDE in the
parent. It's fairly bare so it needs to be wrapped with a script that does
the necessary queries and updates.

I don't know if the dnssec-policy stuff includes timing parameters or
checks to protect against parental publication delays; if not then the
wrapper script will have to keep track of time or poll the parent servers
or something.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Fair Isle: South 3 to 5, occasionally 6 later. Slight or moderate,
becoming rough later in west. Fair. Good.___
Please 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: Preventing a particular type of nameserver abuse

2021-04-14 Thread Tony Finch
Peter Coghlan  wrote:
>
> I wouldn't describe it as background radiation or probes.  It doesn't seem
> to be caused by misconfigured or faulty resolvers or anything of that nature.

Hmm, maybe air pollution would be a better metaphor? What I mean is the
kind of continuous low levels of abuse that's definitely harmful in
aggregate, but it's not clear who is responsible or what can be done about
it. These sl/IN/ANY queries are exactly the kind of thing I had in mind.

> It is possible for me to apply filtering that catches most or maybe all of
> this but this only fixes the problem on my server and does nothing to prevent
> the abuse of lots of other servers out there.

Yeah, it's a wicked problem. There's very little one can do as a server
operator except for relatively limited mitigations. The real fix is to
trace back the traffic and do malware analysis of the sources and all that
fun forensic blue team stuff that is a very long way away from my job or
abilities :-) Before DNS I did anti-spam stuff for several years so I have
had to make peace with protecting my systems and users from the worst of
the abuse, without being in a position to do much about the causes, other
than helping to keep our networks clean.

> Instead, isn't it the case that bind knows what domains it is authoritative
> for (or which ones it is supposed to be authoritative for) and bind is
> therefore in the ideal position to know which queries are abusive and which
> are not rather than wrapping kludgy filtering mechanisms around it?

Not always, sadly, because of misconfigured (lame) delegations. See the
earlier messages from me and Ondřej -

https://lists.isc.org/pipermail/bind-users/2021-April/104408.html

https://lists.isc.org/pipermail/bind-users/2021-April/104423.html

> If there is a resistance to having bind ignore the abusive queries
> altogether, could we at least have something like "errors-per-minute 1"
> which would reduce the problem by a factor of 60 compared with
> "errors-per-second 1"?  "errors-per-hour 1" would be even better still :-)

There is probably something that might improve things, but I'm not sure
what it is. I think the minimum RRL rate of 1 per second might be intended
to work with resolver retry times. I'm wary of suppressing error responses
without thinking through the possible consequences.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Viking, North Utsire, South Utsire, Forties: Northerly or
northwesterly 3 to 5, becoming variable 3 or less later. Moderate
becoming slight. Showers. Good.
___
Please 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: Preventing a particular type of nameserver abuse

2021-04-14 Thread Tony Finch
sth...@nethelp.no  wrote:
>
> Agree that you should be able to ignore them. But as a practical matter,
> ignoring them *may* result in the question being asked again and again,
> while REFUSED *may* stop the client from asking more.

REFUSED leads to retries too: if the client is a legit resolver it will
retry using the other authoritative servers. For example, when I changed
private.cam.ac.uk from refusing external queries to replying with an empty
answer, the load on our auth servers dropped by half.

Retries following REFUSED are also one reason why the RFC 8482 minimal-any
option is not refuse-any: when an ANY attack is bouncing off a recursive
server, the authoritative server can reduce the power of the attack by
returning a small cacheable answer. This reduces the load on the
authoritative servers (no retries), and on the recursive servers (no need
to recurse and retry), and reduces the volume of the attack traffic.

Probe traffic like these sl/IN/ANY queries is a very different matter. I
wouldn't expect any kind of reasonable behaviour, so it makes sense to
drop the queries as early as possible.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Fitzroy, Sole: Easterly or southeasterly 4 to 6. Moderate or
rough. Showers at first in northwest Fitzroy, otherwise fair. Good.

___
Please 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: Preventing a particular type of nameserver abuse

2021-04-13 Thread Tony Finch
Anand Buddhdev  wrote:
>
> A legitimate client, following a normal chain of referrals, has *no*
> reason to query a server for zones it is not authoritative for.

That's true for cases like .sl and other domains whose delegations are set
up correctly, but if a server is accidentally lame then it's helpful to
return REFUSED so that resolvers don't have to wait for a timeout before
trying other servers. A quick REFUSED will also avoid messing up the
resolver's per-server statistics that might interfere with queries for
authoritative zones.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Southwest Fitzroy: Southeasterly 5 to 7, becoming variable 2 to 4 at
times in south. Moderate or rough, occasionally slight in south.
Thundery showers, fog patches. Moderate, occasionally very poor.

___
Please 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: Preventing a particular type of nameserver abuse

2021-04-13 Thread Tony Finch
Peter Coghlan  wrote:
>
> I have a nameserver which is authoritative for three or four domain names.
> It receives around 1000 queries per day that could be regarded as plausably
> legitimate.  It receives around ten times that number of absive queries per
> day from presumably spoofed ip addresses, the vast majority of them IN ANY
> queries for the "sl" domain or for the root nameservers all of which my
> nameserver responds to with return code 5 ie refused.

There have been several helpful replies, but to be honest I wouldn't spend
too much effort on low levels of abuse unless you want to use it as a
learning exercise. (I would care if it was multiple abusive queries per
second...)

> I have tried "errors-per-second 1" and this seems to reduce the abuse
> by about four fifths but one fifth of it still manages to get through
> and I don't find this acceptable.

RRL is designed to avoid interfering with legitimate traffic, but that
does mean that some abuse traffic leaks through. Its aim is to stop
amplification, so that the attackers don't get any benefit from abusing
your server.

But it sounds to me like your problem traffic is more like background
radiation (e.g. probes) than active abuse; if so it's likely that RRL will
not deter them.

> Instead, when I notice particularly heavy abuse of my nameserver,
> I apply packet filtering to prevent the abusive queries from reaching
> my nameserver and therefore to prevent it responding to them.

If all the problem traffic is sl. IN ANY, then I suggest permanently
leaving in place a filter to drop those queries. Use a string match rule,
like Grant Taylor suggested, but match the queries instead of the
responses, so they don't clutter your query logs.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Southwest Shannon: Southeasterly 4 or 5 increasing 6. Moderate
becoming rough. Fair. Good.

___
Please 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: forwarding zone setup from a BIND slave (without recursion?)

2021-04-07 Thread Tony Finch
Mark Andrews  wrote:
> > On 8 Apr 2021, at 00:37, Tony Finch  wrote:
> >
> > Forward zones require the upstream server to be recursive too.
>
> More correctly, the upstream server has to serve the entire namespace being
> forwarded if it does not off recursion to the client for forwarding to
> work.

I thought forwarding expected the target server to resolve CNAMEs? If so,
any out-of-zone CNAMEs in the target namespace would cause problems.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Cape Wrath to Rattray Head including Orkney: Southwesterly 6 to gale
8, occasionally 5 at first in east, then veering westerly or
northwesterly 7 to severe gale 9 later. Moderate or rough, becoming
very rough or high in north. Rain at times, squally snow showers
later. Moderate or good, occasionally very poor later.

___
Please 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: forwarding zone setup from a BIND slave (without recursion?)

2021-04-07 Thread Tony Finch
Chuck Aurora  wrote:
>
> A stub or static-stub zone would not require recursion.  In that case
> named is asking for authoritative data from upstream.  But type
> forward zones indeed cannot work if recursion is disabled.

Be careful in this kind of situation to be very clear about which client
or server is doing what: in this case, it isn't clear what doesn't require
recursion for stub or static stub.

All three types of zone configuration (stub, static stub, and forward)
are only useful on a server that is providing recursive service.

Forward zones require the upstream server to be recursive too.

Stub and static-stub expect the upstream server to be authoritative;
the stub server list is a hint that gets replaced by the authoritative
server list from the zone (a bit like the root hints) whereas static-stub
only uses the configured upstream servers.

> > What I've learned from this list is that you should split
> > authoritative and recursive service.
>
> I would suggest that as a general best practice, but not an absolute
> one.  There's nothing wrong with having internal-only authoritative
> zones on your recursive resolver.  The potential problem comes when
> you're a globally-published NS for your zones; having recursion
> enabled can make you vulnerable to more possible attacks.

Right: the rule is that authoritative servers listed as targets of NS
records should be authoritative-only; it's OK if recursive servers have
authoritative copies of zones: it can make them more resilient to outages,
though it does slightly weird things to DNSSEC validation.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Whitby to Gibraltar Point: Northwest 4 to 6 becoming variable 2 to 4,
then southwest 4 to 6 later. Very rough at first in north, otherwise
moderate or rough. Snow showers, then rain for a time later. Good,
occasionally very poor at first.

___
Please 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: replication time for dynamic records from primary to secondary servers

2021-04-03 Thread Tony Finch
Cuttler, Brian R (HEALTH) via bind-users  wrote:
>
> I don't think the issue I'm having is related to notify message not
> being reacted to nor zone transfer requests not being sent to answered.

It's worth checking the logs to make sure that they agree with what you
expect.

> What I think I'm seeing is DHCP updating the DNS primary, which works
> correctly, but I don't believe it updates the SOA serial number nor
> sends a notify message.

The server is required (by RFC 2136 section 3.6) to update the serial
number after an UPDATE. I would not expect any delay unless the server is
in the middle of a lot of updates and has reached a notify or transfer
rate limit - the logs should tell you if that has happened, or if there
are any ACL-related problems.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Gibraltar Point to North Foreland: Northeasterly backing northwesterly
3 or 4, occasionally 5 at first, backing southwesterly 4 to 6 later.
Slight or moderate, becoming mainly slight. Fair. Good.


___
Please 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: Local resolution first and then public resolution for "google.com" domain

2021-03-31 Thread Tony Finch
Matus UHLAR - fantomas  wrote:
>
> note that for this kind setup, using dnsmasq with two forwarders and
> www.google.com
> overriden through /etc/hosts would be easier solution.

Or a response policy zone, if you don't want to switch software

https://bind9.readthedocs.io/en/v9_16_13/reference.html#rpz

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Forties, Cromarty, Forth: Northeast 5 to 7, backing north 3 to 5.
Slight or moderate. Rain at first. Good, occasionally poor at first.


___
Please 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: resolv.conf question / timeout behaviour

2021-03-31 Thread Tony Finch
Tom Preissler  wrote:
>
> at my work place we have a three resolver setup in /etc/resolv.conf.
>
> We had sometimes, though rarely, response times for DNS like 14000ms,
> due to the fact that the *first* listed resolver is down for maintenance
> reasons.

Sadly the traditional unix stub resolver behaves REALLY BADLY if any of
its servers are unavailable. It does not keep enough information about
server performance and isn't really designed to be able to do that. The
resolv.conf tuning options are too coarse to help in any meaningful way.

Because of this, if it's important for you to avoid multi-second DNS
lookup times (and it usually is!), you need to design your system so that
the libc resolver never tries to talk to a DNS server that isn't
available.

As Matus Uhlar said, one way is to run a resolver daemon (e.g. BIND
configured to forward to your recursive servers) on each machine. Resolver
daemons are better able to keep track of which server is up, and they are
less likely to be unavailable when the client software needs them since
they are on the same machine. Most operating systems have resolver daemons
now; it's bascially only oldskool unix that needs extra setup.

Another way is a high availability setup for your recursive servers. I use
keepalived (my servers are on a resilient layer 2 network that spans
multiple locations); or you can use anycast if you need to do failover at
layer 3.

Of course, you can do both :-)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Faeroes: North backing west 5 or 6, decreasing 3 or 4 for a time.
Moderate or rough. Fair. Good.

___
Please 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: replication time for dynamic records from primary to secondary servers

2021-03-31 Thread Tony Finch
Cuttler, Brian R (HEALTH) via bind-users  wrote:
>
> We are seeing a delay in the primary DNS server updating the secondary
> and would like to shorten that interval.

This is probably due to NOTIFY messages not working. NOTIFY is the
mechanism that allows primary servers to tell secondaries to get the
latest version of a zone promptly. I wrote some notes on debugging slow
zone transfers a couple of weeks ago:

https://lists.isc.org/pipermail/bind-users/2021-March/104278.html

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Fair Isle: North 5 or 6, decreasing 3 or 4, then backing northwest 4
or 5 later. Moderate or rough, becoming slight or moderate. Mainly
fair. Good.

___
Please 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: BIND 9.16.13 and Mac OS X 10.13.6 - problems with ./configure

2021-03-29 Thread Tony Finch
alcol alcol  wrote:

> seriously? is like linux/unix FAQ 

Please, if you can't be helpful, don't reply at all. We all have to learn
somehow, and the best way to show your knowledge is to share it generously.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Trafalgar: Easterly 6 to gale 8 in southeast, otherwise mainly
northeasterly 4 to 6. Moderate or rough. Thundery showers. Good,
occasionally moderate.
___
Please 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: BIND 9.16.13 and Mac OS X 10.13.6 - problems with ./configure

2021-03-26 Thread Tony Finch
Paul Cizmas  wrote:

> ~$ named -v
> BIND 9.9.7-P3 (Extended Support Version)

What's probably happening here is that the BIND on your $PATH isn't
necessarily the BIND that homebrew installed and (hopefully) is running.

You can run `dig @localhost version.bind ch txt` to see what the running
server reports as its version.

You can run `which named` to find out where it is finding 9.9.7.

If you run `rndc status` it should fail, because of the mismatched
installations (I expect your 9.9.7 will not look for the rndc key in the
same place as 9.16.3) but `/usr/local/opt/bind/sbin/rndc status` ought to
work and tell you about the running 9.16.3.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Great Orme Head to the Mull of Galloway: Southwest veering west 6 to
gale 8, backing southwest 5 to 7 later. Moderate, occasionally rough.
Squally showers, rain later. Good, occasionally moderate.

___
Please 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: how to stop and remove BIND 9.9.7-P3 on Mac OS X High Sierra 10.13.6?

2021-03-25 Thread Tony Finch
Paul Cizmas  wrote:
>
> but it appears that “service” must be replaced by something else

Yes: init on macOS is called launchd, and the service control program is
called launchctl, which has a reasonably useful man page.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and
North Channel: Southerly or southwesterly, veering westerly for a
time, 5 to 7, occasionally 4 later. Slight or moderate. Rain or
squally showers. Good, occasionally poor.
___
Please 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: Temporarily no name resolution using second/virtual ip address

2021-03-25 Thread Tony Finch
Jonathan via bind-users  wrote:

> It makes no difference from which subnet the queries come from. For
> testing I used a server in the same subnet like my DNS is, so there is
> no firewall or NAT in between. I also captured the network traffic of
> the DNS-Server and -Client. All I can see is, that the server receives
> the query from the client, but no response is sent from the server. When
> I run dig with the +tcp option, all of the queries will be answered.

Do you have a firewall configured on the server itself? If so does it have
the correct idea about which ports and addresses BIND is listening on?

The other possibility is reverse path filtering - Linux tries to ensure
that packets don't traverse an interface with unexpected addresses. I had
to turn it off on my recursive servers because they have interfaces on two
different VLANs. Dunno if it could cause problems with just one subnet in
play.

set sysctl net.ipv4.conf.XXX.rp_filter=2 where XXX is all, default, and
whatever your ethernet interface is named.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
North Utsire, South Utsire: Southwesterly 5, backing southerly 6 or 7,
occasionally gale 8 in North Utsire. Moderate or rough. Showers. Moderate
or good.

___
Please 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: Zone transfer is happening intermittently between slave and master bind

2021-03-17 Thread Tony Finch
Prasanna Mathivanan (pmathiva) via bind-users  wrote:
>
> I couldn’t find anything from logs (checked both xfer and messages)

The best way to find out if a secondary server thinks a zone is
out-of-date is to look at the notify log messages. On the primary you'll
see something like

17-Mar-2021 12:36:28.311 notify: info: zone cam.ac.uk/IN:
sending notifies (serial 1615984588)

and on a secondary you will see

17-Mar-2021 12:36:28.812 general: info: zone cam.ac.uk/IN/main:
notify from 2001:630:212:8::d:aa#43432: serial 1615984588

followed by xfer-out (on the primary) and xfer-in (on the secondary). The
xfer messages tell you how much of the zone was transferred but not the
serial number.

or if the zone is in sync you will see

17-Mar-2021 12:20:36.985 general: info: zone cl.cam.ac.uk/IN/main:
notify from 128.232.0.19#44340: zone is up to date

If the log messages do not match up like this then something isn't working
properly, such as the allow-notify ACL on the secondary - check there
aren't any erroneous "refused notify from..." messages in the secondary's
logs.

You can run `rndc notify` on the primary to trigger it on demand, which
can make debugging a bit more convenient. You can use `rndc zonestatus` on
the primary and secondary to see what they think the serial numbers are,
so you know whether the notify should trigger a transfer or not.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Wight, Portland, Plymouth: Northwest veering north or northeast, 3 to 5.
Slight or moderate. Mainly fair. Mainly good.
___
Please 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: sub-zone on the same server but in different backend - how?

2021-03-15 Thread Tony Finch
lejeczek via bind-users  wrote:
>
> Have a zone on a server, say:
>
> - the.zone
>
> with "flat" files being the backend for it. Now wanting to have:
>
> - sub.the.zone
>
> served by the same BIND server, but stored in.. "SQL" backend.
>
> How... well how to make that work if at all possible?
> I'd hope it can be done with some "trickery" in config/zone files if it is not
> 'easy-peasy'

It's easy if you think about it the right way :-)

That is, there are two separate things that you need to do to set up a
zone:

  * In the DNS, in the contents of the parent and child zones, you need to
set up the proper NS records at the delegation point in the parent
zone, and at the apex of the child zone. (Plus whatever other records
your delegation might need, such as nameserver A/ records and
DNSSEC)

  * On the servers, configure your DNS software to host the zone.

This is true regardless of how your zones are stored or how your DNS
software is configured.

So for example, if I have a parent zone (e.g. dotat.at) with an
experimental delegation (e.g. ed25519.dotat.at) and the child zone is only
hosted on the primary server, I just put that server in the NS records,
e.g.

ed25519.dotat.at.   NS  onyx.dotat.at.

in both parent and child zones.

That's the first point dealt with.

Regarding the second point, in my example the two zones have very similar
zone{} configurations: they both use "raw" files on disk. But they could
use different storage back-ends if I wanted. For that I would need a dlz{}
or dyndb{} clause to configure the backend. I haven't tried either of them
myself, so I haven't talked about how you actually get the data into a
SQL backend - this is as far as I can help :-)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Malin, Hebrides, Bailey: South 4 or 5, veering west or northwest 5 to 7,
occasionally gale 8 later except in Malin. Moderate or rough, occasionally
very rough in north Bailey. Rain and fog patches. Moderate, occasionally
very
poor.

___
Please 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: Authority and forwarding, but not recursion/iteration

2021-03-12 Thread Tony Finch
Marki  wrote:
>
> But if you need granular filtering, that could become a lot of views...

Yes, I think RPZ is really designed to be a ban hammer for dealing with
abuse, rather than a general-purpose access control mechanism. If you need
to get really fancy then you should look at dnsdist which can be
programmed in Lua.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Fitzroy: Westerly 4 to 6 in south, otherwise 7 to severe gale 9. Rough in
south, otherwise very rough or high. Showers, squally in north. Good,
occasionally poor.

___
Please 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: Authority and forwarding, but not recursion/iteration

2021-03-09 Thread Tony Finch
Marki  wrote:
>
> Concerning static-stub: Using a (bogus) forwarder together with "forward
> first" (default) seems to work (Note: using "forward only" gives SERVFAIL).
> All outside requests get a SERVFAIL even with "forward first" but that's an
> esthetic problem.

Yes, SERVFAIL is ugly - I should have mentioned that.

> I'm not sure about the flexibility of RPZ; it doesn't seem that I can
> have rules like "client 1.2.3.4 is allowed to look up example.com but
> client 1.2.3.5 is not".

You can have multiple response-policy zones, which are matched in the
order they are listed in the configuration. You could perhaps have a zone
listed early that uses RPZ-CLIENT-IP triggers and a PASSTHRU policy for
non-sandboxed clients, then have a zone containing QNAME triggers (with
liberal use of wildcards) and PASSTHRU policy (again) for just the
permitted internal names, and finally a catch-all zone (wildcard to match
any qname) with an NXDOMAIN policy to deny external names for sandboxed
clients. (You can equally well combine the first two into a single zone,
depending on whether you want more single-purpose RPZs or fewer
multi-purpose ones.)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Forties, Cromarty, Forth: South or southeast 5 to 7, increasing gale 8 or
severe gale 9 for a time. Slight or moderate, becoming rough later,
occasionally very rough except in Forth. Rain. Good, becoming moderate or
poor for a time.

___
Please 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: Authority and forwarding, but not recursion/iteration

2021-03-09 Thread Tony Finch
Marki  wrote:
>
> I am seeking a combination of either a combined configuration on one, or a
> config of several different DNS servers together to achieve the following:
>
> * Some clients should be able to resolve authoritative local zones as well as
> some forwarded zones.
>
> * Other clients should be able to resolve all of that _plus_ be able to make
> recursive queries to the internet (or use a global forwarder).

In my opinion, as a rule of thumb it's best to avoid per-zone forwarding
in BIND. (Microsoft DNS really encourages it, but be wary because it
doesn't mean the same thing there!)

It's helpful if you have a clear distinction between authoritative-only
nameservers on the one hand, and on the other hand recursive nameservers
that provide service to stub resolvers. It sounds like you want to provide
an internal-only sandbox to some recursive clients, but it's best to think
of it as a restricted recursive service, not a special kind of
authoritative service. Especially because stub clients expect to receive
fully-resolved answers, so if you point them at an authoritative-only
server you'll get obscure problems in cases like cross-zone CNAMEs.

[ The distinction is that auth-only servers expect to receive only RD=0
(recursion not desired) queries from recursive DNS servers and reply with
RA=0 (recursion not available), whereas recursive servers expect to
receive RD=1 (recursion desired) from stub resolvers and reply with RA=1
(recursion available). ]

When you need to tie authoritative zones together, use delegation records
pointing at your authoritative-only name servers. Then your recursive
servers can just follow delegations in the usual way without special
configuration. (If you are doing split DNS, this can get fiddly, which is
a good reason for keeping your split DNS as simple as possible.)

[ You can configure recursive servers to have their own authoritative
copies of your zones - it can be faster and more resilient - but you can
think of it as a shortcut or optimization, on top of the fundamental
auth/rec split. ]

Your question is now, how to provide a restricted recursive service?

The top-level setup is to have multiple views with match-clients clauses
to determine whether a client is in the sandbox view or not. Then the
question is how to configure the sandbox view.

I don't know of any particularly good ways in BIND :-) When you want
default-allow with a block list, then RPZ is ideal, but you are asking for
default-deny with an allow list.

You might be able to configure a dummy default forwarder, and tell BIND it
is bogus, something like this (which I have not tested!):

forwarders A.B.C.D;
server A.B.C.D {
bogus yes;
};

then have per-zone static-stub configuration for allowed zones, pointing
at working authoritative servers.

Alternatively it might be easier to make other software such as dnsdist do
what you want. Or, consider implementing the sandbox with firewalls at the
network level. (But are you sandboxing DNS because of worries about
data exfiltration?)

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Irish Sea: South or southwest 4 to 6, increasing 7 to severe gale 9 for a
time. Slight or moderate, becoming rough or very rough for a time. Rain.
Moderate occasionally poor.

___
Please 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: BIND server; dig vs dig +trace on failing lookup.

2021-03-04 Thread Tony Finch
Gregory Sloop  wrote:

> Would you mind showing me how you got there?

I like https://dnsviz.net/ and https://zonemaster.net/ - dnsviz is better
at showing DNSSEC issues, and zonemaster has a bigger collection of
general DNS checks, so it's worth using them both.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Southwest Fitzroy: Cyclonic 4 to 6, occasionally 3 at first, becoming
easterly or northeasterly later. Moderate or rough. Showers, thundery at
first. Good, occasionally poor.

___
Please 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: How bind select NS record during recursive queries

2020-11-19 Thread Tony Finch
Duleep Thilakarathne  wrote:
>
> How does bind select NS entry during recursive queries  , when the answer
> section has multiple NS entries.

It's roughly based on measuring the smoothed round trip time (SRTT) to
each nameserver and picking the closest, with a lot of randomness in the
mix. Try searchengineering [BIND SRTT] for lots of discussion of the
algorithm.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
a fair, free and open society
___
Please 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: Logging on a Bind server

2020-10-22 Thread Tony Finch
senthan.sivasunda...@szkb.ch  wrote:

> One Day it came an alert from Cybereason (Antivirus-Software), that our
> Bind server tried to Connect to a suspicious domain "ns2.honeybot.us".

> But I couldn't find the log, which domain the BIND server was searching
> for, so that the BIND server has to connect to "ns2.honeybot.us". I can
> see the Queries log, which domain the Clients were querying but I
> couldn't find out why our Bind Server tried to connect the name server
> "ns2.honeybot.us".

There are a few ways to get answers to questions like this:

1. passive DNS, which captures cache-miss query traffic from a resolver to
the big bad internet. There are two flavours:

1a. a tcpdump tap between the resolver and the internet - the classic
passive DNS setup

1b. use dnstap, which is built-in to BIND

In both cases you will be logging a LOT so it requires sysadmin work: log
rotation, matching log volume to disk space, etc. usw. If you have good
passive DNS collection and analysis tools you can learn a lot about the
weirdness happening on your network. I don't, so I am blissfully unaware,
until I...

2. run `rndc dumpdb` and inspect the contents of named_dump.db

You might (if you are lucky) be able to run this after something happened
that caused questions, without any prior setup work, and maybe get an
answer if the TTLs are long enough.

In this particular case you'll be looking for records like " NS
ns2.honeybot.us". BIND prints named_dump.db in classic zone file format,
without repeating the owner name for every record, so once you have found
an NS record of interest you will need to scroll back to find a sibling
record that has the relevant owner name. So `less` is a better tool than
`grep` for this job.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole: Variable 4 at first in east, otherwise westerly or southwesterly 4 to 6,
occasionally 7 later in west. Moderate or rough, occasionally very rough later
in west. Rain or showers. Good, occasionally moderate.
___
Please 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: Why are no notifies send?

2020-10-22 Thread Tony Finch
Axel Rau  wrote:
>
> Has anybody a working IPv6 notify address in use?

Notifies from my primary to my on-site servers go over IPv6 with a TSIG
key. They are all dual-stack.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Sole: Variable 4 at first in east, otherwise westerly or southwesterly 4 to 6,
occasionally 7 later in west. Moderate or rough, occasionally very rough later
in west. Rain or showers. Good, occasionally moderate.
___
Please 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: Why are no notifies send?

2020-10-18 Thread Tony Finch
Axel Rau  wrote:
>
> I can’t see any notifies to 2001:470:100::2 in the logs.
>
> What am I doing wrong?

Normally BIND only logs "sending notifies" without saying anything about
where it is sending them. You need to increase the log level using `rndc
trace 3` (or more than 3) to get the information you want.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Berwick upon Tweed to Whitby: Variable 3 or less, becoming south 4 or 5,
occasionally 6 later. Moderate. Showers, occasional rain later. Good,
occasionally moderate later.___
Please 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: negative caching ttl question

2020-10-13 Thread Tony Finch
Veaceslav Revutchi  wrote:

> Given this soa:
>
> fe80.info. 3600 IN SOA ns-538.awsdns-03.net.
> awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60
>
> I see bind caching negative answers for 3600 instead of 60. The rfc
> and my google searches suggest that it should pick the MIN(soa ttl,
> soa min ttl) for that purpose. What am I missing?

I think what RFC 2308 says (sections 3 and 5) the authoritative server for
the zone is responsible for calculating the negative TTL from the minimum
of the SOA TTL and MINIMUM fields. Sections 5 and 6 say that resolvers and
caches propagate the negative TTL using just the TTL field of the SOA in
the AUTHORITY section of the response (though the RFC could be a little
more explicit about this).

What's happening for fe80.info is the AWS DNS authoritative servers are
setting the wrong TTL in the negative response, and your BIND cache is
doing what it is told to do.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Ardnamurchan Point to Cape Wrath: Northeast 5 or 6, veering east 3 or 4 later.
Rough becoming moderate. Showers. Good, occasionally moderate.
___
Please 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: RRSIG and TTL

2020-09-17 Thread Tony Finch
Scott Nicholas  wrote:
>
> Primary nameserver is behind a cache/proxy on enterprise network such that
> all external traffic hits this. Zone went bogus. I blame policy but on
> further inspection 2/3 proxys had differing TTL between the DNSKEY and it's
> RRSIG.

Hmm, that's suspicious. In the DNS, an RRset is an atomic unit and every
record must have the same TTL. In DNSSEC the RRSIG is part of the RRset,
so if there is a difference between the DNSKEY TTL and the RRSIG(DNSKEY)
TTL there is a bug, and it might be bad enough to cause validation
failures.

It sounds like you have a good idea of what the bug might be, and my guess
is probably the same. If we're right you will be able to provoke
validation failures by

  * query a (sacrificial!) record via the proxy with DO=0 (dig +nodnssec)
to populate its cache with an RRset maybe lacking RRSIGs
(that's the guess / bug)

  * change the sacrificial record on the primary

  * query again via the proxy with DO=1 (dig +dnssec) before the old TTL expires

If our guess is right, you'll get the old record with the new RRSIG and
validation will fail.

> I suspect that the signature hit the absolute time, got a fresh copy, and
> the DNSKEY stuck around another 2 days (1 week TTL). Now if the system
> wasn't security aware, I'm not sure how the TTL became unmatched but I can
> see that it could happen. I guess?

Yes.

But there's another issue that can make this bug worse: I think the 7 day
TTL on your DNSKEY records is too long.

BIND's default sig-signing-interval is 30 days, and signatures are
regenerated 1/4 of the interval before expiry, i.e. 7.5 days.

If you want to avoid serving bogus signatures, you need to add together
the zone's SOA expire interval, the propagation delay between your primary
server and your public authoritative servers, and the maximum TTL of any
record in your zone. This sum must be less than the signature regeneration
interval (7.5 days by default).

In practice you will never get anywhere near the expiry interval unless
things are broken, and NOTIFY means the propagation delay is negligible.
So in the real world the important number is how good you are at
monitoring zone propagation delays and fixing things if they become
non-negligible. To allow for SNAFUs this is about the same as the
traditional zone expiry time of about a week...

The logistics are a bit different if you have a reverse proxy in your
authoritative server setup, but I hope you get the idea of how to think
about making sure your DNSSEC signatures are fresh enough.

The other interesting number is the TTL. When choosing TTLs there are
roughly two kinds of records, which I call infrastructure records and,
uuuh, I don't have a word for the others - user records? application
records? Anyway, infrastructure records are the irrelevant crap a resolver
needs in order to get the answers that users actually care about, and of
course this irrelevant crap is the tricky stuff that DNS admins have to
work with: NS records, A and  records of DNS servers, DNSKEY records,
DS records.

The TTL for infrastructure records should be relatively long, to minimize
the amount of irrelevant crap that resolvers have to deal with, i.e. to
reduce the tail latency experienced by end users while resolvers go off to
look at the infrastructure. You start hitting diminishing returns for
infrastructure TTLs after about 24 hours - delegation records in TLDs
typically have TTLs of 24h or 48h, and that's a reasonable length for your
in-zone infrastructure records too.

Any longer than that and you are creating pain for yourself any time you
have to do a nameserver migration or a DNSSEC rollover. With 24h TTLs
you'll need to allow a week for a significant move; for a 7 day TTL you
might be looking at a month of faff to deal with something that's often
tricky and perhaps unexpectedly urgent.

For other records, I find an hour is a reasonable balance between decent
cache performance and not-too-annoying update delays. I don't have records
with enough churn to justify shorter TTLs but your mileage may vary.

(There are scientific measurements of DNS TTL vs latency that agree
reasonably well with my suggestions, so there's a bit more to them than
convenient round numbers!)

> A low TTL would minimize it but appliance doesn't allow direct
> configuration for DNSKEY TTL.

GOOD GRIEF :-(

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Biscay, Fitzroy, Sole: East or northeast 4 to 6, occasionally 7 later, but
cyclonic 3 to 5 in south Fitzroy and south Biscay. Moderate or rough, but
slight in southeast Biscay, becoming rough later in Sole. Thundery showers in
Biscay and Fitzroy. Good, occasionally poor in Biscay and Fitzroy.
___
Please 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.

Re: "minimal-any" configuration query

2020-09-17 Thread Tony Finch
ShubhamGoyal  wrote:

> We have enabled " minimal-any yes;" in our Bind DNS Sever, Yet an ANY
> query provides complete details instead of providing reduced details .

Testing minimal-any with dig is tricky and very obscure!

For an example of how to test it, try:

dig cam.ac.uk any @131.111.8.37
dig +notcp cam.ac.uk any @131.111.8.37

There's a special case in dig to use TCP by default for ANY queries, so
that naive users can continue to use ANY queries for debugging. This can
be confusing for slightly less naive users who are trying to test
minimal-any - it trips me up sometimes! And there is no indication in
dig's output to tell you whether it used TCP or UDP, so there is no way
you can be expected to find this out from experimentation.

As well as that there is the issue that dig has two TCP-related options,
and you have to know which one to use in which situation.

The +tcp/+notcp option that I used above controls whether TCP is used in
the initial query. But usually in the past it has only been used as +tcp
because the initial query almost always defaults to UDP (the exception was
things like AXFR). If you wanted to suppress TCP, such as when testing
truncation, then usual way was with the +ignore option. But this only
controls retry-over-tcp when dig sees a TC bit.

If you try to use +notcp when testing truncation, it doesn't work - dig
still retries over TCP. If you try to use +ignore when testing
minimal-any, it doesn't work, because there's no TC bit.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
democracy, participation, and the co-operative principle
___
Please 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: /etc/bind.keys in a chrooted environment

2020-07-22 Thread Tony Finch
Anand Buddhdev  wrote:
> On 22/07/2020 15:06, Josef Moellers wrote:
>
> > named complains about the missing file /etc/bind.keys if run chrooted:
> > unable to open '/etc/bind.keys' using built-in keys
> >
> > What is the preferred way around this? Add "/etc/bind-keys" to
> > NAMED_CONF_INCLUDE_FILES?
>
> Or just ignore the warning, and let BIND use its built-in keys.

Yes, I recommend this.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Mull of Kintyre to Ardnamurchan Point: Southwest veering west 3 or 4,
occasionally 5 at first. Slight or moderate. Occasional rain, fog patches.
Moderate or poor, occasionally very poor.
___
Please 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: DNS_RRL_MAX_RATE defines 1000

2020-07-09 Thread Tony Finch
Zhiyong Cheng  wrote:
>
> We are using named cluster in our internal network as the authoritative
> DNS. So there are no cache servers between clients and named cluster.
> Maybe we should add one but it is just another story.

Sorry, I wasn't completely clear: I was not saying that your authoritative
servers should have a cache. I was saying that all the legitimate clients
of your servers (the resolvers at ISPs areound the Internet) have caches.

> To my mind the RRL should not limit queries with different qnames from
> the same client. So is it my misunderstanding or wrong config?

If you are querying for nonexistent names then RRL will treat the NXDOMAIN
responses as equivalent, so it will rate-limit them. RRL limits responses,
not queries. You can configure a different `nxdomains-per-second` limit if
you want.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Rockall, Malin: Northwest 4 or 5. Moderate. Showers. Good.
___
Please 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: DNS_RRL_MAX_RATE defines 1000

2020-07-08 Thread Tony Finch
程智勇  wrote:
>
> So could anybody tell me why DNS_RRL_MAX_RATE defined 1000?

RRL is designed for authoritative DNS servers. Legitimate queries come
from recursive resolvers with caches. There should not be more than one
query for each RRset from each resolver per TTL. So a normal response rate
limit is relatively small - I set it to 10.

If you are hitting 1000 queries per second, that implies either there
are 1000 resolvers behind one IP address (which is VERY unlikely); or the
query traffic is abusive.

Are you sure the dropped traffic is legitimate?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Channel Islands: West to southwest 4 to 5, occasionally 6 mid-channel
overnight and Thursday morning, occasionally west to northwest 2 to 4 in the
far south of the area. Slight to moderate with a low swell, perhaps
occasionally rather rough mid-channel until late morning. Occasional mist and
fog, especially overnight rain and drizzle at times, especially from Thursday
morning. Moderate to poor or very poor, locally good at times.___
Please 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: How to prepublish additional DNSKEY

2020-07-08 Thread Tony Finch
Klaus Darilion  wrote:
>
> A signed zone shall be moved to another DNS provider. Hence I want to
> add the public KSK of the gaining DNS provider as additional DNSKEY to
> the zone.

I guess you might already have seen this draft - it discusses long-term
multi-provider setups rather than transitional ones, so it isn't direcly
on point, but it still has some useful ideas.

https://tools.ietf.org/html/draft-ietf-dnsop-multi-provider-dnssec

> So, how is the correct process to add an additional DNSKEY (only the public 
> key is known).

I think you are looking for `dnssec-importkey`.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Viking, North Utsire, South Utsire, Northeast Forties: Northwesterly 4 to 6,
becoming variable 2 to 4 except in South Utsire. Slight or moderate. Showers.
Good.
___
Please 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: DNS security, amplification attacks and recursion

2020-07-07 Thread Tony Finch
Brett Delmage  wrote:
> On Tue, 7 Jul 2020, Tony Finch wrote:
> >
> > minimal-any yes;
>
> Why only reduce and not eliminate?

The reason is a bit subtle. If an ANY query comes via a recursive
resolver, it is much better to give the resolver an answer so that it will
put an entry in its cache. The cache entry will stop more ANY queries from
being sent from the resolver to the upstream auth server, as long as its
TTL lasts.

If the auth server does not answer, or sends a REFUSED error, the resolver
is likely to retry, which increases worthless traffic rather than
suppressing it, and the resolver may decide the auth server is lame which
will cause knock-on problems for legitimate queries.

There are some scenarios where reflection attacks go through multiple
servers. If you can get cache entries into those servers then the
attack traffic gets suppressed closer to its source. There have been quite
a lot of attacks that work like this:

  * an ISP has a huge number of customers with crappy home routers, that
can act as open recursive resolvers

  * an arsehole decides to use these crappy home routers in a reflection /
amplification DDoS attack

  * the crappy home routers forward the attack queries to their ISP's
recursive servers; these recursive servers are legitimate and well
configured but suffer from bad client devices

  * the recursive servers resolve the queries against some third party
authoritative servers

If the recursive servers cache the responses, then the auth servers should
not be much affected by the attack: most of the traffic is answered from the
ISP caches, and maybe the home router caches if they have them.

But if the auth servers don't answer, or send REFUSED errors, then the
recursive servers are going to keep retrying queries, and thereby relay a
very large proportion of the attack traffic to the auth servers. Sadness
will follow.

Note that RRL does not help in this scenario, because from the auth
server's point of view the ISP resolvers are legitimate clients, which RRL
can observe from their retry behaviour. RRL is designed for attacks where
the spoofed queries go direct to the auth server, which is not happening
in this case.

When this happened to us (when my servers were the third party auth
servers) the DDoS attack was hitting a very large number of ISPs, so our
auth servers were getting ANY queries via huge numbers of recursive
servers. Extra unfortunately, the ANY response was too big to fit in UDP,
so all the resolvers were trying to query over TCP. And our auth servers
did not have enough TCP capacity to handle the load. Much sadness. (It
didn't take us offline because our off-site auth servers were differently
configured and able to keep answering.)

So I implemented minimal-any to stop it from happening again.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fisher, German Bight: Westerly veering northwesterly 4 to 6, decreasing 3
later in south German Bight. Moderate, occasionally rough at first. Mainly
fair. Mainly good.
___
Please 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: DNS security, amplification attacks and recursion

2020-07-07 Thread Tony Finch
@lbutlr  wrote:
>
> > rate-limit { responses-per-second 10; };
>
> Does that apply to local queries as well (for example, a mail server may
> easily make a whole lot of queries to 127.0.0.1, and rate limiting it
> would at the very least affect logging and could delay mail if the MTA
> cannot verify DNS.

I don't recommend using response rate limiting on recursive servers.

The principle behind RRL is that auth servers are queried by resolvers
with caches, and a correctly-functioning cache will not repeat the same
query very frequently, so it is reasonable to apply a rate limit on the
auth servers.

Recursive servers, on the other hand, are often queried by stub resolvers
without caches. The query rate is then entirely driven by the application
workload, and you can't apply a rate limit on the recursive server without
causing serious trouble for the application.

It can be especially bad because traditional cacheless stub resolvers are
not good at error recovery, and when RRL hits, their retry strategy is
likely to increase the query rate observed by the server, making things
worse.

If you are running an oldskool multi-purpose server that is recursive for
its own daemons but authoritative for others, then you can use the
`rate-limit { exempt-clients }` option so that RRL doesn't apply to
recursive clients. But I wouldn't recommend a setup like this. (My auth
servers have their /etc/resolv.conf pointing at my recursive service.)

> Do these setting also need to be applied to the secondary servers?

The settings I described are for public authoritative servers, i.e ones
that appear in NS records. These servers can be primary or secondary (but
are usually secondary).

Secondary servers don't necessarily appear in NS records, and if they
don't they are less likely to be exposed to this kind of attack.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Southeast Iceland: Westerly or southwesterly, 3 to 5, becoming variable 3 or
less later in north. Moderate. Showers. Good.
___
Please 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: Fun with nsudpate and ac1.nstld.com

2020-07-07 Thread Tony Finch
@lbutlr  wrote:
>
> The latest surprise was that dnssec-enable yes; is obsolete in Bind 9.16.

`dnssec-enable yes` has been the default since 2007, so that directive has
been useless for quite a long time :-) What changed in 9.16 is that you
now can't turn DNSSEC off. (Specifically, support for correctly serving
signed zones on authoritative servers, and support for DNSSEC-aware
clients of resolvers, whether or not any validation is happening.
`dnssec-validation` is a separate setting.)

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
individual and social justice
___
Please 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: DNS security, amplification attacks and recursion

2020-07-07 Thread Tony Finch
Michael De Roover  wrote:
>
> Said friend said to me that he tested my authoritative name servers and
> found them to be not vulnerable. [snip] They do not respond to recursive
> queries. It appears that the test of whether a server is "vulnerable" or
> not has to do with this. The command used to test this was apparently
> "dig +short test.openresolver.com TXT @your.name.server".

OK, that iss all right and correct, but there is (of course) a bit more to
this issue.

As you already know, the most basic thing to avoid is not being an open
recursive server. Out of the box, BIND has a recursion ACL that only
allows queries from directly connected networks, so you won't have this
problem without making an explicit configuration mistake. Normally for an
authoritative-only server, you should set `recursion no` to lock it down
more tightly.

An auth-only server can also be used for amplification attacks that use
its authoritative zones - these attacks don't have to use recursion.
There are a few ways to mitigate auth-only amplification attacks.

Response rate limiting is very effective. Start off by putting the
following in your options{} section, and look in the BIND ARM for other
directives you can put in the rate-limit{} section.

rate-limit {
responses-per-second 10;
};

Especially if you have DNSSEC signed zones then there are a few extra
things you can do to reduce the size of your response packets, which
reduces the attacker's amplification factor, and makes you less likely to
be abused.

Set a maximum UDP packet size, to suppress fragmented packets. The DNS
flag day 2020 campaign will make this a standard setting. For a long time
I have used:

max-udp-size 1420;

https://dnsflagday.net/2020/

A downside of small UDP responses is more truncated packets and more
queries over TCP, but there are still more ways to reduce response size
which also reduce truncation.

Reduce the size of responses to ANY queries, which are a favourite tool of
amplification attacks. There's basically no downside to this one, in my
opinion, but I'm biased because I implemented it.

minimal-any yes;

You can also reduce the size of other answers. In theory this option might
force resolvers to make more queries to get records that by default would
appear in the additional section, but I think in practice resolvers make
these queries anyway because of RFC 2181 trustworthiness logic, and
because applications (such as SMTP servers) find it easier to query
directly than use additional records. So on my auth servers I set:

minimal-responses yes;

If you are signing zones with DNSSEC, consider doing an algorithm
rollover to ECDSA p256 (algorithm 13) because this has much smaller
signatures than RSA. Algorithm rollovers are not particularly easy,
because you need a good grasp of the DNSSEC key timing parameters and how
and when to swap over your DS records. (There used to be even more
gotchas, so it is getting easier, honest!)

Finally, there's the built-in _bind CHAOS view. This has very strict
response rate limiting by default, but if you want to be super careful
you can set `version none` and `hostname none` to lock it down further.
(I don't bother with this.)

Here endeth the brain dump.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Mull of Galloway to Mull of Kintyre including the Firth of Clyde and North
Channel: Variable, 2 to 4. Moderate at first near the Mull of Kintyre,
otherwise smooth or slight. Showers. Mainly good.
___
Please 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: Hints for forwarding a subdomain on a authoritative server

2020-07-06 Thread Tony Finch
Tom  wrote:
>
> But: The zone-forwarding is only working, when I enable "recursion" on the
> authoritative server. Does this means, that zone-forwarding really requires
> recursion?

Yes, forwarding is completely specific to recursive servers. That is, the
server doing the forwarding must be recursive, and the target server must
also be recursive.

[ In some limited cases you can get away with the target server not being
recursive; I think the restrictions are that the target zone must not have
any delegations or out-of-zone CNAMEs, but I haven't tested this myself. ]

> Is there a better way with not enabling recursion (perhaps with views)
> to accomplish this?

Use a type "static-stub" zone if the target server is authoritative.

If the server doing the forwarding is not recursive then it needs to
secondary its own authoritative copy of the zone. But presumably you are
trying to forward because AXFRing the zone isn't possible. In that case
you need something like dnsdist which can act as a DNS reverse proxy. BIND
won't query another server when a query is RD=0.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Fisher, German Bight: West or northwest 7 or gale 8, occasionally severe gale
9 at first in Fisher, decreasing 5 or 6 later. Rough or very rough, becoming
moderate or rough later. Showers. Good.
___
Please 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: $INCLUDE Kexamle.com.+007...

2020-07-05 Thread Tony Finch
@lbutlr  wrote:

> When a domain configuration file contains an include line for the key,
> where is that include looking for the key file?

... good question, I have avoided having to find that out ...

> I'm in a situation where the keys seems to work fine for updating
> DNSSEC, but nsdiff complains the key file is not found.

Well, nsdiff uses named-compilezone to canonicalize zone files, and the
named-compilezone manual lists a couple of options that affect $INCLUDE:

   -t directory
  Chroot to directory so that include directives in the configura‐
  tion file are processed as if run by a similarly chrooted named.

   -w directory
  chdir  to  directory  so  that relative filenames in master file
  $INCLUDE directives work.  This  is  similar  to  the  directory
  clause in named.conf.

So it sounds like "the current directory" is the answer to your question.

However, I don't think you need to $INCLUDE key files. I think maybe that
used to be a thing when signing a zone had to involve dnssec-signzone? But
nowadays even dnssec-signzone will automatically insert public keys into
the signed zone.

When you're doing automatic signing with named (which you have to do if
you are using nsupdate to alter the zone), the keys are included in the
signed zone based on their timing metatata, which you can set with
dnssec-settime. [There's also the new key policy stuff which I have not
yet tried out properly.]

So the actual answer is, you don't explicitly $INCLUDE the keys in the
zone, so questions about current directories do not arise.

Does that make sense?

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Lough Foyle to Carlingford Lough: Southwest veering west, 6 to gale 8, then
veering northwest 4 to 6 later. Moderate or rough, becoming slight or moderate
south of rathlin island. Showers,thundery at first. Good, occasionally
moderate.___
Please 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


  1   2   3   4   5   6   7   8   9   10   >