Re: query about EDNS UDP Packet

[Gaurav Kansal]

Hi Team,

Thanks for help.
My Firewall was dropping packet size larger than 512 bytes.
Cisco 5580 having ASA 8.3. It is by default blocking my EDNS0 Packet.


Thanks and Regards,
Gaurav Kansal


On 12/31/12, Sten Carlsen   wrote:
> 
>   
> 
> 
>  With the replies you have shown, the limitation is very likely within your 
> own walls.
>  
>  While it is possible that some router on the path between you and the test 
> server limits the packet size, I would say it is very likely not the case, 
> much less than 1% propability - according to my experience.
>  
>  I would use a sniffer along the path between each switch/router/firewall/xx 
> until you either don't see the longer edns0 packets or some other evidence 
> (could be some ICMP message) shows you that this is the place.
>  
>  I would also search for keywords like: DNS EDNS0 truncate.
>  
>  Good hunting.
>  
> 
>  On 31/12/12 15:07, Phil Mayers wrote:
>  
>  
> > On 12/31/2012 10:54 AM, Gaurav Kansal wrote: 
> >  
> > > I just want to test whether this limit is within my organization. 
> > >  
> > >  Is any method available by which I can check this? 
> > >  
> > >  
> >  
> >  
> >  https://www.dns-oarc.net/oarc/services/replysizetest 
> >  
> >  
> >  ___ 
> >  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 
> >  
>  
>  
> -- Best regards Sten Carlsen No improvements come from shouting: "MALE BOVINE 
> MANURE!!!" 
> 
>  
> 
> 
--
Thanks n Regards, 
GAURAV KANSAL 
9910118448 
Operation And Routing Unit 
NIC , NEW DELHI 

Happy New Year 2013.

Please don't print this e-mail until & unless you really need, it will save 
Trees on Planet Earth. 
IPv4 is Over,
Are your ready for new Network.
___
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: gitnamed, a project to manage name server by git

[Vernon Schryver]

> When I built my DNS zone creator, I got tired of users complaining that 
> their zones has "errors" and so I re-coded my serials to start with  
> followed by six digits based on the current date/time.
>
> Oddly, that seems to fool most (although not all) of the DNS validation 
> tools out there, despite the fact that I generate things like 2012804572 
> which doesn't exactly have a "valid" MM or dd.

For many years I've found serial number checks good indications of
whether a DNS validation tool's report will be a bad joke.  If it
checks the serial number format, then that's often the least harmful
among the FUD that it's selling.

I just tried some DNS "validation" tools, and revalidated that rule
and another.  The other rule is that if they sell DNS and other
monitoring services, then they will flash red and yellow about your
serial numbers, your MX servers, and a host of other non-issues that
you almost certainly should not "fix."

Even if RFC 1912 were not Informational, it would still only recommend
and not mandate MMDDnn.  Even if RFC 1912 were on the standards
track and said "MUST", it would be violated in zones that change more
than 100 times per day.  How long has BIND9 had "serial-update-method"?


> I've given up contacting so-called validation tools and asking them to 
> remove warnings about valid serials, they seem happier reporting 
> non-errors, and at best they'll return a "Not standard, but I guess it's 
> okay". It's a shame too, as these tools can provide a sanity check.

What good are sanity checks from the certifiable or worse?  Do you
take medical advice (or any advice) from those who claim that DPT
vaccines cause autism?
https://encrypted.google.com/search?q=whooping+cough+worst+1955 

It's sad but predictable that DNS validation/monitoring services are
like some auto repair shops.  Last week my wife took her car to the
dealer for a minor recall.  She came back with a long list of expensive
things that she should have had fixed before leaving the dealer--provided
you're car clue allergic, credulous, and don't have anyone to shout
"NO!" when asked.  On the other hand, the dealer's careful inspection
failed to note the idiot light warning about a low tire.
(cue discussion with wife 2 mornings later when I noticed the flat
tire about the "flame (sic)" idiot light that she'd been watching since
before the trip to the dealer and that obviously didn't matter because
high temperatures can only be a good thing given the weather.)


Vernon Schryverv...@rhyolite.com
___
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: gitnamed, a project to manage name server by git

[Dave Warren]

On 1/8/2013 13:48, Mike Hoskins (michoski) wrote:

Thanks for sharing both.

