Re: Getting a formerr 'invalid response' for winqual.microsoft.com. but dig +trace works.

[David Miller]

On 2/8/2012 10:32 PM, Matt Doughty wrote:

I have spend the afternoon trying to figure this out. The response I
get back from their nameserver looks fine to me, and dig +trace works
fine, but a regular dig returns a servfail. I have looked at the code
for invalid response, but I don't quite follow what is going on there,
and the comment 'responder is insane' leaves something to be desired.
Any help would be appreciated here. I have included the dig +trace
output below:

dig +trace winqual.partners.extranet.microsoft.com.

;<<>>  DiG 9.7.0-P1<<>>  +trace winqual.partners.extranet.microsoft.com.
;; global options: +cmd
.   518004  IN  NS  j.root-servers.net.
.   518004  IN  NS  e.root-servers.net.
.   518004  IN  NS  l.root-servers.net.
.   518004  IN  NS  c.root-servers.net.
.   518004  IN  NS  m.root-servers.net.
.   518004  IN  NS  d.root-servers.net.
.   518004  IN  NS  b.root-servers.net.
.   518004  IN  NS  h.root-servers.net.
.   518004  IN  NS  k.root-servers.net.
.   518004  IN  NS  a.root-servers.net.
.   518004  IN  NS  g.root-servers.net.
.   518004  IN  NS  i.root-servers.net.
.   518004  IN  NS  f.root-servers.net.
;; Received 228 bytes from 172.16.255.1#53(172.16.255.1) in 1 ms

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

microsoft.com.  172800  IN  NS  ns3.msft.net.
microsoft.com.  172800  IN  NS  ns1.msft.net.
microsoft.com.  172800  IN  NS  ns5.msft.net.
microsoft.com.  172800  IN  NS  ns2.msft.net.
microsoft.com.  172800  IN  NS  ns4.msft.net.
;; Received 235 bytes from 192.43.172.30#53(i.gtld-servers.net) in 67 ms

partners.extranet.microsoft.com. 3600 IN NS dns10.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns13.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns11.one.microsoft.com.
partners.extranet.microsoft.com. 3600 IN NS dns12.one.microsoft.com.
;; Received 236 bytes from 64.4.59.173#53(ns2.msft.net) in 3 ms

winqual.partners.extranet.microsoft.com. 10 IN A 131.107.97.31
;; Received 112 bytes from 131.107.125.65#53(dns10.one.microsoft.com) in 23 ms



If I just dig at their servers for NS, I get a trunc and retry over TCP 
that times out.


If I signal a bufsize, I get back a 777 byte response with NS that don't 
match the parent and an additional full of private 10/8 addresses


# dig +norecurse +bufsize=1024 ns partners.extranet.microsoft.com 
@dns10.one.microsoft.com.


; <<>> DiG 9.8.1 <<>> +norecurse +bufsize=1024 ns 
partners.extranet.microsoft.com @dns10.one.microsoft.com.

;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10678
;; flags: qr ra; QUERY: 1, ANSWER: 16, AUTHORITY: 0, ADDITIONAL: 17

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;partners.extranet.microsoft.com. INNS

;; ANSWER SECTION:
partners.extranet.microsoft.com. 1076 IN NS 
tk5-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
kaw-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
co2-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
co2-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
tk5-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
db3-ptnr-dc-02.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
db3-ptnr-dc-01.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
tk5-ptnr-dc-03.partners.extranet.microsoft.com.
partners.extranet.microsoft.com. 1076 IN NS 
sin-ptnr

Re: Version statement...

[David Miller]

On 8/17/2012 1:13 AM, Jeff Justice wrote:
> I am trying to mask our DNS servers version output to a custom string, but it 
> doesn't seem to be working for me.  In a nutshell, I have added this to my 
> options block of my named.conf:
> 
>version "[DNS Server]";

