Re: Postgres v MySQL v Berkely backend for BIND

[Chris Dew]

Are there performance increases/decreases involved with using a db in
place of bind's normal zone files?

Is there a sqlite3 backend to bind?

Regards,

Chris.

-- 

http://www.finalcog.com/

2009/5/4 David Ford :
> I use the DLZ/PG backend and it's rock solid.  I use Ant with a few
> modifications for my front end.
>
> Stephen Carville wrote:
>> I have to bother you all again.
>>
>> I was asked Friday afternoon about using a database with the new BIND
>> servers.  To me it seems using MySQL or PostgreSQL is a bit like
>> hunting rabbits with a howitzer though Berkely DB looks like a good
>> fit.  I can find patches for all three but no real information on
>> reliability or performance.  Performance is not the big deal but
>> reliability and ease of maintenance is.
>>
>> Anyone here have experience or an informed opinion in using a database
>> backend to BIND?
>>
>> This is for BIND 9 on a CentOS or Redhat 5 system.
>>
>>
>
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: tcp versus udp

[Peter Dambier]

Hello Martin,

since a major outage at my provider, dtag.de or Deutsche Telecom AG, I have 
trouble
with f.root-servers.net. Sometimes "dig ... +vc" does help me to see 
f.root-servers.net.

The real problem is anycast. With udp it behaves different than with tcp.

When querying servers that are difficult to reach, sometimes you are more lucky 
with
tcp than with udp.

Amplification attacks using nameservers don't work with tcp.

Sometimes bugs in resolvers sometimes in clients cause failover to tcp.

With DNSSEC tcp is almost a must. Same with IPv6.


Kind regards
Peter



Martin McCormick wrote:
>   When are tcp dns queries necessary?
> 
>   It was my understanding that clients could user tcp or
> udp.
> 
> Martin McCormick WB5AGZ  Stillwater, OK 
> Systems Engineer
> OSU Information Technology Department Telecommunications Services Group
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: pe...@peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: tcp versus udp

[Traynham . Ken]

Please explain: With DNSSEC tcp is almost a must. Same with IPv6.Is EDNS0 not sufficient? Thanks,Ken Ken TraynhamNetwork Engineer, ITS-EPA CLIN9CSC79 TW Alexander Drive, Building 4201, Durham NC 27709ITIS | p: 919.767.7059 | f: 919.767.7506 | traynham@epa.gov | www.csc.comThis is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.-bind-users-boun...@lists.isc.org wrote: -To: bind-us...@isc.orgFrom: Peter Dambier Sent by: bind-users-boun...@lists.isc.orgDate: 05/05/2009 05:31AMSubject: Re: tcp versus udpHello Martin,since a major outage at my provider, dtag.de or Deutsche Telecom AG, I have troublewith f.root-servers.net. Sometimes "dig ... +vc" does help me to see f.root-servers.net.The real problem is anycast. With udp it behaves different than with tcp.When querying servers that are difficult to reach, sometimes you are more lucky withtcp than with udp.Amplification attacks using nameservers don't work with tcp.Sometimes bugs in resolvers sometimes in clients cause failover to tcp.With DNSSEC tcp is almost a must. Same with IPv6.Kind regardsPeterMartin McCormick wrote:> When are tcp dns queries necessary?> > It was my understanding that clients could user tcp or> udp.> > Martin McCormick WB5AGZ  Stillwater, OK > Systems Engineer> OSU Information Technology Department Telecommunications Services Group> ___> bind-users mailing list> bind-users@lists.isc.org> https://lists.isc.org/mailman/listinfo/bind-users-- Peter and Karin DambierCesidian Root - Radice CesidianaRimbacher Strasse 16D-69509 Moerlenbach-Bonsweiher+49(6209)795-816 (Telekom)+49(6252)750-308 (VoIP: sipgate.de)mail: pe...@peter-dambier.dehttp://www.peter-dambier.de/http://iason.site.voila.fr/https://sourceforge.net/projects/iason/ULA= fd80:4ce1:c66a::/48___bind-users mailing listbind-users@lists.isc.orghttps://lists.isc.org/mailman/listinfo/bind-users___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: tcp versus udp

[Peter Dambier]

EDNS would be nice if it was working, but the same guy who disabled tcp in the
firewall somehow has shot EDNS too.

There are so many broken firewalls around nameservers that tcp is a must.

It is not an EDNS or bind problem. It is the firewalls in between.
Expect the worst but try to give your best says please keep tcp working.

Cheers
Peter

traynham@epamail.epa.gov wrote:
> Please explain:
>  
> With DNSSEC tcp is almost a must. Same with IPv6.
> Is EDNS0 not sufficient?
>  
> Thanks,
> Ken
>  
> Ken Traynham
> Network Engineer, ITS-EPA CLIN9
> CSC
> 
> 79 TW Alexander Drive, Building 4201, Durham NC 27709
> ITIS | p: 919.767.7059 | f: 919.767.7506 | traynham@epa.gov
>  | www.csc.com 
> 
> 
> This is a PRIVATE message. If you are not the intended recipient, please 
> delete without copying and kindly advise us by e-mail of the mistake in 
> delivery. NOTE: Regardless of content, this e-mail shall not operate to bind 
> CSC to any order or other contract unless pursuant to explicit written 
> agreement or government initiative expressly permitting the use of e-mail for 
> such purpose.
> 
> 
> -bind-users-boun...@lists.isc.org wrote: -
> 
> To: bind-us...@isc.org
> From: Peter Dambier 
> Sent by: bind-users-boun...@lists.isc.org
> Date: 05/05/2009 05:31AM
> Subject: Re: tcp versus udp
> 
> Hello Martin,
> 
> since a major outage at my provider, dtag.de or Deutsche Telecom AG,
> I have trouble
> with f.root-servers.net. Sometimes "dig ... +vc" does help me to see
> f.root-servers.net.
> 
> The real problem is anycast. With udp it behaves different than with
> tcp.
> 
> When querying servers that are difficult to reach, sometimes you are
> more lucky with
> tcp than with udp.
> 
> Amplification attacks using nameservers don't work with tcp.
> 
> Sometimes bugs in resolvers sometimes in clients cause failover to tcp.
> 
> With DNSSEC tcp is almost a must. Same with IPv6.
> 
> 
> Kind regards
> Peter
> 
> 
> 
> Martin McCormick wrote:
> > When are tcp dns queries necessary?
> >
> > It was my understanding that clients could user tcp or
> > udp.
> >
> > Martin McCormick WB5AGZ  Stillwater, OK
> > Systems Engineer
> > OSU Information Technology Department Telecommunications Services
> Group
> > ___
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> 
> -- 
> Peter and Karin Dambier
> Cesidian Root - Radice Cesidiana
> Rimbacher Strasse 16
> D-69509 Moerlenbach-Bonsweiher
> +49(6209)795-816 (Telekom)
> +49(6252)750-308 (VoIP: sipgate.de)
> mail: pe...@peter-dambier.de
> http://www.peter-dambier.de/
> http://iason.site.voila.fr/
> https://sourceforge.net/projects/iason/
> ULA= fd80:4ce1:c66a::/48
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 
> 
> 
> 
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Peter and Karin Dambier
Cesidian Root - Radice Cesidiana
Rimbacher Strasse 16
D-69509 Moerlenbach-Bonsweiher
+49(6209)795-816 (Telekom)
+49(6252)750-308 (VoIP: sipgate.de)
mail: pe...@peter-dambier.de
http://www.peter-dambier.de/
http://iason.site.voila.fr/
https://sourceforge.net/projects/iason/
ULA= fd80:4ce1:c66a::/48
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Bind Statistics questions

[Nuno Ribeiro]

Hi all,

I have some doubts and I would like clarify them:
- Bind ( version 9.5) provides lots of statistics information and provides
two interfaces for users to get access to it (file dump and HTTP access).
For what I see and read the counters are cumulative during the time the
service is running. My question is if it possible to reset the counter
statistics in real time in order to have statistic details in a time
interval?
Other question is if there is any statistic detail provide us information
such this "average time answering to queries of type A"

Thanks in  any advance.

Best Regards,

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

FORMERR during DNS queries

[Eric Swenson]

I'm seeing lots of DNS resolution failures on my router (running Utuntu
8.10, bind 9.3.4).  While most succeed, I get quite a few FORMERR errors
similar to:
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 66.151.140.2#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.168.3.1#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.112.36.4#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 128.63.2.53#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.228.79.201#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.36.148.17#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 202.12.27.33#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.33.4.12#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.5.5.241#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.58.128.30#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 128.8.10.90#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 198.41.0.4#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.203.230.10#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 193.0.14.129#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 199.7.83.42#53