Like the built-in sanity checks...Wonder why the fedora folks don't
automate the serial number update, since in my experience that seems to be
one of the top silly mistakes with BIND updates?

Our push process sets that to the mtime of the zone for non-dynamic zones,
which seems to work well except for the occasional DNS validation tool
baulking that we're not using MMDDNN format.  :-)


When I built my DNS zone creator, I got tired of users complaining that 
their zones has "errors" and so I re-coded my serials to start with  
followed by six digits based on the current date/time.


Oddly, that seems to fool most (although not all) of the DNS validation 
tools out there, despite the fact that I generate things like 2012804572 
which doesn't exactly have a "valid" MM or dd.


I've given up contacting so-called validation tools and asking them to 
remove warnings about valid serials, they seem happier reporting 
non-errors, and at best they'll return a "Not standard, but I guess it's 
okay". It's a shame too, as these tools can provide a sanity check.


--
Dave Warren
http://www.hireahit.com/
http://ca.linkedin.com/in/davejwarren

___
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: gitnamed, a project to manage name server by git

[Mike Hoskins (michoski)]

-Original Message-

From: Jan-Piet Mens 
Date: Tuesday, January 8, 2013 4:35 PM
To: "bind-users@lists.isc.org" 
Subject: Re: gitnamed, a project to manage name server by git

>> GitNamed is a project that manage name server by git. you can clone
>> the git repo to any workstation, edit zone file, commit and push it.
>> the data will push to the master and slave name server on the fly.
>
>Very interesting; thanks for sharing.
>
>I hear the Fedora Project does something along similar lines. Code &
>'docs' are at [1].
>
>-JP
>
>[1] http://infrastructure.fedoraproject.org/infra/dns/README

Thanks for sharing both.

Like the built-in sanity checks...Wonder why the fedora folks don't
automate the serial number update, since in my experience that seems to be
one of the top silly mistakes with BIND updates?

Our push process sets that to the mtime of the zone for non-dynamic zones,
which seems to work well except for the occasional DNS validation tool
baulking that we're not using MMDDNN format.  :-)

___
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: gitnamed, a project to manage name server by git

[Jan-Piet Mens]

> GitNamed is a project that manage name server by git. you can clone
> the git repo to any workstation, edit zone file, commit and push it.
> the data will push to the master and slave name server on the fly.

Very interesting; thanks for sharing.

I hear the Fedora Project does something along similar lines. Code &
'docs' are at [1].

-JP

[1] http://infrastructure.fedoraproject.org/infra/dns/README
___
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: Transfers-out

[Chris Buxton]

On Jan 8, 2013, at 1:24 PM, Manson, John wrote:

> Can this option be used in a ‘slave’ config to prevent out-bound transfers?
> Transfers-out 0;
> The 9.9.2 ARM is ambiguous.

Wouldn't it be simpler to just write this instead, in your options statement?

allow-transfer { none; };

Chris Buxton
BlueCat Networks


___
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

Transfers-out

[Manson, John]

Can this option be used in a 'slave' config to prevent out-bound transfers?
Transfers-out 0;
The 9.9.2 ARM is ambiguous.
Thanks


John Manson
CAO/HIR/NAF Data-Communications | U.S. House of Representatives | Washington, 
DC 20515
Desk: 202-226-4244 | TCC: 202-226-6430 | 
john.man...@mail.house.gov

___
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: lame-servers: error (FORMERR) resolving [something]

[Matus UHLAR - fantomas]

