Re: strange reply dumped URGENT
> On 13 Jul 2024, at 12:44, Herman Brule wrote:
>
> Thanks, I'm looking how solve this, cleanly.
> In my country only 1 ISP have IPv6, then I need keep IPv4.
> I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
> Then:
> 1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but reply
> correctly to all my dig query)
> 2) I have to provide a way to my customer can resolve query on their DNS
> server on their IPv6 VPS, their need be able to just put their vps dns or at
> least common server dns (where I had to put their zone, then I dislike this
> idea)
> For now your method fail, include I try:
> zone "ore.org.bo" {
> type master;
> file "/etc/bind/ore.org.bo.db";
> };
> But failed too.
Well I didn’t say to do that. You have they wrong type of zone. Make it a
secondary (slave) zone
like I told you to do.
zone ore.org.bo {
type secondary;
file “ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
Now that should work as I can AXFR the zone from that server. You should also
note the difference in
the flags in the responses for smtp.ore.org.bo. The one from 2803:1920::c:1963
is an authoritative
reply (aa) and the TTL stays at 3600, whereas the one from 45.225.75.8 is not
(aa is not set in the
flags) and the TTL decreases indicating that it comes from a recursive server.
It also looks like someone tried to comment out *.ore.org.bo but used the wrong
comment character ‘#'
rather than ‘;’.
[ant:~/git/bind9] marka% dig axfr ore.org.bo @2803:1920::c:1963
; <<>> DiG 9.19.25-dev <<>> axfr ore.org.bo @2803:1920::c:1963
;; global options: +cmd
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800
86400 2419200 604800
ore.org.bo. 604800 IN NS 811.vps.confiared.com.
ore.org.bo. 3600 IN MX 1 smtp.ore.org.bo.
ore.org.bo. 3600 IN A 45.225.75.8
ore.org.bo. 3600 IN 2803:1920::c:1963
#*.ore.org.bo. 604800 IN CNAME ore.org.bo.
smtp.ore.org.bo. 3600 IN A 45.225.75.8
smtp.ore.org.bo. 3600 IN 2803:1920::c:1963
www.ore.org.bo. 604800 IN CNAME ore.org.bo.
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800
86400 2419200 604800
;; Query time: 497 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (TCP)
;; WHEN: Mon Jul 15 09:47:16 AEST 2024
;; XFR size: 10 records (messages 1, bytes 324)
[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @2803:1920::c:1963
; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @2803:1920::c:1963
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4584
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cdbac4bb692528b30100669463a2ffd887df1b2535a8 (good)
;; QUESTION SECTION:
;smtp.ore.org.bo. IN A
;; ANSWER SECTION:
smtp.ore.org.bo. 3600 IN A 45.225.75.8
;; Query time: 659 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (UDP)
;; WHEN: Mon Jul 15 09:47:47 AEST 2024
;; MSG SIZE rcvd: 88
[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @45.225.75.8
; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @45.225.75.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33189
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 42c6758d745eb62b0100669463baea9db7cd3474c256 (good)
;; QUESTION SECTION:
;smtp.ore.org.bo. IN A
;; ANSWER SECTION:
smtp.ore.org.bo. 3266 IN A 45.225.75.8
;; Query time: 264 msec
;; SERVER: 45.225.75.8#53(45.225.75.8) (UDP)
;; WHEN: Mon Jul 15 09:48:10 AEST 2024
;; MSG SIZE rcvd: 88
[ant:~/git/bind9] marka%
Mark
> alpha_one_x86/BRULE Herman
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and
> server management
> IT, OS, technologies, research & development, security and business department
> On 7/12/24 19:01, Mark Andrews wrote:
>>
>>
>>> On 13 Jul 2024, at 04:38, Herman Brule via bind-users
>>> wrote:
>>>
>>> Because the customer are into IPv6 zone
>>>
>> Well all zones should be served by both IPv4 servers and IPv6 servers. IPv6
>> is nearly 30 years old now. There are
>> sites that are IPv6 only because they would prefer to not have to run
>> everything through 2 or 3 layers of NAT when
>> they don’t need it at all for IPv6 and would really like to not have to send
>> all there DNS queries though NAT64 boxes.
>>
>>
>>> And the EDGE router connecting IPv4 and IPv6 is internal to the data center
>>> company, not accessible for the customer.
>>> Forward zone to edge will be more complex, it's more simple just forward
>>> the query.
>>> Thanks for you observation, but I know, I doing this quickly, I will keep
>>> like this for now, this will produce only problem for availability if the
>>> server is down.
>>>
>> Except you are wrong. You are writing here because it *is* causing you and
>> everyone else a
Re: strange reply dumped URGENT
I open this to test (45.225.75.8 is particial anycast IP, for DNS/UDP
have bind9):
dig A ore.org.bo @199.38.247.210
With on 199.38.247.210 (work):
zone ore.org.bo {
type master;
file "/etc/bind/ore.org.bo.db";
};
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39291
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 9948d53f96271fa8010066947311b2e477062b98c6ee (good)
;; QUESTION SECTION:
;ore.org.bo. IN A
;; ANSWER SECTION:
ore.org.bo. 3600 IN A 45.225.75.8
;; Query time: 99 msec
;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
;; WHEN: Mon Jul 15 00:53:38 UTC 2024
;; MSG SIZE rcvd: 83
With on 199.38.247.210 (not work):
zone ore.org.bo {
type secondary;
file “/etc/bind/ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14941
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f9006eb35715f0da0100669473a08e2898af7098316c (good)
;; QUESTION SECTION:
;ore.org.bo. IN A
;; Query time: 87 msec
;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
;; WHEN: Mon Jul 15 00:56:01 UTC 2024
;; MSG SIZE rcvd: 67
alpha_one_x86/BRULE Herman
Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and server
management
IT, OS, technologies, research & development, security and business department
On 7/14/24 20:00, Mark Andrews wrote:
On 13 Jul 2024, at 12:44, Herman Brule wrote:
Thanks, I'm looking how solve this, cleanly.
In my country only 1 ISP have IPv6, then I need keep IPv4.
I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
Then:
1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but reply
correctly to all my dig query)
2) I have to provide a way to my customer can resolve query on their DNS server
on their IPv6 VPS, their need be able to just put their vps dns or at least
common server dns (where I had to put their zone, then I dislike this idea)
For now your method fail, include I try:
zone "ore.org.bo" {
type master;
file "/etc/bind/ore.org.bo.db";
};
But failed too.
Well I didn’t say to do that. You have they wrong type of zone. Make it a
secondary (slave) zone
like I told you to do.
zone ore.org.bo {
type secondary;
file “ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
Now that should work as I can AXFR the zone from that server. You should also
note the difference in
the flags in the responses for smtp.ore.org.bo. The one from 2803:1920::c:1963
is an authoritative
reply (aa) and the TTL stays at 3600, whereas the one from 45.225.75.8 is not
(aa is not set in the
flags) and the TTL decreases indicating that it comes from a recursive server.
It also looks like someone tried to comment out *.ore.org.bo but used the wrong
comment character ‘#'
rather than ‘;’.
[ant:~/git/bind9] marka% dig axfr ore.org.bo @2803:1920::c:1963
; <<>> DiG 9.19.25-dev <<>> axfr ore.org.bo @2803:1920::c:1963
;; global options: +cmd
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800
86400 2419200 604800
ore.org.bo. 604800 IN NS 811.vps.confiared.com.
ore.org.bo. 3600 IN MX 1 smtp.ore.org.bo.
ore.org.bo. 3600 IN A 45.225.75.8
ore.org.bo. 3600 IN 2803:1920::c:1963
#*.ore.org.bo. 604800 IN CNAME ore.org.bo.
smtp.ore.org.bo. 3600 IN A 45.225.75.8
smtp.ore.org.bo. 3600 IN 2803:1920::c:1963
www.ore.org.bo. 604800 IN CNAME ore.org.bo.
ore.org.bo. 604800 IN SOA 811.vps.confiared.com. admin.ore.org.bo. 3 604800
86400 2419200 604800
;; Query time: 497 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (TCP)
;; WHEN: Mon Jul 15 09:47:16 AEST 2024
;; XFR size: 10 records (messages 1, bytes 324)
[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @2803:1920::c:1963
; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @2803:1920::c:1963
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4584
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cdbac4bb692528b30100669463a2ffd887df1b2535a8 (good)
;; QUESTION SECTION:
;smtp.ore.org.bo. IN A
;; ANSWER SECTION:
smtp.ore.org.bo. 3600 IN A 45.225.75.8
;; Query time: 659 msec
;; SERVER: 2803:1920::c:1963#53(2803:1920::c:1963) (UDP)
;; WHEN: Mon Jul 15 09:47:47 AEST 2024
;; MSG SIZE rcvd: 88
[ant:~/git/bind9] marka% dig a smtp.ore.org.bo @45.225.75.8
; <<>> DiG 9.19.25-dev <<>> a smtp.ore.org.bo @45.225.75.8
;; global o
Re: Building bind 9.19.24 on Openwrt w/ MUSL
Finally got it done. Sorry for taking so long. Had a lot of travel. > On Jun 2, 2024, at 2:37 AM, Ondřej Surý wrote: > > Hi Philip, > > we'll need more. Ideally fill an issue, follow the bug template and attach > config.log as a bare minimum. > -- > Ondřej Surý — ISC (He/Him) > > My working hours and your working hours may be different. Please do not feel > obligated to reply outside your normal working hours. > >> On 1. 6. 2024, at 23:19, Philip Prindeville via bind-users >> wrote: >> >> Hi, >> >> Having some more issues building 9.19.24 on MUSL. configure.ac isn't >> correctly detecting the following: >> >> ac_cv_func_setresuid=yes >> ac_cv_type_size_t=yes >> ac_cv_type_ssize_t=yes >> ac_cv_type_uintptr_t=yes >> >> And even passing this manually via ./configure's environment isn't causing >> it to work... it's showing as the wrong value and not "(cached)". >> >> I wouldn't have noticed except that the included replacement for setresuid() >> dies in compilation with a warning about it being declared as static and >> then later defined as non-static or some such. >> >> Anyone else had problems with autoconf and cross-compilation w/ MUSL? >> >> I wanted to do a bump on bind to pick up this fix: >> >> https://gitlab.isc.org/isc-projects/bind9/-/issues/3152 >> >> Thanks, >> >> -Philip >> >> -- >> 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 > -- 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: strange reply dumped URGENT
Really it is very hard to help people who keep changing random things making a
moving
target. You started out with a machine at 45.225.75.8 that could reach
2803:1920::c:1963
based on the forward zone declaration so it had to be dual stacked (both IPv4
and IPv6).
You have now added two new machines 69.162.65.138 and 192.169.93.210 which may
or may not
be able to reach 2803:1920::c:1963 and have changed the delegation to point to
them and they
return NXDOMAIN for smtp.ore.org.bo.
Now if you have IPv4 only nameservers that need to get the zone content from an
IPv6 only
server you will need to have an intermediate dual stacked server that can
transfer the zone
content from the IPv6 only server and send it to the IPv4 only servers when
they request it.
P(IPv6-only) -> I(IPv4 and IPv6) -> S(IPv4 only)
Also read the nameserver’s logs. They will help you work out what is going
wrong.
2803:1920::c:1963 (IPv6 only):
zone ore.org.bo {
type primary;
file "ore.org.bo.db”;
};
45.225.75.8/ (dual stacked):
zone ore.org.bo {
type secondary;
file "ore.org.bo.db”;
primaries { 2803:1920::c:1963; };
};
69.162.65.138 (IPv4 only):
zone ore.org.bo {
type secondary;
file "ore.org.bo.db”;
primaries { 45.225.75.8; };
};
Alternatively you can add IPv6 to an IPv4 only machine using services like
https://tunnelbroker.net/ even when the ISP does not support IPv6.
Mark
> On 15 Jul 2024, at 11:00, Herman Brule wrote:
>
> I open this to test (45.225.75.8 is particial anycast IP, for DNS/UDP have
> bind9):
> dig A ore.org.bo @199.38.247.210
> With on 199.38.247.210 (work):
> zone ore.org.bo {
> type master;
> file "/etc/bind/ore.org.bo.db";
> };
> ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39291
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: 9948d53f96271fa8010066947311b2e477062b98c6ee (good)
> ;; QUESTION SECTION:
> ;ore.org.bo.IN A
>
> ;; ANSWER SECTION:
> ore.org.bo. 3600IN A 45.225.75.8
>
> ;; Query time: 99 msec
> ;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
> ;; WHEN: Mon Jul 15 00:53:38 UTC 2024
> ;; MSG SIZE rcvd: 83
>
> With on 199.38.247.210 (not work):
> zone ore.org.bo {
> type secondary;
> file “/etc/bind/ore.org.bo.db”;
> primaries { 2803:1920::c:1963; };
> };
>
> ; <<>> DiG 9.18.19-1~deb12u1-Debian <<>> A ore.org.bo @199.38.247.210
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 14941
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: f9006eb35715f0da0100669473a08e2898af7098316c (good)
> ;; QUESTION SECTION:
> ;ore.org.bo.IN A
>
> ;; Query time: 87 msec
> ;; SERVER: 199.38.247.210#53(199.38.247.210) (UDP)
> ;; WHEN: Mon Jul 15 00:56:01 UTC 2024
> ;; MSG SIZE rcvd: 67
> alpha_one_x86/BRULE Herman
> Main developer of Supercopier/Ultracopier/CatchChallenger, Esourcing and
> server management
> IT, OS, technologies, research & development, security and business department
> On 7/14/24 20:00, Mark Andrews wrote:
>>
>>
>>> On 13 Jul 2024, at 12:44, Herman Brule wrote:
>>>
>>> Thanks, I'm looking how solve this, cleanly.
>>> In my country only 1 ISP have IPv6, then I need keep IPv4.
>>> I have 1 IPv4 for 1000 VPS, no way here to have more IPv4.
>>> Then:
>>> 1) I'm not sure if my DNS authoritative on IPv6 reply correctly (but reply
>>> correctly to all my dig query)
>>> 2) I have to provide a way to my customer can resolve query on their DNS
>>> server on their IPv6 VPS, their need be able to just put their vps dns or
>>> at least common server dns (where I had to put their zone, then I dislike
>>> this idea)
>>> For now your method fail, include I try:
>>> zone "ore.org.bo" {
>>> type master;
>>> file "/etc/bind/ore.org.bo.db";
>>> };
>>> But failed too.
>>>
>> Well I didn’t say to do that. You have they wrong type of zone. Make it a
>> secondary (slave) zone
>> like I told you to do.
>>
>> zone ore.org.bo {
>> type secondary;
>> file “ore.org.bo.db”;
>> primaries { 2803:1920::c:1963; };
>> };
>>
>> Now that should work as I can AXFR the zone from that server. You should
>> also note the difference in
>> the flags in the responses for smtp.ore.org.bo. The one from
>> 2803:1920::c:1963 is an authoritative
>> reply (aa) and the TTL stays at 3600, whereas the one from 45.225.75.8 is
>> not (aa is not set in the
>> flags) and the TTL decreases indicating that it comes from a recursive
>> server.
>>
>> It also looks like someone tried to comment out *.ore.org.bo but used the
>> wrong comment character ‘#'
>> ra