I'm running an iptables firewall on this box, which is connected to the
internet via a wireless access point on my roof with a link to my ISP.  As a
result of the above FORMERRs, clients on my lan are unable to resolve
addresses -- in the above case, imap.gmail.com, and therefore are unable to
access mail.  Upon the recommendations of someone familiar with the relevant
technologies, I've updated my DNS (named.conf) to set the edns-udp-size 500
option.  This had no effect.

If I use dig to resolve imap.gmail.com manually, by specifying any of the
above-mentioned DNS servers, everything works fine.  In fact, I can usually
force my DNS server to begin resolving these address (e.g. imap.gmail.com)
for a LITTLE while, by manually using nslookup and querying first for the NS
record of gmail.com, and then for the A record of imap.gmail.com.  Once I
succeed in getting a resolution, the address record is cached, and my DNS
will resolve the hostname until the cache time is exceeded. And then I'm
back to no resolution and FORMERRs.

Can anyone suggest anything I can try?

Thanks much. -- Eric

PS: If this message appears twice on the list, I apologize.  I'm not seeing
my posts show up (although I'm seeing others' posts)
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind Statistics questions

[Emery]

Hello Nuno,

I don't know if you can reset the stats, but in my environment I had the 
need to check statistics to alert us to attacks and high abnormally high 
query numbers. In order to do this, I wrote shell scripts that check the 
current count and writes that value to a file. This is a rotating 
process with the each iteration writing the current value to a file and 
on the next cycle comparing the new value to the written value before 
writing the new value to the file. On each iteration, the new value is 
subtracted from the written value to get the actual 1 minute count.


I use this process for the query and recursive query counts and if they 
breach a specific level, an email is sent. We also use Sitescope 
monitoring to the values to get trending information. If the stats 
cannot be reset, this is an alternative that has worked for me.


Emery Rudolph
University of Maryland University College.


Nuno Ribeiro wrote:


Hi all,

I have some doubts and I would like clarify them:
- Bind ( version 9.5) provides lots of statistics information and 
provides two interfaces for users to get access to it (file dump and 
HTTP access). For what I see and read the counters are cumulative 
during the time the service is running. My question is if it possible 
to reset the counter statistics in real time in order to have 
statistic details in a time interval?
Other question is if there is any statistic detail provide us 
information such this "average time answering to queries of type A"
 
Thanks in  any advance.


Best Regards,

--
Nuno Ribeiro


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

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

Delegation or PEBKAC problems?

[Todd Snyder]

Good day,

(BIND 9.6.0-P1)

Although, to me, delegation seems like a fairly simple configuration, I
seem to be having problems.  What I am trying to do is very simple - I
have a lab, and I want to delegate part of the namespace to someone else
in the lab.  My configuration looks like this:

(zone lab.foo.example)
;delegation
group.lab.foo.example.  IN  NS  group-ns01.lab.foo.example.
group.lab.foo.example.  IN  NS  group-ns02.lab.foo.example.

; glue
group-ns01  IN  A   1.1.1.1
group-ns02  IN  A   1.1.1.2

I load the zone, it loads just fine.  I can resolve the 2 ns servers
directly, so I know the glue is good.

However, when I dig for a record in that zone, I get

[10:43:08 r...@ns01.lab.foo.example:~ ()]# dig @ns01.lab.foo.example
record.group.foo.example any

; <<>> DiG 9.6.0-P1 <<>> +qr @s01.lab.foo.example
record.group.foo.example any
; (1 server found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59035
;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;record.group.foo.example.IN  ANY
;; connection timed out; no servers could be reached

When I dig directly at the delegated nameserver, I can get the record
just fine.

When I run tcpdump on the nameserver, I see the requests come in,
timeout, come in, time out, come in, timeout, then the resolver gives
up.  I don't see packets going out to the other server, nor do I see the
server returning anything to the resolver (ie: authority records)

If I disable recursion on this view, the server, loading the same zone,
returns NS records immediately, which tells me that the server is
loading the zone properly, and that the data is good.

My understanding of delegation is that the resolver goes out to it's
configured nameserver.  That nameserver returns the NS records for the
delegated namespace, then the resolver goes to the delegated server to
ask the next question.  Am I incorrect in that?  

We've been fiddling with this for a bit now, and I can't see what I've
done wrong.  My best guess right now is that we're htiting some oddness
with views/delegation.

Can anyone think of something I've missed?  Can anyone clarify my view
of delegation? 

Thanks,

Todd.




-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Delegation or PEBKAC problems?

[John Hascall]

> My understanding of delegation is that the resolver goes out to it's
> configured nameserver.  That nameserver returns the NS records for the
> delegated namespace, then the resolver goes to the delegated server to
> ask the next question.  Am I incorrect in that?  

It works that way, sometimes.

If recursion is enabled on your server, it will query
the other servers in the NS records on behalf of the resolver
and return what it finds.  If recursion is off, it will
just return the NS records and the resolver is expected
to follow them (and some really dumb resolvers might
not be able to do that).

If your first server can't talk to the other (delegated zone's)
NS's (say because of a firewall issue) you can get something
that matches what you seem to be getting.

John
---
John Hascall, j...@iastate.edu
Team Lead, NIADS (Network Infrastructure, Authentication & Directory Services)
IT Services, The Iowa State University of Science and Technology
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Delegation or PEBKAC problems?

[Todd Snyder]

>It works that way, sometimes.
>
>If recursion is enabled on your server, it will query the other servers
in 
>the NS records on behalf of the resolver and return what it finds.  If 
>recursion is off, it will just return the NS records and the resolver
is 
>expected to follow them (and some really dumb resolvers might not be
able
>to do that).
>
>If your first server can't talk to the other (delegated zone's) NS's
(say 
>because of a firewall issue) you can get something that matches what
you 
>seem to be getting.

Thanks John.

>From the first server, I can talk to the delegated nameserver no
problem.  We thought it might be firewall/acl related, but digs confirm
that they can talk directly without problem.  They are, logically
speaking, on the same switch, with no firewalls between.

Todd.


-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Delegation or PEBKAC problems?

[Todd Snyder]

it's been pointed out that I made a mistake cleaning up my example data
below .. my dig should read:

[10:43:08 r...@ns01.lab.foo.example:~ ()]# dig @ns01.lab.foo.example
record.group.lab.foo.example any

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Todd Snyder
Sent: Tuesday, May 05, 2009 11:08 AM
To: bind-us...@isc.org
Subject: Delegation or PEBKAC problems?

Good day,

(BIND 9.6.0-P1)

Although, to me, delegation seems like a fairly simple configuration, I
seem to be having problems.  What I am trying to do is very simple - I
have a lab, and I want to delegate part of the namespace to someone else
in the lab.  My configuration looks like this:

(zone lab.foo.example)
;delegation
group.lab.foo.example.  IN  NS  group-ns01.lab.foo.example.
group.lab.foo.example.  IN  NS  group-ns02.lab.foo.example.

; glue
group-ns01  IN  A   1.1.1.1
group-ns02  IN  A   1.1.1.2

I load the zone, it loads just fine.  I can resolve the 2 ns servers
directly, so I know the glue is good.

However, when I dig for a record in that zone, I get

[10:43:08 r...@ns01.lab.foo.example:~ ()]# dig @ns01.lab.foo.example
record.group.lab.foo.example any

; <<>> DiG 9.6.0-P1 <<>> +qr @s01.lab.foo.example
record.group.foo.example any ; (1 server found) ;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59035 ;; flags: rd;
QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;record.group.foo.example.IN  ANY
;; connection timed out; no servers could be reached

When I dig directly at the delegated nameserver, I can get the record
just fine.

When I run tcpdump on the nameserver, I see the requests come in,
timeout, come in, time out, come in, timeout, then the resolver gives
up.  I don't see packets going out to the other server, nor do I see the
server returning anything to the resolver (ie: authority records)

If I disable recursion on this view, the server, loading the same zone,
returns NS records immediately, which tells me that the server is
loading the zone properly, and that the data is good.

My understanding of delegation is that the resolver goes out to it's
configured nameserver.  That nameserver returns the NS records for the
delegated namespace, then the resolver goes to the delegated server to
ask the next question.  Am I incorrect in that?  

We've been fiddling with this for a bit now, and I can't see what I've
done wrong.  My best guess right now is that we're htiting some oddness
with views/delegation.

Can anyone think of something I've missed?  Can anyone clarify my view
of delegation? 

Thanks,

Todd.