> Sometimes I can't resolve some addresses and, in the logs, I can find
> the message in the title:
>lame-servers: error (FORMERR) resolving [something]
> (where `something` is the address I'm trying to resolve).
>
> What does it means?



2013/1/8 Shane Kerr 

When acting as a recursive resolver, BIND 9 follows the chain of
delegation from the root, contacting name servers identified for each
domain on the way.

In this case, one of those name servers returned a packet that BIND 9
did not like for some reason - a FORMat ERRor. The offending server is
marked as "lame" since it cannot answer queries for the domain in
question.

The message should also include the IP address of the server that it is
going to at the end of the line.


On 08.01.13 13:05, Daniele wrote:

So it's not my responsibility to resolve the problem, right?

The point is that, sometimes, I can't resolve an address because of this
lame servers, and dig (for example) fails.

Is it possible?


possible, yes. but I would not be sure, since there are many different
reasons for the lookups to fail.

and there are few web services that check proper DNS functionality. I advise
check with more of them, since there's none I would completely trust.


--
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Spam = (S)tupid (P)eople's (A)dvertising (M)ethod
___
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

gitnamed, a project to manage name server by git

[彭勇]

https://github.com/pubyun/gitnamed

GitNamed

GitNamed is a project that manage name server by git. you can clone
the git repo to any workstation, edit zone file, commit and push it.
the data will push to the master and slave name server on the fly.

you don't need to touch name server any more, you have all your data
in git repo with a history of your zone file.

if you need add a new zone, just create a new file in zones directory,
zone file name should be the domain name:

vi zones/example.com
git add zones/example.com
git commit -m "add example.com"
here is a example zone file:

$TTL 3600
@   IN  SOA ns1.example.com. sysadm.example.com. (
2012040812  ; serial
7200; refresh
1800; retry
1209600 ; expire
300 )   ; minimum
IN  NS  ns1.example.com.
IN  NS  ns2.example.com.
IN  A   61.160.235.206
$ORIGIN example.com.
ns1 172800IN  A   61.160.235.206
ns2 172800IN  A   61.160.235.203
www IN  A   61.160.235.206
testIN  A   61.160.235.200
*   IN  CNAME   example.com.
any one having the access right of git repo can manage the name
server now.

it's tested on CentOS 6.2 and Debian 6.0.

If you find any problems, please contact me:

email: p...@pubyun.com
weibo: http://weibo.com/refactor
blog: http://www.pubyun.com/blog
github: https://github.com/pubyun/gitnamed

Install Guide
enviroment

install bind on master and slave dns server
CentOS:
#yum -y install bind
Debian:
#aptitude -y install bind9
Setup master DNS server

get source code
#git clone git://github.com/pubyun/gitnamed.git /home/named
#cd /home/named
modify IP of domain name server in config file:
#vi script/settings.py
modify trusted IP of your domain name server
you should include ip of all your slave dns servers in the trusted ip
block, so they can transfer data from master dns server

#vi named.conf
acl trusted {
127.0.0.1/32;
192.168.0.0/16;
172.16.0.0/16;
61.160.235.0/24;
};
runing setup file:
#./script/setup.py
start named
#service named start
setup a private git Repo

I recommend gitolite:
https://github.com/sitaramc/gitolite

add a repo to it, here is part of conf/gitolite.conf:
repogitnamed
RW =   refactor
R  =   gitnamed
NOTE:

please use the private key just generated in .ssh/id_rsa.pub for
gitolite private key.

your private repo url is something like:

ssh://g...@git.pubyun.org/gitnamed.git
push code to your private repo:
#su - named
$git remote add hub ssh://g...@git.pubyun.org/gitnamed.git
$git push hub master
now you can test git pull:

#su - named
$git pull hub master
Already up-to-date.
Setup slave DNS server

copy code
use a tool like rsync to copy /home/named/ to slave dns server, it
must be same directory as master dns.

runing setup file:
#./script/setup.py slave
start named
#service named start
enable sync master to slave

setup authorized_keys on all your slave dns
#su - named
$vi .ssh/authorized_keys

# enable push from master name server
from="61.160.235.206",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty
ssh-rsa 
B3NzaC1yc2EBIwAAAQEApclazU9YfjfahDYT2692PSWYvjTOoFMTfgyTRpN/c/bq+GNPrC9hBunpVrhHyQ439t3Zj4VIEweY4AOTRstf94+IRp7BvYC8etb4x+M7oPbsa0JQGnfFIYrzpo7e2+t3+i1VfRgO4OtqrQTwuB45a+8zL8uHV6rK1vbDNUKdfiO7NRmCQoelhWgREUJkhYn00NCQyUUhcBB+MtP4mk4vHHKT2ZdAU/DeNL5cKbet90t871enIrfOMxkIRiCRA5SLJVQp9vWlmfo2Da79DVjWohKIrngF6ydJ7zJd3Izw0bVt7ZoawvTfQhuIPdAd6bJ95kOYzoJbFjin0wY8ZF6Qkw==
run syndns.py script on master dns server to test

#su - named
$ /home/named/script/syndns.py
Already up-to-date.
server reload successful
reloading 61.160.235.203
named.conf.slave

 100%  150 0.2KB/s   00:00
server reload successful
enable push from git to master

setup authorized_keys on all master dns
#su - named
$vi .ssh/authorized_keys
# enable push from git server
from="61.160.235.208",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/home/named/script/syndns.py"
 ssh-rsa 
B3NzaC1yc2EBIwAAAQEApclazU9YfjfahDYT2692PSWYvjTOoFMTfgyTRpN/c/bq+GNPrC9hBunpVrhHyQ439t3Zj4VIEweY4AOTRstf94+IRp7BvYC8etb4x+M7oPbsa0JQGnfFIYrzpo7e2+t3+i1VfRgO4OtqrQTwuB45a+8zL8uHV6rK1vbDNUKdfiO7NRmCQoelhWgREUJkhYn00NCQyUUhcBB+MtP4mk4vHHKT2ZdAU/DeNL5cKbet90t871enIrfOMxkIRiCRA5SLJVQp9vWlmfo2Da79DVjWohKIrngF6ydJ7zJd3Izw0bVt7ZoawvTfQhuIPdAd6bJ95kOYzoJbFjin0wY8ZF6Qkw==
test pushing data to master:
on git server, you can trigger the script on master dns server:

$/usr/bin/ssh -i /home/git/.ssh/gitnamed na...@ns1.pubyun.org sleep 1
Already up-to-date.
server reload successful
server reload successful
add script to hooks:

$vi  ~git/repositories/gitnamed.git/hooks/post-receive
/usr/bin/ssh -i /home/git/.ssh/gitnamed na...@ns1.pubyun.org sleep 1
add pre-commit hook to check zone file

ln -s ../../script/check.sh .git/hooks/pre-commit

it works now

you can clone the git repo to any workstation, edit zone file, commit
and push it.
the data will push t

Re: Name resolution fails if not forwarding

[Kevin Darcy]

On 1/8/2013 9:35 AM, Daniele wrote:
If I use BIND9 forwarding all the queries not belonging to my local 
zones, it works.


But if I don't forward those queries, `dig` sometimes (and this is 
weird) fails (with "connection timed out; no servers could be 
reached") and the logs are full of "lame server", "FORMERR".


Why?
My guess is that your nameserver is having so much trouble resolving 
Internet names that it's thrashing and this is causing intermittent 
slowdowns/failures resolving even names from local zones.


You might be able to confirm or deny this speculation by looking at how 
many concurrent recursive clients you have (e.g. through rndc).


If confirmed, this leads to the bigger question of why you're having 
trouble resolving Internet names. "Lame server" is almost certainly a 
problem with the remote nameserver and/or the delegation to that 
nameserver, rather than your nameserver or anything in between. FORMERR, 
on the other hand, might be caused if some intermediate device is 
mangling your packets. Personally, I'd do a packet capture at various 
points in the path and analyze the results. Improper handling of EDNS0 
frequently leads to these types of symptoms.


- Kevin

___
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: Name resolution fails if not forwarding

[Ben Croswell]

My first thought would be lack of firewall rules and connectivity to the
Internet.
On Jan 8, 2013 9:35 AM, "Daniele"  wrote:

> If I use BIND9 forwarding all the queries not belonging to my local zones,
> it works.
>
> But if I don't forward those queries, `dig` sometimes (and this is weird)
> fails (with "connection timed out; no servers could be reached") and the
> logs are full of "lame server", "FORMERR".
>
> 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
>
___
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

Name resolution fails if not forwarding

[Daniele]

If I use BIND9 forwarding all the queries not belonging to my local zones,
it works.

But if I don't forward those queries, `dig` sometimes (and this is weird)
fails (with "connection timed out; no servers could be reached") and the
logs are full of "lame server", "FORMERR".

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: Logging

[Timothe Litt]

You might as well solve world poverty and cure cancer while you're at it. :-)

Maybe tomorrow.

How do you notify someone -- good luck getting valid contact data for the 
domain holder
As I suggested - if we put data into a database/trouble list, shame 
should work.  Or their customers will find it and complain.   And in 
that scenario, the database has to be accessible - not the faulty 
server/domain.


 If we log back to their servers (IP address is known, since we traced 
the delegation and  got a lame reply), there some chance it will be seen.

hat their DNS is bust if you can't get to their web site or send them email?
I didn't say it was perfect.  But these days, the admin e-mail is as 
often as not in another domain - I recommend this.  And in theory there 
are supposed to be phone/fax/even snail-mail contact info in Whois - 
though that is controversial these days.  And, frequently the issue is 
that one nameserver is lame, but another is not.  So the admin thinks 
her domain is up, and clients just get slow/broken responses a fraction 
of the time.  So e-mail may go thru.


In any case, *attempting* to record the data where it might be acted 
upon seems like it would be a step up from the current situation.  
Today, the lame server logging delivers data to the source about 0% of 
the time.   If my suggestion increases that to any non-zero number, it 
would be an improvement.


Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.

On 08-Jan-13 08:44, Jim Reid wrote:

On 8 Jan 2013, at 13:19, Timothe Litt  wrote:


What I think would be more useful is if named actually reported the issues to 
where they'd do some good.

You might as well solve world poverty and cure cancer while you're at it. :-)

I think you may well have not thought this out. How do you notify someone -- 
good luck getting valid contact data for the domain holder -- that their DNS is 
bust if you can't get to their web site or send them email?

FYI, I had to contact all ICANN-accredited registrars last year. Around 15% of 
the email addresses they'd supplied to ICANN when they got accredited didn't 
work. A few of those registrars had no working email servers or DNS server at 
all. If that's what happens with people who are supposedly DNS-clueful, imagine 
what it must be like for the general public.







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

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

Re: Logging

[WBrown]

Timothe Litt  wrote on 01/08/2013 08:19:56 AM:

> What I think would be more useful is if named actually reported the 
> issues to where they'd do some good.  Perhaps a DNS extension "I got an 
> invalid message from you" - so it shows up in the log of the server (and 

> administrator) with the problem.  (I'd worry about denial of service, 
> though if the server is in fact lame, it's not providing service - at 
> least to that zone .  Abuse of the reporting mechanism is the main risk, 

> and avoiding it would take some careful engineering.)