options {
version "string";

works for me in 9.8.  Maybe BIND doesn't like the square brackets?


> But when I do a query, it still shows the actual version number i.e. BIND 
> 9.9.1-P2, both from the command line and from an outside query tool.
> 
> What am I missing?
> 
> Jeff
> ___
> 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

Re: Disable log message

[David Miller]

On 10/19/2012 11:57 PM, Chris Buxton wrote:
> On Oct 19, 2012, at 6:22 PM, Warren Kumari wrote:
>> On Oct 19, 2012, at 9:17 PM, "Michael Hoskins (michoski)" 
>>  wrote:
>>> -Original Message-
 On Oct 19, 2012, at 6:13 PM, Alan Clegg  wrote:

>
> On Oct 18, 2012, at 1:13 PM, Chris Thompson  wrote:
>
>> On Oct 18 2012, Jeremy C. Reed wrote:
>>
>>> On Thu, 18 Oct 2012, Jack Tavares wrote:
>>>
 I  am running bind9.8.x built from source and I see this message in
 the logs
 built with '--prefix=/blah' '--sbindir=/blah' '--sysconfdir=/blah'
 '--localstatedir=/var' '--exec-prefix=/usr' '--libdir=/usr/lib'
 '--mandir=/usr/share/man' '--with-openssl=/blah'
 '--enable-fixed-rrset' '--enable-shared' '--enable-threads'
 '--enable-ipv6' '--with-libtool'  etc etc etc I would prefer to not
 have that show up in the log.
 Short of modifying the source, is there an easy way to disable that?
>>>
>>> No way to disable just it. It is in the "general" catch-all category.
>>
>> Also, it is output before the configuration "logging" directives have
>> been
>> processed, so it comes out with the internal defaults for category and
>> priority (daemon.notice). Any suppression would need to be done at the
>> syslog level.
>>
>> But I have some difficulty understanding why anyone would want it
>> suppressed.
>> It's true that BIND is a bit noisier than it used to be at this stage,
>> but
>> can this really be a problem? Do you let the black hats see your
>> system logs?
>
>
> This message was added by general recognition that being able to
> rebuild a "drop-in" binary for BIND when you didn't have access to the
> build directory (where the config.log contains the information) was a
> good thing.

 Yah, a very good thingŠ This has been really really useful to me on a
 number of occasionsŠ

>
> I, for one, see no reason to suppress this message (but I do have blind
> spots at times).

 Me neither, but I am interested why folk might want toŠ
>>>
>>> Maybe it's viewed as information disclosure?
>>
>> Ah, that's a good point, especially if BIND is being incorporated into an 
>> appliance / black box and there is no need for the users of the appliance to 
>> know what all goes on under the hood?
> 
> An an employee of the maker of an appliance solution, I can say that we 
> gladly tell our customers what's going on under the hood. If we didn't, they 
> wouldn't trust us.

Does this log message provide any information that the -V option doesn't
provide?

$ named -V
BIND 9.8.0-P4 built with '--prefix=/blah' '--exec-prefix=/blah'
'--enable-threads' '--enable-ipv6' 'CFLAGS=-O2 -march=native ...and so on...
using OpenSSL version: OpenSSL 1.0.0d 8 Feb 2011
using libxml2 version: 2.7.8

-DMM
___
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: DNS Amplification Attacks... and a trivial proposal

[David Miller]

On 06/13/2013 05:33 AM, Phil Mayers wrote:
> On 06/13/2013 06:31 AM, Ronald F. Guilmette wrote:
>
>> 1)  If everyone on the planet were to somehow magically and
>> immediately be
>> converted over to DNSSEC tomorrow, then would DNS amplification attacks
>> become a thing of the past, starting tomorrow?  Does DNSSEC "solve" the
>> DNS amplification attack problem?  Or does it have no direct bearing on
>
> No, quite the opposite in fact. By increasing the size of responses,
> DNSSEC arguably makes the amplification problem (slightly) worse.

"slightly" is generous.  I would say "dramatically".

$ dig mx isc.org @ord.sns-pb.isc.org +noall +stats +nodnssec

; <<>> DiG 9.9.2-P1 <<>> mx isc.org @ord.sns-pb.isc.org +noall +stats
+nodnssec
;; global options: +cmd
;; Query time: 223 msec
;; SERVER: 199.6.0.30#53(199.6.0.30)
;; WHEN: Thu Jun 13 11:28:49 2013
;; MSG SIZE  rcvd: 403


$ dig mx isc.org @ord.sns-pb.isc.org +noall +stats +dnssec

; <<>> DiG 9.9.2-P1 <<>> mx isc.org @ord.sns-pb.isc.org +noall +stats
+dnssec
;; global options: +cmd
;; Query time: 242 msec
;; SERVER: 199.6.0.30#53(199.6.0.30)
;; WHEN: Thu Jun 13 11:28:54 2013
;; MSG SIZE  rcvd: 2427


DNS reflection attacks are all about amplification (a small request
resulting in a response larger than the request).  A 6 times greater
response size is a large jump in amplification.

>
> DNSSEC is a good thing and necessary for other reasons, but it does
> not help amplification attacks.

+1

>
>> 2)  Has anyone ever proposed adding to the DNS protocol something
>> vaguely
>> reminicent of the old ICMP Source Quench?  If so, what became of that
>> proposal?
>
> 
>
>> Basically, the whole idea is just simply to allow a victim to switch to
>> "safe TCP only mode" with all of the intermediaries that are
>> participating
>
> The problem with that idea is that it needs software updates on both
> the reflecting DNS server and the victim. It also seems to require
> keeping a lot of soft state in the endpoints.

This would require both software updates and an update to the DNS protocol.

This idea does require state at the endpoints.  We seem to have already
lost that battle - example RRL.  Would this require more state at the
endpoints than RRL?  I think that this probably would require more state.

One concern I have is that it turns the problem on its head and now the
network that is the target of the attack is required to get packets out
through their loaded equipment to stop the attack.

This could lead to wrong headed statements like, "Yes, we sent X GB of
traffic at your network.  You didn't implement DNS source quench?  You
should have."

The chain of responsibility for these attacks is:
1. The person(s) originating the spoofed traffic.
2. The network(s) allowing the origination of spoofed traffic.
3. The network(s) transmitting the spoofed traffic.
4. The operators of nodes amplifying the traffic towards the victim.
5. The victim.

A system that requires the victim to take action to stop attacks might
be misconstrued by some to be abdicating the responsibility of the upper
four levels.

>
> Altogether, it seems easier for everyone to just apply RRL patches, do
> BCP38 and de-peer with people who don't do BCP38.

Agreed.  Close all open resolvers as well.

Using this strategy, however, you will have to do an awful lot of
de-peering.

-DMM

___
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: long SPF txt record

