Re: How do I debug if the queries are not getting resolved?

[Grant Taylor via bind-users]

On 12/11/23 18:47, Blason R wrote:
Oh I forgot to tell you that. This is BIND RPZ and all the queries are 
recursive.


Okay, what RPZ configuration do you have?  Is it messing with the 
queries you're testing in any way?


What configuration do you have for RPZ related to DNSSEC?


Dig output just dies out and does not spit anything.


Please elaborate on "just dies".  Does the dig abort / terminate / fail 
and immediately return you to a command prompt?  Or does it simply take 
longer than you are allowing it to run?


What happens if you allow dig to run for 5-8 minutes?  It should timeout 
sometime long before 8 minutes and print something germane to the terminal.


I think that a network sniffer while running dig tests above is a very 
helpful thing.  #trustTheBitsOnTheWire


And this specifically i noticed with .gov and .gov.in  
domain. This is the reason I thing it might be related with DNSSEC.


RPZ and DNSSEC have an interesting relationship.

What happens if you do a `\dig +trace` on the name you're testing?

N.B. the leading backslash is important to disable any local shell aliasing.

Also, `which dig` to confirm that you are running the binary that you 
think you are running.



Also wanted to understand overall how do I debug any queries.


Something somewhere will give you diagnostically relevant data.  You 
need to find it and understand it.  Even strace / dtrace on dig will be 
helpful at times.


There's a possibility that there is a missing library and dig can't even 
run.  But that's unlikely -- but not impossible -- with dig installed 
via standard repo commands.




--
Grant. . . .
--
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 stats

[Grant Taylor via bind-users]

On 8/21/23 10:11 AM, Mark Elkins via bind-users wrote:

Hi,


Hi,


1) Count how many delegated domains there are (Names with NS records)


Mind your $ORIGIN and check the number of NS record owners.


2) Extract the above Names - so I can look for changes (Added/Deleted names)


I suspect that deltas; add / change / delete, will likely be outside of 
the scope of what bind will provide unless you crank up logging and 
parse it or behave as an incremental zone transfer client.



3) find out how many unique names have DS records (I can DIG I suppose)


Mind your $ORIGIN and check the number of DS record owners.


I'd also like to spot broken stuff (named-checkzone ?)


How are you getting your zone data?  Is it a zone transfer (AXFR / 
IXFR)?  Or do you have raw zone files?


One hindrance is that journal files are present - so it is not just the 
zone file but the zone.jnl file as well.


Check out the "-clean" flag to the "sync" command for rndc.

The primary purpose is to pull in data into an (ICANN requested) African 
DNS Observatory.


It sounds like you might be better off extracting data for multiple 
zones / (sub)domains therein from DNS and storing it in some format, 
likely a database, that will then be easier to process.




Grant. . . .
--
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: Possibility of using views to properly return appropriate IP address for hostname based on requestor subnet?

[Grant Taylor via bind-users]

On 6/29/23 6:44 AM, Matus UHLAR - fantomas wrote:
bind has "sortlist" statement that could do what you want. It will 
provide all IPs but sorted differently.


+1 to "sortlist".  I couldn't remember the exact nomenclature nor how it 
was used.


Otherwise, you can set up multiple views with different versions of the 
same zone, configured to provide different verision according to source IP.

This is much harder to set up.


One thing that I was concerned with in Ubence's original message is I 
wasn't entirely clear if search domains were coming into play, and if 
so, what the possible domains were.  This could also be a contributing 
complication.




Grant. . . .
--
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: Controlling which interface named uses

[Grant Taylor via bind-users]

On 6/12/23 2:48 AM, Matus UHLAR - fantomas wrote:
note that query-source settings affects source IP of packet, while "ip 
rule" affects outgoing interface (unless you also configure SNAT for 
those packets), so they are not exactly the same.


Late comment:  `ip route` can have some influence on what the source IP 
is for traffic via it's `from` stanza.


This is commonly needed when you have things like VPNs between sites and 
you want the VPN gateway to originate traffic to the remote LAN from the 
local LAN interface, not the internet connection, thereby causing the 
traffic to match LAN to LAN configuration in the VPN.


(LAN A)---[.1 R1 .83]---(Internet)---[.77 R2 .1]---(LAN B)

Something like / from memory:

r1# ip route add $LANB via $GW from $LANA.1



Grant. . . .
--
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 restriction

[Grant Taylor via bind-users]

On 5/15/23 1:58 PM, Kereszt Vezeték wrote:

Hi Everybody


Hi,

I have a dns server in my private network with a local domain. The dns 
server forward the public request to the google dns server . I wold like 
separate hosts in the inside network.


One group allow only the local host resolve, not forward to the 8.8.8.8 
.Other group allow the local hosts resolve, and able to forward to the 
google dns server.


Are there any way to solve this problem with bind9 ?


It seems to me like this may be described a authoritative only without 
recursion and both authoritative and recursive service.


With this in mind, I'd wonder, if BIND's recursion restrictions might 
suffice.  E.e.  allow 192.168.1.10 & 192.168.1.11 to make recursive 
queries which get forwarded to ${UPSTREAM_DNS_PROVIDER} while only 
serving local authoritative content to 192.168.1.20 & 192.168.1.21.


I assume there is some nuance that I'm over looking / haven't had enough 
caffeine to properly appreciate yet.


But this is what I'd try myself.

N.B. you probably want to also apply the similar ACL to querying the 
cache, lest 192.168.1.20 & 192.168.1.21 be able get things out of cache 
that 192.168.1.10 & 192.168.1.11 queried from ${UPSTREAM_DNS_PROVIDER}.




Grant. . . .
--
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 dns amplification attack

[Grant Taylor via bind-users]

On 3/28/23 11:28 AM, Matus UHLAR - fantomas wrote:

Yes, this is one of the problem "authoritative zones for local use".


Authorizing the /zone/ for local use wasn't the problem.  The problem 
was that the world could get some of that zone's data from the query 
cache even if they couldn't query the zone directly.


The default root "hint" zone is only available for those who have 
recursion available.


I feel like the "root hint zone" is considerably different than "root 
zone" proper.  The fact that they have different zone types seems to 
support that.


;-)

I bring this up as this is something that I've stubbed my toe on and I 
would like it if others can avoid similarly stubbing their toes.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 dns amplification attack

[Grant Taylor via bind-users]

On 3/28/23 10:48 AM, Matus UHLAR - fantomas wrote:
If your server has authroritative zones for internal use, yes, in such 
case allow-query is good idea.


The server that I first set this on had a secondary copy of the root 
zone for my systems use.  I ended up adding additional restrictions to 
prevent the world from querying it in addition to the public zones that 
are allowed to be queried by the world.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 dns amplification attack

[Grant Taylor via bind-users]

On 3/28/23 6:30 AM, Matus UHLAR - fantomas wrote:
Great, this means that only clients with those IP addresses can query 
your server for non-local information.


I used to think the same thing.

Then I learned that I needed to also add similar configuration for 
`allow-query {...};` and `allow-query-cache {...};`


The `allow-query-cache {...};` actually bit me because people were able 
to get the result of recursion if it was in the cache.


   allow-recursion   { recclients; };
   allow-query   { recclients; };
   allow-query-cache { recclients; };

Something to consider.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Correlation between NOTIFY-Source and AXFR-Source

[Grant Taylor via bind-users]

On 3/11/23 10:43 AM, Fred Morris wrote:
I've found myself in situations in the past where NOTIFY has been 
fetishized as "real time"


"real time" can be a VERY loaded phrase.

Some sometimes it's measured in fractions of a second.  Other times it's 
measured in minutes.


I've always simply considered it faster than the alternative.  In this 
case, before the secondary would naturally get to it's refresh / retry 
timer.





--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Correlation between NOTIFY-Source and AXFR-Source

[Grant Taylor via bind-users]

On 3/11/23 10:37 AM, Paul Stead wrote:
Sorry I should have made it clearer that the notifier should only be 
shuffled to the top of the list if it is a defined primary for said zone.


Okay.  The try the notifier first /if/ it's a configured primary makes 
more sense to me.  I guess I've not had enough caffeine to connect the 
conditional.  Thank you for the assist.


I.e An IP on the notify-from list, but not a configured primary wouldn't 
be in the list of primaries for that zone so would not be shuffled to 
the top of the list.


ACK



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Correlation between NOTIFY-Source and AXFR-Source

[Grant Taylor via bind-users]

Hi Paul,

Thank you for explaining.

On 3/10/23 12:21 AM, Paul Stead wrote:
Imagine that 1.1.1.1 has lost network connectivity recently. A notify 
comes from 2.2.2.2 - if I understand correctly Bind will try 1.1.1.1 
first, time out and then try 2.2.2.2 - even though we know given the 
situation that 2.2.2.2 has the latest copy of the zone we want.


I guess what I don't understand is why it's a problem for BIND to follow 
the configuration that's on the system where it's running.


N.B. I am quite certain that I've sent notifications from a system that 
wasn't a DNS server before.  I don't remember if it was dig or something 
else.


I only see a loose suggestion that BIND can do a zone transfer from the 
system that it received notifications from.


I could see having a hierarchy with multiple public secondaries which 
transfer from the hidden private mname as well as multiple public 
tertiaries which transfer from the secondaries and configuring the 
hidden private mname to send notifications to all servers.


Perhaps the larger spirit of this thread is if that association can be 
made hard or not.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Correlation between NOTIFY-Source and AXFR-Source

[Grant Taylor via bind-users]

On 3/9/23 2:25 PM, Paul Stead wrote:

Chiming in to say +1 to Kalus' logic and sight of benefit here.


Please forgive my ignorance in asking:

Why doesn't the order of the configured primaries suffice?

N.B. I'm assuming that this is the the order of the primaries for a zone 
in the named.conf file and not actually zone contents.


What am I failing to understand?



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 With Primary Hidden - Clarifying Question from Documentation

[Grant Taylor via bind-users]

On 1/17/23 4:45 PM, Michael Richardson wrote:

Many people do exactly that.


Sorry, I don't see that as an answer to -- my understanding of -- the 
OP's question of "Does the primary server that handles the DNSSEC duties 
need to be not hidden / publicly accessible?"


Specifically what many people do, or not, doesn't translate to a 
requirement.



In my opinion, this is the best way to do things, and the in-place signing is
just a total pain.


Your opinions, such as they are, are independent of the OP's question.

I've got an ancient version of BIND managing all of the DNSSEC wherein 
the master is sort of hidden in that it's listed in the SOA's MNAME, but 
is not listed as an NS.  The MNAME is globally accessible.


I'm sure that I'm overlooking something at the end of a long day, but I 
can't see anything that prevents the OP from having the primary perform 
DNSSEC functions while also functioning as a hidden primary role.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 lookups not working when Internet connection failed.

[Grant Taylor via bind-users]

On 11/7/22 9:45 AM, Fred Morris wrote:
The PUBLIC DNS is not secure against eavesdropping or parallel 
construction and never will be.


Even if the information is out there, I believe there is an exposure 
risk for ISPs if they do something that makes it /easy/ to correlate 
customer / client resources.


An ISP's lawyer won't care if the customer advertises their own IP space 
on their website as long as the ISP is not the one to expose such 
information.


That being said -- I assume -- we are all adults here and we can make 
our own informed decisions.  :-)




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: automatic reverse and forwarding zones

[Grant Taylor via bind-users]

On 11/7/22 9:08 AM, Matus UHLAR - fantomas wrote:
I'm afraid that this problem can become really huge when someone creates 
huge amount of generated records, e.g.  using proposed module.


Even if BIND's cache is simply FIFO -- which I'm fairly certain that 
it's smarter than that -- and flushes a less garbage record in favor of 
a more garbage record, then BIND will do what it's designed to do the 
next time someone queries for the less garbage record, namely it will go 
fetch it and cache it.


It will effectively be the same as if it never had the less garbage 
record in cache like if it is from a cold start.


It will be a small delay.  But it won't negatively impact the stability 
or operation of BIND.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 lookups not working when Internet connection failed.

[Grant Taylor via bind-users]

On 11/6/22 6:39 AM, Matus UHLAR - fantomas wrote:

3. allow your servers to to fetch 66.136.193.in-addr.arpa.


Is this 3rd step documented somewhere?

I searched for it in RFC 2317 but didn't find it.  Maybe I over looked it.

alternatively they can choose to 0/28.66.136.193.in-addr.arpa. or 
0-15.66.136.193.in-addr.arpa.  instead of 0-28.66.136.193.in-addr.arpa.


N.B. I've had some problems with the forward slash character "/" in 
domain names multiple times in the past.  I'd stick with the hyphen "-" 
for compatibility.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 lookups not working when Internet connection failed.