My sense of most lame servers is they served entities that had disappeared 
from the face of the earth, taking most of their online presence with 
them.  The only thing left was their domain registration and the NS 
records in the parent domain, probably due to multi-year registrations 
that had not yet expired.  Or they could have been spam related domains 
that were no longer being used.

Reporting such domains would simply be noise. 

If there is truly is a domain having technical difficulties with name 
resolution, I suspect that they would find out about it soon enough 
because no one would be able to connect to them:

-  No email
-  outgoing email might be rejected depending on receiver's 
  filtering policies
-  No web presence
-  Failure of other systems relying on DNS

Wouldn't dig +trace reveal the lame server with the BAD REFERRAL error?

>From lame.log:

08-Jan-2013 08:52:37.747 lame server resolving 
'mail.desktoptrainingacademy.com' (in 'desktoptrainingacademy.com'?): 
208.89.21.65#53


And "dig +trace desktoptrainingacademy.com" returns 

; <<>> DiG 9.4.2-P2.1 <<>> +trace desktoptrainingacademy.com
;; global options:  printcmd
.   452564  IN  NS  g.root-servers.net.
.   452564  IN  NS  h.root-servers.net.
.   452564  IN  NS  l.root-servers.net.
.   452564  IN  NS  e.root-servers.net.
.   452564  IN  NS  a.root-servers.net.
.   452564  IN  NS  m.root-servers.net.
.   452564  IN  NS  i.root-servers.net.
.   452564  IN  NS  b.root-servers.net.
.   452564  IN  NS  c.root-servers.net.
.   452564  IN  NS  k.root-servers.net.
.   452564  IN  NS  j.root-servers.net.
.   452564  IN  NS  d.root-servers.net.
.   452564  IN  NS  f.root-servers.net.
;; Received 508 bytes from 168.169.12.2#53(168.169.12.2) in 0 ms