[David Miller]

On 6/20/2013 1:13 PM, Koehler, Charles wrote:
> Our email group wants to change the current SPF txt record and replace it 
> with one that is 274 characters. 
> 
> How can I put it in so that it works correctly?
> 
> Thanks
> --cwk

>From RFC 4408 ( http://www.ietf.org/rfc/rfc4408.txt )

3.1.3.  Multiple Strings in a Single DNS record

   As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS
   record (either TXT or SPF RR types) can be composed of more than one
   string.  If a published record contains multiple strings, then the
   record MUST be treated as if those strings are concatenated together
   without adding spaces.  For example:

  IN TXT "v=spf1  first" "second string..."

   MUST be treated as equivalent to

  IN TXT "v=spf1  firstsecond string..."

   SPF or TXT records containing multiple strings are useful in
   constructing records that would exceed the 255-byte maximum length of
   a string within a single TXT or SPF RR record.


-DMM
___
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: bind/sendmail resolving.. (NXDOMAIN)

[David Miller]

On 9/20/2013 7:28 PM, Mark Andrews wrote:
> 
> In message <021501ceb653$ede37250$c9aa56f0$@leadmon.net>, "Howard Leadmon" 
> writ
> es:
>>   This is probably easier than I am making it, but my googlefu seems to be
>> failing me at the moment when I look around.   I  handle a batch of FreeBSD
>> servers running sendmail, and I am having a site that is trying to deliver
>> mail being rejected, but they swear their DNS is right, so I am not sure if
>> we have an issue, or they do.
>>
>>  I am seeing sendmail rejects like this:
>>
>> Sep 20 14:45:59 mail3 mail3-smtp[15388]: r8JE8kQg099367:
>> to=, delay=1+04:37:10, xdelay=00:00:31,
>> mailer=esmtp, pri=5259883, relay=smtp2.panini.co.uk., dsn=4.0.0,
>> stat=Deferred: Name server: smtp2.panini.co.uk.: host name lookup failure
>>
>>
>>  If I take and run a host lookup, I get a response like this:
>>
>> $ host panini.co.uk 
>> panini.co.uk mail is handled by 10 smtp.panini.co.uk.
>> panini.co.uk mail is handled by 20 smtp2.panini.co.uk.
>>
>>
>> Now if I try that on any of the hosts that should accept the mail, I see:
>>
>> $ host smtp.panini.co.uk
>> smtp.panini.co.uk is an alias for smtp.panini.it.
>> smtp.panini.it has address 151.12.160.24
>> Host smtp.panini.it not found: 3(NXDOMAIN)
>>
>> $ host smtp2.panini.co.uk
>> smtp2.panini.co.uk is an alias for smtp2.panini.it.
>> smtp2.panini.it has address 151.12.160.30
>> Host smtp2.panini.it not found: 3(NXDOMAIN)
> 
> Firstly MX records are not supposed to point to CNAME records.  The
> MX records need to be updated.
> 
>>  So I get the IP address returned, but then an NXDOMAIN that follows.   I do
>> have the Broken config option in my sendmail, so know it's not that, or
>> I don't think so.Yet if I do a dig on the hosts, they seem to come back
>> with an IP address as expected, and shown above.
>>
>>  So if anyone can offer a clue on this, it would be appreciated..
> 
> Secondly and more importantly they have a misconfigured load balancer
> that is returning bad answers.  The last answer to "dig +trace
> smtp2.panini.it " should be "smtp2.panini.it. 86400 IN SOA
> paninirad1.panini.it. administrator.panini.it".
> 
> Note the SOA record needs to be from the zone delegated (smtp2.panini.it)
> to the load balancer.
> 
> They need to contact their load balancer vendor for proper instructions
> on how to configure it. 
> 
> Mark
> 
> % dig +trace smtp2.panini.it 
> 
> ; <<>> DiG 9.10.0a1 <<>> +trace smtp2.panini.it 
> ;; global options: +cmd
> . 518400  IN  NS  f.root-servers.net.
> . 518400  IN  NS  c.root-servers.net.
> . 518400  IN  NS  k.root-servers.net.
> . 518400  IN  NS  d.root-servers.net.
> . 518400  IN  NS  l.root-servers.net.
> . 518400  IN  NS  i.root-servers.net.
> . 518400  IN  NS  h.root-servers.net.
> . 518400  IN  NS  b.root-servers.net.
> . 518400  IN  NS  e.root-servers.net.
> . 518400  IN  NS  m.root-servers.net.
> . 518400  IN  NS  g.root-servers.net.
> . 518400  IN  NS  a.root-servers.net.
> . 518400  IN  NS  j.root-servers.net.
> . 518400  IN  RRSIG   NS 8 0 518400 2013092700 
> 2013091923 49656 . 
> U9k2KFpbNYnY4EfyKzla26XbharLoAQtkQG02oq3aHVnM3OlLp6lmBdT 
> wgMDcShAQJxIk50krHlIuoyOGHHuJ56P6ubFiGBRU0V4OOt2/V8emJZx 
> U6MRMDwDyTweZbfNZiiK20T5RVlUK/PLI3YbbcYxxtSCKzV2fThLxi3F /x4=
> ;; Received 397 bytes from 127.0.0.1#53(127.0.0.1) in 3 ms
> 
> it.   172800  IN  NS  a.dns.it.
> it.   172800  IN  NS  c.dns.it.
> it.   172800  IN  NS  m.dns.it.
> it.   172800  IN  NS  r.dns.it.
> it.   172800  IN  NS  dns.nic.it.
> it.   172800  IN  NS  nameserver.cnr.it.
> it.   86400   IN  NSECje. NS RRSIG NSEC
> it.   86400   IN  RRSIG   NSEC 8 1 86400 2013092700 
> 2013091923 49656 . 
> A01ecU1p6o7U4le9Jh8F2aQ4fl9XdPFMcERxLf2cZ6aiHkKsZdQsHiwN 
> eI/5VnC9N1sLgF9p8uD7H8adMjC/EFHDK/kXmbpJNps9Hi/VdYa846He 
> tu4iYxmQpaq0SgIpCqsRSRk0TjnL0l0B/VZueZREvpEQND6Zjjys7Zow ZvE=
> ;; Received 610 bytes from 128.63.2.53#53(h.root-servers.net) in 352 ms
> 
> panini.it.10800   IN  NS  dns1.quadrante.com.
> panini.it.10800   IN  NS  dns2.quadrante.com.
> ;; Received 108 bytes from 2001:678:4::16#53(c.dns.it) in 200 ms
> 
> smtp2.panini.it.  3600IN  NS  paninirad3.panini.it.
> smtp2.panini.it.  3600IN  NS  paninirad2.panini.it.
> smtp2.panini.it.  3600IN  NS  paninirad1.panini.it.
> ;; Received 167 bytes from 83.103.76.83#53(d

Re: Here I am again, hat in hand with humble demeanor.......

[David Miller]

To answer some of your direct questions directly:

On 9/24/2010 11:58 AM, Stewart Dean wrote:

 More questions...(CentOS 5.5, bind-9.7.1-P2)
1) I assume the canonical location of named.conf is always in /etc?  
Nobody (Little grasshopper from ORA, google) says so, but there are 
intimations here and there.