[Grant Taylor via bind-users]

On 11/6/22 11:12 AM, Carl Byington via bind-users wrote:
or use $clientname.66.136.193.in-addr.arpa. as the intermediate zone 
which has a slight advantage when the same client has multiple disjoint 
parts of the same /24.


I find that $CLIENTNAME or some other stand in for the client is a 
potential for information lek.


There is nothing inherent in the CNAME to non-identifying RNAMEs that 
leaks any client identifying information.


Conversely the client is in charge of what information they put in the 
sub-zone, so it's not the ISP leaking client identifying information.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 lookups not working when Internet connection failed.

[Grant Taylor via bind-users]

On 11/5/22 4:32 AM, Ondřej Surý wrote:
The IPv4 reverse zone is easy to scrape and stored for situations 
like this… just saying.


Fair enough.

Though if we're going to not officially sanctioned behavior, I'm 
inclined to create a local version of the 66.136.193.in-addr.arpa. zone 
that CNAMEs the (OP's) records of interest as necessary /and/ 
""delegates the other records over to the real zone.  --  It's a hack, 
but it works acceptably well in my experience.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 lookups not working when Internet connection failed.

[Grant Taylor via bind-users]

On 11/4/22 2:07 PM, Mark Andrews wrote:
Any ISP that offers these delegations should be allowing their 
customers to transfer the zone that contains the CNAMEs for the 
customer address space by default.


I've had enough trouble getting ISPs to support 2317 delegation period. 
I think that asking them to allow me to do a zone transfer would have 
been a hard no.


I certainly don't think this would be allowed /by/ /default/.

I just checked and § 5.1 of RFC 2317 mentioned having the parent do a 
secondary zone transfer of the child zone.  But I don't see any mention 
of the child doing a secondary zone transfer of the parent zone.


I think that would be a good idea.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 lookups not working when Internet connection failed.

[Grant Taylor via bind-users]

On 11/4/22 12:09 PM, Cuttler, Brian R (HEALTH) via bind-users wrote:

My pointer zones are more like

Zone "28.66.136.193.in-addr.arpa.", I've never had that leading "0-"

Is that typical? What does it do?


I invite you to go skim RFC 2317 -- Classless IN-ADDR.ARPA Delegation.

TL;DR:  2317 is a way to delegate /part/ /of/ a single class of IPs.

N.B. "class" is akin to the dot boundary in dotted quad IPv4.

This is important because DNS (sub)domains are delegated on the dot 
boundary.


The idea is to turn 1.2.0.192.in-addr.arpa., which normally has the PTR 
record, into a CNAME to an RNAME that is in a /different/ /domain/. 
This is done explicitly so that the /different/ /domain/ can be 
delegated to someone so that they can manage their own reverse DNS PTR 
records.  E.g.:


$ORIGIN 2.0.192.in-addr.arpa.
;...
; 0-3 are directly in the 2.0.192.in-addr.arpa. zone file.
0   IN  PTR test0.example.net.
1   IN  PTR test1.example.net.
2   IN  PTR test2.example.net.
3   IN  PTR test3.example.net.
; 4-7 are aliased to records in the 4-30.2.0.192.in-addr.arpa. zone.
4   IN  CNAME   4.4-30.2.0.192.in-addr.arpa.
5   IN  CNAME   5.4-30.2.0.192.in-addr.arpa.
6   IN  CNAME   6.4-30.2.0.192.in-addr.arpa.
7   IN  CNAME   7.4-30.2.0.192.in-addr.arpa.
; 8-15 are aliased to records in the 8-29.2.0.192.in-addr.arpa. zone.
8   IN  CNAME   8.8-29.2.0.192.in-addr.arpa.
9   IN  CNAME   9.8-29.2.0.192.in-addr.arpa.
...
14  IN  CNAME   14.8-29.2.0.192.in-addr.arpa.
15  IN  CNAME   15.8-29.2.0.192.in-addr.arpa.
; delegate the 4-30.2.0.192.in-addr.arpa. zone to Customer1.
4-30IN  NS  ns1.customer1.example.
IN  NS  ns2.customer1.example.
; delegate the 8-29.2.0.192.in-addr.arpa. zone to Customer2.
8-29IN  NS  nsA.customer2.example.
IN  NS  nsB.customer2.example.

Notice how the PTR records for 0-3 are found directly in the 
2.0.192.in-addr.arpa. zone.


Notice how the PTR records for 4-7 and 8-15 are aliased to records in a 
sub-domain.


Notice how the 4-30 and 8-29 sub-domains of the 2.0.192.in-addr.arpa. 
zone are delegated to different entities.


RFC 2317 delegates (NS records for (sub)domain) control over the PTR 
records to other DNS administrators via CNAME records in the parent zone.


N.B. the 0-28 in the OP's examples and my 4-30 & 8-29, are using the RFC 
2317 /convention/ of delegating to the - as the 
sub-domain to use.  --  I maintain that this is a convention and is not 
required.  --  RNAME records could just as easily have been delegated to 
16.example.com and the example.com zone could have had the following record:


   16   IN  PTR test0x10.example.com



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 lookups not working when Internet connection failed.

[Grant Taylor via bind-users]

On 11/4/22 11:19 AM, David Carvalho via bind-users wrote:

Thanks again.


You're welcome again.  :-)

Probably. Am I supposed to, I have just 2 segments in this network 
(and 2 others on another work) ?


Normally no, you're not supposed to /need/ to have a copy of an 
intermediate zone.


However, because you're using RFC 2317 Classless IN-ADDR.ARPA 
delegation, you have introduced additional complexity.  As such, you 
have an additional dependency.


I don't think that's a bad thing per se.  But it definitely is something 
to keep in mind.


Yes! But I never heard of intermediate zone before. As far as I know, 
my top domain forwards all "di.ubi.pt" requests to me and that works.


The intermediate zone; 66.136.193.in-addr.arpa. is for /reverse/ /DNS/. 
Your "di.ubi.pt." zone is /forward/ /DNS/.


There are actually multiple intermediate zones for both forward DNS; 
ubi.pt. and pt., and reverse DNS; 66.136.193.in-addr.arpa., 
136.193.in-addr.arpa., 193.in-addr.arpa., in-addr.arpa., and arpa.  It's 
just that the intermediate zones are hosted outside of your control. 
Both forward and reverse DNS chain down to zones that you do have 
control over hosting.


The difference in behavior between forward and reverse DNS /while/ 
/offline/ has to do with how things work technically.  Forward DNS 
simply looks for records of a given name in a given zone, both of which 
you have.  Reverse DNS on the other hand translates an IP address to a 
FQDN to look up in the DNS system.  E.g.


   a.b.c.d becomes d.c.b.a.in-addr.arpa

Your use of RFC 2317 Classless IN-ADDR.ARPA delegation complicates 
things in that,


   d.c.b.a.in-addr.arpa. becomes d.x-y.c.b.a.in-addr.arpa.

This 2317 delegation means that your client & server don't recognize 
that d.c.b.a.in-addr.arpa. maps to d.x-y.c.b.a.in-addr.arpa. /without/ 
the knowledge contained in the c.b.a.in-addr.arpa. zone.


Does that help thin the mud at all?  Or did I make things worse?



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 lookups not working when Internet connection failed.

[Grant Taylor via bind-users]

On 11/4/22 10:54 AM, David Carvalho via bind-users wrote:

Thanks for the replies.


You're welcome.

My reverse zone in named.conf. My secondary dns gets it automatically 
daily, along with the "di.ubi.pt.".


ACK


zone "0-28.66.136.193.in-addr.arpa." IN {
 allow-query { any; };
 type master;
 file "rev0.hosts";
};


That confirms that the origin is in fact "0-28.66.136.193.in-addr.arpa." 
 (Save for any typo that I may have introduced.)


I'll have to study more about some things you guys wrote. This is 
getting complicated 


So when your system(s) try to do a reverse DNS (PTR) lookup for 
193.136.66.1, it will actually do a PTR lookup for 
1.66.136.193.in-addr.arpa. and fail because you don't have a copy of the 
66.136.193.in-addr.arpa. zone file locally.


At least my understanding is that you have a copy of your forward zone, 
and your 0-28.66.136.193.in-addr.arpa. zone.  But you don't have a copy 
of, nor access to, the intermediate 66.136.193.in-addr.arpa. zone that 
references the 0-28.66.136.193.in-addr.arpa. zone.


Does that help?

Please feel free to ask additional questions.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 lookups not working when Internet connection failed.

[Grant Taylor via bind-users]

On 11/4/22 10:07 AM, David Carvalho via bind-users wrote:

My reverse zone file


What is the origin of your zone file?  0-28.66.136.193.in-addr.arpa.?


1.0-28.66.136.193.in-addr.arpa. IN  A   193.136.66.1


You seem to be using RFC 2317 Classless IN-ADDR.ARPA delegation.

As such, your reverse DNS is /dependent/ upon the parent zone; 
66.136.193.in-addr.arpa., where the Classless IN-ADDR.ARPA delegation 
CNAME records exist.  E.g.


   1.66.136.193.in-addr.arpa.   IN   CNAME 
1.0-28.66.136.193.in-addr.arpa.


It is likely this -- almost certainly -- external dependency was missing 
while your Internet connections was down that prevented your systems 
from being able to resolve reverse DNS.


Two options come to mind:

1)  Create a bogus 66.136.193.in-addr.arpa. zone locally to host the 
2317 CNAMEs.  --  This will likely have some side effects that need to 
be mitigated.
2)  Leverage Response Policy Zone(s) to try to influence the lookup as 
others suggested.  E.g. cause 1.66.136.193.in-addr.arpa. to become 
1.0-28.66.136.193.in-addr.arpa. locally.  --  I'd have to read about how 
to do this.


Aside:  I see no need for 1.0-28.66.136.193.in-addr.arpa. to have an A 
record.  But I don't see any problem with having it either.



1.0-28.66.136.193.in-addr.arpa. IN  A   193.136.66.1

; Reverse mapping

1   IN  PTR dns.di.ubi.pt.
...


These are the types of PTR records that I would expect to see in a 
reverse DNS context.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: automatic reverse and forwarding zones

[Grant Taylor via bind-users]

On 10/27/22 4:18 PM, Andrew Latham wrote:
IRC for example will check for PTR and gate login. I know there are 
others but that came to mind quickly. In some regions having PTRs was a 
requirement. It has been years but I recall LACNIC required/desired PTRs 
be set.


I wasn't aware of IRC's requirement for PTRs.  I'll have to ask some 
others for background.


I'd be interested in learning what other things /require/ or are at 
least predicated on having PTR records for IPs.


I absolutely agree that having PTR records, especially records that are 
of some value, are a worth while thing to have.


That being said, I think expecting DNS servers to have fully populated 
ip6.arpa zones is a non-starter.  I don't even thing it makes it as far 
as untenable as I think a fully populated zone will cause most things to 
simply fall over flat on their face.


Perhaps this will end up being one of those unplanned differences 
between IPv4 and IPv6.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: automatic reverse and forwarding zones

[Grant Taylor via bind-users]

On 10/27/22 1:24 PM, Marco wrote:
At least for IPv4, there are servers that reject connections from 
IPs that don't have a reverse zone with PTR record.


Please elaborate.

I've not heard of (unspecified type of) servers rejecting connections 
because of the lack of a PTR record.


I have heard of mail servers /accepting/ a /TCP/ /transport/ connection 
layer but /rejecting/ email at the /SMTP/ /application/ layer for the 
lack of a PTR record.


IMHO mail servers are not in scope for a $GENERATE style flood filling 
of a zone.  Rather they are in scope for very specifically generated 
 records.



That is the only reason that I see for that.
Most ISPs do it.


I'd say that /many/ ISPs populate in-addr.arpa zone(s) for IPv4.  --  I 
still run across IPv4 addresses that don't have PTR records way more 
often than I think is reasonable.


I've seen no evidence that ISPs also populate ip6.arpa zone(s) for IPv6 
in a similar way.  Not the least of which are some of the reasons called 
out in this thread.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: automatic reverse and forwarding zones

[Grant Taylor via bind-users]

On 10/27/22 11:23 AM, Marco wrote:

It isn't, because a customer gets /48 or /56 in most cases.


"For example one of their clients has the IP 2001:db::3." is a singular IP.

The customer's router can use various methods to assign addresses, auto 
configuration and DHCPv6.


Agreed.

However that's contrary to the example in your original message.