com.172800  IN  NS  j.gtld-servers.net.
com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  a.gtld-servers.net.
;; Received 504 bytes from 202.12.27.33#53(m.root-servers.net) in 188 ms

desktoptrainingacademy.com. 172800 IN   NS  ns2.evolveip.net.
desktoptrainingacademy.com. 172800 IN   NS  ns1.pbp.com.
;; Received 128 bytes from 192.12.94.30#53(e.gtld-servers.net) in 94 ms

desktoptrainingacademy.com. 3600 IN A   216.4.210.253
;; Received 60 bytes from 208.89.23.71#53(ns1.pbp.com) in 12 ms

root@ns5:/etc/bind# dig +trace mail.desktoptrainingacademy.com

; <<>> DiG 9.4.2-P2.1 <<>> +trace mail.desktoptrainingacademy.com
;; global options:  printcmd
.   452533  IN  NS  e.root-servers.net.
.   452533  IN  NS  j.root-servers.net.
.   452533  IN  NS  a.root-servers.net.
.   452533  IN  NS  d.root-servers.net.
.   452533  IN  NS  m.root-servers.net.
.   452533  IN  NS  c.root-servers.net.
.   452533  IN  NS  h.root-servers.net.
.   452533  IN  NS  k.root-servers.net.
.   452533  IN  NS  b.root-servers.net.
.   452533  IN  NS  l.root-servers.net.
.   452533  IN  NS  g.root-servers.net.
.   452533  IN  NS  i.root-servers.net.
.   452533  IN  NS  f.root-servers.net.
;; Rec