-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you have received this
transmission in error, please immediately reply to the sender and delete
this information from your system. Use, dissemination, distribution, or
reproduction of this transmission by unintended recipients is not
authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

-
This transmission (including any attachments) may contain confidential 
information, privileged material (including material protected by the 
solicitor-client or other applicable privileges), or constitute non-public 
information. Any use of this information by anyone other than the intended 
recipient is prohibited. If you have received this transmission in error, 
please immediately reply to the sender and delete this information from your 
system. Use, dissemination, distribution, or reproduction of this transmission 
by unintended recipients is not authorized and may be unlawful.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind Statistics questions

[Emery]

As I have received numerous request for my script, I've attached it 
here. Hopefully it is helpful.


   * Please note that I have removed our email address and domain at
 the end of the script during the mailx statement.


mailx -s "TOTAL Queries on `uname -n` are running $NUM/min" -r 
"d...@`uname -n`.domain.edu"  email_remo...@domain.edu < $err_dir/stdQueryMsg



Nuno Ribeiro wrote:


Hi all,

I have some doubts and I would like clarify them:
- Bind ( version 9.5) provides lots of statistics information and 
provides two interfaces for users to get access to it (file dump and 
HTTP access). For what I see and read the counters are cumulative 
during the time the service is running. My question is if it possible 
to reset the counter statistics in real time in order to have 
statistic details in a time interval?
Other question is if there is any statistic detail provide us 
information such this "average time answering to queries of type A"
 
Thanks in  any advance.


Best Regards,

--
Nuno Ribeiro


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
#!/usr/bin/ksh

#   
# Author: Emery Rudolph #
# Date: Mar 03, 2009#
# Purpose: This script takes the count  #
# for total queries and sets a  #
# threshold above which a notification  #
# email is sent to alert sysadmins. #
# There is no action to take upon the   #
# server. Inform INET, so that they can #
# monitor and perhaps block the address #
#


dir=/var/run
err_dir=$dir/err_msgs
integer NUM
integer getValue
integer TRIGGER=1

cd $dir

sleep 3
cat /dev/null > $err_dir/stdQueryMsg
rm stdQuery2
mv stdQuery1 stdQuery2
touch stdQuery1

getValue=$(grep -w QUERY named.stats | awk '{print $1}')

echo "$getValue" >stdQuery1

var1=$(cat stdQuery1)   
var2=$(cat stdQuery2)   

echo "VAR1=$var1"
echo "VAR2=$var2"

NUM="$var1"-"$var2"
echo "Variable NUM=$NUM"
echo ""
echo $NUM > $dir/sitescope.standard.value

if(("$NUM">"$TRIGGER"))
then
echo "QUERY ALARM"

echo 
"##" >> 
$err_dir/stdQueryMsg
echo "The `uname -n` server is experiencing an unusually high   
" >> $err_dir/stdQueryMsg
echo "level of Standard Queries, which could be an  
" >> $err_dir/stdQueryMsg
echo "indication of a DOS attack. Please inspect the current
" >> $err_dir/stdQueryMsg
echo "activity in the $dir/Errors log and if confirmed, 
" >> $err_dir/stdQueryMsg
echo "contact the INET group to possibly block the offending
" >> $err_dir/stdQueryMsg
echo "IP address if warranted.  
" >> $err_dir/stdQueryMsg
echo "__
" >> $err_dir/stdQueryMsg
echo "CURRENT Total Queries: $NUM/minute
" >> $err_dir/stdQueryMsg
echo "__
" >> $err_dir/stdQueryMsg
echo 
"##" >> 
$err_dir/stdQueryMsg

mailx -s "TOTAL Queries on `uname -n` are running $NUM/min" -r 
"d...@`uname -n`.domain.edu" email_remo...@domain.edu < $err_dir/stdQueryMsg
fi
exit
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DNS Resolution Failure - FORMERR

[Eric Swenson]

I'm seeing lots of DNS resolution failures on my router (running Utuntu
8.10, bind 9.3.4).  While most succeed, I get quite a few FORMERR errors
similar to:
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 66.151.140.2#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.168.3.1#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.112.36.4#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 128.63.2.53#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.228.79.201#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.36.148.17#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 202.12.27.33#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.33.4.12#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.5.5.241#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.58.128.30#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 128.8.10.90#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 198.41.0.4#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.203.230.10#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 193.0.14.129#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 199.7.83.42#53

I'm running an iptables firewall on this box, which is connected to the
internet via a wireless access point on my roof with a link to my ISP.  As a
result of the above FORMERRs, clients on my lan are unable to resolve
addresses -- in the above case, imap.gmail.com, and therefore are unable to
access mail.  Upon the recommendations of someone familiar with the relevant
technologies, I've updated my DNS (named.conf) to set the edns-udp-size 500
option.  This had no effect.

If I use dig to resolve imap.gmail.com manually, by specifying any of the
above-mentioned DNS servers, everything works fine.  Also, when clients
within my network fail to have imap.gmail.com resolve, I can "fix" things
for a short while, by simply issuing the following:

nslookup
set querytype=ns
gmail.com.
lserver 
set querytype=a
imap.gmail.com

Once I've done the above, my DNS server caches the A record for
imap.gmail.com and happily hands it out until the cache time is exceeded,
when I'm back getting FORMERRs and failing to resolve imap.gmail.com.

There are other addresses than imap.gmail.com that cannot be resolved due to
FORMERRs, but this domain name is the most prevalent, and most annoying,
since it prevents users within my network from getting mail.

Since I can force my DNS to resolve these addresses by issuing the above
queries, I'm wondering if the problem is due to having the following in my
named.conf:

 forwarders {
 192.168.3.1;
 66.151.140.2;
 };

My ISP provides the above two DNS servers and I have mine delegating to
theirs.  Perhaps one of these two DNS servers (or any that they forward to)
is having problems (perhaps no EDNS0 support?), which causes the FORMERRs to
be reported by my DNS server.

I haven't yet tried removing the forwarders.  I figured this was not the
issue because the FORMERR log messages suggest (to me) that my DNS is trying
to contact the root servers itself (and not relying on the downstream DNS
servers to do so).

Does anyone have ideas about what is going on?

Thanks much. -- Eric
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Delegation or PEBKAC problems?

[Todd Snyder]

With help of a list member, we got this figured out.

The problem is that, outside of the config I showed you, I had a
forwarder setup.

zone "foo.example" IN {
type  forward;
forward only;
forwarders { x; y };
};

My understanding of things was that BIND would answer most specifically.
So I thought that because I was authoritative for lab.foo.example, it
would only use the foo.example for things that didn't fall under
lab.foo.example.  That doesn't seem to be the case.  BIND was using the
forwarding, and not even looking at the authoritative zone.

>From my reading of "DNS and Bind (pg 244, 4th paragraph)", I'm wondering
if the book or BIND are mistaken:

"If a resolver requests records that are already in the nameserver's
authoritative data or cached adata, the nameserver answer that with the
information, this part of its operation hasn't changed.  However, if the
records aren't in its database, the nameserver sends the query to a
forwarder ..."  (this relates to forward only mode)

For forward first mode, the book states (pg 245, 2nd paragraph):

"A nameserver in forward-only mode is a variation on a nameserver that
uses forwarders.  It still answers queries from its authoritative data
and cached data."

So, in both cases, the server should be answering authoritatively first,
then going to the forwarders.

Having said that, I reconfigured it to use "forward first" and I'm
getting the behaviour I was looking for - so the server seems to behave
as I thought in "forward first" mode, but not in "forward only" mode.

Has the logic here changed, or am I misinterpreting the book?

Thanks!

Todd.



-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Todd Snyder
Sent: Tuesday, May 05, 2009 11:59 AM
To: bind-us...@isc.org
Subject: RE: Delegation or PEBKAC problems?

it's been pointed out that I made a mistake cleaning up my example data
below .. my dig should read:

[10:43:08 r...@ns01.lab.foo.example:~ ()]# dig @ns01.lab.foo.example
record.group.lab.foo.example any

-Original Message-
From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Todd Snyder
Sent: Tuesday, May 05, 2009 11:08 AM
To: bind-us...@isc.org
Subject: Delegation or PEBKAC problems?

Good day,

(BIND 9.6.0-P1)

Although, to me, delegation seems like a fairly simple configuration, I
seem to be having problems.  What I am trying to do is very simple - I
have a lab, and I want to delegate part of the namespace to someone else
in the lab.  My configuration looks like this:

(zone lab.foo.example)
;delegation
group.lab.foo.example.  IN  NS  group-ns01.lab.foo.example.
group.lab.foo.example.  IN  NS  group-ns02.lab.foo.example.