I have always used /etc/named.conf

2) My home-built binary is nearly 7MB, while the CentOS distro binary 
is about 400K.  Is this right?  Is there a way as in sendmail of 
determining what features bind was built with or is that an invalid 
question?


/path/named -V will (in my versions) give you a lot of useful 
information.  No idea about CentOS precompiles, but can't hurt to try.


# named -V
BIND 9.7.1 built with '--enable-threads' '--with-openssl' 
'--enable-ipv6' '--disable-shared' '--enable-atomic' 'CFLAGS=-O2 
-march=native' 'CXXFLAGS=-O2 -march=native'



--
-___
David Miller
Tiggee LLC
dmil...@tiggee.com

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

Re: non-24 bit subnets

[David Miller]

 On 10/6/2010 3:21 PM, Jay Ford wrote:

On Wed, 6 Oct 2010, Alex McKenzie wrote:

Unfortunately, we do have need -- or at least a use -- to have smaller
subnets in multiple files, but without delegating authority.  The
problem is that some of those small subnets should have a shorter TTL,
or other settings changed.  If there's a way to change all the settings
by host in a single file, that would at least make that easier.


You could use one real zone file which is referenced by named.conf, 
with $INCLUDE directives in that zone file to pull in the parts of the 
zone from files containing the subsets you want.  A $TTL directive at 
the top of each small file should give you the variable TTL defaulting 
you want.




You can have a different TTL for each and every record, if you like, in 
the same zone file with no includes (the $TTL directive can appear 
multiple times).


e.g. :

$TTL 300; 5 mins
*PTRhost-no-spec.example.com.
$TTL 3600; 1 hour
17   PTR   mail.example.com.
$TTL 1800; 30 mins
18   PTR   mail2.example.com.
$TTL 86400;  1 day
19PTRwhatever.example.com
20PTRwhatever2.example.com
22PTRwhatever2.example.com

^^ This works for me.


For larger subnets we can use multiple zones, but I'd hoped to avoid it
if possible.  It sounds from this like there isn't a way, though.


Right.


Jay Ford, Network Engineering Group, Information Technology Services
University of Iowa, Iowa City, IA 52242
email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users



--
-_______
David Miller
Tiggee LLC
dmil...@tiggee.com

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

Re: Bind and blacklist IP file

[David Miller]

 On 10/11/2010 3:26 PM, Andrey G. Sergeev (AKA Andris) wrote:

Hello Alans,


Mon, 11 Oct 2010 20:07:40 +0300 Alans wrote:


Why not? OpenDNS is a good example i think.

Good example? Was it a joke? Do the traceroute on IP addresses of the
two OpenDNS resolvers and you'll find that they both are behind the
same router. Do you still trust the OpenDNS people who advertise their
service as reliable?


You are kidding right?  ...or was this post a joke?

OpenDNS is Anycast - http://en.wikipedia.org/wiki/Anycast

Here is an DNS Stuff Vector Trace for 208.67.222.222 (one of OpenDNS' 
resolvers):
  
http://www.dnsstuff.com/tools/vectortrace?ip=208.67.222.222&token=26314c5ba0c8ae4e2c32430c19d55018


Note that end points are very local to the widely spread start points.

From any one location an IP Anycast service will appear to be very 
local.  That is the point.



P.S. Please don't top-post - this breaks the logic of the discussion
thread. Thank you.