If the ISP wants to provide reverse zone for all possible addresses 
(ISP doesn't know which one of the assigned are used by the customer), 
it must have all reverse zones on their zone file or dynamically 
create them when a DNS server receives a request.


As others have indicated, populating reverse zone file(s) with 
2^(128-48) records is a non-starter and tantamount to a DoS.


The ISP could delegate the /48 if it was to another provider that ran 
their own DNS server.  But that's not likely the scenario with Prefix 
Delegation.


/If/ I needed to populate any significant portion of an ip6.arpa zone I 
would probably look at seeing if I could leverage Dynamically Loadable 
Zones [1] & [2] to pull content from an external ""database on an 
as-needed basis.


I've glanced at DLZ a handfull of times but have never used it.  Every 
time that I do, I gravitate towards the Stub (sample) [3] and wonder if 
I can (ab)use it to create something that will allow me to run a command 
(program / script / etc.) that will create synthetic records w/o needing 
to populate them in a database.


N.B. I consider DLZ to be for BIND to be much like the Milter API is for 
Sendmail / Postfix; e.g. a way to call out to something else to do 
something with the request.


Aside:  I do question what you would populate the /48 ~ /56 ip6.arpa 
zone with.  What hypothetical data would you put in it?  If it's PD to 
an end user, what information would the ISP put in there that wouldn't 
be confidential or potentially reveal that any and all IPs in that 
prefix belong to a customer w/o also identifying the customer?


[1] https://kb.isc.org/docs/aa-00995
[2] https://bind-dlz.sourceforge.net/
[3] https://bind-dlz.sourceforge.net/stub_driver.html



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

Re: automatic reverse and forwarding zones

[Grant Taylor via bind-users]

On 10/27/22 1:16 AM, Marco Moock wrote:

Hello,


Hi,


how do ISPs automatically create the reverse and forwaring zones for
their customers IP pools?


I think it might be out of scope for what you were asking about, but I 
believe the following is an alternative approach.



For example one of their clients has the IP 2001:db::3.


So for clarity, we're talking about 2001:db:0:0:0:0:0:3.  (I think.  I'm 
on my first cup of coffee.)


This is a singular IP (presumably link-net) for a customer.  So there 
would be exactly one forward  and one reverse PTR record.


I remember years ago that DHCP servers could be configured to 
dynamically update the forward and / or reverse zone when providing a 
lease to a client.


With this in mind, the forward and reverse zones would be roughly the 
size of the number of customers thus not blossoming ~> exploding into 
something that is tantamount to a DoS.



Its reverse zone
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.d.0.0.1.0.0.2.ip6.arpa
includes a PTR pointing to
3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.d.0.0.1.0.0.2.isp.example.org

This has an  record of 2001:db::3.

Is it possible to let bind create that automatically for certain zones?


Aside from $GENERATE, which others have talked about exploding the zone, 
I'm not aware of any way to have BIND /initiate/ the change to zone 
content / data (for this).




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Question About Internal Recursive Resolvers

[Grant Taylor via bind-users]

On 10/15/22 1:51 PM, Greg Choules via bind-users wrote:

Hi Grant.


Hi Gred,

I'm quickly replying to your message.  I'll reply to Matus & Fred later 
when I have more time for a proper reply.


My understanding is this, which is almost identical to what I did in a 
former life:


client ---recursive_query---> recursive_DNS_server 
---non_recursive_query---> internal_auth/Internet


where:
client == laptop/phone/server running stub resolver code
recursive_DNS_server == what Bob is asking about, a recursive-only DNS 
server

internal_auth == the other component, an authoritative-only DNS server


ACK

I that's the topology I had in my mental map.

Separation of internal and external clients - preventing external ones 
from accessing internal names - is easily achieved with a couple of 
views, such as this:


I /absolutely/ agree with you.  However "views" is /non-default/.  -- 
To reflect Bob's original message.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Question About Internal Recursive Resolvers

[Grant Taylor via bind-users]

On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:
If you are an ISP/registry/DNS provider, it makes sense to separate 
authoritative zones for your clients' domains, for all those cases your 
client move their domains somewhere else without notifying you (hell, 
they do that too often), or to be able to prepare moving domains to your 
servers.


#truth


forward zones - named sends recursive query to the primary servers
stub zones- named fetches NS records from primary servers and 
uses them for resolution
static-stub zones - named forwards iterative (non-recursive) requests to 
primary servers


clients accessing any of these zones must have recursion allowed and 
recursion must be enabled in BIND.


Please clarify where recursion needs to be allowed; the BIND server 
clients are talking to and / or the back end server that BIND is talking 
to on the client's behalf.


I'm not completely clear and I think it's better to ask than to assume 
incorrectly.



On 10/15/22 10:03 AM, Bob McDonald wrote:
If a non-secure client (read the next sentence...) accesses the same 
recursive server as a regular client, it will have access to the 
internal zones by default.. Therefore we need to have some sort of 
access controls in place.
and THIS is exactly the reason you SHOULD put your internal zones on 
your internal server.


Sorry if I'm being particularly dense this morning, but I'm not 
following ~> understanding Bob's and Matus's statements like I want to.


How does hosting the zone on an internal server provide any additional 
security?  Or are you simply relying on other security mechanisms to 
prevent non-secure clients -- as Bob described them -- from accessing 
the server ~> zone?


I feel like, by default -- as Bob described, any hosted zone is going to 
be accessible by any client that can query the server.


With this in mind, I feel like the type of zone; primary / secondary / 
mirror / stub / static-stub / forward, makes little difference in and of 
itself.  Rather, it would be dependent on global and / or per-zone 
allow-* statements to protect the server / zone(s) at the BIND 
application level.


Does that make sense?

What am I missing / misunderstanding?


that's why we are here.


:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Question About Internal Recursive Resolvers

[Grant Taylor via bind-users]

On 10/15/22 10:03 AM, Bob McDonald wrote:
My understanding has always been that the recommendation is/was to 
separate recursive and non-recursive servers.


I too (had) long shared -- what I'm going to retroactively call -- that 
over simplification.


Now I understand I'm talking about an INTERNAL environment and the 
rules have over the years become somewhat lax... In this case I also 
believe this would provide a more granular approach to using security 
features such as tsig keys to control updates.


I don't know if the rules have become more lax so much as been clarified 
to indicate internal / private vs external / (semi)public servers. 
Semi-public in things like an ISP allows it's IP space to perform 
recursive queries.


If a non-secure client (read the next sentence...) accesses the same 
recursive server as a regular client, it will have access to the 
internal zones by default.. Therefore we need to have some sort of 
access controls in place.


I think the emphasis is on "by default".  I also believe there are many 
ways to alter this default behavior.


Please forgive me if my post was confusing, arrogant, or naive. I'm 
simply trying to seek the wisdom of those on the list that have more 
experience or different experience than myself. Hopefully, I can gain 
from that wisdom and we can provide a kind environment where those 
less educated feel mentored.


I've found that almost everyone, myself included, tends to get invested 
and energetic in discussions.  Sometimes even animated.  But as long as 
we don't make anything personal and keep things at arms length, we can 
almost always see through the fog and help / learn from each other.


By all means, feel free to dislike / disagree with things I say / do. 
Please ask why I do things.  Please share why you think / do what you do 
as I'd like to learn from you.  But please, for the love of $DEITY 
please do not perpetuate ad hominem attacks.  --  Not that anyone has in 
this thread.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 over VPN

[Grant Taylor via bind-users]

On 9/6/22 4:16 PM, Michael De Roover wrote:
once I tried to do the same on the satellite network, BIND on the main 
network would see the zone transfer as coming from 192.168.10.51 or 
192.168.10.52 -- instead of coming from 192.168.20.3 -- and refuse 
it. The same is true the other way around, where the name server on 
the satellite network sees zone transfers from the main network as 
coming from 192.168.20.1 instead.


This screams of a VPN / routing / NATing / masquerading problem to me.

I would expect that BIND would see the traffic as sourced from the name 
server's LAN IP, not the local VPN gateway IP.


Presuming that the routing is working correctly, you should be able to 
configure BIND ACLs as you indicate you tried to do.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: rate limiting queries with firewall (was: Stopping ddos)

[Grant Taylor via bind-users]

On 8/2/22 3:15 PM, Grant Taylor via bind-users wrote:
It looks like you're dealing with A queries for the root domain.  I've 
blocked this, and similar queries, via iptables firewall in the past.


I've seen a number of responses to Robert's "Stopping ddos" thread 
discussing using firewalls (iptables) to /rate/ /limit/ queries.


I wanted to add an overarching comment that such /rate/ /limiting/ 
ultimately means that some amount of state must be maintained on 
systems.  This is a potential vector for a denial of service if left 
unchecked.


So I'd like to clarify that I believe that it is better in some 
situations to /statelessly/ /drop/ traffic that has no reason for going 
to a server.  E.g. a server that's only authoritative for 2nd level 
domains has no business responding to any form of queries for the root zone.


To whit I have the following rule in the PREROUTING chain of the raw 
table to filter out queries for the root zone.


iptables -t raw -A PREROUTING -i eth0 -p udp -m udp --dport 53 -m string 
--hex-string "|ff0001|" --algo bm --from 40 --to 65535 -j DROP


Just a follow up / drive by comment.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Stopping ddos

[Grant Taylor via bind-users]

On 8/2/22 2:02 PM, Robert Moskowitz wrote:

Any best practices on this?


It looks like you're dealing with A queries for the root domain.  I've 
blocked this, and similar queries, via iptables firewall in the past.


Also, make sure that you apply the same BIND ACL to the cache that you 
do for queries.  --  I had a system that didn't have the same ACL and 
rogue clients were able to get things from the cache despite not being 
able to initiate the queries directly.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 adoption

[Grant Taylor via bind-users]

On 8/2/22 11:51 AM, Brown, William wrote:
Or perhaps some way of the client side deciding how to handle hard v./ 
soft failure.


Wouldn't this require the client side being aware of DNSSEC and making 
decision based on it?


Maybe it's just me, but I think client application side DNSSEC 
validation is woefully lacking.


Maybe there could be an option to ask a recursive DNS server to do 
DNSSEC validation and return record data even if the validation fails. 
Then the client could decide to use the data or not based on it's 
preferences.


I feel like similar behavior can be achieved by messing with the CD / DO 
flags across multiple queries.  But even this requires the client side 
being aware of DNSSEC.  (See prior statement.)


I also feel like what we're discussing is dangerously close to defeating 
DNSSEC and antithetical to it's purpose.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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.11/RHEL7 Server Freezes FUTEX_WAKE_PRIVATE

[Grant Taylor via bind-users]

On 8/1/22 4:21 PM, Greg Choules via bind-users wrote:

Off the top of my head, could it be this?

random-device

...

BIND will need a good source of randomness for crypto operations.


Drive by plug:  If it is lack of entropy, try installing and running 
Haveged.  At least as a troubleshooting aid.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 signing of an internal zone gains nothing (unless??)

[Grant Taylor via bind-users]

Let's flip this on it's head.

On 8/1/22 10:15 AM, John W. Blue via bind-users wrote:
As some enterprise networks begin to engineer towards the concepts of 
ZeroTrust, one item caught me unaware:  PM’s asking for the DNSSEC 
signing of an internal zone.


So why shouldn't the internal zone(s) be signed?

Granted, it has long been considered unwise by DNS pro’s with a commonly 
stated reason that it increasing the size of the zone yadda, yadda, yadda.


Are we really going to let the storage capacity / memory consumption of 
the DNS server dictate the security posture?


If anything, it seems like this is a justification to upgrade the DNS 
server.  }:-)


While that extra overhead is true, it is more accurate to say that if 
internal clients are talking directly to an authoritative server the AD 
flag will not be set.  You will only get the AA flag.  So there is 
nothing to be gained from signing an internal zone.


An argument could be made that this seems like an excuse to not sign zones.

However, I have not tested it yet, I would assume that if a 
non-authoritative internal server was queried it would be able to walk 
the chain of trust and return AD.


I would expect so.


Thoughts?


Yes;  sign the internal zone(s).  Upgrade the servers to hold the 
(somewhat) larger zone(s) if you need to.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 signing of an internal zone gains nothing (unless??)

[Grant Taylor via bind-users]

On 8/1/22 11:51 AM, John W. Blue via bind-users wrote:
However, the intent of the thread is to talk about the lack of an 
AD flag from a non-public internal authoritative server.  Based upon 
what I am seeing only the AA flag is set.


There are multiple reasons to sign zones.  The existence of the AD flag 
is only one of them.


IM(NS)HO, the lack of an AD flag from an authoritative server is not in 
and of itself a reason to not sign zones; internal or otherwise.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 signing of an internal zone gains nothing (unless??)

[Grant Taylor via bind-users]