Re: Logging

[Sten Carlsen]

On 08/01/13 14:19, Timothe Litt wrote:
>> 1. Should ISC change the default logging for lame servers to disabled?
>
> Well, since you asked:  the lame server logging goes back to when the
> internet was a small, collegial place and one wrote a quick note to a
> friend to fix these issues.  And people who accidentally had a lame
> server were embarrassed.  Those days, sadly, are gone.
>
> The current logging only tells the victim why a query failed; it's
> pretty much useless unless troubleshooting a persistent, impactful
> problem.  And at that point, it's easy enough to turn on for the
> duration. So I'd vote for disabled - and the ability to enable for
> resolution of queries to specific domains/nameservers via rndc for
> troubleshooting.
>
> What I think would be more useful is if named actually reported the
> issues to where they'd do some good.  Perhaps a DNS extension "I got
> an invalid message from you" - so it shows up in the log of the server
> (and administrator) with the problem.  (I'd worry about denial of
> service, though if the server is in fact lame, it's not providing
> service - at least to that zone .  Abuse of the reporting mechanism is
> the main risk, and avoiding it would take some careful engineering.)
If you have a lame server my guess is that the logs of that server are
never looked at, rather the server is neglected completely, forgotten.
The place to talk to is the next level up, they should probably stop
referring to the lame server and might be the people caring about
whether their web site is reachable.
It has been seen a number of times that, say 5 servers have been
delegated to and only 3 of those actually answer, the other 2 were there
for "historical reasons" (nobody knew why, so better not change).
>
> Or, perhaps logged to a 'troubled' list of nameservers like the email
> RBL blacklists.  People don't like being on 'bad citizen' lists, so if
> that list sent the whois registered technical contact for the domain
> an e-mail once a week in addition to making the list public... maybe
> some shame would work.   But it's probably a dream. And there'd be a
> lot of fingers pointed at client firewalls...
>
> Since choice 2 is out-of-band, it would be a lot easier to put in
> place - if someone (ISC?) volunteered to host the list...
>
> In general, logging is most useful when the data goes to someone who
> can do something about it.  Logging at the victim is useful for
> isolating a problem - but if no-one is actually troubleshooting (and
> won't), it's largely wasted.
>
> DNSSEC is another area where issues need to be forwarded to the
> source, not the victim.
>
> That's my 3 cents.
Up to a Dime.
>
>
>
> ___
> 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

-- 
Best regards

Sten Carlsen

No improvements come from shouting:
   "MALE BOVINE MANURE!!!"

___
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

Logging

[Timothe Litt]

1. Should ISC change the default logging for lame servers to disabled?


Well, since you asked:  the lame server logging goes back to when the 
internet was a small, collegial place and one wrote a quick note to a 
friend to fix these issues.  And people who accidentally had a lame 
server were embarrassed.  Those days, sadly, are gone.


The current logging only tells the victim why a query failed; it's 
pretty much useless unless troubleshooting a persistent, impactful 
problem.  And at that point, it's easy enough to turn on for the 
duration. So I'd vote for disabled - and the ability to enable for 
resolution of queries to specific domains/nameservers via rndc for 
troubleshooting.


What I think would be more useful is if named actually reported the 
issues to where they'd do some good.  Perhaps a DNS extension "I got an 
invalid message from you" - so it shows up in the log of the server (and 
administrator) with the problem.  (I'd worry about denial of service, 
though if the server is in fact lame, it's not providing service - at 
least to that zone .  Abuse of the reporting mechanism is the main risk, 
and avoiding it would take some careful engineering.)