regards,
Alans

On 10/11/2010 07:37 PM, Matus UHLAR - fantomas wrote:

On 11.10.10 14:16, Alans wrote:

Thanks Dave, yes i know about OpenDNS, I'm trying to imlement
somehting kind of similar to that in a small scale.
So i was wondering about Bind dns capabilities and may be third
party stuffs that could integrate with bind dns in addition to the
ip/website list.

This is NOT something BIND (or any DNS server) should do. Blocking
web sites is business for web proxies, firewalls etc. Doing this
stuff at DNS level could lead to many surprises.



--
-_______
David Miller
Tiggee LLC
dmil...@tiggee.com

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

Re: incorrect dns returned by public servers for our domain

[David Miller]

On 2/24/2011 1:19 AM, Matthew Seaman wrote:

On 24/02/2011 04:14, Noel Butler wrote:

You can pretty much remove the entire statement now, as all /8's are
issued as of about two weeks ago.

This works for me:

lucid-nonsense:~/src/namedb:% cat acl-ipv4-bogons.conf
// @(#) $Id: acl-ipv4-bogons.conf 800 2011-02-03 20:22:12Z matthew $
//
// Networks listed by IANA as test, RFC 1918, Multicast, Experimental,
// etc. (RFC 5735)
//
// See: http://www.team-cymru.org/Services/Bogons/bogon-bn-agg.txt

acl ipv4-bogons {
 0.0.0.0/8;
 10.0.0.0/8;
 127.0.0.0/8;
 169.254.0.0/16;
 172.16.0.0/12;
 192.0.0.0/24;
 192.0.2.0/24;
 192.168.0.0/16;
 198.18.0.0/15;
 198.51.100.0/24;
 203.0.113.0/24;
 224.0.0.0/3;
};
//
// That's All Folks!
//

All of which are special purpose networks listed in RFC 5735 which you
shouldn't be seeing any DNS query traffic from on the open internet.
This bogon list is going to be static for the foreseeable future.



+ 192.88.99.0/24  // 6to4 relay anycast - can be destination of packets, 
*should* never be source
+ 240.0.0.0/4 // reserved for future use - likely to *never* be valid 
source - I block, YMMV


-DM


Cheers,

Matthew



___
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: An Invitation to Neuroscientists and Physicists: Singapore Citizen Mr. Teo En Ming (Zhang Enming) Reports First Hand Account of Mind Intrusion and Mind Reading

[David Miller]

On 5/17/2011 2:07 PM, Warren Kumari wrote:

On May 17, 2011, at 1:17 PM, Michelle Konzack wrote:


69th Spam/Mailinglist (I am subscribed to 137 lists)

How is it possibel, this guy is spaming at least 69  mailinglists  where
most are subscriber only?

Um, maybe his claims are true -- if "Mind Intrusion" exists and works well, its 
it *really* that hard to believe that he would be able to use his mind to flip the 
subscribed bit on a mailing list?!

Really?!

W

:-P



Perhaps we aren't even receiving the email and instead are just having 
our minds tricked into thinking that we received it...


-DM


Thanks, Greetings and nice Day/Evening
Michelle Konzack

--
# Debian GNU/Linux Consultant ##
   Development of Intranet and Embedded Systems with Debian GNU/Linux

itsystems@tdnet France EURL   itsystems@tdnet UG (limited liability)
Owner Michelle KonzackOwner Michelle Konzack

Apt. 917 (homeoffice)
50, rue de Soultz Kinzigstraße 17
67100 Strasbourg/France   77694 Kehl/Germany
Tel: +33-6-61925193 mobil Tel: +49-177-9351947  mobil
  Tel: +49-176-86004575 office

   
  

Jabber linux4miche...@jabber.ccc.de
ICQ#328449886

Linux-User #280138 with the Linux Counter, http://counter.li.org/
___
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


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

Re: nameserver registration

[David Miller]

On 6/18/2011 12:24 PM, Lyle Giese wrote:

On 06/18/11 09:30, Jorg W. wrote:

Greetings,

given my domain name is example.net, and my NS servers for 
example.net are:


ns1.example.com
ns2.example.com