On 8/1/22 10:15 AM, John W. Blue via bind-users wrote:
While that extra overhead is true, it is more accurate to say that if 
internal clients are talking directly to an authoritative server the AD 
flag will not be set.  You will only get the AA flag.  So there is 
nothing to be gained from signing an internal zone.


I feel like that's an unacceptably big if.  It also precludes clients 
from doing client side DNSSEC validation.


Finally, why hold internal systems to a lower security standard than 
external systems?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 nsupdate remotely

[Grant Taylor via bind-users]

On 7/11/22 11:48 PM, Philip Prindeville wrote:

Hi,


Hi,

I have a remote subnet that has its own DHCP server, but wants to 
update the domain which spans several locations and subnets.


What do I need to do on both ends (remote DHCP server and central 
DNS server) to push updates over?
I would seriously consider secondary DNS server(s) doing zone 
transfer(s) at each remote site /and/ *configure* *the* *secondary* 
*server(s)* *to* *forward* *updates* *to* *the* *primary* *server* at 
the central site.


This would offer some autonomy for both DHCP /and/ /DNS/ in the event 
that the connection to the central site was unavailable.  Admittedly 
DDNS updates might fail during such an outage, but clients would still 
be able to get an IP /and/ /query/ /DNS/.


I know that this isn't quite what you have described / asked about, but 
it's what I would consider for such a multi-site installation and I 
believe I would be remiss if I didn't at least ask "have you 
considered".  ;-)




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: AXFR from Windows 2008R2 failing after upgrading to 9.18

[Grant Taylor via bind-users]

On 5/23/22 5:55 PM, Lefteris Tsintjelis via bind-users wrote:

Nothing actually. Windows logs are clean. Unix logs also.


#trustTheBitsOnTheWire
#useTheSniffer