; glue
group-ns01  IN  A   1.1.1.1
group-ns02  IN  A   1.1.1.2

I load the zone, it loads just fine.  I can resolve the 2 ns servers
directly, so I know the glue is good.

However, when I dig for a record in that zone, I get

[10:43:08 r...@ns01.lab.foo.example:~ ()]# dig @ns01.lab.foo.example
record.group.lab.foo.example any

; <<>> DiG 9.6.0-P1 <<>> +qr @s01.lab.foo.example
record.group.foo.example any ; (1 server found) ;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59035 ;; flags: rd;
QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;record.group.foo.example.IN  ANY
;; connection timed out; no servers could be reached

When I dig directly at the delegated nameserver, I can get the record
just fine.

When I run tcpdump on the nameserver, I see the requests come in,
timeout, come in, time out, come in, timeout, then the resolver gives
up.  I don't see packets going out to the other server, nor do I see the
server returning anything to the resolver (ie: authority records)

If I disable recursion on this view, the server, loading the same zone,
returns NS records immediately, which tells me that the server is
loading the zone properly, and that the data is good.

My understanding of delegation is that the resolver goes out to it's
configured nameserver.  That nameserver returns the NS records for the
delegated namespace, then the resolver goes to the delegated server to
ask the next question.  Am I incorrect in that?  

We've been fiddling with this for a bit now, and I can't see what I've
done wrong.  My best guess right now is that we're htiting some oddness
with views/delegation.

Can anyone think of something I've missed?  Can anyone clarify my view
of delegation? 

Thanks,

Todd.




-
This transmission (including any attachments) may contain confidential
information, privileged material (including material protected by the
solicitor-client or other applicable privileges), or constitute
non-public information. Any use of this information by anyone other than
the intended recipient is prohibited. If you ha

Re: Bind Statistics questions

[JINMEI Tatuya / 神明達哉]

At Tue, 5 May 2009 11:11:13 +0100,
Nuno Ribeiro  wrote:

> I have some doubts and I would like clarify them:
> - Bind ( version 9.5) provides lots of statistics information and provides
> two interfaces for users to get access to it (file dump and HTTP access).
> For what I see and read the counters are cumulative during the time the
> service is running. My question is if it possible to reset the counter
> statistics in real time in order to have statistic details in a time
> interval?

It's currently not possible.  We've actually discussed before, so you
might want to search the mail archive.  It would not be difficult to
implement it, but I've personally not yet seen a strong argument for
it.  Most if not all of the things that the reset feature could
provide can be achieved by post-processing cumulative data, so, for
now I'd rather keep the server side simple.

> Other question is if there is any statistic detail provide us information
> such this "average time answering to queries of type A"

The answer would be no anyway, but I'm afraid the question is also not
very clear.  Can you define "average time answering to queries of type
A" more precisely? (e.g. it's not even clear about an authoritative
server or a recursive server)

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

DNS resolution failure - FORMERR

[Eric Swenson]

I'm seeing lots of DNS resolution failures on my router (running Utuntu
8.10, bind 9.3.4).  While most succeed, I get quite a few FORMERR errors
similar to:
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 66.151.140.2#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.168.3.1#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.112.36.4#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 128.63.2.53#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.228.79.201#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.36.148.17#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 202.12.27.33#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.33.4.12#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.5.5.241#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.58.128.30#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 128.8.10.90#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 198.41.0.4#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 192.203.230.10#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 193.0.14.129#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving '
imap.gmail.com/A/IN': 199.7.83.42#53

I'm running an iptables firewall on this box, which is connected to the
internet via a wireless access point on my roof with a link to my ISP.  As a
result of the above FORMERRs, clients on my lan are unable to resolve
addresses -- in the above case, imap.gmail.com, and therefore are unable to
access mail.  Upon the recommendations of someone familiar with the relevant
technologies, I've updated my DNS (named.conf) to set the edns-udp-size 500
option.  This had no effect.

If I use dig to resolve imap.gmail.com manually, by specifying any of the
above-mentioned DNS servers, everything works fine.  Also, when clients
within my network fail to have imap.gmail.com resolve, I can "fix" things
for a short while, by simply issuing the following:

nslookup
set querytype=ns
gmail.com.
lserver 
set querytype=a
imap.gmail.com

Once I've done the above, my DNS server caches the A record for
imap.gmail.com and happily hands it out until the cache time is exceeded,
when I'm back getting FORMERRs and failing to resolve imap.gmail.com.

There are other addresses than imap.gmail.com that cannot be resolved due to
FORMERRs, but this domain name is the most prevalent, and most annoying,
since it prevents users within my network from getting mail.

Since I can force my DNS to resolve these addresses by issuing the above
queries, I'm wondering if the problem is due to having the following in my
named.conf:

 forwarders {
 192.168.3.1;
 66.151.140.2;
 };

My ISP provides the above two DNS servers and I have mine delegating to
theirs.  Perhaps one of these two DNS servers (or any that they forward to)
is having problems (perhaps no EDNS0 support?), which causes the FORMERRs to
be reported by my DNS server.

I haven't yet tried removing the forwarders.  I figured this was not the
issue because the FORMERR log messages suggest (to me) that my DNS is trying
to contact the root servers itself (and not relying on the downstream DNS
servers to do so).

Does anyone have ideas about what is going on?

Thanks much. -- Eric
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS Resolution Failure - FORMERR

[Eric Swenson]

I apologize for the multiple posts. I didn't think my post was making it to
the list since I never received my own post, but have been receiving those
of others.  And yes, I'm configured to see my own posts.
A couple people have suggested I look at the trace output of bind to see
what server is sending the bad response.  I provide some of the trace output
below.  I certainly don't see anything amiss, and one of the servers that
appears to provoke the FORMERR seems to have responded just fine.  Here is
relevant output (with some stuff deleted due to verbosity):

05-May-2009 10:49:14.943 dispatch 0x8144b90 response 0x81476b8
192.228.79.201#53: attached to task 0x80ed240
05-May-2009 10:49:14.945 resquery 0x8152c70 (fctx 0x812f170(
imap.gmail.com/A)): sent
05-May-2009 10:49:14.945 resquery 0x8152c70 (fctx 0x812f170(
imap.gmail.com/A)): senddone
05-May-2009 10:49:14.945 dispatch 0x8149a70: got packet: requests 0, buffers
2, recvs 1
05-May-2009 10:49:14.945 dispatch 0x8149a70: shutting down; detaching from
sock 0x81418f0, task 0x8141a20
05-May-2009 10:49:14.965 socket 0x8141460 192.228.79.201#53: packet received
correctly
05-May-2009 10:49:14.966 dispatch 0x8144b90: got packet: requests 1, buffers
1, recvs 1
05-May-2009 10:49:14.966 dispatch 0x8144b90: got valid DNS message header,
/QR 1, id 47066
05-May-2009 10:49:14.966 resquery 0x8152c70 (fctx 0x812f170(
imap.gmail.com/A)): response
05-May-2009 10:49:14.967 received packet:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  47066
;; flags: qr rd ra ; QUESTION: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;imap.gmail.com. IN A

;; ANSWER SECTION:
imap.gmail.com. 241 IN CNAME gmail-imap.l.google.com.
gmail-imap.l.google.com. 241 IN A 209.85.201.111
gmail-imap.l.google.com. 241 IN A 209.85.201.109

;; AUTHORITY SECTION:
gmail.com. 76384 IN NS ns4.google.com.
gmail.com. 76384 IN NS ns1.google.com.
gmail.com. 76384 IN NS ns2.google.com.
gmail.com. 76384 IN NS ns3.google.com.

;; ADDITIONAL SECTION:
ns4.google.com. 77136 IN A 216.239.38.10
ns1.google.com. 77136 IN A 216.239.32.10
ns2.google.com. 77136 IN A 216.239.34.10
ns3.google.com. 77136 IN A 216.239.36.10


