Multiple A Records - Followup Question
As a followup to my earlier question on have a single hostname with multiple A record, I want to understand a slightly different scenario. 3 hosts exist with canonical A records: hosta A 1.2.3.4 hostb A 5.6.7.8 hostc A 9.10.11.12 My earlier question was whether one host could have more than one A record. But say, I want to to this as follows: testA 1.2.3.4 testA 5.6.7.8 testA 9.10.11.12 Is this legit? IOW, can a given *IP* appear in more than one A record? I realize that this does have the problem that the reverses would resolve to hostX not test. Thanks, -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ 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: Multiple A Records - Followup Question
Hi there, On Sun, 2 Oct 2016, Tim Daneliuk wrote: ... can a given *IP* appear in more than one A record? ... http://serverfault.com/questions/56539/dns-multiple-a-records-or-1-a-record-and-lots-of-cnames -- 73, Ged. ___ 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: Multiple A Records - Followup Question
Am 02.10.2016 um 13:57 schrieb Tim Daneliuk: My earlier question was whether one host could have more than one A record. But say, I want to to this as follows: testA 1.2.3.4 testA 5.6.7.8 testA 9.10.11.12 Is this legit? surely - guess how dns-round-robin load balancing works :-) https://en.wikipedia.org/wiki/Round-robin_DNS IOW, can a given *IP* appear in more than one A record? I realize that this does have the problem that the reverses would resolve to hostX not test on IP should only have on PTR - period avoid anything else than PTR/A-matching if the machine is supposed to send outbound mail ___ 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
debug SERVFAIL
Hi, What is the best way to debug a SERVFAIL problem? I have tried to ramp up the trace level a lot but that did not return anything useful. It is only one zone in question, namely the PTR for our external subnet. What puzzles me the most is that a secondary on the same subnet answers just fine for thesame query. All forwards zones resolves good as well. BIND version is 9.10.4-P3 Thanks, //per ___ 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: debug SERVFAIL
Am 02.10.2016 um 16:46 schrieb Per olof Ljungmark: What is the best way to debug a SERVFAIL problem? I have tried to ramp up the trace level a lot but that did not return anything useful. It is only one zone in question, namely the PTR for our external subnet. What puzzles me the most is that a secondary on the same subnet answers just fine for thesame query. All forwards zones resolves good as well. BIND version is 9.10.4-P3 most likely some error in the zonefile, look at named logs that the secondary answers is normal because if the master refuses to load a zone it never reaches the slave and start to fail there only when it expires before the error is fixed hence master/slave while in most environemnts you could technically generate the identical zone-files on all nameservers but then with the same errors and so all would fail (in case of PTR and mailservers with horrible results) ___ 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: debug SERVFAIL
On 2016-10-02 16:50, Reindl Harald wrote: > > > Am 02.10.2016 um 16:46 schrieb Per olof Ljungmark: >> What is the best way to debug a SERVFAIL problem? I have tried to ramp >> up the trace level a lot but that did not return anything useful. >> >> It is only one zone in question, namely the PTR for our external subnet. >> What puzzles me the most is that a secondary on the same subnet answers >> just fine for thesame query. All forwards zones resolves good as well. >> >> BIND version is 9.10.4-P3 > > most likely some error in the zonefile, look at named logs > > that the secondary answers is normal because if the master refuses to > load a zone it never reaches the slave and start to fail there only when > it expires before the error is fixed > > hence master/slave while in most environemnts you could technically > generate the identical zone-files on all nameservers but then with the > same errors and so all would fail (in case of PTR and mailservers with > horrible results) There is nothing useful in the logs, hence my question above. The zone files are identical on master and slaves so I doubt there is a problem with that. ___ 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: debug SERVFAIL
Am 02.10.2016 um 17:00 schrieb Per olof Ljungmark: On 2016-10-02 16:50, Reindl Harald wrote: Am 02.10.2016 um 16:46 schrieb Per olof Ljungmark: What is the best way to debug a SERVFAIL problem? I have tried to ramp up the trace level a lot but that did not return anything useful. It is only one zone in question, namely the PTR for our external subnet. What puzzles me the most is that a secondary on the same subnet answers just fine for thesame query. All forwards zones resolves good as well. BIND version is 9.10.4-P3 most likely some error in the zonefile, look at named logs that the secondary answers is normal because if the master refuses to load a zone it never reaches the slave and start to fail there only when it expires before the error is fixed hence master/slave while in most environemnts you could technically generate the identical zone-files on all nameservers but then with the same errors and so all would fail (in case of PTR and mailservers with horrible results) There is nothing useful in the logs, hence my question above. The zone files are identical on master and slaves so I doubt there is a problem with that. you need to provide the startup logs as well as the log-configuration ___ 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: debug SERVFAIL
On 2016-10-02 17:02, Reindl Harald wrote:
>
>
> Am 02.10.2016 um 17:00 schrieb Per olof Ljungmark:
>> On 2016-10-02 16:50, Reindl Harald wrote:
>>>
>>>
>>> Am 02.10.2016 um 16:46 schrieb Per olof Ljungmark:
What is the best way to debug a SERVFAIL problem? I have tried to ramp
up the trace level a lot but that did not return anything useful.
It is only one zone in question, namely the PTR for our external
subnet.
What puzzles me the most is that a secondary on the same subnet answers
just fine for thesame query. All forwards zones resolves good as well.
BIND version is 9.10.4-P3
>>>
>>> most likely some error in the zonefile, look at named logs
>>>
>>> that the secondary answers is normal because if the master refuses to
>>> load a zone it never reaches the slave and start to fail there only when
>>> it expires before the error is fixed
>>>
>>> hence master/slave while in most environemnts you could technically
>>> generate the identical zone-files on all nameservers but then with the
>>> same errors and so all would fail (in case of PTR and mailservers with
>>> horrible results)
>>
>> There is nothing useful in the logs, hence my question above. The zone
>> files are identical on master and slaves so I doubt there is a problem
>> with that.
>
> you need to provide the startup logs as well as the log-configuration
Hmmm, looks like I've found something here. The default named.conf on
FreeBSD has the following section on the root servers. If I comment out
the "traditional" root hints and instead use what is recommended below,
all reverse lookups will generate a SERVFAIL.
This is in the log:
zone in-addr.arpa/IN: refresh: non-authoritative answer from master
192.5.5.241#53 (source 0.0.0.0#0)
Would be interesting to hear comments.
// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
/* Slaving the following zones from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS
On the other hand, this method requires more monitoring than the
hints file to be sure that an unexpected failure mode has not
incapacitated your server. Name servers that are serving a lot
of clients will benefit more from this approach than individual
hosts. Use with caution.
To use this mechanism, uncomment the entries below, and comment
the hint zone above.
As documented at http://dns.icann.org/services/axfr/ these zones:
"." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET
are available for AXFR from these servers on IPv4 and IPv6:
xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
*/
/*
zone "." {
type slave;
file "/usr/local/etc/namedb/slave/root.slave";
masters {
192.5.5.241;// F.ROOT-SERVERS.NET.
};
notify no;
};
zone "arpa" {
type slave;
file "/usr/local/etc/namedb/slave/arpa.slave";
masters {
192.5.5.241;// F.ROOT-SERVERS.NET.
};
notify no;
};
*/
___
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: debug SERVFAIL
On 02/10/16 17:22, Per olof Ljungmark wrote: Hello Per, Please see my answers below. You appear to have a bad configuration. > Hmmm, looks like I've found something here. The default named.conf on > FreeBSD has the following section on the root servers. If I comment out > the "traditional" root hints and instead use what is recommended below, > all reverse lookups will generate a SERVFAIL. > > This is in the log: > zone in-addr.arpa/IN: refresh: non-authoritative answer from master > 192.5.5.241#53 (source 0.0.0.0#0) This line indicates that your BIND server tried to XFR the in-addr.arpa zone from f.root-servers.net (192.5.5.241). However, none of the root servers are authoritative for the in-addr.arpa zone. Have you also configured your BIND server to slave this from 192.5.5.241? If so, then it's a misconfiguration. I would also add that you should NOT slave the root and arpa zones, unless you fully understand what you're doing. I suggest that you stop doing it. Just use the "hint" type configuration. This is just fine for most users. Regards, Anand ___ 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: debug SERVFAIL
Hi, On 2016-10-02 17:51, Anand Buddhdev wrote: > On 02/10/16 17:22, Per olof Ljungmark wrote: > > Hello Per, > > Please see my answers below. You appear to have a bad configuration. Well, HAD a bad configuration as I just posted. >> Hmmm, looks like I've found something here. The default named.conf on >> FreeBSD has the following section on the root servers. If I comment out >> the "traditional" root hints and instead use what is recommended below, >> all reverse lookups will generate a SERVFAIL. >> >> This is in the log: >> zone in-addr.arpa/IN: refresh: non-authoritative answer from master >> 192.5.5.241#53 (source 0.0.0.0#0) > > This line indicates that your BIND server tried to XFR the in-addr.arpa > zone from f.root-servers.net (192.5.5.241). However, none of the root > servers are authoritative for the in-addr.arpa zone. Have you also > configured your BIND server to slave this from 192.5.5.241? If so, then > it's a misconfiguration. > > I would also add that you should NOT slave the root and arpa zones, > unless you fully understand what you're doing. I suggest that you stop > doing it. Already stopped as I just wrote, it is not something we normally do either. > Just use the "hint" type configuration. This is just fine for most users. The interesting thing is why FreeBSD includes the recommendation in the default named.conf if that is not good, and I thought it would be interesting to know why. ___ 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: debug SERVFAIL
Hi Per, > On 2 Oct 2016, at 19:07, Per olof Ljungmark wrote: > > [...] > >> Just use the "hint" type configuration. This is just fine for most users. > > The interesting thing is why FreeBSD includes the recommendation in the > default named.conf if that is not good, and I thought it would be > interesting to know why. I just checked one of my FreeBSD servers and couldn't find this section/recommendation. If I'm not mistaken the default named.conf does include hints and also RFC1918 in-addr.arpa, not more. Cheers, -- Nico ___ 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: debug SERVFAIL
Hi,
On 2016-10-02 19:22, Nico CARTRON wrote:
> Hi Per,
>
>> On 2 Oct 2016, at 19:07, Per olof Ljungmark wrote:
>>
>> [...]
>>
>>> Just use the "hint" type configuration. This is just fine for most users.
>>
>> The interesting thing is why FreeBSD includes the recommendation in the
>> default named.conf if that is not good, and I thought it would be
>> interesting to know why.
>
> I just checked one of my FreeBSD servers and couldn't find this
> section/recommendation.
> If I'm not mistaken the default named.conf does include hints and also
> RFC1918 in-addr.arpa, not more.
The default is the hints file yes, but the default (named.conf.sample)
file does have the following lines, at least with 9.10 and it uses the
word "advantages" for the alternative config which obviously does not
work in all cases. It adds "Use with caution" though.
// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
/* Slaving the following zones from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS
On the other hand, this method requires more monitoring than the
hints file to be sure that an unexpected failure mode has not
incapacitated your server. Name servers that are serving a lot
of clients will benefit more from this approach than individual
hosts. Use with caution.
To use this mechanism, uncomment the entries below, and comment
the hint zone above.
As documented at http://dns.icann.org/services/axfr/ these zones:
"." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET
are available for AXFR from these servers on IPv4 and IPv6:
xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
*/
/*
zone "." {
type slave;
file "/usr/local/etc/namedb/slave/root.slave";
masters {
192.5.5.241;// F.ROOT-SERVERS.NET.
};
notify no;
};
zone "arpa" {
type slave;
file "/usr/local/etc/namedb/slave/arpa.slave";
masters {
192.5.5.241;// F.ROOT-SERVERS.NET.
};
notify no;
};
*/
/* Serving the following zones locally will prevent any queries
for these zones leaving your network and going to the root
name servers. This has two significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
*/
___
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: debug SERVFAIL
Am 02.10.2016 um 20:32 schrieb Per olof Ljungmark:
On 2016-10-02 19:22, Nico CARTRON wrote:
Hi Per,
On 2 Oct 2016, at 19:07, Per olof Ljungmark wrote:
[...]
Just use the "hint" type configuration. This is just fine for most users.
The interesting thing is why FreeBSD includes the recommendation in the
default named.conf if that is not good, and I thought it would be
interesting to know why.
I just checked one of my FreeBSD servers and couldn't find this
section/recommendation.
If I'm not mistaken the default named.conf does include hints and also RFC1918
in-addr.arpa, not more.
The default is the hints file yes, but the default (named.conf.sample)
file does have the following lines, at least with 9.10 and it uses the
word "advantages" for the alternative config which obviously does not
work in all cases. It adds "Use with caution" though.
well, indepenent what some comments pretend with our without warnings -
*never* ever slave a zone where don't know the admin on the other side
in person because there is no guarantee that tomorrow a transfer is
allowed even if it's today
hence the "this method requires more monitoring"
that means: if you can't monitor or even don't know how to monitor and
don't fully understand leave your fingers from it
// The traditional root hints mechanism. Use this, OR the slave zones below.
zone "." { type hint; file "/usr/local/etc/namedb/named.root"; };
/* Slaving the following zones from the root name servers has some
significant advantages:
1. Faster local resolution for your users
2. No spurious traffic will be sent from your network to the roots
3. Greater resilience to any potential root server failure/DDoS
On the other hand, this method requires more monitoring than the
hints file to be sure that an unexpected failure mode has not
incapacitated your server. Name servers that are serving a lot
of clients will benefit more from this approach than individual
hosts. Use with caution.
To use this mechanism, uncomment the entries below, and comment
the hint zone above.
As documented at http://dns.icann.org/services/axfr/ these zones:
"." (the root), ARPA, IN-ADDR.ARPA, IP6.ARPA, and ROOT-SERVERS.NET
are available for AXFR from these servers on IPv4 and IPv6:
xfr.lax.dns.icann.org, xfr.cjr.dns.icann.org
___
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: debug SERVFAIL
Hi, On 2016-10-02 20:41, Reindl Harald wrote: > > > Am 02.10.2016 um 20:32 schrieb Per olof Ljungmark: >> On 2016-10-02 19:22, Nico CARTRON wrote: >>> Hi Per, >>> On 2 Oct 2016, at 19:07, Per olof Ljungmark wrote: [...] > Just use the "hint" type configuration. This is just fine for most > users. The interesting thing is why FreeBSD includes the recommendation in the default named.conf if that is not good, and I thought it would be interesting to know why. >>> >>> I just checked one of my FreeBSD servers and couldn't find this >>> section/recommendation. >>> If I'm not mistaken the default named.conf does include hints and >>> also RFC1918 in-addr.arpa, not more. >> >> The default is the hints file yes, but the default (named.conf.sample) >> file does have the following lines, at least with 9.10 and it uses the >> word "advantages" for the alternative config which obviously does not >> work in all cases. It adds "Use with caution" though. > > well, indepenent what some comments pretend with our without warnings - > *never* ever slave a zone where don't know the admin on the other side > in person because there is no guarantee that tomorrow a transfer is > allowed even if it's today > > hence the "this method requires more monitoring" > > that means: if you can't monitor or even don't know how to monitor and > don't fully understand leave your fingers from it Thank you for all good advices, but I cannot refrain from commenting on the fact that nobody answered my real question, namely, A tip on how to generate debug output from "dig", in particular when investigating SERVFAIL. In my stupidity I though asking on this list would generate better answers than Google but it did not. Anyway, problem fixed, all happy. ___ 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: debug SERVFAIL
Am 02.10.2016 um 21:25 schrieb Per olof Ljungmark: Thank you for all good advices, but I cannot refrain from commenting on the fact that nobody answered my real question, namely, A tip on how to generate debug output from "dig", in particular when investigating SERVFAIL. In my stupidity I though asking on this list would generate better answers than Google but it did not. dig can not tell you why the server responds with SERVFAIL how would you imagine this to be possible? ___ 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: debug SERVFAIL
how about nslookup with set debug option i think would do From: bind-users on behalf of Reindl Harald Sent: Monday, October 3, 2016 8:34 AM To: bind-users@lists.isc.org Subject: Re: debug SERVFAIL Am 02.10.2016 um 21:25 schrieb Per olof Ljungmark: > Thank you for all good advices, but I cannot refrain from commenting on > the fact that nobody answered my real question, namely, > > A tip on how to generate debug output from "dig", in particular when > investigating SERVFAIL. In my stupidity I though asking on this list > would generate better answers than Google but it did not. dig can not tell you why the server responds with SERVFAIL how would you imagine this to be possible? ___ 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 Confidentiality Notice: This email (including any attachment) is intended for internal use only. Any unauthorized use, dissemination or copying of the content is prohibited. If you are not the intended recipient and have received this e-mail in error, please notify the sender by email and delete this email and any attachment. Confidentiality Notice: This email (including any attachment) is intended for internal use only. Any unauthorized use, dissemination or copying of the content is prohibited. If you are not the intended recipient and have received this e-mail in error, please notify the sender by email and delete this email and any attachment. ___ 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: ip6tables with raw table(no conntrack) drop fragmented packet
This is for recursive, and our recursive got 10X more queries than our authoritative ones, and we had to disable conntrack on our DNS servers last summer by using raw table and everything works for IPv4 including fragmentation, we just noticed fragment fails for IPv6 when using raw table, query not trigger fragment works fine, like this one: dig @2001:500:60::30 isc.org I've added the trace to the ip6table, and here is the pcap: 15:51:48.746691 IP6 (hlim 64, next-header UDP (17) payload length: 44) 2001:0468:2:183::20.45955 > 2001:500:60::30.53: [udp sum ok] 59884+ [1au] ANY? isc.org. ar: . OPT UDPsize=4096 OK (36) 15:51:48.846080 IP6 (hlim 52, next-header Fragment (44) payload length: 1240) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:0|1232) 53 > 45955: 59884*- q: ANY? isc.org. 27/0/16 isc.org. RRSIG, isc.org. SPF, isc.org. RRSIG, isc.org. RRSIG, isc.org. DNSKEY, isc.org. DNSKEY, isc.org. RRSIG[|domain] 15:51:48.846101 IP6 (hlim 52, next-header Fragment (44) payload length: 1240) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:1232|1232) 15:51:48.846122 IP6 (hlim 52, next-header Fragment (44) payload length: 1240) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:2464|1232) 15:51:48.846126 IP6 (hlim 52, next-header Fragment (44) payload length: 318) 2001:500:60::30 > 2001:0468:2:183::20: frag (0xefa32c05:3696|310) Here is the dmesg: TRACE: raw:OUTPUT:rule:3 IN= OUT=eth0 SRC=2001:0468:0002:0183::::0020 DST=2001:0500:0060:::::0030 LEN=84 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0 TRACE: raw:OUTPUT:policy:5 IN= OUT=eth0 SRC=2001:0468:0002:0183::::0020 DST=2001:0500:0060:::::0030 LEN=84 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0 TRACE: filter:OUTPUT:policy:1 IN= OUT=eth0 SRC=2001:0468:0002:0183::::0020 DST=2001:0500:0060:::::0030 LEN=84 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0 TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT= MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd SRC=2001:0500:0060:::::0030 DST=2001:0468:0002:0183::::0020 LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:0 INCOMPLETE ID:90c4bbe8 ) PROTO=UDP SPT=53 DPT=38537 LEN=4006 TRACE: filter:INPUT:rule:1 IN=eth0 OUT= MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd SRC=2001:0500:0060:::::0030 DST=2001:0468:0002:0183::::0020 LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:0 INCOMPLETE ID:90c4bbe8 ) PROTO=UDP SPT=53 DPT=38537 LEN=4006 TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT= MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd SRC=2001:0500:0060:::::0030 DST=2001:0468:0002:0183::::0020 LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:1232 INCOMPLETE ID:90c4bbe8 ) PROTO=UDP TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT= MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd SRC=2001:0500:0060:::::0030 DST=2001:0468:0002:0183::::0020 LEN=1280 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:2464 INCOMPLETE ID:90c4bbe8 ) PROTO=UDP TRACE: raw:PREROUTING:policy:5 IN=eth0 OUT= MAC=00:50:56:a9:44:68:00:23:9c:f5:67:f0:86:dd SRC=2001:0500:0060:::::0030 DST=2001:0468:0002:0183::::0020 LEN=358 TC=0 HOPLIMIT=52 FLOWLBL=0 OPT ( FRAG:3696 ID:90c4bbe8 ) PROTO=UDP TRACE: raw:OUTPUT:rule:3 IN= OUT=eth0 SRC=2001:0468:0002:0183::::0020 DST=2001:0500:0060:::::0030 LEN=84 TC=0 HOPLIMIT=64 FLOWLBL=0 PROTO=UDP SPT=38537 DPT=53 LEN=44 UID=0 GID=0 Thanks! Larry On Sat, Oct 1, 2016 at 2:21 PM, /dev/rob0 wrote: > On Fri, Sep 30, 2016 at 11:55:18PM -0400, Larry Larson wrote: > > I've followed instructions in this BIND Knowledge base article and > > installed ip6tables on my DNS server, using raw table with no > > conntrack for DNS: > > https://kb.isc.org/article/AA-01183/0/Linux-connection- > tracking-and-DNS.html > > This is mostly for authoritative servers which must be open to > queries from anywhere. Perhaps this is not a real issue, as it > sounds like you might be setting up a recursive server? Of course, > it CAN be a problem for recursive-only servers too; it just depends > how many users and concurrent queries you need to support. If your > userbase can flood your conntrack table, you need this. > > > But for IPv6 it drops fragmented packets, for example this query > > fails once the ip6table is on: > > dig +dnssec isc.org any @2001:500:60::30 > > Can you show us how you found out that it was affecting fragments? > Is this query falling back to TCP? Do you have a pcap? > > > Everything works great for IPv4 with similar rules, can someone > > help shed some light on what might be wrong: > > > > # Firewall configuration written by system-config-firewall > > A minor issue, the NOTRACK target is deprecated by CT with the > --notrack option. (That's not the problem, however.) > > We can test things with a few TRACE rules. Let's add rul
Re: debug SERVFAIL
Am 02.10.2016 um 22:04 schrieb Maile Halatuituia: how about nslookup with set debug option i think would do besides the fact that when you think "nslookup" is the solution for anything you don't know your problem you did not understand my simple question: "dig" or "nslookup" or whatever is just a client talking to a dns server on port 53 - that's it - it won't debug your server and if it would be able to do so your server would leak informations classified as security hole which needs to be closed From: bind-users on behalf of Reindl Harald Sent: Monday, October 3, 2016 8:34 AM To: bind-users@lists.isc.org Subject: Re: debug SERVFAIL Am 02.10.2016 um 21:25 schrieb Per olof Ljungmark: Thank you for all good advices, but I cannot refrain from commenting on the fact that nobody answered my real question, namely, A tip on how to generate debug output from "dig", in particular when investigating SERVFAIL. In my stupidity I though asking on this list would generate better answers than Google but it did not. dig can not tell you why the server responds with SERVFAIL how would you imagine this to be possible? ___ 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: Multiple A Records - Followup Question
On 2016-10-02 12:59, Reindl Harald wrote: > >> IOW, can a given *IP* appear in more than one A record? I realize >> that this does have the problem that the reverses would resolve to >> hostX not >> test > > on IP should only have on PTR - period > > avoid anything else than PTR/A-matching if the machine is supposed to > send outbound mail it is very helpful to have multiple PTR records for an IP on a mail server so anti-spam engines can accurately make fully verified forward and reverse lookups not just for DNS but also certificate verification. mail servers that can't correctly emit the right EHLO for outbound email should remain in the 1990s. ___ 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: Multiple A Records - Followup Question
Am 02.10.2016 um 22:42 schrieb David Ford: On 2016-10-02 12:59, Reindl Harald wrote: IOW, can a given *IP* appear in more than one A record? I realize that this does have the problem that the reverses would resolve to hostX not test on IP should only have on PTR - period avoid anything else than PTR/A-matching if the machine is supposed to send outbound mail it is very helpful to have multiple PTR records for an IP on a mail server so anti-spam engines can accurately make fully verified forward and reverse lookups not just for DNS but also certificate verification. which is *exactly* what you break with *multiple* PTR records for a single IP - seems you don't understand what https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS really means mail servers that can't correctly emit the right EHLO for outbound email should remain in the 1990s. yes, and your EHLO matches the A record of your IP which of the multiple PTR's should the receiving server use? guess what: it uses a random one one time it matches your EHLO, the next time not congratulations: you are playing lottery and yes i had cases where we blocked email because check_reverse_client_hostname_access when the mailadmin did request a PTR and the ISP was too dumb to remove the generic one which ended in some mails hit rules and others not ___ 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: debug SERVFAIL
On 2016-10-02 22:09, Reindl Harald wrote: > > > Am 02.10.2016 um 22:04 schrieb Maile Halatuituia: >> how about nslookup with set debug option i think would do > > besides the fact that when you think "nslookup" is the solution for > anything you don't know your problem you did not understand my simple > question: > > "dig" or "nslookup" or whatever is just a client talking to a dns server > on port 53 - that's it - it won't debug your server and if it would be > able to do so your server would leak informations classified as security > hole which needs to be closed Why don't you try to be helpful instead of telling everybody they are idiots? I think most people on the list *knows* that "dig" and "nslookup" are just clients - but we also know that sending a query can generate useful information in both the server log and the command line. My first question was: "What is the best way to debug a SERVFAIL problem?" You did not answer it, and with the use of dig and reading the server logs I fixed it myself. ___ 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: debug SERVFAIL
Am 02.10.2016 um 23:24 schrieb Per olof Ljungmark: On 2016-10-02 22:09, Reindl Harald wrote: Am 02.10.2016 um 22:04 schrieb Maile Halatuituia: how about nslookup with set debug option i think would do besides the fact that when you think "nslookup" is the solution for anything you don't know your problem you did not understand my simple question: "dig" or "nslookup" or whatever is just a client talking to a dns server on port 53 - that's it - it won't debug your server and if it would be able to do so your server would leak informations classified as security hole which needs to be closed Why don't you try to be helpful instead of telling everybody they are idiots? frankly: i *was* helpful and asked for your serverlogs which obviously included the reason what exactly is your problem? I think most people on the list *knows* that "dig" and "nslookup" are just clients - but we also know that sending a query can generate useful information in both the server log and the command line. so why do ask who the client can tell you a server configuration problem in detail when your logs can't? My first question was: "What is the best way to debug a SERVFAIL problem?" You did not answer it, and with the use of dig and reading the server logs I fixed it myself i did answer it: look in your *server* logs ___ 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: Multiple A Records - Followup Question
On 2016-10-02 21:22, Reindl Harald wrote: > > > Am 02.10.2016 um 22:42 schrieb David Ford: >> On 2016-10-02 12:59, Reindl Harald wrote: >>> IOW, can a given *IP* appear in more than one A record? I realize that this does have the problem that the reverses would resolve to hostX not test >>> >>> on IP should only have on PTR - period >>> >>> avoid anything else than PTR/A-matching if the machine is supposed to >>> send outbound mail >> >> it is very helpful to have multiple PTR records for an IP on a mail >> server so anti-spam engines can accurately make fully verified forward >> and reverse lookups not just for DNS but also certificate verification. > > which is *exactly* what you break with *multiple* PTR records for a > single IP - seems you don't understand what > https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS really means no, it exactly doesn't break. it exactly applies to -every- domain served by that mail server with each domain serviced having fully verified forward and backward reachable chain regardless of how many A or PTR (and even CNAME) records exist in RR answers, each having their own domain set in their MX record. > >> mail servers that can't correctly emit the right EHLO for outbound email >> should remain in the 1990s. > > yes, and your EHLO matches the A record of your IP > > which of the multiple PTR's should the receiving server use? > guess what: it uses a random one > one time it matches your EHLO, the next time not PTR lookup of 1.2.3.4 returns all RR for a.foo.com, b.zee.com, c.lark.com, where each of these also resolves to 1.2.3.4. it is your -client- that determines what to do with each RR after it has received the answer. if your MTA or milter software cannot iterate all the RR records to find the matching hostname, you should get a better MTA or milter. > > congratulations: you are playing lottery you're only playing the lottery with MTAs and anti-spam services that are too naive to understand that multiple records can exist in a single RR answer and it should utilize all the records. > > and yes i had cases where we blocked email because > check_reverse_client_hostname_access when the mailadmin did request a > PTR and the ISP was too dumb to remove the generic one which ended in > some mails hit rules and others not the notion of a 1-to-1 relationship between A and PTR is a relic of history. the internet is always evolving and sharing of IPs to host multiple domains has been around for a long time and increasing considerably as people try to stretch IPv4 further while waiting for their upstream to provide IPv6. there are a considerable number of existing servers that use a many-to-many relationship of A and PTR records and it's only going to increase as more customers request their IPs resolve to all of their hosted domains. the cat and mouse game of spam is always ratcheting upward. as mail providers get better at blocking half-assed setups due to spam, sending providers improve their configuration to rise above the spammers. with the simple fully verified FR of IP/PTR/EHLO, i block more than 87% of incoming spam right at the edge. i have very very few false positives. many-to-many works, and i support it's use. i also support the adoption of MTAs and milters capable of handling modern many-to-many instead of breaking because they expect a legacy 1-to-1 or 1-to-many RR. ___ 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: Multiple A Records - Followup Question
Am 03.10.2016 um 00:08 schrieb David Ford: On 2016-10-02 21:22, Reindl Harald wrote: Am 02.10.2016 um 22:42 schrieb David Ford: On 2016-10-02 12:59, Reindl Harald wrote: IOW, can a given *IP* appear in more than one A record? I realize that this does have the problem that the reverses would resolve to hostX not test on IP should only have on PTR - period avoid anything else than PTR/A-matching if the machine is supposed to send outbound mail it is very helpful to have multiple PTR records for an IP on a mail server so anti-spam engines can accurately make fully verified forward and reverse lookups not just for DNS but also certificate verification. which is *exactly* what you break with *multiple* PTR records for a single IP - seems you don't understand what https://en.wikipedia.org/wiki/Forward-confirmed_reverse_DNS really means no, it exactly doesn't break. it exactly applies to -every- domain served by that mail server with each domain serviced having fully verified forward and backward reachable chain regardless of how many A or PTR (and even CNAME) records exist in RR answers, each having their own domain set in their MX record. no - a mailserver needs exactly *one* IP address with *one* matching PTR record since it's not a webserver serving different document roots and hence you need only *one* certificate for TLS while without DANE TLS in case of smtp is opportunistic anyways besides that receiveing mail has nothing to do with the senders MX at all, really nothing except sender-verifciation in very rare justified cases to not make side attacks to the victims of sender-forging but it's off-topic here mail servers that can't correctly emit the right EHLO for outbound email should remain in the 1990s. yes, and your EHLO matches the A record of your IP which of the multiple PTR's should the receiving server use? guess what: it uses a random one one time it matches your EHLO, the next time not PTR lookup of 1.2.3.4 returns all RR for a.foo.com, b.zee.com, c.lark.com, where each of these also resolves to 1.2.3.4. it is your -client- that determines what to do with each RR after it has received the answer. if your MTA or milter software cannot iterate all the RR records to find the matching hostname, you should get a better MTA or milter. congratulations: you are playing lottery you're only playing the lottery with MTAs and anti-spam services that are too naive to understand that multiple records can exist in a single RR answer and it should utilize all the records. nonsense - when i reject highly suspect dynamic-xx.xx.xx.xx.some-isp.example.com and "mail.example.net" is another PTR of this IP the sender is a fool, that's it go ahead, subscribe on the postfix mailing list abnd explain Wietse that his implementation is naive because you know better - i am curious how far you get and yes i had cases where we blocked email because check_reverse_client_hostname_access when the mailadmin did request a PTR and the ISP was too dumb to remove the generic one which ended in some mails hit rules and others not the notion of a 1-to-1 relationship between A and PTR is a relic of history. the internet is always evolving and sharing of IPs to host multiple domains has been around for a long time and increasing considerably as people try to stretch IPv4 further while waiting for their upstream to provide IPv6. there are a considerable number of existing servers that use a many-to-many relationship of A and PTR records and it's only going to increase as more customers request their IPs resolve to all of their hosted domains. nonsense the cat and mouse game of spam is always ratcheting upward. as mail providers get better at blocking half-assed setups due to spam, sending providers improve their configuration to rise above the spammers. with the simple fully verified FR of IP/PTR/EHLO, i block more than 87% of incoming spam right at the edge. i have very very few false positives. 87% is not very impressive many-to-many works, and i support it's use. i also support the adoption of MTAs and milters capable of handling modern many-to-many instead of breaking because they expect a legacy 1-to-1 or 1-to-many RR so you are happy to play troublemaker - fine yor *your* setups but don't recommend not following best practices to others ___ 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
root zone on a nameserver which cannot reach root-servers
We have a DNS server setup where all zones are either slaves or forwards to a internal DNS servers which resolves external names. Questions: 1. Do we still need a root zone (type=hint) ? 2. What is the side effect of having root zone when our nameserver cannot reach root servers? (additional load on DNS if yes what percentage?) Thanks Blr ___ 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: Querying locally on a nameserver - odd behavior
On Wednesday, September 21, 2016 at 8:10:16 AM UTC-7, Graham Clinch wrote: > >>> I have a DNS server (which is both forwarder and authoritative NS) and I > >>> see this odd behavior locally on the host: > >>> > >>> dig @localhost # returns immediately with right response > >>> > >>> dig @ # returns sometimes, timesout most > >>> of the time > > [...] > > during this behavior, I saw lots of UDP packet loss on the host: > > > > netstat -s | egrep -A4 "Udp:" > > ... > > .. > > > > > > I tried similar local queries when traffic reduced (and when UDP pkt loss > > was zero) and both local queries succeeded. > > Which version of Bind are you running? This sounds like an issue I've > seen with prefetch in 9.10 before 9.10.4. > > https://kb.isc.org/article/AA-01315/0/prefetch-performance-in-BIND-9.10.html > > Graham BIND 9.8.x. This behavior is seen when there are flood of NXDOMAIN queries sent to our nameserver running BIND 9.8.x As a short-term fix, we have added our nameservers behind a netscalar VIP and provided additional capacity to hadoop applications. I hope I'll have some time soon to get to the bottom of this problem (or just upgrade to BIND 9.10.x ? :) ) thanks Blr ___ 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