I'd start by capturing w/ tcpdump using the `-s 0` and `-w 
/path/to/capture.pcapng` options.  Then use Wireshark to analyze the 
packet capture.


You may see the problem with tcpdump, especially if you turn verbosity 
up.  But Wireshark has some much nicer decoding and display than tcpdump 
does.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Dynamic A records similar to nip.io or xip

[Grant Taylor via bind-users]

On 5/23/22 4:30 AM, Nux wrote:

Hi,

Does anyone know whether it's possible to generate with Bind these kind 
of A records automatically on the authoritative side, similar to 
services like xip.io or nip.io? Eg:

127.0.0.1.nip.io -> 127.0.0.1
name.127.0.0.1.nip.io -> 127.0.0.1
and so on.


Does the $GENERATE directive in BIND zone files do what you need?

I have to look up the syntax and play with things every time I use the 
$GENERATE directive, but it has always done what I needed for things 
like this.


It's probably not what you want, but I'd expect that such generation 
could be done manually / programmatically outside of BIND and entered 
into a zone file as static data.  E.g. a for loop with counting 
redirecting into a file.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 record responses based on originating IP

[Grant Taylor via bind-users]

On 5/15/22 7:28 AM, Angus Clarke wrote:

Hi Grant


Hi Angus,


maybe, I'm reading up ...

poking around the manual, are you alluding to the "sortlist" directive?


Yes, that's what I was referring to.

So the concern with returning an ordered RRset is that the set could be 
large:


Okay.

I assume that's opposed to returning small distinct / unique RR sets 
with per client granularity.


The intention is that each private site/network will have its own DNS 
server pair and that local recursors resolve all private zones from that 
local pair. So things like NS records would be in scope for the ordered 
RRset response. With more sites come more DNS pairs and therefore more 
NS records to be added to the RRset. Maybe I can limit a RRset response 
to the first X number of entries?


Hum.

With this description in mind, I'd be tempted to do something with the 
anycast methodology that was recently discussed.  Return one small RRset 
that references the fixed set of any cast NS IPs.  Then routing at each 
site will get clients to the local instance of those anycasted IPs.


This would probably scale a lot better.


Thanks


:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 record responses based on originating IP

[Grant Taylor via bind-users]

On 5/12/22 2:41 PM, Nick Tait via bind-users wrote:

This sounds like exactly the sort of use case for Response Policy Zones:


How are you going to have RPZ return different addresses for different 
clients?  Are you suggesting use different RPZs with different contents 
for different clients?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 record responses based on originating IP

[Grant Taylor via bind-users]

On 5/12/22 6:30 AM, Angus Clarke wrote:

Hello


Hi,


With bind (and others) it seems that DNS views are the way to go,


Before stepping up to views I'd stop to ask the question, would 
returning multiple IPs in a preferred sort order suffice?


BIND has the ability to sort RRs differently based on different client 
criteria.


Does bind have some simple way to respond differently based on source 
address but on a per record basis? Or perhaps include a baseline zone in 
a view and separately include differences for that view - something like 
this perhaps?


If sorting of replies won't suffice, please provide a hypothetical 
example of a couple of different clients & responses for an example RR.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Determining Which Authoritative Sever to Use

[Grant Taylor via bind-users]

On 5/11/22 2:19 PM, Bob Harold wrote:

Not sure who set it up, but my DHCP servers have for some zones:

zone x.y.z.in-addr.arpa
{
     primary 10.2.3.4;
}


I'm assuming that is BIND's named.conf syntax.


Which I believe overrides the MNAME lookup.


Doesn't that just tell BIND where to initiate a zone transfer from?

I didn't think that it altered the zone contents in any way.

Aside:  I'm not connecting the dots of what this has to do with the 
larger conversation, /unless/ you are thinking that it alters the zone 
contents or at least what's returned to clients querying this DNS server.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Determining Which Authoritative Sever to Use

[Grant Taylor via bind-users]

On 5/11/22 11:24 AM, Bob McDonald wrote:
It would seem that using an anycast cloud name (An anycast cloud 
of the NS device IPs) for the MNAME might provide the same level of 
distribution as per Windows.  However, again, you run into the issues 
of forwarded updates.


Another thing that I've seen discussed -- but haven't tested myself -- 
is to play tricks like having the MNAME be it's own zone hosted on each 
DNS server wherein the zone resolves the MNAME to the local DNS server.


This seems like a varient on anycasting, which operates on the IP layer. 
 Except this provides similar functionality at the DNS application layer.


You could probably achieve similar results with an RPZ overriding the 
MNAME with the local server's IP address.


}:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Determining Which Authoritative Sever to Use

[Grant Taylor via bind-users]

On 5/8/22 5:58 AM, Tony Finch wrote:
Regarding anycast, it isn't necessary for internal authoritative 
servers unless your organization is really huge (and probably not 
even then): it is simpler to just use the DNS's standard reliabilty 
features. All you need to do is have more than one authoritative 
server for each zone.


I don't know if it's a requirement for the OP or not, but Windows used 
to reach out to the MName server to perform dynamic updates.  So there 
might be some merit to the name of the MName server to be a pseudo name 
that resolves to an anycasted address, thus clients try to perform the 
dynamic update to the closest instance of the anycast / (pseudo) MName 
server.


Aside:  Years ago, BIND secondaries would happily forward such dynamic 
updates the real primary MName server.


Further aside:  The last time I looked, MS-DNS ADI zones would forge the 
local server's name as the MName to cause this type of client redirection.


On the other hand, anycast is a good way to improve the availability 
and maintainability of your resolvers, because your users' devices 
talk directly to them, and if they don't work there might as well 
not be an Internet connection.


I agree that anycasted service points make administration somewhat 
simpler.  However I do question the /need/ for such flexibility when 
things like DHCP are likely used for client configuration and can 
therefor manage most things automatically.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 Server conflicts with docker0 interface

[Grant Taylor via bind-users]

On 5/5/22 1:35 PM, Maurà cio Penteado via bind-users wrote:

Hi folks,


Hi,


Thank you for the reply.


:-)

Unfortunately, I did not understand how I am supposed to add multiple 
A-records for the same name to the zone-file to fix this issue.


Based on your first message, you already have multiple A records for 
ns1.example.lan; 192.168.0.10 and 172.17.0.1.


My suggestion was to have bind order the two records in a way favorable 
to the requesting client.  E.g. if the client is on the 172.17.0.0/24 
network, reply with 172.17.0.1 and 192.168.0.10 verses if the client is 
on the 192.168.0.0/24 network where the response would be 192.168.0.10 
and 172.17.0.1.  Both get the same A records, just in a different order. 
 Ideally the order puts the optimal IP for the client's use first.



On my Bind9 server, I have the following zone-files:

forward.example.lan.db:
ns1     IN      A           192.168.0.10
ns1     IN          fe80::f21f:afff:fe5d:be90


I don't see the 2nd, Docker (?), address; 172.17.0.1, in the zone.  So 
if your client is still receiving that address in addition to the 
192.168.0.10 address, then something else is happening outside of BIND.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 Server conflicts with docker0 interface

[Grant Taylor via bind-users]

On 5/5/22 9:01 AM, Reindl Harald wrote:

by not add multiple A-records for the same name to the zone-file
BIND don't know about docker on it's own


Another option would be to leverage BIND's ability to sort A records 
based on configured preference (in the config file, not the zone file) 
based on client IP.  So even if BIND does return the Docker IP, it's not 
the 1st IP in the response, thereby hopefully alleviating the problems 
of it's existence.


This may be germane if the Docker IP is automatically registered and 
making it stop will be a different kettle of fish to roll up a different 
hill.


and please avoid HTML formatted mails, it makes responding with inline 
quotes more difficult as it should be


+10



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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 and forwarding

[Grant Taylor via bind-users]

On 4/12/22 7:18 PM, Duchscher, Dave J via bind-users wrote:

We are dropping this configuration and looking at doing something else.


I'm sorry to hear that.

We have had intermittent issues with Slack, Microsoft, and a growing 
list of domains. Even have one that consistently fails.


Are you able to share any specific details / examples so that others can 
see an example of what to loo out for?




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Can an RPZ record be used for a non-existed domain?

[Grant Taylor via bind-users]

On 3/24/22 4:34 PM, Carl Byington via bind-users wrote:

Yes, the disconnect was my brain. I will try to plug that back in.


;-)

We've all had those days.  Most of us will have them again.


How do you do that in /etc/hosts?


It's been a while, so I'm relying on memory, a.k.a. lossy media.

   /etc/hosts:
  a.b.c.d   outbound.example.com

Really that simple.  Forward lookup would search names (right hand 
side).  Reverse lookup would search the IPs (left hand side).


Maybe this is somewhat dependent on the stub resolver library on the 
system and / or the system itself.  It's been 5-15 years since I've last 
done this.  It could be very likely that things were quite different 25 
years ago.



For some users, for some (possibly all) senders, we require that d.c.b.a
.in-addr.arpa has some PTR record where the corresponding A record
resolves back to a.b.c.d.


There is also a key difference in what you've said vs what I've said. 
You seem to be using DNS specific terminology while I'm using host 
generic name resolution.  The former doesn't support /etc/hosts while 
the latter does.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Can an RPZ record be used for a non-existed domain?

[Grant Taylor via bind-users]

On 3/24/22 3:50 PM, Carl Byington via bind-users wrote:
In general, the domain exists with a bunch of existing names - www, 
mail, etc. We just need to add one more (outbound) and tie it to the 
ip address of their outbound mail server. I don't want to take over 
their entire domain. 


Fair enough.

But there seems to be a disconnect.

I was talking about adding a domain that is outbound.example.com. and 
put the A /  records in that domain's apex.  Thus you are only 
overriding outbound.example.com and nothing else in the example.com domain.


Rather than updating /etc/hosts on a bunch of customer mail servers, 
their dns server just zone transfers the rpz zone using notify/ixfr.


ACK  Using standard zone transfers for RPZ(s) is one of the many 
features of RPZ.


And many times, their error is in an incorrect or missing PTR record, 
so /etc/hosts does not help there.


We must have different experiences and / or have used different MTAs. 
I've routinely been able to address one offs do to lack of PTR via 
/etc/hosts entries.


But this is one rpz file to maintain, rather than adding a few hundred 
zones to the dns servers.


Fair enough.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Can an RPZ record be used for a non-existed domain?

[Grant Taylor via bind-users]

On 3/24/22 10:02 AM, Carl Byington via bind-users wrote:

I think so.


Agreed.

Presumably to create those domains locally. Of course the rest of 
the world won't see them.


1.0.0.127.in-addr.arpaPTR outbound.example.com.
outbound.example.com  A   127.0.0.1


What advantage does RPZ have in this case over just hosting the 
domain(s) locally?


Aside:  I've usually gotten around this specific problem via entries in 
/etc/hosts.  Maybe the software is more picky than what I've run into 
before.


I am a fan of RPZ and use it often.  I'm still trying to find which tool 
to use in various situations.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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

[Grant Taylor via bind-users]

On 3/1/22 5:35 AM, Matus UHLAR - fantomas wrote:

you are right, forwarding queries requires recursion.


Thank you for the confirmation Matus.  :-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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

[Grant Taylor via bind-users]

On 2/28/22 1:47 PM, Gregory Sloop wrote:
I figured before I beat my head against the wall for too long, I'd ask 
the real experts! :)


I'm definitely not an expert.  I don't even pretend to be one on T.V.

But I do wonder what, if any, sort of restrictions you are placing on 
recursion on your system.


It's my (mis)understanding that recursion has some effect on forwarding 
queries.  My limited understanding is recursion is another way of saying 
if the server should chase the answer for you or not.  If it doesn't 
have it in it's own data (authoritative and / or cache), then it's 
recursion setting comes into play.


If I'm mistaken, please correct me.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: ipv6 adoption

[Grant Taylor via bind-users]

On 2/16/22 9:24 AM, G.W. Haywood via bind-users wrote:

FWIW I've been using DNSSEC with HE slaves since October 2017.  I'm
happy to report that I've never had any problem with the service.


Please clarify if you are talking about DNSSEC for your own zone that 
they are doing secondary transfers of or if you are talking about DNSSEC 
for the IPv6's reverse DNS namespace that they delegate to you.


Also, +1 for the H.E. IPv6 training.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: ipv6 adoption

[Grant Taylor via bind-users]

On 2/16/22 7:35 AM, Mark Tinka wrote:
I was assuming Linux has something similar, where in userland, you have 
the option to install which train of BIND you want, regardless of OS 
version.


Most of the -- what I'll call -- binary distributions of Linux tend to 
have a fairly small range of any given versions of software in the 
repositories provided by the Linux distribution provider.


There is nothing that prevents you from sourcing other versions, binary 
or compile it yourself, from other providers.  But some people are 
unwilling to accept the risk.


But thinking about the days when I ran SuSE Linux and OpenSUSE (up until 
2007), I think I recall apps being tied to major/minor OS versions, when 
they used RPM as the package manager. It's been a while, so things may 
have since changed.


I'm used to seeing ~current, down level, and maybe bleeding level in the 
beta / early adopters distro releases.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Setup a hidden master

[Grant Taylor via bind-users]

On 2/15/22 1:07 AM, Bjørn Mork wrote:
You'll normally get a few update queries to the SOA MNAME if you 
leave the real master there.


This was going through my mind as I read the thread.

Aside:  BIND secondaries can be configured to forward such updates to 
the hidden primary.



Whether you should change the MNAME or not is another question...


Is there a recommendation / best practice regarding what to set the 
MNAME to in a hidden primary configuration?


I believe that each server in an MS-DNS AD integrated configuration uses 
it's own name as the MNAME.  I'm not aware of a way to do similar with 
BIND.  The closest that I've come (in a thought experiment) is to use a 
place holder name that each BIND server resolves said name to itself. 
This can be done with a dedicated name it it's own independent zone that 
each server has different zone contents to refer to itself.


Are there any recommendations around MNAMEs in a hidden primary situation?



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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?

[Grant Taylor via bind-users]

On 1/4/22 4:37 AM, Ray Bellis wrote:
Better yet, use BIND's mirror zones feature so that the zone is also 
DNSSEC validated.


Completely agreed.  I think the type of authoritative information is 
somewhat independent of the fact that any authoritative information exists.


IMHO, the strictures against running authoritative and recursive on the 
same server seem to get mis-applied a lot of the time.  I think it's 
perfectly fine for an *internal* recursive server to also hold 
authoritative copies of your own zones.


Yep.  This is where I have settled.  But I don't feel I can defend it 
when asked.  Hence my seeking to better understand.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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?

[Grant Taylor via bind-users]

On 1/3/22 10:57 AM, John Thurston wrote:
It must have a 'forward' zone defined on it for each of those stupid 
domains. And yes, you are right . . at that point it is no longer only 
performing recursion.


;-)

But there is no other way to do it. Even in a combined 
recursive/authoritative design, your server would have no way to resolve 
names in those stupid domains; there must be an explicit 'forward' zone 
defined.


If I'm allowing recursion and authoritative on the same server, I'd have 
the recursive + authoritative server do secondary zone transfers off of 
the internal MS-DNS / AD server.  That way the clients can get the info 
off of the first server they talk to.


To me, the secondary copy of the zone is a form of authoritative 
information on the otherwise recursive server.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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?

[Grant Taylor via bind-users]

On 1/3/22 12:15 AM, Borja Marcos wrote:
If you separate the roles it is much simpler to implement an effective 
access control.


The problem I have with separating recursive and authoritative servers 
has to do with internal LANs and things like Microsoft Active Directory 
on non-globally-recognized domains.


In short, how do you get a /purely/ /recursive/ server to know that 
internal-corp-lan.example (or any domain not in the global DNS 
hierarchy) is served by some other /purely/ /authoritative/ DNS server 
inside the company?


I feel like anything you do to the /purely/ /recursive/ DNS server to 
get it to know that it needs to route based on the DNS domain 
information slides away from the /purely/ /recursive/ role to somewhat 
/mixed/ /recursive/ & /authoritative/ role.


This niche role is the one nagging thing that I have that prevents me 
from supporting and proselytizing the role separation anywhere and 
everywhere.  --  I've been looking for, but have not yet found, what I 
consider to be a good method that maintains strict separation of roles 
in this niche use case.


Note:  I'm completely on board with the separate roles for public / 
Internet facing servers.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Grant Taylor via bind-users]

On 12/15/21 4:51 AM, Danilo Godec via bind-users wrote:

Hello,


Hi,

I'm noticing some unusual activity where 48 external IPs generated over 
2M queries that have all been denied (just today):


15-Dec-2021 00:01:42.023 security: info: client @0x7f96180b3fe0 
194.48.217.14#59698 (.): view outside: query (cache) './ANY/IN' denied


I see this type of thing on occasion.

I'm guessing this is some sort of an reflection attack attempt, but I 
don't quite understand if these are the perpetrators or victims?


I'd bet a reasonable lunch that these are spoofed addresses of intended 
victims.



Would I be doing a bad thing by using fail2ban to block these IPs?


As others have indicated, there are likely side effects to blocking the 
IPs, be it with fail2ban or otherwise.


I'd suggest investigating response rate limiting.  It seems like it can 
fairly gracefully help ensure that your server doesn't participate in a 
DoS reply attack while still playing fairly well with otherwise well 
behaving clients.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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-chroot queries on symbolic Links to named.conf

[Grant Taylor via bind-users]

On 12/9/21 12:18 AM, Harshith Mulky wrote:

Hello Experts


Hi,

I'm fairly certain that I'm not an expert, but I've dealt with BIND in 
chroot recently.



I need some help with bind-chroot

We are running below version of bind and bind-chroot

bind-9.11.2-lp151.10.1.x86_64
bind-chrootenv-9.11.2-lp151.10.1.x86_64


First, which platform and version?

Our Automation code is running to add Zone files to 
/var/lib/named/etc/named.conf only and not to /etc/named.conf


Is that the path that your automation is using?  Or is that the path to 
the named.conf file independent of your automation's influence?


So in order to reflect the zone files created in 
/var/lib/named/etc/named.conf in /etc/named.conf, i created a symbolic 
link in /etc as "ln -s /var/lib/named/etc/named.conf named.conf" to 
reflect as below
lrwxrwxrwx 1 root root 29 Dec  9 11:03 named.conf -> 
/var/lib/named/etc/named.conf


Please clarify, was this done outside of the chroot or is this a 
reference to /etc/named.conf inside the chroot?


Now, when I make changes to file in /var/lib/named/etc/named.conf and do 
a "service named restart"

The file in /etc/named.conf fails to Load


Is this "/etc/named.conf" inside of or outside of the chroot?


Error messages in /var/log/messages as below

2021-12-09T11:04:46.684677+05:30 lavasadns1 systemd[1]: Stopped Berkeley 
Internet Name Domain (DNS).
2021-12-09T11:04:46.685049+05:30 lavasadns1 systemd[1]: Starting 
Berkeley Internet Name Domain (DNS)...
2021-12-09T11:04:46.735359+05:30 lavasadns1 named.init[2509]: Starting 
name server BIND cp: cannot stat '/etc/named.conf': No such file or 
directory
2021-12-09T11:04:46.844546+05:30 lavasadns1 named.init[2509]: open: 
/etc/named.conf: file not found
2021-12-09T11:04:46.847806+05:30 lavasadns1 systemd[1]: named.service: 
Control process exited, code=exited status=6
2021-12-09T11:04:46.848137+05:30 lavasadns1 systemd[1]: Failed to start 
Berkeley Internet Name Domain (DNS).
2021-12-09T11:04:46.848475+05:30 lavasadns1 systemd[1]: named.service: 
Unit entered failed state.
2021-12-09T11:04:46.848772+05:30 lavasadns1 systemd[1]: named.service: 
Failed with result 'exit-code'.
2021-12-09T11:05:31.657460+05:30 lavasadns1 systemd[1]: Starting 
Berkeley Internet Name Domain (DNS)...
2021-12-09T11:05:31.666976+05:30 lavasadns1 named.init[2573]: Name 
server configuration file /etc/named.conf does not exist.
2021-12-09T11:05:31.667600+05:30 lavasadns1 systemd[1]: named.service: 
Control process exited, code=exited status=6


This is almost certainly from viewed as inside of the chroot.  Thus it 
is quite likely really the /var/lib/named/etc/named.conf file, assuming 
that's the proper path for the chroot.



and the Symbolic link changes color to Red.


That sounds to me like the sym-link is broken.  I don't know what is 
creating the break.  Either it was broken in the first place (bad paths 
used when creating it) or something removed / moved files. Or



Why is this happening?


Not yet.


And how can avoid this error


You're going to need to do some more investigation to identify the 
underlying cause.


If things work properly before automation and then break after 
automation I'd guess that automation is doing something that is 
incompatible with how you're trying to do things.


I'd suggest looking at the output of "namei -l" on any and all 
named.conf (et al.) files involved using any and all paths, both before 
and after automation.  Hopefully that will give some more information as 
to what might be wrong.


Note:  If you don't have namei installed, you can get similar 
information manually by doing an ls -l on each component in the path; 
/etc/named.conf becomes /etc/named.conf, /etc, and /.  Namei just makes 
that much more convenient, especially for deeper files.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Rear View RPZ: PTR records from local knowledge

[Grant Taylor via bind-users]

On 12/2/21 9:59 AM, Fred Morris wrote:
Hello, Rear View RPZ (https://github.com/m3047/rear_view_rpz) is now 
generally available: turn your local BIND resolver into a network 
investigation enabler with locally generated PTR records.


Would you please elaborate on what Rear View RPZ does?

It seems as if it synthetically fabricates PTR records (which are served 
via RPZ) with some additional information for subsequent use by 
investigators.


If that is correct, please provide an example of the original PTR and 
the synthetic augmented PTR.


Aside:  Creative use and combination of DNSTap and RPZ.  



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Grant Taylor via bind-users]

On 11/18/21 3:14 AM, Mark Elkins wrote:
With IPv6 - you might want to use NSEC3 - as there can be huge holes in 
the reverse zone. Make the bad guy work at guessing what is in the zone.


Be mindful of current efforts for minimizing NSEC3 rounds / iterations 
which purportedly have a diminishing RoI for higher counts.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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 ?

[Grant Taylor via bind-users]

On 11/13/21 9:07 AM, Reindl Harald wrote:

but you have to deal with it


And?  So?

We have to deal with all sorts of things.  The need to do our job is not 
a reason in and of itself a reason to not do it.



you missed my second post!


No, order of reply vs reading.


* he needs the delegation because lack of control


Maybe I've lost context, but I thought the overall theme of the thread 
was delegating to a private IP address.



* when the clients network is using a public
   forwarder the delegation simply can't work


My thought was around three DNS servers.

1)  Company A's local DNS server.
2)  Company B's local DNS server.
3)  Public DNS hierarchy which delegates A's domain to a private IP in 
A's LAN.


If there is a VPN between company A and company B, then client's on 
company B's LAN will use company B's local recursive DNS server.  B's 
recursive DNS server will receive the delegation from 3 to 1, traverse 
the VPN to talk to A.  Thus 2 will be able to resolve something 
delegated to A's DNS server with private IP.



* so the problem is lack of control and can't be solved

personally i would simply add additional names point to the LAN 
addresses in my normal public zone, you don't even need a full subdomain 
zone for add "something.priv.example.com" poining to 192.168.196.10




and not to forget: most networks are forwarding to some public 
nameserver which can't reach your private named at all


I don't view -- what I consider to be -- questionable practice to be a 
valid reason to not do something.  A *LOT* of people smoked in the mid 
19th century, and that's turned out to be not as good as once thought.


I would advocate for businesses to have their own LAN based DNS servers 
that are authoritative for their own zone(s) and recursive for other 
zones.  If people want, they can have their local DNS server forward the 
recursive responsibility elsewhere.


In some ways this thread is a re-hash of the venerable "Why can't Google 
DNS figure out my private Active Directory? ... But WHY?!?!?!".




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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 ?

[Grant Taylor via bind-users]

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?  Or is it the end systems behind the resolvers failing 
to be able to use the resolved private IP and trying resolution again? 
How and why does an authoritative server returning authoritative data 
cause resolvers / clients to send more queries?


Note:  I'm expanding "private" to be an IP that is not globally 
accessible, because it's RFC 1918 (et al.), not globally routed, 
firewalled, etc.  If this is not a fair expansion, please enlighten me.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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 ?

[Grant Taylor via bind-users]

On 11/13/21 12:59 AM, Reindl Harald wrote:
i doubt that any ISP out there would delegate to a private address and 
when your bind is asked over it's public IP a view won't work


ISP's willingness to do something is a policy decision and that's 
completely different than their capability to do something which is a 
technology decision.


I see zero reason that a parent zone operator can't delegate something 
to a private / non-globally-routed IP.



chicken / egg


Not necessarily.  Just because the Internet at large can't access the IP 
that the child zone is delegated to doesn't mean that business partner's 
can't access it.  --  I believe that I saw in one of the messages that 
there was a VPN between the sites / business partners which did support 
/ provide routing to the private IP.


In some ways, this is similar to making something resolve to 127.0.0.1 
and / or ::1.  That information can be published in globally accessible 
DNS, but it will likely be of very limited value.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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 service suddenly fails to start

[Grant Taylor via bind-users]

On 11/4/21 1:27 PM, Bruce Johnson via bind-users wrote:
named-checkconf -z revealed a name had been entered with underscores. 
The person responsible has been sacked. (not really, merely reminded no 
underscores are allowed in A records :-)


You might want to apologize to them.

Underscores are legitimate in DNS record owner names, despite the 
disagreement of their use in hostnames.


Underscores are used in _acme-challenge., TLSA records 
_25._tcp._smtp., and DMARC _dmarc. to name a 
few legitimate uses.  (from a quick `fgrep dig $HISTFILE | fgrep _`)


Remember, DNS is (a lot more) than /just/ hostnames.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Grant Taylor via bind-users]

On 10/21/21 1:33 AM, Edwardo Garcia wrote:

Hai all,


Hi,

One of these is we have a number of reverse zones, a /19 in fact, they 
are mostly GENERATE'd  for regions with fixed gw and a few other local 
custom PTRs


So 32 x /24s.  Annoying, but not terrible to work with.


In our examples I have tried
zone "8-15.110.100.in-addr.arpa" {
         type master;
         file "cgnat.rev";
         notify no;
};
I also tried 8/21.110.100...


I've had bad luck with "/" in domain (dot) names (of in-addr.arpa and 
elsewhere).


and it always complain loading from master file cgnat.rev failed: 
unknown class/type


The zone file has usual header, and PTR entry are only
151.10  PTR     blue.stop.
(even tried   10.151)


I don't see the expected "IN(ternet)" class indication.  That matches 
the unknown class / type message you are getting.


I would expect something like the following:

151.10   3600   IN   PTR   blue.stop.

Perhaps there is a BIND zone file optimization that I'm not taking into 
account.


I guess bind can not consolidate like this and we have to put up with a 
million /24 zone files ?


Maybe it's just me, but I feel like 32 is a far cry from a million /24 
zone files.


I was thinking because we can do classless dele with smaller than /24, 
it would work on bigger  :)


Remember, DNS does things on the domain (dot) boundary.  DNS ~> BIND 
does not have any knowledge that "8-15" or "8/21" in the 
"8-15.110.100.in-addr.arpa" or "8/21.110.100.in-addr.arpa" domains 
represent subnet prefixes.  To BIND, they are just strings of text that 
mean something to the hostmaster.  This is why RFC 2317 CNAMEs some of 
the records to records in a separate domain name that can be delegated.


You should be able to use $GENERATE to be able to create the records.

   $GENERATE 0-15 $ CNAME $-21.110.100.in-addr.arpa.

That being said, I would never use RFC 2317 CNAME alias for the 3rd 
octet.  I would use standard NS delegation.  E.g.:


   $GENERATE 0-15 $ NS mydnsserver.example.net.

Then I would configure the domains / zones on my DNS server.

...

Aside:  I've been known to use what I refer to as cross delegation.  It 
works for me.  But credible people have discouraged it.


Server 1 has records like this:

   $GENERATE 0-127   $.2.0.192.in-addr.arpa. PTR $.2.0.192.in-addr.arpa.
   $GENERATE 128-255 $.2.0.192.in-addr.arpa. NS server2.example.net.

Server 2 has records like this:

   $GENERATE 0-127   $.2.0.192.in-addr.arpa. NS server1.example.net.
   $GENERATE 128-255 $.2.0.192.in-addr.arpa. PTR $.2.0.192.in-addr.arpa.

This simply re-uses the same method of delegating owner names / 
sub-domains from one server to another server.  I tend to refer to this 
as cross delegation.  Some will refer to this as an ugly hack.  But it 
has worked for me every time that I've needed to use it.


...

Finally, the more that I look at your 100.110.8/21 example, the more 
that I realize that you're probably wanting to have two incrementing 
numbers, the 8-15 for the 3rd octet and 0-255 for the 4th octet.  I 
don't think that $GENERATE can do that.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Reloading new certs for DNS over HTTPS

[Grant Taylor via bind-users]

On 9/9/21 10:29 AM, Ondřej Surý wrote:
I think the rndc reconfig should pick the new cert/key, but I am not 
sure if we have actually implemented this.


Drive by comment:

Should BIND /need/ to take any action for a /reconfig/ if it's 
configuration hasn't change?  --  To me the configuration is the same.


This seems more like an issue where I would expect to HUP a daemon, or 
something more than /just/ a /reconfig/.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Grant Taylor via bind-users]

Tony's statements surprised me enough that I shaved them for later deep 
read and pondering.  That time has now come.


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).


My motivation was wanting to understand how what Tony was relaying 
related to localhost being it's own top level zone with only an A and / 
or  record(s) resolving to 127.0.0.1 and / or ::1 respectively.


I'm still not convinced that fully qualified localhost.(implicit null) 
is a problem in and of itself.  But I see how unqualified localhost can 
~> is a problem.



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

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


RFC 6761 section 6.3 seems to support having the fully qualified 
localhost.(implicit null) zone.


Points #4 and #5 makes me think that authoritative responses for fully 
qualified localhost.(implicit null) should be returned.


I feel like BIND's deny-answer-addresses {...} is a very good option to 
help protect against answers that would resolve to 127.0.0.1, et al. 
Among other things, I have the following:


acl "IANAspecialPurpose" {
   0.0.0.0/8;  // "This network"[RFC791], 
Section 3.2  1981-09N/A True  False
   10.0.0.0/8; // Private-Use   [RFC1918] 
   1996-02N/A True  True
   100.64.0.0/10;  // Shared Address Space  [RFC6598] 
   2012-04N/A True  True
   127.0.0.0/8;// Loopback  [RFC1122], 
Section 3.2.1.3 1981-09N/A False [1] False [1]
   169.254.0.0/16; // Link Local[RFC3927] 
   2005-05N/A True  True
   172.16.0.0/12;  // Private-Use   [RFC1918] 
   1996-02N/A True  True
   192.0.0.0/24;   // IETF Protocol Assignments [RFC6890], 
Section 2.1 2010-01N/A False False
   192.0.2.0/24;   // Documentation TEST-NET-1  [RFC5737] 
   2010-01N/A False False
   192.168.0.0/16; // Private-Use   [RFC1918] 
   1996-02N/A True  True
   198.18.0.0/15;  // Benchmarking  [RFC2544] 
   1999-03N/A True  True
   198.51.100.0/24;// Documentation TEST-NET-2  [RFC5737] 
   2010-01N/A False False
   203.0.113.0/24; // Documentation TEST-NET-3  [RFC5737] 
   2010-01N/A False False
   240.0.0.0/4;// Reserved  [RFC1112], 
Section 4   1989-08N/A False False
   255.255.255.255/32; // Limited Broadcast [RFC8190] 
[RFC919], Section 7  1984-10N/A False True

};

deny-answer-address {
   ...
   IANAspecialPurpose;
   ...
} except-from {
   ...
}

My understanding, and intention is that anything that returns an address 
that IANA considers to be special purpose ends up filtered.  The only 
exception being my personal domain.  I also have my own networks that 
don't fall within the IANAspecialPurposes ACL listed (...) as their own 
ACLs and should be filtered.


My current takeaway is that localhost., other than 
localhost.(null), is verboten, and that localhost.(null) is okay. 
Please enlighten me if this is an incorrect / unsafe takeaway.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Any interest in a write-up showing how to configure BIND 9.17x with DoH and LetsEncrypt?

[Grant Taylor via bind-users]

On 5/30/21 9:24 AM, Richard T.A. Neal wrote:
I spent a little time this weekend setting-up BIND 9.17.13 on Ubuntu 
21.04 and configuring the system as a recursive resolver offering DNS 
over HTTPS using a LetsEncrypt certificate.


Nice work.

Is there any interest in me writing this up as a web article, or has 
everyone who’s interested in DoH already got it running comfortably in 
their test environment?


Yes!

I would be /very/ interested in reading such a write up.

If you do write it up, please share where you publish your write up.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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.16 zone SOA record issue.

[Grant Taylor via bind-users]

On 5/23/21 9:27 AM, Ondřej Surý wrote:
Nope, that’s how you enter email to SOA with dot in user part as 
the first dot gets converted to @.


#TodayIlearned

I agree with Ondřej.  I think it's the missing $ in front of ORIGIN. 

Remember the $ lines are directives to BIND and not zone data. 
ORIGIN without the leading $ would be zone data.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Grant Taylor via bind-users]

On 4/27/21 10:24 AM, Kevin A. McGrail wrote:

Agreed on the OT and good subject change.


:-)

For me, I wouldn't bind DNS to the eth0, just another attack surface 
hence I would use local loopback.


I think the main reason to bind to eth0 / LAN is for when there are 
multiple (mail) servers that can benefit from a common instance of BIND. 
 As opposed to having a dedicated instance of BIND on lo per (mail) server.


Having a DNS on the lan is good too but caching on any mail server is 
good.


Do you think that per (mail) server instances of BIND are worth the 
additional administrative overhead as compared to more central shared 
instances?


E.g. if you had 29 mail servers, would you run BIND on each of their 
lo's?  Or would you use a small number of central / shared / redundant 
servers?



There are a lot of DNS queries for email and anti-spam.


Yep.


But the key takeaway is don't use something like quad-8.


}:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

OT: How to Easily Set Up a Full-Featured Linux Mail Server on Ubuntu 18.04.5 LTS with iRedMail 1.4.0

[Grant Taylor via bind-users]

BIND-Users on topic content first:


#1 bind for a local caching DNS query server


I absolutely agree.


and change resolve.conf to 127.0.0.1 for the best RBL performance.


How much effective performance difference does the loopback interface 
(lo) vs the local LAN interface (eth0) make?


Similarly, how much effective performance difference does an on host 
instance of BIND make vs across the LAN to another host in the same site 
make?


I absolutely agree that a /local/ /to/ /the/ /network/ caching DNS 
server is a boon for email.  --  Definitely avoid simply relying on big 
3rd party resolvers across the Internet.




Aside:  The rest of my reply gets to ride along and would not have been 
sufficient for a reply in and of itself because I believe it's off topic 
for BIND-Users.


On 4/27/21 7:55 AM, Kevin A. McGrail wrote:

Very nice.


It's interesting.  It's a recent take on one of many ways to host your 
own email.


This was also posted on Postfix's list but nice to hear firsthand 
reports as I just read it.


I saw this message splattered to a number of mailing lists, many of 
which I think the message (content) was rather off topic for the list. 
E.g. what does it have to do with the BIND DNS server installation, 
configuration, and operation, other than the fact that email usually 
relies heavily on DNS service (implementation independent).



Two minor notes to continue the project that you might consider:

#1 bind for a local caching DNS query server


(See above.)


#2 add the KAM ruleset: https://mcgrail.com/template/projects#KAM1


To each their own.

Email administration is a massive topic in and of itself, which is 
probably better discussed elsewhere.


I appreciate the recent, as in not months ~> years old article 
encouraging people to host their own email.  Though I personally 
disagree with it or would do things a fair bit differently.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: NXDOMAIN processing

[Grant Taylor via bind-users]

On 4/26/21 2:45 PM, bamberg2000 via bind-users wrote:

Hi!


Hi,

BIND 9.11.5, I forward the request ("forward zone" or global "forward 
first") to another server and I get NXDOMAIN. Is it possible to process 


NXDOMAIN other than "redirect zone"? I just want to repeat the request 
to another forwarder.


I'm not sure what your actual use case is or if what I did will work.

I wrote a quick overview article about something I did years ago that 
/might/ help with what you /may/ be doing.


Link - Duplicate authoritative DNS zones ... on purpose
 - 
https://dotfiles.tnetconsulting.net/blog/2013/0610/Duplicate-authoritative-DNS-zones-on-purpose.html


TL;DR:  Two BIND servers worked in concert with each other such that the 
master / authoritative zone in the D.R. environment could be a subset of 
the production environment to override things while still falling back 
to the full prod environment for records that weren't overridden.


It's a bit of a hack, but it allowed us to enter the ~100 names specific 
to the D.R. environment and leverage the other thousands of names from 
prod without needing to import / merge records in D.R.


I don't remember why simply using RPZ to override wasn't sufficient.  I 
think it had to do with the infrastructure / configuration I was working 
with.


Maybe this will give you some ideas.  Or maybe it wasted some bandwidth 
and 30 seconds of people's time.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Grant Taylor via bind-users]

On 4/12/21 1:41 PM, Peter Coghlan wrote:
As far as I can see providing no response at all in any instance when 
a code 5 refused response would normally be returned would be the 
appropriate thing for my nameserver to do here and doing this would 
cause no difficulties at all with any legitimate queries or anyone 
who is not an abuser.  Am I correct here?


You might consider filtering the egress code 5 from your server via 
local firewall.  I'm not entirely sure how to do this.  But I suspect 
that your platform's firewall has an option.


I know that I've used IPTable's "string" match extension to filter out 
problematic inbound queries at times in the past.  Perhaps something 
like this could be pressed into service to filter outgoing code 5 replies.


You might be able to apply the same methodology to filter unwanted 
inbound queries to completely avoid sending the reply code at all.


All results of my research point to the use of rate limiting as the 
only approach available for dealing with this sort of issue.


There are always multiple ways to do things.  It's a question of how 
practical they are.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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

[Grant Taylor via bind-users]

On 3/31/21 10:00 AM, Tony Finch wrote:
Because of this, if it's important for you to avoid multi-second 
DNS lookup times ... you need to design your system so that the libc 
resolver never tries to talk to a DNS server that isn't available.


I've seen various client OSs fail in really weird ways when the first 
DNS server in the list doesn't respond quick enough, much less never.



Another way is a high availability setup for your recursive servers.


+1 to something like VRRP / CARP / routing tricks to make sure that the 
Virtual / Service IP that client's use as the first DNS server is always 
available.  Even if the first and second IP are on the same system for a 
few minutes while the other is patched.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Advice on Bind9/ISC DHCP cluster

[Grant Taylor via bind-users]

On 3/25/21 9:19 AM, Olivier wrote:

Hello,


Hi,


I would like to implement a 3 hosts cluster with the following features:


I don't see anything conceptually wrong with what you've outlined. 
Though I wouldn't call it a "cluster".  To me a cluster is something 
that is (as largely as possible) self redundant meaning no Single Point 
of Failure.  You are SPoFed on host1.



1- host1 is a bind9 master
2- host2 is a bind9 slave/ISC DHCP primary
3- host3 is a bind9 slave/ISC DHCP secondary
4- primary ISC DHCP instance sends dynamic updates to bind9 master
5- secondary ISC DHCP instance sends dynamic updates to bind9 master
6- DNS clients queries Bind9 slaves (hosts 2 and 3)
7- DNS updates are made on Bind9 master


I assume that you are thinking that the DHCP server will be sending the 
updates.


It's probably worth pointing out that the bind9 secondaries (host2 & 
host3) can be configured to forward any dynamic updates which they 
receive on to the primary (host1).  This is germane when clients send 
dynamic updates to the DNS server(s) that they are querying.  IMHO 
Windows is (at least used to be) notorious for doing this.


I can accept to loose (either static or dynamic) updates if host1 
is down


This is the SPoF that I was talking about.

You also need to be mindful of your expiration timers on your zone(s). 
What if the primary server is down for 8 days (for reasons) and the 
secondaries honor a zone expiration time of 7 days?



1. Is it possible to implement both 4 and 5 ?


I would assume that #4 can be done.

I would expect that #5 can be done.


2. Any alternative architecture (I can use up to 5 hosts) ?


I /think/ that BIND has some options to use something else, a 
(traditional) DB and / or LDAP for zone information via Dynamically 
Loadable Zones.  Thus you can use replications features in the DB / LDAP 
servers that work to avoid the SPoF of a single primary.


I would highly recommend that you consider VRRP et al. for VIPs that 
clients point to.  That way you can move them between servers as you 
need to have one down for maintenance.  --  I've seen some clients get 
really crochety and not fall back to their second configured DNS server 
nearly as gracefully as I would have hoped.  Having the preferred DNS 
server's VIP re-homed on an alternate system would have allowed the 
client to think that it's preferred server is and responding like 
normal, even if the real host is out of the rack and in pieces on the floor.


Depending on your needed scale you might consider some form of load 
balancing.  --  You can look at some form of ""hardware / ""appliance[1] 
based load balancer or you can look at a host based software solution. 
--  There are a number of solutions in this space.  But they are 
somewhat platform dependent and I don't see any information on what 
platform you're using.


[1] What is ""hardware / ""appliance other than a different host that 
runs software.


Good luck.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Dynamic zone update problems, continued

[Grant Taylor via bind-users]

On 3/5/21 1:41 PM, Bruce Johnson wrote:
Turne out to be a dumdum mistake on my part. SELinux was set to 
enforce…set it to permissive and voila! the .jnl file was created.


Ah.

That sounds like an SELinux policy problem.  SELinux /should/ allow 
named to create journal files.


A non-default location may be an contributing factor.


I coulda sworn I’d fixed that before...


I would not be surprised if a system update accidentally overwrote a 
tweak to a SELinux policy.


If you can't tell, I prefer to leave things enabled at the security 
posture they are at and provide exceptions for things that need to be 
allowed.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Dynamic zone update problems, continued

[Grant Taylor via bind-users]

On 3/5/21 12:07 PM, Bruce Johnson wrote:
Fixing the permissions and restarting named got dynamic updating 
working again, but new systems (ie names that are NOT already in 
the Zone file ) are throwing errors about the journal file: error: 
journal open failed: unexpected error


It seems like you still have a permissions error.

Can the user that named is running as create new files in the directory 
where the zone is stored?


Is there a specific command to create the .jnl file? I thought named 
created it automatically as needed. (at least the named-journalprint 
man page indicates this…)


I don't remember ever needing to manually create a journal (.jnl) file. 
I think that named always did it.


Named will create, modify, and remove the journal file as needed.  rndc 
freeze will sync the in memory zone contents to the journal file.  rndc 
sync will sync the journal file to the main zone file.  The -clean 
option to rndc sync will remove the journal file.  --  Don't forget to 
rndc thaw a frozen zone to start allowing dynamic updates again.


Beyond that, I've not needed to worry about the journal file or it's 
contents.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Can't use Bind DLZ through LDAPS SSL

[Grant Taylor via bind-users]

On 2/16/21 11:54 PM, Dario García Díaz-Miguel via bind-users wrote:

Hi everybody,


Hi,

Since I'm a little bit desperate with this issue, and after asking 
this on reddit (r/sysadmin) and serverfault with low or none responses,


I think it would be worth half an hour or so to test stunnel.  It should 
be able to help prove your overall end to end design works.  Having a 
successful end to end design will also help defend the use of the tool.


You can also probably dig deeper into why you might need stunnel 
independently of does the design work.


Sometimes having additional information, via a crutch, helps in 
diagnosing problems.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Can't use Bind DLZ through LDAPS SSL

[Grant Taylor via bind-users]

On 2/12/21 4:49 AM, Ted Mittelstaedt wrote:
If you are not familiar with stunnel you should have looked up what 
it was before responding.  It's not going to be applicable here and 
I would not have suggested it if I had known both programs were on 
the same machine.


What does being on the same machine have to do with using stunnel or not?

Won't stunnel be configured to listen on one port and connect to a 
different port?


Thus the connections would be:

127.0.0.1: --- 127.0.0.1:389
127.0.0.1: --- 127.0.0.1:639

What am I missing?



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Quick dynamic DNS?

[Grant Taylor via bind-users]

On 12/24/20 3:05 PM, Mark Andrews wrote:
TSIG, GSS-TSIG and SIG(0) are all secure mechanisms to update DNS 
zones.


Thank you for the follow up Mark.

It's good to know that they are secure mechanisms.

With all the churn in the TLS space, I can't keep up with it, much less 
have any idea how the concepts cross pollinate to other things.



MacOS uses TSIG to update the DNS.

Windows uses GSS-TSIG in active directory.


*nod*

Jan-Piet Mens has a good article on this.

SIG(0) is in future work for home net updating records added on a 
first come basis.  It can also be used to update records added by 
other means as long as the KEY records where added at the same time.


Would you please elaborate what you mean by "on a first come basis"?  Is 
it simply the first person to put a KEY record, or someone that has 
knowledge there of?


Thank you for enlightening me.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Quick dynamic DNS?

[Grant Taylor via bind-users]

On 12/24/20 8:48 AM, @lbutlr wrote:

That is what example.com always is, yes.


Sorry.  I'm so used to people not using documentation domains that I 
double check that they aren't actually trying to literally use 
documentation domains internally.


It's a refreshing change to see documentation domains / IPs / networks 
used properly.


I tip my hat to you.


As I said, it is authoritative for example.com.


ACK


Yep.

No, I just want my bind server to get updated with the external IP 
of my home connection when it changes and update the A pointer.


Okay.  IMHO that's relatively easy to do.  See Stanley's reply as it 
seems quite good.


About the only thing that I'd do differently is to use update-policy { 
... } "grant" statements to more granularly control what the key can 
update.  E.g. allow it to /only/ update A and / or  records for the 
home.example.com name and nothing else.


An alternative to grant statements is to use a CNAME to yourself in a 
different sub-domain where you have carte blanch access to update.  But, 
seeing as how the CNAME will reference explicitly one name, you have 
less of a security risk in the alias domain.  E.g. home.example.com -> 
home.client1.ddns.example.com.  Then give each client the ability to 
update it's client#.ddns.example.com sub-doimain.



I just want to update the IP address in a single A record.


IMHO that makes this almost trivial once you know how to do it.


Possibly, though that is certainly part of what I am asking.


*nod*nod*


But the bind server doesn't know the new IP address?


SSH from rPI to bind9 and remotely run a command.  Possibly extracting 
the IP from the SSH_{CLIENT,CONNECTION} environment variable.  ;-)


As I said. The bind server is at example.com. It is authoritative 
for example.com (and several other domains as well).


*nod*nod*nod*

I expect that many on this list have such systems at their disposal.  }:-)

At home I have a connection to an ISP and that connection MAY change 
since it is in a DHCP pool. I want to be able to updated my DNS server 
so that "home.example.com" points to my home IP address.


Typical and quintessential use case.

I have done this in the past with various dynamic DNS services (like 
DynDNS) where their software client would automatically update a custom 
subdomain of one of their domains like homeftp.net (the have many and 
which one isn't relevant) and then on the Bind server I would have, 
for example, in example.com,


home	CNAME lbutlr.homeftp.net. #example name, not real dynDNS 
address)


When the client updated my IP address, bind would simply relay 
connections to home.exmple.com to lbutlr.homeftp.net regardless of 
what the IP address was.


What I want to do is eliminate the 3rd party service and client so 
that the bind server can simply have:


homeA   12.34.56.789 # obvs not a real IP


Aw ... no Test-Net IPs?  :-P

IMHO what you're wanting to do is quite doable with a little bit of 
knowledge and trial and error.  See Stanley's email for more details on 
said knowledge.


The only parting thoughts I'll add is that I don't know if TSIG keys are 
sufficiently secure, or if there is a better option.  I've not looked in 
a while.  --  I personally tend to isolate what can be changed with 
grant statements and consider it good enough.  --  This is also where 
remotely executing nsupdate through SSH sort of elides this issue and 
makes things somewhat simpler.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Quick dynamic DNS?

[Grant Taylor via bind-users]

On 12/23/20 6:53 PM, @lbutlr wrote:
Give that I have a authoritative bind9 server for example.com and 
given that I have a home connection that is (technically) dynamic 
home.example.com what is the easiest way for me to automatically 
update the DNS on the rare occasions that it changes?


I assume:

1)  That example.com is a stand in for the real domain name(s)
2)  Your bind9 server is somewhere on the Internet
3)  You are asking how to dynamically update it to change where 
home.example.com resolves to.


The example.com domain is setup with DNSSEC and the home connection 
has a rPI already acting as an unbound/piHole server, if that helps.


Are you wanting to do some sort of zone transfer from the rPI to BIND?

Is home.example.com public or private?  Can the world query it?

I used to use a dynamic DNS service, but I figure I have the tools 
available to do this all myself. What am I doing right now is just 
manually changing the IP.


ACK

I'm going to further assume:

4)  That you have home.example.com delegated to the rPI at your house.
5)  That you want to dynamically update this delegation.

You can use BIND's support for Dynamic DNS across the Internet.  (I 
can't speak to the security of such.)  I assume that you will be using 
something like TSIG keys or Kerberos to authenticate your Dynamic DNS 
updates.  (Possibly even a VPN or the likes.)


Or you can use nsupdate on the system hosting your public BIND DNS server.

Please clarify where the Dynamic DNS client will be in comparison to the 
BIND DNS server.  Then we can get into the minutia of how to go about 
things.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: named can't listen while using VRF

[Grant Taylor via bind-users]

On 12/14/20 9:50 PM, Mark Andrews wrote:

In theory all that should be needed is "ip vrf exec [ NAME ] named …"


What I've done with l3mdev makes me think that if BIND is run in the 
master network namespace, it should be able to bind (no pun intended) to 
IPs across VRFs if the l3mdev allows (as in tuneable).


Yes, BIND can be run inside of a network namespace / vrf without 
problems.  But that would make it be isolated to said network namespace 
/ vrf.  But that contradicts one of the primary uses cases for l3mdevs 
that I'm aware of.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: srv lookup in record

[Grant Taylor via bind-users]

On 8/25/20 8:43 PM, John Levine wrote:
These SRV records say that the service is on ports 31024, 31852, 
and 31790 on the respective servers.  CNAME does not give you a 
port number.  There is no way to fake SRV using CNAME.


Agreed.

I've had some off-line conversations with Marc about some related 
things, so I thought he was only looking for the IP aspect and not 
worried about the port aspect of the SRV records.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: srv lookup in record

[Grant Taylor via bind-users]

On 8/21/20 4:26 PM, Marc Roos wrote:
Is it possible to use srv lookups, like eg cname. I do not want to 
create SRV record, I just want to 'get' the ip addresses, that I 
would get vai srv lookup.


I don't know of any over the counter - if you will - way to do what - I 
think - you want to do.



Say I have this task

[@temp3]$ dig +short server.test.marathon.mesos
192.168.123.101
192.168.124.50
192.168.124.52
192.168.124.51
192.168.123.100
192.168.123.102


Are these the IP addresses that the names in the following SRV records 
resolve to?



[@temp3]$ dig +short srv _http-apps._server.test._tcp.marathon.mesos
0 1 31024 server.test-usbzr-s3.marathon.mesos.
0 1 31852 server.test-z9x84-s3.marathon.mesos.
0 1 31790 server.test-k7g8r-s4.marathon.mesos.

[marc@os0 temp3]$ dig +short srv 
_http-demo._server.test._tcp.marathon.mesos

0 1 31791 server.test-c8g8b-s4.marathon.mesos.
0 1 31025 server.test-wtbza-s3.marathon.mesos.
0 1 31853 server.test-d0x87-s3.marathon.mesos.

I would like to only make available the ip addresses that are in the 
same range. If I would use a cname like this:


What does "same range" mean in this context?

Is it the client's IP range?  Or is it the server's IP range?  Or some 
reference to _http-apps vs _http-demo?


To me, the following three owner names are completely independent of 
each other.


 - server.test.marathon.mesos
 - _http-apps._server.test._tcp.marathon.mesos
 - _http-demo._server.test._tcp.marathon.mesos

I see how we as humans can probably correlate the three.  But I don't 
see how BIND will do it.



server.local.   CNAMEserver.test.marathon.mesos.


That seems like a simple enough alias.  Simple enough that I think that 
it's existence can largely be ignored and focus on the IP extraction 
from SRV record(s) that I think you're asking about.



I would get 6 of which 3 ip addresses are not in the same range. So I
need to have something like

server.local.   ???  _http-apps._server.test._tcp.marathon.mesos.


How are you going to convey the "???" portion in the owner name of the 
DNS query?



Is this possible in bind-9.8.2-0.68.rc1.el6_10.3.x86_64?


I don't think what - I'm speculating - you want is possible as is with 
stock BIND.


I do wonder if you might be able to write a custom Dynamic Loadable Zone 
database (?) driver that might be able to do what you want.


Specifically, if you could create a DLZ driver that could take the query 
name, apply some logic to it (to determine the "???" above), perform the 
proper resolution of the SRV record(s), post process, and return the 
desired result to the original DNS query.


$Marc's_Request   IN   CNAME   bind-dlz.sourceforge.net

Link - BIND DLZ Home
 - http://bind-dlz.sourceforge.net/

Aside:  I think this is atypical of BIND.  But I also think that it 
/may/ be in BIND's wheel house to ... hack a possible solution to.


Further aside:  I have wondered about a custom DLZ that would return the 
client's IP address (as seen by the server).  I'd like to roll my own 
"what's my IP" type service.  }:-)




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: scripts-to-block-domains

[Grant Taylor via bind-users]

On 7/14/20 12:08 AM, MEjaz wrote:
Thanks for every one’s  contribution.  I use RPZ and listed 5000  forged 
domain to block it in  a particular zone  without having addiotnal 
zones, I hope that’s the feature of  RPZ, Seems good.


You might want to look through those domains and see if there are any 
name servers that stick out significantly more than others.


Presuming that there are some believed to be bad name servers, you can 
also use RPZ to filter traffic to said name servers carte blanch, even 
if the names aren't listed in the RPZ, yet.  ;-)




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: scripts-to-block-domains

[Grant Taylor via bind-users]

On 7/13/20 12:44 AM, MEjaz wrote:

Hell  all,


Hi,

I have an requirement from our  national Cyber security to block several 
thousand forged domains from our recursive servers, Is there any way we 
can add clause in named.conf to scan such bogus domain list without 
impacting the performance of the servers.


$RPZ++

If you can't use RPZ, then you /can/ create skeleton zones to make your 
server authoritative for the zones in question.  However, there are 
drawbacks to this regarding performance based on the number and size of 
all the additional zones.


I would strongly recommend RPZ, or the new Response Policy Service, 
which there are a few commercial implementations of.  RPS is for DNS 
what milters are for mail servers.


  RPZ is a ""static list.
  RPS is an active / dynamic service.

Note:  Response Policy Zones can be updated via normal dynamic DNS methods.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: Dumb Question is an A or AAAA record required?

[Grant Taylor via bind-users]

On 7/9/20 6:43 AM, Anand Buddhdev wrote:
If you don't have an A record at the zone apex, the browser will not 
get back any address and display an error message for the user.


There was a point in time when the big web browsers would try connecting 
to www.. if connecting to . failed.


I don't know what the current state of affairs is.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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-users Digest, Vol 3492, Issue 1

[Grant Taylor via bind-users]

On 7/6/20 10:42 PM, ShubhamGoyal wrote:
i am working in Centos 8 with bind version 9.17.2 and  i am install 
from source package


It sounds like you're missing some dependencies.

Read the documents that come with BIND source code and make sure you 
have all the dependencies.


Seeing as how you are working with CentOS, chances are decent that you 
also need the *-dev versions of the listed dependencies.


I'd chase the dlopen first.

I would expect librpz.so to be provided with BIND.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: issue in bind installation

[Grant Taylor via bind-users]

On 7/6/20 10:00 PM, ShubhamGoyal wrote:
I am installing bind  latest version with additional feature , it gave 
me "configure: error librpz.so and dlopen needed for dnsrps" error.
I am searching for that error but i did not find the solution. 
please help me!


Are you compiling from source?  Or did you install a binary package and 
now you're getting that error when trying to run something?


Please tell us a little bit about what you have done up to this point.

Please include details about the platform and version (updates) that you 
are working on.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
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: TSIG DDNS and windows clients

[Grant Taylor via bind-users]

On 5/13/20 6:29 AM, Bob Harold wrote:
Your ACL looks right.  I think Ben has the key - Windows uses GSS-TSIG, 
not regular TSIG.  Not sure how or if that can be solved.


I would bet someone a coffee and doughnut that it can.

Check out Jan-Piet Mens' article:

Link - RFC 2136 Dynamic DNS Updates using GSS-TSIG and Kerberos
 - 
https://jpmens.net/2012/06/29/dynamic-dns-updates-using-gss-tsig-and-kerberos/




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: What is the proper way to delegate to a private / hidden sub-domain?

[Grant Taylor via bind-users]

On 5/6/20 6:56 PM, John Levine wrote:
Oh, in that case, why don't you just put some adjusted NS entries in 
your stub .net zone pointing at your internal name servers?  Seems a 
lot easier than fooling around with routing.


Because that is a hack at best.

I figured that there was something I was missing that didn't require 
anycast for proper delegation.  But I'm not seeing anything else.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: What is the proper way to delegate to a private / hidden sub-domain?

[Grant Taylor via bind-users]

On 5/6/20 4:12 PM, John Levine wrote:
Since they can't access the root servers, how do you expect them to 
do DNS lookups at all?

There is a copy of the root zone in the environment.

There is also enough net zone for the needed tests.

DNSSEC is obviously not in play with doctored zones in the labs.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: What is the proper way to delegate to a private / hidden sub-domain?

[Grant Taylor via bind-users]

On 5/6/20 3:38 PM, John Levine wrote:

The DNS server sends different answers depending on the client IP,
so on your internal network it sees the private subdomain,
everywhere else sees a ENT or NXDOMAIN.


Thank you for confirming.  That is indeed what I /thought/ we were 
talking about.  But given the difference in what you were describing and 
what I was thinking, I figured that it was worth confirming.


If you really have to use physically separate servers for reasons 
that you can't explain,...


There's not anything stopping me from explaining.

The main network I want dig +trace to behave (as) correctly (as 
possible) is inside the labs.  (Obviously tracing won't work without 
some support infrastructure on the disconnected labs.)


The external server is more to make the delegation into the labs look as 
clean as possible to the rest of the world.  I.e. return NXDOMAIN 
instead of timeouts.


In some ways, the external aspect is somewhat optional, save for the 
desire to lay nice with others.


I'd like to consistently re-use the same method across all labs, 
independent if they are isolated or not, both internally and externally.


...I suppose putting the two servers at the same IP addresss facing 
different networks could work,


Hence "anycast".

although you're asking for trouble with route leaks anytime someone 
adjusts a router anywhere near one or the other.


In general, I agree with you.  However, in this particular case, I don't 
think it's going to be an issue.  The router inside the lab is not using 
any routing protocols, only static configs.  The router can get the 
local traffic to the anycast IP without worrying about anything 
escaping.  (Be it on the router w/ local DNS server, or directly 
attached network, or a host route to another system that is directly 
attached.)


I'm taking your warning, processing it, and then deciding that this 
particular scenario is not subject to the concerns you rightfully have.


Remember that with normal anycast all of the mirrors send identical 
or at least equivalent answers so the routes are not a security 
issue.

Agreed.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: What is the proper way to delegate to a private / hidden sub-domain?

[Grant Taylor via bind-users]

On 5/6/20 3:40 PM, John Levine wrote:
Can clients on the internal network contact hosts in the outside 
world, or is it really disconnected?

It depends on which particular lab is being used and what is being tested.

I can guarantee that some of the labs will NOT have access to other 
networks, much less the Internet.  (Some of them even have a protocol 
barrier.)


(IPv4 network)---[IPv4|bastion|IPX]---(IPX 
network)---[IPX|router|IPX]---(IPX network)---[IPX|bastion|IPv6]---(IPv6 
network)


Nothing IPv4 in the lab is going to make it out to the world.

The IPX router hard filters anything that's not IPX.



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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