But, example.com itself's NS servers are the registrator's (for
example, godaddy's).

Under this case, I don't need any glue for ns[1-2].example.com.
But why I still need to register them in the .com NS servers?

Thanks.



You are wrong.  You do need glue records.  Glue records registers the 
ip address of your name server(s) with the root name servers.


Only TLDs/ccTLDs (com., org., xxx., etc.) insert name servers and glue 
into the root name servers.  All second level domains (example.com., 
example.net., etc.) insert name servers and glue into their parent 
TLD/ccTLD's name servers.


To be clear:
"name servers" are NS records
"glue records" are A/ records that point to IPv4/IPv6 addresses for 
hostnames that are name servers.




In this case the glue records are associated with ns1 and 
ns2.example.com.  The name servers need to be registered with the 
domain registrar for example.com and forwarded as glue records to the 
root name servers for .com.


Root in DNS terms is ".".   Better to say "to the authoritative DNS 
servers for .com." or just "TLD/ccTLD name servers".




Godaddy is a domain name registrar and does not run any root name 
servers.  However, it is the responsibility of the domain name 
registrars to make sure proper glue records are maintained for any/all 
name servers used with a domain registered with them.


All domains, at every level, have to configure their records such that 
the tree can be walked from root to their domain.


Follow the "."s.

For: this.long.chain.example.com.

com. must be delegated by .
example.com. must be delegated by com.
chain.example.com. must be delegated by example.com.
long.chain.example.com. must be delegated by chain.example.com.
this.long.chain.example.com. must be delegated by long.chain.example.com.

The wikipedia article on DNS is quite good:  
http://en.wikipedia.org/wiki/Domain_Name_System


In the particular case of the OP - example.net. has name servers under 
example.com.


To make lookups for records under example.net., resolvers walk the tree 
from "." to "net." and get NS records - ns1.example.com. and 
ns2.example.com.


You can't insert glue records into net. for name servers that exist 
under com., so now resolvers walk the tree from "." to "com." to get the 
name servers for example.com. which in the OP's case are - GoDaddy name 
servers.


If there are no glue records in com. for ns1.example.com. and 
ns2.example.com., then resolvers will just ask the authoritative name 
servers for example.com. (which in the OP's case are - GoDaddy name 
servers) for the A/ records for ns1.example.com. and 
ns2.example.com.  If the GoDaddy name servers provide A/ records for 
ns1.example.com. and ns2.example.com., then resolution works and 
everyone is happy.


Glue is only required if that is the only way to traverse the tree to 
get to the IP addresses for the name servers for a domain.


Can someone point to an RFC or BCP that says that *all* name servers 
*must* have glue present in their parent?


-DMM

___
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: CNAME / MX Record question

[David Miller]

On 8/7/2011 9:05 AM, Scott Hughes wrote:

All,

I have Googled and searched the archives for two days and cannot find 
an answer to this question... just more confusion!  Please forgive me 
ahead of time as I run two name servers for my mid-sized company and 
am by no means an expert in using bind DNS. We have about eight 
domains but don't have a lot of records for each zone.  Here is my issue:


We are moving to a two Exchange server / two data center model for 
auto-failover reasons. Both data centers are in to different locations 
and have multiple internet pipes and tier 1 providers coming into 
their data centers.


Here is what I'm trying to do:

For example, our email domain name on the Exchange servers is: 
mail.blahblah.us Our spam filtering 
device is: spam.blahblah.us  and is the MX 
record.  In the blahblah.us  zone file I have A 
records pointing to both correctly.


Our problem comes in on our other domains. I am trying to point 
mail.company1.com  to mail.blahblah.us 
 and spam.company1.com 
 to spam.blahblah.us 
 using CNAME records.  I'm obviously doing 
this wrong or trying to do something that can't or shouldn't be done. 
 Like I said, I am fairly new to bind9 but I'd sure rather use it than 
something link MS DNS servers!


What I am attempting to do is make it so that if an outside email 
server or inside user goes to mail.company1.com 
  or spam.company1.com 
 they are 'redirected' to the blahblah.us 
 domain where our UCC cert covers both of the 
Exchange servers.


Please let me know if I've left anything out that would be helpful in 
answering these questions.





blahblah.us and company1.com are actual registered domain names.  If 
they are registered to you, then using these domains in examples is 
fine... if not, then better to use RFC2606 names...


If I understand your environment correctly:

Your "main domain" - example.com - looks (in part) like this:

// Begin example.com

$TTL 86400

@   IN  SOA ns1.example.com.  contact.example.com. (
2011080701  ; serial number YYMMDDNN
28800   ; Refresh
7200; Retry
864000  ; Expire
86400   ; Min TTL
)

NS  ns1.example.com.
NS  ns2.example.com.

MX  10 spam.example.com.
MX  20 spam2.example.com.

$ORIGIN example.com.

spamIN  A   192.0.2.25
spam2   IN  A   192.0.2.26
mailIN  A   192.0.2.30

// End example.com

There is no reason that example.net (another of your domains) can't look 
like this:


// Begin example.net

$TTL 86400

@   IN  SOA ns1.example.com.  contact.example.net. (
2011080701  ; serial number YYMMDDNN
28800   ; Refresh
7200; Retry
864000  ; Expire
86400   ; Min TTL
)

NS  ns1.example.com.
NS  ns2.example.com.

MX  10 spam.example.com.
MX  20 spam2.example.com.

$ORIGIN example.net.

// End example.net


^^^ MX records in example.net point to example.com hosts (which are A 
records).


If you have a 'requirement' that the users for example.net configure 
their mail clients with example.net mail server hostnames, then you can 
create a CNAME record in example.net that aliases mail.example.net to 
mail.example.com.


If, however, you have a 'requirement' to make it 'seem' that example.com 
and example.net have 'independent' mail servers at a DNS level - i.e. 
you want to use MX records in example.net that are in example.net, then 
you need to add A records for spam & spam2 in example.net that point to 
the IP addresses of these hosts (and you need to do this for all domains 
'like' example.net as well -and- update the A records in all of these 
domains if the IP addresses of these hosts change in the future... c'est 
la DNS).  Like so:


// Begin example.com

$TTL 86400

@   IN  SOA ns1.example.com.  contact.example.com. (
2011080701  ; serial number YYMMDDNN
28800   ; Refresh
7200; Retry
864000  ; Expire
86400   ; Min TTL
)

NS  ns1.example.com.
NS  ns2.example.com.

MX  10 spam.example.com.
MX  20 spam2.example.com.

$ORI

Re: NXDOMAIN redirection in BIND 9.9

[David Miller]

On 9/30/2011 6:21 PM, Shawn Bakhtiar wrote:


"We came to the conclusion that no matter how much we wanted it to not 
be true, people find a way to do NXDOMAIN if they want to. The issue 
is not ours to push, it's between the ISP and the customer ultimately, 
and people will do it -- and more intrusively -- than BIND 9.9 will."


That is just giving in. To what WILL end up being akin (is akin) to 
taking away access. The argument that everyone is doing it so let's 
just facilitate it is a bad one. This is a cave in to bad behavior 
which borders on freedom of speech violation, since your sanctioning 
the ability to arbitrarily redirecting (without redirecting) content. 
Important part being the sanctioning of.


http://en.wikipedia.org/wiki/DNS_hijacking



You get to run your network how ever you like.  This is your right.  
Turn the feature on if you like -or- make sure it is off if you don't 
like it.


You don't get to tell others how to run their networks.  Well... you can 
tell them, but they don't have to listen to you...


Many organizations want to do NXDOMAIN redirections on their resolvers 
on their own internal networks or on guest wireless networks or on 
whatever networks they control for whatever reasons they like.


Other resolvers have had the ability to do NXDOMAIN redirections for 
many years.  The pressures keeping ISPs from implementing NXDOMAIN 
redirections has never been the fact that BIND didn't support it.


You are going to have a hard time making the case that NXDOMAIN 
redirections are a "freedom of speech violation", but the place for that 
argument is in the court room.


Instead of seeing this as a "sky is falling" event, why not see it as an 
opportunity to create your own resolving DNS service that does not do 
NXDOMAIN redirections?  Then every ISP that implemented NXDOMAIN 
redirections (using BIND or any of the myriad of other software that 
will do it) would be another potential group of customers for you.


-DMM

___
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: host versus nslookup

[David Miller]

On 10/12/2011 3:01 PM, Kevin Darcy wrote:

On 10/12/2011 1:21 PM, Martin McCormick wrote:

Many years ago, various flavors of unix began distributing a
utility called host which did almost the same thing as nslookup.
Host is what I use most of the time, now, and I actually thought
that nslookup on unix systems was maybe going away.

A coworker recently asked me about nslookup on our
FreeBSD system and I verified the behavior he was asking about.

Other than a different output format, what are the
advantages of having both host and nslookup.

On the FreeBSD system in question, nslookup is
definitely a different binary than is host so one is not
hard-linked to the other.

The behavior he was asking about was simply that all
foreign domains that one looks up with nslookup report as
non-authoritative since the DNS one is using isnot authoritative
for, say, microsoft.com or yahoo.com.

This is not a problem. I am just curious.

nslookup has lots of problems. Four that I can cite off the top of my 
head:
1) most versions of nslookup will stop dead in their tracks if they 
can't reverse-resolve the name of whatever resolver they're trying to 
use (even though that's basically irrelevant to the actual lookup that 
the user requested)
2) nslookup will by default use a searchlist, but it does this 
completely invisibly by default (unless a debugging option is turned 
on), and thus will often mis-represent the real result of the query 
(e.g. you look up foo.example1.com, that gets a SERVFAIL, then 
unbeknownst to the user, nslookup tries the searchlist'ed name 
foo.example1.com.example2.com and reports the resulting NXDOMAIN as 
the final error of the lookup, thus obscuring the real error -- SERVFAIL)
3) the default output format of nslookup doesn't distinguish the 
result of the query from the identity of the resolver clearly enough, 
so unsophisticated users will often think that the name they're 
looking up actually resolves to the address of the DNS resolver, and 
much hilarity ensues (mis-routed trouble tickets, drama, confusion, etc.)
4) some versions of nslookup display atypical DNS responses (e.g. 
dangling CNAMEs, referrals) in very confusing, non-intuitive ways.