Or, perhaps logged to a 'troubled' list of nameservers like the email 
RBL blacklists.  People don't like being on 'bad citizen' lists, so if 
that list sent the whois registered technical contact for the domain an 
e-mail once a week in addition to making the list public... maybe some 
shame would work.   But it's probably a dream. And there'd be a lot of 
fingers pointed at client firewalls...


Since choice 2 is out-of-band, it would be a lot easier to put in place 
- if someone (ISC?) volunteered to host the list...


In general, logging is most useful when the data goes to someone who can 
do something about it.  Logging at the victim is useful for isolating a 
problem - but if no-one is actually troubleshooting (and won't), it's 
largely wasted.


DNSSEC is another area where issues need to be forwarded to the source, 
not the victim.


That's my 3 cents.

--
Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed.




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

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

Re: lame-servers: error (FORMERR) resolving [something]

[Daniele]

Thank you.

So it's not my responsibility to resolve the problem, right?

The point is that, sometimes, I can't resolve an address because of this
lame servers, and dig (for example) fails.

Is it possible?


2013/1/8 Shane Kerr 

> Daniele,
>
> On Tuesday, 2013-01-08 09:49:57 +0100,
> Daniele  wrote:
> > Hi all.
> >
> > Sometimes I can't resolve some addresses and, in the logs, I can find
> > the message in the title:
> >lame-servers: error (FORMERR) resolving [something]
> > (where `something` is the address I'm trying to resolve).
> >
> > What does it means?
>
> When acting as a recursive resolver, BIND 9 follows the chain of
> delegation from the root, contacting name servers identified for each
> domain on the way.
>
> In this case, one of those name servers returned a packet that BIND 9
> did not like for some reason - a FORMat ERRor. The offending server is
> marked as "lame" since it cannot answer queries for the domain in
> question.
>
> The message should also include the IP address of the server that it is
> going to at the end of the line.
>
> > And how can I resolve this problem?
>
> In theory, you could try contacting the administrator of the server at
> that IP address, and letting her know that there is some technical
> problem so she can resolve it.
>
> In practice, this is a worthless message and you should disable it in
> named.conf:
>
> logging {
> category lame-servers { null; };
> };
>
>
>
> A couple of questions to everyone on the list...
>
> 1. Should ISC change the default logging for lame servers to disabled?
>
> 2. Are there other usually worthless default log messages we should
>disable?
>
>
> Cheers,
>
> --
> Shane
>
___
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: lame-servers: error (FORMERR) resolving [something]

[Shane Kerr]

Daniele,

On Tuesday, 2013-01-08 09:49:57 +0100, 
Daniele  wrote:
> Hi all.
> 
> Sometimes I can't resolve some addresses and, in the logs, I can find
> the message in the title:
>lame-servers: error (FORMERR) resolving [something]
> (where `something` is the address I'm trying to resolve).
> 
> What does it means?

When acting as a recursive resolver, BIND 9 follows the chain of
delegation from the root, contacting name servers identified for each
domain on the way.

In this case, one of those name servers returned a packet that BIND 9
did not like for some reason - a FORMat ERRor. The offending server is
marked as "lame" since it cannot answer queries for the domain in
question.

The message should also include the IP address of the server that it is
going to at the end of the line.

> And how can I resolve this problem?

In theory, you could try contacting the administrator of the server at
that IP address, and letting her know that there is some technical
problem so she can resolve it.

In practice, this is a worthless message and you should disable it in
named.conf:

logging {
category lame-servers { null; };
};



A couple of questions to everyone on the list...

1. Should ISC change the default logging for lame servers to disabled?

2. Are there other usually worthless default log messages we should
   disable?


Cheers,

--
Shane
___
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

lame-servers: error (FORMERR) resolving [something]

[Daniele]

Hi all.

Sometimes I can't resolve some addresses and, in the logs, I can find the
message in the title:
   lame-servers: error (FORMERR) resolving [something]
(where `something` is the address I'm trying to resolve).

What does it means?
And how can I resolve this problem?

Thank you!
___
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