RE: New BIND 9.16.19 I think don't run with Intel VLANs
Hi Peter, I remember you having this problem before with 9.16.18, did you ever get that version to work? I’ve just upgraded from 9.16.18 to 9.16.19 on Windows Server 2019 without issue but I don’t have any VLANs configured nor am I using an additional network card management application. Best, Richard. From: bind-users On Behalf Of Peter via bind-users Sent: 21 July 2021 9:34 pm To: bind-users@lists.isc.org Subject: New BIND 9.16.19 I think don't run with Intel VLANs I have three PC's tested that all work fine on 9.16.15 or 9.17.12 with my Intel VLANs but 9.16.19 simply will not start. Is this a new limitation for BIND on windows now? or a change that causes it not to run if it detects VLANs with the intel APP? ___ 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: Resolve any query to same IP address
Thanks for the answer. Worked here.
Thanks!
Em qua., 21 de jul. de 2021 às 12:23, Kevin Darcy via bind-users <
bind-users@lists.isc.org> escreveu:
> [ Classification Level: GENERAL BUSINESS ]
>
> Dot "." instead of asterisk "*" as the zone name. Remove the "hint" zone,
> since that doesn't apply when you host your own root zone.
>
> You need a proper MNAME for the SOA RR too.
>
> - Kevin
>
> On Wed, Jul 21, 2021 at 11:18 AM Jeronimo wrote:
>
>> Hi,
>>
>> how can I get the same IPv6 address as the answer to any query to my
>> Bind9?
>>
>> I am using Ubuntu 20 and Bind 9.11 whit configuration as bellow:
>>
>> --
>> $ cat /etc/bind/named.conf
>> include "/etc/bind/named.conf.options";
>> include "/etc/bind/named.conf.local";
>> include "/etc/bind/named.conf.default-zones";
>> --
>> $ cat /etc/bind/named.conf.options
>> options {
>> directory "/var/cache/bind";
>> recursion no;
>> querylog yes;
>> listen-on-v6 { any; };
>> dnssec-validation auto;
>> auth-nxdomain no;# conform to RFC1035
>> };
>>
>> $ cat /etc/bind/named.conf.default-zones
>> zone "." {
>> type hint;
>> file "/etc/bind/db.root";
>> };
>>
>> zone "localhost" {
>> type master;
>> file "/etc/bind/db.local";
>> };
>>
>> zone "127.in-addr.arpa" {
>> type master;
>> file "/etc/bind/db.127";
>> };
>>
>> zone "0.in-addr.arpa" {
>> type master;
>> file "/etc/bind/db.0";
>> };
>>
>> zone "255.in-addr.arpa" {
>> type master;
>> file "/etc/bind/db.255";
>> };
>>
>> zone "*" {
>> type master;
>> file "/etc/bind/db.fakeroot";
>> };
>> --
>> $ cat db.fakeroot
>> $TTL 30
>> @ IN SOA * hostmaster.mydomain.com. (
>> 1 ; Serial
>> 240 ; Refresh
>> 120 ; Retry
>> 900 ; Expire
>> 300 ; Negative Cache TTL
>> )
>> ;
>> IN NS
>> * IN
>>
>> Any help is welcome.
>>
>> Regards,
>>
>> Jeronimo
>>
>> ___
>> 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
>>
> ___
> 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
>
___
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: query-source and listened interfaces
I understand CDN might need a change. What I don't understand is why single recursive cache somewhere in the middle chain should serve different names to its clients. On 7/13/21 8:19 AM, Xinyu Wang wrote: > Should authoritative servers reply different way to each recursive > server IP? > > --sometimes, yes. especially the FQDN is using CDN. > > How would be served content different? Is there reason, why remote > authoritative server changes replies based on source IP? > > --again, I'll explain this based on CDN cases. There might be tons of > cache nodes in a delivery network. The authority chooses the 'best' > one by identifying the end-users location. Most of CDN traffic are > dispatched by doing this, and the source IP tells the authority where > an end-user comes from. Sure, caching is vital. For most CDN usages all records are more or less equivalent. For any resolver close to authoritative server it should not matter what view/region it were chosen from. It should just deliver IP which is close by network topology. I do not understand, why should it propagate that differences even to intermediate caching server. Why should server in the middle deliver different results to its clients? Almost all normal resolvers will not behave this way and just ask once, cache it and deliver the same content to all its clients. No matter what source they were from. This scenario has to be supported. Configuring all caches on the way is hard. I would prefer using separate caches for networks which need different results. It would be easier to debug later. Your design: +---+ A ++ +-+ |auth +--+ cache +-+ client1 | | | | | +-+ | +--+ | +-+ | | B | +-+ client2 | +---+ ++ +-+ My expectation: +---+ A ++ +-+ |auth +--+ cache1 +-+ client1 | | | ++ +-+ | | ++ +-+ | +--+ cache2 +-+ client2 | +---+ B ++ +-+ Why are your clients sharing the same resolver, when it has to deliver different results based on their source? Is it required? Should they share common cache except few specific domains? Your request would still result in more or less my expectation, just it would be virtual inside of bind. I am just interested why was this solution chosed. It seems more complicated to me. > > Thanks. > > Petr Menšík mailto:pemen...@redhat.com>> > 于2021年7月12日周一 下午11:17写道： > > Should authoritative servers reply different way to each recursive > server IP? > > I think whatever tweaks needs to be done, they should be done on > recursive server. Whether using secondary zones or RPZ > manipulation, but > I think it should not make difference to other servers in chain. > > How would be served content different? Is there reason, why remote > authoritative server changes replies based on source IP? Could it be > moved closer to clients? Would it make sense to create just separate > instances for separate resolver groups? > > It would be more clear is authoritative responded always the same way > for everyone. Possible changes would be implemented at recursive > resolver itself. Sharing for example RPZ rules for multiple servers if > required. > > Just my 2 cents. > > Petr > > On 7/12/21 2:03 PM, Xinyu Wang wrote: > > Hi Petr, > > > > Thanks for your reply. > > I was doing this because sometimes the recursive DNS has multiple IP > > addresses, meanwhile ECS is not supported by a recursive BIND. > > > > So, let's say the recursive has 2 IPs, and they are in different > views on > > the authoritative DNS of a certain domain. > > > > In this case, the 'query source' should be exactly the same as > the IP which > > is the original's destination IP , so that the corresponding > query could > > match the right view. > > > > Does that make sense? > > > > Thanks > > > > Petr Menšík mailto:pemen...@redhat.com>> > 于2021年7月12日周一 下午5:32写道： > > > >> Hi Xinyu. > >> > >> Why would you need client-facing IP address to appear on > authoritative > >> servers? It should be more or less independent. > >> > >> I think it might be possible to use views and match-destination > combined > >> with query-source for each view. But it seems similar to > running separate > >> bind instances. I think it would have different cache anyway. > >> > >> Can you share why source addresses are important? > >> > >> Cheers, > >> > >> Petr > >> On 7/8/21 9:08 AM, Xinyu Wang wrote: > >> > >> Hi guys, > >> > >> Is it possible to make a recursive BIND send queries to > authorities from > >> the interface which the original query was sent to. > >>
New BIND 9.16.19 I think don't run with Intel VLANs
I have three PC's tested that all work fine on 9.16.15 or 9.17.12 with my Intel VLANs but 9.16.19 simply will not start. Is this a new limitation for BIND on windows now? or a change that causes it not to run if it detects VLANs with the intel APP? ___ 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: Resolve any query to same IP address
[ Classification Level: GENERAL BUSINESS ]
Dot "." instead of asterisk "*" as the zone name. Remove the "hint" zone,
since that doesn't apply when you host your own root zone.
You need a proper MNAME for the SOA RR too.
- Kevin
On Wed, Jul 21, 2021 at 11:18 AM Jeronimo wrote:
> Hi,
>
> how can I get the same IPv6 address as the answer to any query to my Bind9?
>
> I am using Ubuntu 20 and Bind 9.11 whit configuration as bellow:
>
> --
> $ cat /etc/bind/named.conf
> include "/etc/bind/named.conf.options";
> include "/etc/bind/named.conf.local";
> include "/etc/bind/named.conf.default-zones";
> --
> $ cat /etc/bind/named.conf.options
> options {
> directory "/var/cache/bind";
> recursion no;
> querylog yes;
> listen-on-v6 { any; };
> dnssec-validation auto;
> auth-nxdomain no;# conform to RFC1035
> };
>
> $ cat /etc/bind/named.conf.default-zones
> zone "." {
> type hint;
> file "/etc/bind/db.root";
> };
>
> zone "localhost" {
> type master;
> file "/etc/bind/db.local";
> };
>
> zone "127.in-addr.arpa" {
> type master;
> file "/etc/bind/db.127";
> };
>
> zone "0.in-addr.arpa" {
> type master;
> file "/etc/bind/db.0";
> };
>
> zone "255.in-addr.arpa" {
> type master;
> file "/etc/bind/db.255";
> };
>
> zone "*" {
> type master;
> file "/etc/bind/db.fakeroot";
> };
> --
> $ cat db.fakeroot
> $TTL 30
> @ IN SOA * hostmaster.mydomain.com. (
> 1 ; Serial
> 240 ; Refresh
> 120 ; Retry
> 900 ; Expire
> 300 ; Negative Cache TTL
> )
> ;
> IN NS
> * IN
>
> Any help is welcome.
>
> Regards,
>
> Jeronimo
>
> ___
> 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
>
___
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
Resolve any query to same IP address
Hi,
how can I get the same IPv6 address as the answer to any query to my Bind9?
I am using Ubuntu 20 and Bind 9.11 whit configuration as bellow:
--
$ cat /etc/bind/named.conf
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
--
$ cat /etc/bind/named.conf.options
options {
directory "/var/cache/bind";
recursion no;
querylog yes;
listen-on-v6 { any; };
dnssec-validation auto;
auth-nxdomain no;# conform to RFC1035
};
$ cat /etc/bind/named.conf.default-zones
zone "." {
type hint;
file "/etc/bind/db.root";
};
zone "localhost" {
type master;
file "/etc/bind/db.local";
};
zone "127.in-addr.arpa" {
type master;
file "/etc/bind/db.127";
};
zone "0.in-addr.arpa" {
type master;
file "/etc/bind/db.0";
};
zone "255.in-addr.arpa" {
type master;
file "/etc/bind/db.255";
};
zone "*" {
type master;
file "/etc/bind/db.fakeroot";
};
--
$ cat db.fakeroot
$TTL 30
@ IN SOA * hostmaster.mydomain.com. (
1 ; Serial
240 ; Refresh
120 ; Retry
900 ; Expire
300 ; Negative Cache TTL
)
;
IN NS
* IN
Any help is welcome.
Regards,
Jeronimo
___
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