- Kevin


Use dig.

Always use dig.  If dig isn't installed - install dig and then use dig.  
Make dig part of your default set of packages on all boxes.


"host vs nslookup?" is asking whether you should hit your self in the 
head with a small or large hammer.


Put down the hammer and use dig.

-DMM

___
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: Defense against a client?

[David Miller]

Mark Andrews  wrote:

>
>In message ,
>Barry Mar
>golin writes:
>> In article ,
>>  Chuck Anderson  wrote:
>> 
>> > On Mon, Jan 16, 2012 at 03:41:15PM +, Florian Weimer wrote:
>> > > * Chuck Anderson:
>> > > 
>> > > > Unfortunately, these sorts of per-IP limiting are going to
>become more
>> > > > and more inappropriate with the likes of Carrier Grade NATs,
>since
>> > > > there will be many subscribers sharing a single public IP
>address.
>> > > > You may end up causing performance problems for legitimate
>traffic.
>> > > 
>> > > Fortunately, this is not that relevant because it's not really
>feasible
>> > > to run largish DNS resolvers behind port-based NAT anyway (in
>part due
>> > > to source port randomization). 8-)
>> > 
>> > You miss the point.  The DNS server, not behind a NAT, will end up
>> > rate-limiting or blocking clients who ARE behind NATs.
>> 
>> DNS queries don't come directly from clients, they come from caching 
>> servers, aka resolvers.  Its those caching servers that shouldn't be 
>> behind NATs.
>
>Which will more and more be behind CGN especially as DNSSEC take up
>increases.
>
>Mark
>-- 
>Mark Andrews, ISC
>1 Seymour St., Dundas Valley, NSW 2117, Australia
>PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org