05-May-2009 10:49:14.967 fctx 0x812f170(imap.gmail.com/A'): answer_response
05-May-2009 10:49:14.968 fctx 0x812f170(imap.gmail.com/A'):
noanswer_response
05-May-2009 10:49:14.968 fctx 0x812f170(imap.gmail.com/A'): cancelquery
05-May-2009 10:49:14.968 dispatch 0x8144b90 response 0x81476b8
192.228.79.201#53: detaching from task 0x80ed240
05-May-2009 10:49:14.968 dispatch 0x8144b90: detach: refcount 0
05-May-2009 10:49:14.968 fctx 0x812f170(imap.gmail.com/A'): add_bad
05-May-2009 10:49:14.969 FORMERR resolving 'imap.gmail.com/A/IN':
192.228.79.201#53

Does this trace output suggest what is going wrong?  -- Eric

On Tue, May 5, 2009 at 9:53 AM, Eric Swenson  wrote:

> I'm seeing lots of DNS resolution failures on my router (running Utuntu
> 8.10, bind 9.3.4).  While most succeed, I get quite a few FORMERR errors
> similar to:
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 66.151.140.2#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 192.168.3.1#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 192.112.36.4#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 128.63.2.53#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 192.228.79.201#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 192.36.148.17#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 202.12.27.33#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 192.33.4.12#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 192.5.5.241#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 192.58.128.30#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 128.8.10.90#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 198.41.0.4#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 192.203.230.10#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 193.0.14.129#53
> May  4 20:25:25 localhost named[19579]: FORMERR resolving '
> imap.gmail.com/A/IN': 199.7.83.42#53
>
> I'm running an iptables firewall on this box, which is connected to the
> internet via a wireless access point on my roof with a link to my ISP.  As a
> result of the above FORMERRs, clients on my lan are unable to resolve
> addresses -- in the above case, imap.gmail.com, and therefore are unable
> to access mail.  Upon the recommendations of someone familiar with the
> relevant technologies, I've updated my DNS (named.conf) to set
> the edns-udp-size 500 option.  Thi

[DNSSEC] SERVFAIL when resolving ".gov" through DLV

[Stephane Bortzmeyer]

I get a SERVFAIL when trying to resolve ".gov":

% dig +dnssec @127.0.0.1 SOA gov.

; <<>> DiG 9.5.1-P1 <<>> +dnssec @127.0.0.1 SOA gov.
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54920
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;gov.   IN  SOA

;; Query time: 784 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May  5 20:31:54 2009
;; MSG SIZE  rcvd: 32

This is a BIND 9.5.1-P1, Debian package. It is configured to use ISC's
DLV:

dnssec-enable yes;
dnssec-lookaside . trust-anchor dlv.isc.org.; 

Other signed TLD such as ".cz" or ".pr" creates no problems.

With Unbound, which also uses the same DLV, things seem to work so I
suspect a BIND bug. Restarting the name server does not seem to help.

Here is the log:

05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: 
starting
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: 
looking for DLV
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: 
plain DNSSEC returns unsecure (.): looking for DLV
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: 
looking for DLV gov.dlv.isc.org
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: 
DLV gov found
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: 
dlv_validator_start
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: 
restarting using DLV
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: 
attempting positive response validation
05-May-2009 20:29:50.425 dnssec: info: validating @0x7ff090d763d0: gov SOA: no 
valid signature found
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: 
falling back to insecurity proof
05-May-2009 20:29:50.425 dnssec: debug 3: validating @0x7ff090d763d0: gov SOA: 
insecurity proof failed
05-May-2009 20:29:50.425 dnssec: debug 3: validator @0x7ff090d763d0: 
dns_validator_destroy
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [DNSSEC] SERVFAIL when resolving ".gov" through DLV

[Jeremy C. Reed]

On Tue, 5 May 2009, Stephane Bortzmeyer wrote:

> This is a BIND 9.5.1-P1, Debian package. It is configured to use ISC's
> DLV:

https://www.isc.org/node/437
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [DNSSEC] SERVFAIL when resolving ".gov" through DLV

[R Dicaire]

On Tue, May 5, 2009 at 2:34 PM, Stephane Bortzmeyer  wrote:
> I get a SERVFAIL when trying to resolve ".gov":

I get:

; <<>> DiG 9.4.3-P2 <<>> +dnssec SOA gov.
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32204
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;gov.   IN  SOA

;; ANSWER SECTION:
gov.259200  IN  SOA A.GOV.ZONEEDIT.COM.
govcontact.ZONEEDIT.COM. 1241524864 3600 900 1814400 86400
gov.259200  IN  RRSIG   SOA 7 1 259200
20090510110105 20090505110105 31802 gov.
WR3awt6m9j1C3o72BRR/SdFp5RrSOPLxSGV90DpQ0s+I2d9jp6RvR1vg
YFRuPtu2L8r+9/NSwEzOAVvXivEJJYTZYM3olNaO7j+EZHy81vCFW5Wl
iwyuo5pl1ITWdam//+m6wd67legEeYJOu4Xn929YQ6AHyNVUT/T7+XxK
Cwyp+8IrLb4AhVjWFCKROwfhyIGkmv+uMPe1p3zyT7zcSFB5oYVAYoK1
hBUUEmzYDSi5DHvctA+3tFu/PzVLM3Fz88sB+gDYoMO79dCbMgXegwA7
hKuwhk9SJzu3DylNdZpy4jQOtrtNRUFrCAgBY0bCwmNdfZBe2RSZvBKF O69QUw==

;; Query time: 231 msec
;; SERVER: 192.168.1.6#53(192.168.1.6)
;; WHEN: Tue May  5 14:41:28 2009
;; MSG SIZE  rcvd: 388

Whats missing is the RA flag...




-- 
aRDy Music and Rick Dicaire present:
http://www.ardynet.com
http://www.ardynet.com:9000/ardymusic.ogg.m3u
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [DNSSEC] SERVFAIL when resolving ".gov" through DLV

[Mark Elkins]

Does work with bind 9.6.0 - as NSEC3 is available...
; <<>> DiG 9.6.0-P1 <<>> +dnssec @127.0.0.1 SOA gov.
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41388
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 8, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;gov.   IN  SOA
...
(Waiting on 9.6.1 via gentoo!)

On Tue, 2009-05-05 at 13:45 -0500, Jeremy C. Reed wrote:
> On Tue, 5 May 2009, Stephane Bortzmeyer wrote:
> 
> > This is a BIND 9.5.1-P1, Debian package. It is configured to use ISC's
> > DLV:
> 
> https://www.isc.org/node/437
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
  .  . ___. .__  Posix Systems - Sth Africa.  e.164 VOIP ready
 /| /|   / /__   m...@posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

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

host unreachable resolving

[alexus]

i just deployed new bind-9.6.0-p1

and I'm getting a lot of these:

May  5 20:18:41 dd named[21037]: host unreachable resolving
'128.235.241.88.zen.spamhaus.org/TXT/IN': 2001:7b8:3:1f:0:2:53:1#53

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

success resolving after reducing the advertised EDNS UDP packet size to 512 octets

[alexus]

the other problem im having is these:

May  5 20:44:57 dd named[21037]: success resolving
'92.68.83.189.zen.spamhaus.org/TXT' (in 'zen.spamhaus.org'?) after
reducing the advertised EDNS UDP packet size to 512 octets

i have followings in my named.conf

edns-udp-size 512;
max-udp-size 512;


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

Re: [DNSSEC] SERVFAIL when resolving ".gov" through DLV

[Stephane Bortzmeyer]

On Tue, May 05, 2009 at 01:45:40PM -0500,
 Jeremy C. Reed  wrote 
 a message of 6 lines which said:

> > This is a BIND 9.5.1-P1, Debian package. It is configured to use ISC's
> > DLV:
> 
> https://www.isc.org/node/437

I was aware of this bug, but not that it apparently has not been
addressed in Debian 

I will report it to Debian. In the mean time, users of Debian stable
version, codenamed "lenny", has no choice but to stop using DLV,
because of this bug.

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

Re: [DNSSEC] SERVFAIL when resolving ".gov" through DLV

[Benedikt Gollatz]

On Tuesday 05 May 2009, 23:06 Stephane Bortzmeyer wrote:
> On Tue, May 05, 2009 at 01:45:40PM -0500,
>  Jeremy C. Reed  wrote
> > https://www.isc.org/node/437
>
> I was aware of this bug, but not that it apparently has not been
> addressed in Debian 

It has. An updated version of bind9 is available in lenny-proposed-updates.

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

Re: host unreachable resolving

[Jeremy C. Reed]

On Tue, 5 May 2009, alexus wrote:

> i just deployed new bind-9.6.0-p1
> 
> and I'm getting a lot of these:
> 
> May  5 20:18:41 dd named[21037]: host unreachable resolving
> '128.235.241.88.zen.spamhaus.org/TXT/IN': 2001:7b8:3:1f:0:2:53:1#53

If you have IPv6 but don't use IPv6, see the named switch -4 "Use IPv4 
only even if the host machine is capable of IPv6.  -4 and -6 are mutually 
exclusive."

(I get the same types of messages on my personal NetBSD system since I 
don't have a IPv6 tunnel setup here.)

  Jeremy C. Reed
  ISC Sales & Support Engineer
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: [DNSSEC] SERVFAIL when resolving ".gov" through DLV

[Stephane Bortzmeyer]

On Tue, May 05, 2009 at 11:18:05PM +0200,
 Benedikt Gollatz  wrote 
 a message of 15 lines which said:

> It has. 

Well, most people do not track XXX-proposed-updates which is supposed
to be a bit... untested. I just had lenny and
security.debian.org/updates in my sources.list (this is Debian's
default).

> An updated version of bind9 is available in lenny-proposed-updates.

Upgraded and it solved the problem. Thanks.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: host unreachable resolving

[alexus]

On Tue, May 5, 2009 at 5:41 PM, Jeremy C. Reed  wrote:
> On Tue, 5 May 2009, alexus wrote:
>
>> i just deployed new bind-9.6.0-p1
>>
>> and I'm getting a lot of these:
>>
>> May  5 20:18:41 dd named[21037]: host unreachable resolving
>> '128.235.241.88.zen.spamhaus.org/TXT/IN': 2001:7b8:3:1f:0:2:53:1#53
>
> If you have IPv6 but don't use IPv6, see the named switch -4 "Use IPv4
> only even if the host machine is capable of IPv6.  -4 and -6 are mutually
> exclusive."
>
> (I get the same types of messages on my personal NetBSD system since I
> don't have a IPv6 tunnel setup here.)
>
>  Jeremy C. Reed
>  ISC Sales & Support Engineer
>

I see,

I do have IPv6 on my box, but I guess its not configured even though
my system aware of it, so I re-run it with -4 let's see how that works
out...

thanks
-- 
http://alexus.org/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: success resolving after reducing the advertised EDNS UDP packet size to 512 octets

[Jeremy C. Reed]

On Tue, 5 May 2009, alexus wrote:

> the other problem im having is these:
> 
> May  5 20:44:57 dd named[21037]: success resolving
> '92.68.83.189.zen.spamhaus.org/TXT' (in 'zen.spamhaus.org'?) after
> reducing the advertised EDNS UDP packet size to 512 octets
> 
> i have followings in my named.conf
> 
>   edns-udp-size 512;
>   max-udp-size 512;

I don't see the problem. (The log message above says "success" and is 
doing what you told it.)

Why do you have edns-udp-size and max-udp-size defined? Do you really need 
them?
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: success resolving after reducing the advertised EDNS UDP packet size to 512 octets

[alexus]

On Tue, May 5, 2009 at 5:56 PM, Jeremy C. Reed  wrote:
> On Tue, 5 May 2009, alexus wrote:
>
>> the other problem im having is these:
>>
>> May  5 20:44:57 dd named[21037]: success resolving
>> '92.68.83.189.zen.spamhaus.org/TXT' (in 'zen.spamhaus.org'?) after
>> reducing the advertised EDNS UDP packet size to 512 octets
>>
>> i have followings in my named.conf
>>
>>       edns-udp-size 512;
>>       max-udp-size 512;
>
> I don't see the problem. (The log message above says "success" and is
> doing what you told it.)
>
> Why do you have edns-udp-size and max-udp-size defined? Do you really need
> them?
>

i thought if i'd had these i wouldn't see these msg in the logs

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

Re: DNS Resolution Failure - FORMERR

[Kevin Darcy]

Eric Swenson wrote:
I apologize for the multiple posts. I didn't think my post was making 
it to the list since I never received my own post, but have been 
receiving those of others.  And yes, I'm configured to see my own posts.


A couple people have suggested I look at the trace output of bind to 
see what server is sending the bad response.  I provide some of the 
trace output below.  I certainly don't see anything amiss, and one of 
the servers that appears to provoke the FORMERR seems to have 
responded just fine.  Here is relevant output (with some stuff deleted 
due to verbosity):


05-May-2009 10:49:14.943 dispatch 0x8144b90 response 0x81476b8 
192.228.79.201#53: attached to task 0x80ed240
05-May-2009 10:49:14.945 resquery 0x8152c70 (fctx 
0x812f170(imap.gmail.com/A) ): sent
05-May-2009 10:49:14.945 resquery 0x8152c70 (fctx 
0x812f170(imap.gmail.com/A) ): senddone
05-May-2009 10:49:14.945 dispatch 0x8149a70: got packet: requests 0, 
buffers 2, recvs 1
05-May-2009 10:49:14.945 dispatch 0x8149a70: shutting down; detaching 
from sock 0x81418f0, task 0x8141a20
05-May-2009 10:49:14.965 socket 0x8141460 192.228.79.201#53: packet 
received correctly
05-May-2009 10:49:14.966 dispatch 0x8144b90: got packet: requests 1, 
buffers 1, recvs 1
05-May-2009 10:49:14.966 dispatch 0x8144b90: got valid DNS message 
header, /QR 1, id 47066
05-May-2009 10:49:14.966 resquery 0x8152c70 (fctx 
0x812f170(imap.gmail.com/A) ): response

05-May-2009 10:49:14.967 received packet:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  47066
;; flags: qr rd ra ; QUESTION: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
;; QUESTION SECTION:
;imap.gmail.com . IN A

;; ANSWER SECTION:
imap.gmail.com . 241 IN CNAME 
gmail-imap.l.google.com .
gmail-imap.l.google.com . 241 IN A 
209.85.201.111
gmail-imap.l.google.com . 241 IN A 
209.85.201.109


;; AUTHORITY SECTION:
gmail.com . 76384 IN NS ns4.google.com 
.
gmail.com . 76384 IN NS ns1.google.com 
.
gmail.com . 76384 IN NS ns2.google.com 
.
gmail.com . 76384 IN NS ns3.google.com 
.


;; ADDITIONAL SECTION:
ns4.google.com . 77136 IN A 216.239.38.10
ns1.google.com . 77136 IN A 216.239.32.10
ns2.google.com . 77136 IN A 216.239.34.10
ns3.google.com . 77136 IN A 216.239.36.10
This is a little suspect. Usually when you have a CNAME and A records in 
the Answer Section, the Authority Section contains NS records for the 
zone containing the A record (in this case, gmail-imap.l.google.com). 
Here, however, the Authority Section contains NS records for the zone 
containing the CNAME itself (imap.gmail.com). Odd. When I query the 
name, I get the l.google.com NS records in Authority.


I'm not sure, however, that this anomaly alone is sufficient to cause 
problems.



05-May-2009 10:49:14.967 fctx 0x812f170(imap.gmail.com/A' 
): answer_response
05-May-2009 10:49:14.968 fctx 0x812f170(imap.gmail.com/A' 
): noanswer_response
05-May-2009 10:49:14.968 fctx 0x812f170(imap.gmail.com/A' 
): cancelquery
05-May-2009 10:49:14.968 dispatch 0x8144b90 response 0x81476b8 
192.228.79.201#53: detaching from task 0x80ed240

05-May-2009 10:49:14.968 dispatch 0x8144b90: detach: refcount 0
05-May-2009 10:49:14.968 fctx 0x812f170(imap.gmail.com/A' 
): add_bad
05-May-2009 10:49:14.969 FORMERR resolving 'imap.gmail.com/A/IN 
': 192.228.79.201#53


Does this trace output suggest what is going wrong?  -- Eric

On Tue, May 5, 2009 at 9:53 AM, Eric Swenson > wrote:


I'm seeing lots of DNS resolution failures on my router (running
Utuntu 8.10, bind 9.3.4).  While most succeed, I get quite a few
FORMERR errors similar to:

May  4 20:25:25 localhost named[19579]: FORMERR resolving
'imap.gmail.com/A/IN ': 66.151.140.2#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving
'imap.gmail.com/A/IN ': 192.168.3.1#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving
'imap.gmail.com/A/IN ': 192.112.36.4#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving
'imap.gmail.com/A/IN ': 128.63.2.53#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving
'imap.gmail.com/A/IN ': 192.228.79.201#53
May  4 20:25:25 localhost named[19579]: FORMERR resolving
'imap.gmail.com/A/IN 

Re: Delegation or PEBKAC problems?

[Mark Andrews]

In message <1d8c9a4471119a40bd574f9d8d464ae304bd4...@xch60ykf.rim.net>, "Todd S
nyder" writes:
> With help of a list member, we got this figured out.
> 
> The problem is that, outside of the config I showed you, I had a
> forwarder setup.
> 
> zone "foo.example" IN {
>   type  forward;
>   forward only;
>   forwarders { x; y };
> };
> 
> My understanding of things was that BIND would answer most specifically.
> So I thought that because I was authoritative for lab.foo.example, it
> would only use the foo.example for things that didn't fall under
> lab.foo.example.  That doesn't seem to be the case.  BIND was using the
> forwarding, and not even looking at the authoritative zone.

Put a empty forwarders clause in the master/slave zone configuration.

e.g.
zone lab.foo.example {
type master;
file "";
forwarders { /* empty */ };
};
 
> >From my reading of "DNS and Bind (pg 244, 4th paragraph)", I'm wondering
> if the book or BIND are mistaken:
> 
> "If a resolver requests records that are already in the nameserver's
> authoritative data or cached adata, the nameserver answer that with the
> information, this part of its operation hasn't changed.  However, if the
> records aren't in its database, the nameserver sends the query to a
> forwarder ..."  (this relates to forward only mode)
> 
> For forward first mode, the book states (pg 245, 2nd paragraph):
> 
> "A nameserver in forward-only mode is a variation on a nameserver that
> uses forwarders.  It still answers queries from its authoritative data
> and cached data."
> 
> So, in both cases, the server should be answering authoritatively first,
> then going to the forwarders.
> 
> Having said that, I reconfigured it to use "forward first" and I'm
> getting the behaviour I was looking for - so the server seems to behave
> as I thought in "forward first" mode, but not in "forward only" mode.
> 
> Has the logic here changed, or am I misinterpreting the book?
> 
> Thanks!
> 
> Todd.
> 
> 
> 
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Todd Snyder
> Sent: Tuesday, May 05, 2009 11:59 AM
> To: bind-us...@isc.org
> Subject: RE: Delegation or PEBKAC problems?
> 
> it's been pointed out that I made a mistake cleaning up my example data
> below .. my dig should read:
> 
> [10:43:08 r...@ns01.lab.foo.example:~ ()]# dig @ns01.lab.foo.example
> record.group.lab.foo.example any
> 
> -Original Message-
> From: bind-users-boun...@lists.isc.org
> [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Todd Snyder
> Sent: Tuesday, May 05, 2009 11:08 AM
> To: bind-us...@isc.org
> Subject: Delegation or PEBKAC problems?
> 
> Good day,
> 
> (BIND 9.6.0-P1)
> 
> Although, to me, delegation seems like a fairly simple configuration, I
> seem to be having problems.  What I am trying to do is very simple - I
> have a lab, and I want to delegate part of the namespace to someone else
> in the lab.  My configuration looks like this:
> 
> (zone lab.foo.example)
> ;delegation
> group.lab.foo.example.IN  NS  group-ns01.lab.foo.example.
> group.lab.foo.example.IN  NS  group-ns02.lab.foo.example.
> 
> ; glue
> group-ns01IN  A   1.1.1.1
> group-ns02IN  A   1.1.1.2
> 
> I load the zone, it loads just fine.  I can resolve the 2 ns servers
> directly, so I know the glue is good.
> 
> However, when I dig for a record in that zone, I get
> 
> [10:43:08 r...@ns01.lab.foo.example:~ ()]# dig @ns01.lab.foo.example
> record.group.lab.foo.example any
> 
> ; <<>> DiG 9.6.0-P1 <<>> +qr @s01.lab.foo.example
> record.group.foo.example any ; (1 server found) ;; global options: +cmd
> ;; Sending:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59035 ;; flags: rd;
> QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;record.group.foo.example.IN  ANY
> ;; connection timed out; no servers could be reached
> 
> When I dig directly at the delegated nameserver, I can get the record
> just fine.
> 
> When I run tcpdump on the nameserver, I see the requests come in,
> timeout, come in, time out, come in, timeout, then the resolver gives
> up.  I don't see packets going out to the other server, nor do I see the
> server returning anything to the resolver (ie: authority records)
> 
> If I disable recursion on this view, the server, loading the same zone,
returns NS records immediately, which tells me that the server is
> loading the zone properly, and that the data is good.
> 
> My understanding of delegation is that the resolver goes out to it's
> configured nameserver.  That nameserver returns the NS records for the
> delegated namespace, then the resolver goes to the delegated server to
> ask the next question.  Am I incorrect in that?  
> 
> We've been fiddling with this for a bit now, and I can'

Re: DNS Resolution Failure - FORMERR

[Mark Andrews]

In message <4a00c706.5060...@chrysler.com>, Kevin Darcy writes:
> 
> Eric Swenson wrote:
> > I apologize for the multiple posts. I didn't think my post was making 
> > it to the list since I never received my own post, but have been 
> > receiving those of others.  And yes, I'm configured to see my own posts.
> >
> > A couple people have suggested I look at the trace output of bind to 
> > see what server is sending the bad response.  I provide some of the 
> > trace output below.  I certainly don't see anything amiss, and one of 
> > the servers that appears to provoke the FORMERR seems to have 
> > responded just fine.  Here is relevant output (with some stuff deleted 
> > due to verbosity):
> >
> > 05-May-2009 10:49:14.943 dispatch 0x8144b90 response 0x81476b8 
> > 192.228.79.201#53: attached to task 0x80ed240
> > 05-May-2009 10:49:14.945 resquery 0x8152c70 (fctx 
> > 0x812f170(imap.gmail.com/A) ): sent
> > 05-May-2009 10:49:14.945 resquery 0x8152c70 (fctx 
> > 0x812f170(imap.gmail.com/A) ): senddone
> > 05-May-2009 10:49:14.945 dispatch 0x8149a70: got packet: requests 0, 
> > buffers 2, recvs 1
> > 05-May-2009 10:49:14.945 dispatch 0x8149a70: shutting down; detaching 
> > from sock 0x81418f0, task 0x8141a20
> > 05-May-2009 10:49:14.965 socket 0x8141460 192.228.79.201#53: packet 
> > received correctly
> > 05-May-2009 10:49:14.966 dispatch 0x8144b90: got packet: requests 1, 
> > buffers 1, recvs 1
> > 05-May-2009 10:49:14.966 dispatch 0x8144b90: got valid DNS message 
> > header, /QR 1, id 47066
> > 05-May-2009 10:49:14.966 resquery 0x8152c70 (fctx 
> > 0x812f170(imap.gmail.com/A) ): response
> > 05-May-2009 10:49:14.967 received packet:
> > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  47066
> > ;; flags: qr rd ra ; QUESTION: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
> > ;; QUESTION SECTION:
> > ;imap.gmail.com . IN A
> >
> > ;; ANSWER SECTION:
> > imap.gmail.com . 241 IN CNAME 
> > gmail-imap.l.google.com .
> > gmail-imap.l.google.com . 241 IN A 
> > 209.85.201.111
> > gmail-imap.l.google.com . 241 IN A 
> > 209.85.201.109
> >
> > ;; AUTHORITY SECTION:
> > gmail.com . 76384 IN NS ns4.google.com 
> > .
> > gmail.com . 76384 IN NS ns1.google.com 
> > .
> > gmail.com . 76384 IN NS ns2.google.com 
> > .
> > gmail.com . 76384 IN NS ns3.google.com 
> > .
> >
> > ;; ADDITIONAL SECTION:
> > ns4.google.com . 77136 IN A 216.239.38.10
> > ns1.google.com . 77136 IN A 216.239.32.10
> > ns2.google.com . 77136 IN A 216.239.34.10
> > ns3.google.com . 77136 IN A 216.239.36.10
> This is a little suspect. Usually when you have a CNAME and A records in 
> the Answer Section, the Authority Section contains NS records for the 
> zone containing the A record (in this case, gmail-imap.l.google.com). 
> Here, however, the Authority Section contains NS records for the zone 
> containing the CNAME itself (imap.gmail.com). Odd. When I query the 
> name, I get the l.google.com NS records in Authority.

An iterative resolver will not work well with a "transparent"
dns cache.  The answer above nominally came from 192.228.79.201
(b.root-servers.net).  It should have been something like this.

bsdi# dig gmail-imap.l.google.com +norec @192.228.79.201

; <<>> DiG 8.3 <<>> gmail-imap.l.google.com +norec @192.228.79.201 
; (1 server found)
;; res options: init defnam dnsrch no-tld-query edns0
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44866
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 16
;; QUERY SECTION:
;;  gmail-imap.l.google.com, type = A, class = IN

;; AUTHORITY SECTION:
com.2D IN NSK.GTLD-SERVERS.NET.
com.2D IN NSL.GTLD-SERVERS.NET.
com.2D IN NSM.GTLD-SERVERS.NET.
com.2D IN NSA.GTLD-SERVERS.NET.
com.2D IN NSB.GTLD-SERVERS.NET.
com.2D IN NSC.GTLD-SERVERS.NET.
com.2D IN NSD.GTLD-SERVERS.NET.
com.2D IN NSE.GTLD-SERVERS.NET.
com.2D IN NSF.GTLD-SERVERS.NET.
com.2D IN NSG.GTLD-SERVERS.NET.
com.2D IN NSH.GTLD-SERVERS.NET.
com.2D IN NSI.GTLD-SERVERS.NET.
com.2D IN NSJ.GTLD-SERVERS.NET.

;; ADDITIONAL SECTION:
A.GTLD-SERVERS.NET. 2D IN A 192.5.6.30
B.GTLD-SERVERS.NET. 2D IN A 192.33.14.30
C.GTLD-SERVERS.NET.   

Re: tcp versus udp

[Danny Mayer]

Peter Dambier wrote:
> Hello Martin,
> 
> since a major outage at my provider, dtag.de or Deutsche Telecom AG, I have 
> trouble
> with f.root-servers.net. Sometimes "dig ... +vc" does help me to see 
> f.root-servers.net.
> 
> The real problem is anycast. With udp it behaves different than with tcp.

That's nonsense. anycast is invisible to this. anycast doesn't care if
it's udp or tcp, it only deals with the routing tables to determine
where to send the request packet.

> 
> When querying servers that are difficult to reach, sometimes you are more 
> lucky with
> tcp than with udp.

Only if they are misconfigured.

> 
> Amplification attacks using nameservers don't work with tcp.
> 
> Sometimes bugs in resolvers sometimes in clients cause failover to tcp.
> 
> With DNSSEC tcp is almost a must. Same with IPv6.
> 

This is also untrue. DNSSEC has EDNS0 as a prerequisite and IPv6 fits
into any EDNS0 packet unless there's too much for even for the larger
EDNS0 packets. TCP is only required if the answer doesn't fit in the
packet. There are lots of firewalls, etc. that do not handle EDNS0 but
that is a different question.

Danny


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

Re: DNS Resolution Failure - FORMERR

[Eric Swenson]

I suspect my problem has to do with the fact that imap.gmail.com is a CNAME
for gmail-imap.l.google.com. When queries fail (with the FORMERRs), the
responses I see coming back to my DNS server include a CNAME record and two
A records.  When I do the little hack with a manual query, which makes the
server respond successfully for a while, I note that I get a CNAME record
with only one A record back from one ISP DNS servers I forward to.
Also, if I change my iphone/thunderbird applications to use
gmail-imap.l.google.com rather than imap.gmail.com, everything works fine
(no FORMERRs or resolution failures).

Does this ring any bells?

On Tue, May 5, 2009 at 9:11 PM, Eric Swenson  wrote:

> I renamed the forwarders and added a "forward only;" option, and now, while
> I still can't resolve imap.gmail.com, I now simply get FORMERRs for the
> two forwarded DNS servers:
> May  5 21:05:10 localhost named[12188]: FORMERR resolving '
> imap.gmail.com/A/IN': 66.151.140.2#53
> May  5 21:05:10 localhost named[12188]: FORMERR resolving '
> imap.gmail.com/A/IN': 192.168.3.1#53
>
> Since if I use "dig" or "nslookup" against these two servers directly,
> (from my router machine) the queries come back fine, what does this mean?  I
> wouldn't think my firewall is to be suspected of causing this since I can
> issue these requests and get valid answers back, and that traffic would go
> through the firewall in the same way as requests going through my DNS
> server, right?
>
> -- Eric
>
> On Tue, May 5, 2009 at 4:08 PM, Kevin Darcy  wrote:
>
>>
>> Eric Swenson wrote:
>>
>>> I apologize for the multiple posts. I didn't think my post was making it
>>> to the list since I never received my own post, but have been receiving
>>> those of others.  And yes, I'm configured to see my own posts.
>>>
>>> A couple people have suggested I look at the trace output of bind to see
>>> what server is sending the bad response.  I provide some of the trace output
>>> below.  I certainly don't see anything amiss, and one of the servers that
>>> appears to provoke the FORMERR seems to have responded just fine.  Here is
>>> relevant output (with some stuff deleted due to verbosity):
>>>
>>> 05-May-2009 10:49:14.943 dispatch 0x8144b90 response 0x81476b8
>>> 192.228.79.201#53: attached to task 0x80ed240
>>> 05-May-2009 10:49:14.945 resquery 0x8152c70 (fctx 0x812f170(
>>> imap.gmail.com/A) ): sent
>>> 05-May-2009 10:49:14.945 resquery 0x8152c70 (fctx 0x812f170(
>>> imap.gmail.com/A) ): senddone
>>> 05-May-2009 10:49:14.945 dispatch 0x8149a70: got packet: requests 0,
>>> buffers 2, recvs 1
>>> 05-May-2009 10:49:14.945 dispatch 0x8149a70: shutting down; detaching
>>> from sock 0x81418f0, task 0x8141a20
>>> 05-May-2009 10:49:14.965 socket 0x8141460 192.228.79.201#53: packet
>>> received correctly
>>> 05-May-2009 10:49:14.966 dispatch 0x8144b90: got packet: requests 1,
>>> buffers 1, recvs 1
>>> 05-May-2009 10:49:14.966 dispatch 0x8144b90: got valid DNS message
>>> header, /QR 1, id 47066
>>> 05-May-2009 10:49:14.966 resquery 0x8152c70 (fctx 0x812f170(
>>> imap.gmail.com/A) ): response
>>> 05-May-2009 10:49:14.967 received packet:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:  47066
>>> ;; flags: qr rd ra ; QUESTION: 1, ANSWER: 3, AUTHORITY: 4, ADDITIONAL: 4
>>> ;; QUESTION SECTION:
>>> ;imap.gmail.com . IN A
>>>
>>> ;; ANSWER SECTION:
>>> imap.gmail.com . 241 IN CNAME
>>> gmail-imap.l.google.com .
>>> gmail-imap.l.google.com . 241 IN A
>>> 209.85.201.111
>>> gmail-imap.l.google.com . 241 IN A
>>> 209.85.201.109
>>>
>>> ;; AUTHORITY SECTION:
>>> gmail.com . 76384 IN NS ns4.google.com <
>>> http://ns4.google.com>.
>>> gmail.com . 76384 IN NS ns1.google.com <
>>> http://ns1.google.com>.
>>> gmail.com . 76384 IN NS ns2.google.com <
>>> http://ns2.google.com>.
>>> gmail.com . 76384 IN NS ns3.google.com <
>>> http://ns3.google.com>.
>>>
>>> ;; ADDITIONAL SECTION:
>>> ns4.google.com . 77136 IN A 216.239.38.10
>>> ns1.google.com . 77136 IN A 216.239.32.10
>>> ns2.google.com . 77136 IN A 216.239.34.10
>>> ns3.google.com . 77136 IN A 216.239.36.10
>>>
>> This is a little suspect. Usually when you have a CNAME and A records in
>> the Answer Section, the Authority Section contains NS records for the zone
>> containing the A record (in this case, gmail-imap.l.google.com). Here,
>> however, the Authority Section contains NS records for the zone containing
>> the CNAME itself (imap.gmail.com). Odd. When I query the name, I get the
>> l.google.com NS records in Authority.
>>
>> I'm not sure, however, that this anomaly alone is sufficient to cause
>> problems.
>>
>>>
>>>
>>> 05-May

Re: tcp versus udp

[Stephane Bortzmeyer]

On Wed, May 06, 2009 at 12:00:12AM -0400,
 Danny Mayer  wrote 
 a message of 39 lines which said:

> That's nonsense.

That's Peter Dambier. If you try to fix every mistake he makes, you're
not over soon...

http://xkcd.com/386/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: tcp versus udp

[Mark Elkins]

On Wed, 2009-05-06 at 07:59 +0200, Stephane Bortzmeyer wrote:
> On Wed, May 06, 2009 at 12:00:12AM -0400,
>  Danny Mayer  wrote 
>  a message of 39 lines which said:
> 
> > That's nonsense.
> 
> That's Peter Dambier. If you try to fix every mistake he makes, you're
> not over soon...

Some people are there to make us question and test our understanding.

One place that TCP may make sense - if you are involved in a registry
system and the process involves actually checking the information that
you are given, including nameservers (do they exist, do they serve that
zone - correctly?) - it may make a lot of sense to do TCP Digs for the
information (though that should probably be after a failed UDP dig - as
a number of people do insist on disallowing Port 53 TCP).
-- 
  .  . ___. .__  Posix Systems - Sth Africa.  e.164 VOIP ready
 /| /|   / /__   m...@posix.co.za  -  Mark J Elkins, Cisco CCIE
/ |/ |ARK \_/ /__ LKINS  Tel: +27 12 807 0590  Cell: +27 82 601 0496

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