If one sets up a infrastructure such that a large number of end users "share 
the same fate" through having the same source address... then one should not be 
surprised when these end users actually do share the same fate...

-DMM

___
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: DNSSEC

[David Miller]

I assume that you are asking about providing authoritative DNS for 
example.com.


Should you deploy DNSSEC?  Yes, if you want your query responses to be 
validated by DNSSEC resolvers.


Does this have anything to do with the DNSSEC signing of the root 
domain?  No, not really.  Unless your TLD's name servers will also be 
signed and your domain registrar will support loading your key(s) into 
your TLD's name servers, then you will still need to use DLV (regardless 
of whether the root is signed or not).


In other words "in the absence of a fully signed path from root to a 
zone" you will need DLV to use DNSSEC"  Quote from: https://dlv.isc.org/


-DM

On 4/30/2010 8:57 PM, Jeff Pang wrote:

Hello,

Since the global root DNS servers have deployed dnssec, as a
hostmaster for the common domain like example.com, should we also
deploy dnssec with named? Thanks.

Regards.
___
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

DNSSEC - Root zone - FUD

[David Miller]

All,

There has been quite a bit of FUD bouncing around the net regarding the 
May 5th signing of the root zone and the sky falling (or at least 
massive failures across the internet).  I have been asked multiple times 
about how I was going to prevent the internet from collapsing for my users.


Examples:
http://www.theregister.co.uk/2010/04/13/dnssec/
http://www.itnews.com.au/News/173412,warning-why-your-internet-might-fail-on-may-5.aspx

As I understand it, and please (PLEASE) correct me if I am wrong, the 
facts are:


  1. All that is happening on May 5th is that the last root server to 
do so (J) will begin serving the DURZ (Deliberately Unvalidatable Root 
Zone).  All of the other root servers have been serving the DURZ for 
quite a while already with no ill effects.
   Reference - 
http://www.root-dnssec.org/2010/04/14/status-update-april-2010/


  2. All of the root servers are currently responding to regular DNS 
queries (i.e. those that do not specifically request DNSSEC) as they 
have always done, and after May 5th the root servers will continue to 
respond to regular DNS queries as they have always done.


  3. Only DNS queries that specifically request DNSSEC (i.e. set the DO 
bit in their request) will see any difference in their query responses 
from the J root name server on May 5th (all of the other root name 
servers are already serving the DURZ today - see 1 above - and have been 
responding with unvalidatable DNSSEC responses to queries that request 
DNSSEC for a while now).


  4. DNSSEC will be in no way REQUIRED after May 5th.

  5. In all likelihood, DNSSEC will never be REQUIRED.  Even if the 
root zone were validly DNSSEC signed and every single TLD/ccTLD DNS zone 
on the internet were validly DNSSEC signed and every single DNS 
subdomain were validly DNSSEC signed today, a resolving name server that 
does not implement DNSSEC in any way would continue to function properly 
as it does today.


Despite the Example articles above, which seem to state/imply that May 
5th represents some massive shift/change in DNS on the internet, May 5th 
is an important milestone but should not affect any end users.


Will implementing DNSSEC in individual infrastructures require 
investigating allowed DNS response sizes in those networks?  Absolutely.


Is this something that it is important for network operators to begin 
investigating?  Yes.


Will May 5th be the day that the internet died?  No.

-DM

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

Re: Master server offline

[David Miller]

Secondaries need to 'know' that this old sec is now a master as well.

DNS is kind of critical (unless your internet presence is not important), so 
... Knowing nothing about you org... Would rec that you priortise fixing DNS 
pretty highly.


--
-_______
David Miller
Tiggee LLC
dmil...@tiggee.com
On May 6, 2010 23:23, Barry Margolin <bar...@alum.mit.edu> wrote: 

In article <mailman.1415.1273200624.21153.bind-us...@lists.isc.org>,

 Bruce Ray <bruce@zionsbancorp.com> wrote:



> You have until the expiry counter expires for a given zone.

> 

> We typically run our expiries at a week to allow for this type of failure.



You can easily turn a slave into a master.  Just go into its named.conf 

file, change "type slave" to "type master" and comment out the "masters 

{...}" clause.



> 

> 

> From: bind-users-bounces+bruce.ray=zionsbancorp@lists.isc.org 

> <bind-users-bounces+bruce.ray=zionsbancorp@lists.isc.org>

> To: bind-users@lists.isc.org <bind-users@lists.isc.org>

> Sent: Thu May 06 21:37:35 2010

> Subject: Master server offline

> 

> Our master server machine had a drive failure and looks like it will be 

> offline for some time. Somewhere in the back of my mind, I thought I 

> remembered that something bad can happen to the dns resolution for your 
zones 

> if the master is offline for too long. Is there anything to this or am I 
just 

> dreaming? As long as the secondary can answer request, we should be ok?

> 

> Cheers,

> 

> Dave



-- 

Barry Margolin, bar...@alum.mit.edu

Arlington, MA

*** PLEASE don't copy me on replies, I'll read them in the group ***

___

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