Re: allow-update in global options (was Re: bind and certbot with dns-challenge)

[Sam Wilson]

On 2019-03-17 20:37:56 +, Alan Clegg said:


On 3/17/19 2:51 PM, Alan Clegg wrote:

On 3/17/19 7:13 AM, Stephan von Krawczynski wrote:

Hello all,

I am using "BIND 9.13.7 (Development Release) " on arch linux. Up
to few days ago everything was fine using "certbot renew". I had
"allow-update" in nameds' global section, everything worked well. Updating to
the above version threw a config error that "allow-update" has no global scope
and is to be used in every single zone definition.


And you may have found a bug.  I'm checking internally at this time.


So, after a discussion with one of the BIND engineers this afternoon,
this turned out to be quite an interesting and deep-rooted issue.

During a cleanup of other code (specifically named-checkconf), code was
changed that enforced what was believed to have been the default
previously: specifically, allow-update was only allowed in zone stanzas.


Can I ask who believed it was previously the default?  I hope I'm not 
misreading the first dozen or so lines of this page (which seems to be 
reflected in previous editions of the ARM).


 



Sam

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
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: Selective forwarding?

[Sam Wilson]

On 2019-01-23 05:06:03 +, ObNox said:


On 22/01/2019 02:20, Grant Taylor via bind-users wrote:

Note:  I'm assuming a zone expiry of a week to a month.  I think that 
would accommodate most outages.


I thought of that too :-) A week would be far enough in my case.


Be careful of what you mean by "a week".  If a problem happens on a 
Friday just after you leave for a week's holiday/vacation then you need 
a 10-day timeout to be able to fix it on the Monday you come back.


Sam

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
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: Need help on RPZ sever, bit urgent

[Sam Wilson]

On 2018-08-09 14:00:55 +, Blason R said:


For example this one.

18:59:26.905177 IP 192.168.1.120.65049 > 192.168.1.42.53: 42074+ A? 
0351dag.com. (29)
18:59:26.905299 IP 192.168.1.42.53 > 192.168.1.120.65049: 42074 
NXDomain 0/1/0 (102)


$ dig 0351dag.com

; <<>> DiG 9.8.3-P1 <<>> 0351dag.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 44466
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;0351dag.com.   IN  A

;; AUTHORITY SECTION:
com.			900	IN	SOA	a.gtld-servers.net. nstld.verisign-grs.com. 
1533828275 1800 900 604800 86400


Sam

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
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: restarting bind fixes some resolution issues

[Sam Wilson]

On 2017-07-09 15:04:53 +, Matus UHLAR - fantomas said:


On 09.07.17 14:36, Dario Corti wrote:
Hi, I occasionally have issues updating some packages, with the package 
manager saying that it cannot resolve deb.nodesource.com. I'm using 
1:9.9.5.dfsg-9+deb8u11 and I verified that a bind restart fixes the 
problem every time (even if technically the domain CAN be resolved also 
before the restart).


https://mxtoolbox.com/SuperTool.aspx?action=dns%3adeb.nodesource.com=toolpage 


http://dnscheck.pingdom.com/?domain=deb.nodesource.com

both checkers report errors...

I issued a dig before and after the restart and it does report 
something different, but I'm unable to understand it, so I wonder if 
anyone can suggest a possible reason for this.


Before: https://pastebin.com/7qZUmPKA
After: https://pastebin.com/U0DUhE20


i don't see any difference here, both cases report deb.nodesource.com to be
a CNAME to d2buw04m05mirl.cloudfront.net - maybe you should look up that one
next time problem appears.


What's different is the authority section.  In neither case does it 
provide the expected NS records for nodesource.com or cloudfront.net, 
or even NS records for d2buw04m05mirl.cloudfront.net, which my servers 
have cached.  There is something odd about the configuration.


Sam

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
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: make AAAA type the default for dig

[Sam Wilson]

On 2017-06-14 10:45:30 +, Marco Davids (SIDN) said:


Hi,

Not sure if this has been proposed before, but I am wondering:

Has ISC ever considered to change the default 'dig -t' option from A to ?


Or a -H option to do both A and  queries in a kind of Happy Eyeballs mode?

(Yes, I know about things like 
 and 
.)


Sam

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
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: Unable to slave root zones

[Sam Wilson]

On 2017-04-07 15:26:57 +, Matus UHLAR - fantomas said:


On 07.04.17 07:36, Mark Knight wrote:
I've just noticed (after the slave zones expired), that the root name 
servers have been refusing my zone transfer requests since the end of 
March.


My confirm is per the standard named.conf example, e.g.:

zone "." {
type slave;
file "/usr/local/etc/namedb/slave/root.slave";
masters {
192.5.5.241;// F.ROOT-SERVERS.NET.
};
allow-query { localnets; };
notify no;
};


1. are you sure you need slaving the root? most of clients doesn't...

2. there are ~13 servers for root zone. did you check on more of them?


$ for ns in a b c d e f g h i j k l m ; do echo $ns: ; dig . axfr 
@$ns.root-servers.net | wc ; done

a:
  4  15  96
b:
  22529  169284 2231035
c:
  22529  169284 2231028
d:
  4  15  96
e:
  4  15  96
f:
  4  15  96
g:
  22529  169284 2231030
h:
  4  15  96
i:
  4  15  96
j:
  4  15  96
k:
  22529  169284 2231030
l:
  4  15  96
m:
  4  15  96

IPv4 only; 4 lines is a REFUSED.

Sam

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.

___
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: Delegation questions

[Sam Wilson]

Speaking as a European, at least for now, I suspect the forwarding 
mindset is more from the enterprise and security culture rather than 
being territorial.  There's a viewpoint that says things are better if 
they are tightly controlled and predictable, so always using the same 
configured path for DNS lookups is The Right Thing To Do (and there may 
be test suites and monitoring to try to ensure that 99% of all 
transactions complete within so many milliseconds etc etc).

Sam

In article ,
 Chris Buxton  wrote:

> Forwarding is more similar to how some other systems work. But it's not how 
> DNS naturally works. I think the biggest source of "forwarding = natural" is 
> perhaps from admins coming from other parts of IT, rather than any regional 
> difference. But I could be wrong.
> 
> From a technical perspective, in addition to the performance factor that 
> Kevin described, there is the fact that forwarding is inherently brittle. (So 
> are stub zones, for different reasons.) So the more you forward, the harder 
> it becomes to troubleshoot the inevitable problems that will arise, because 
> you have more systems to check and more ways for things to go wrong.
> 
> Regards,
> Chris
> 
> Sent from my iPhone
> 
> > On Aug 12, 2016, at 5:11 PM, Darcy Kevin (FCA)  
> > wrote:
> > 
> > True, strictly from a per-hop latency standpoint, there shouldn't be much 
> > difference between forwarding a packet or forwarding a DNS query.
> > 
> > Having said that -- and I'm sure the BIND developers could elaborate 
> > further on this -- I know that there's big difference between processing 
> > *packets*, from, say, a routing standpoint, which customized ASIC-level 
> > hardware can do to the tune of millions per second, and processing 
> > *queries*, which are much higher-level constructs, with a lot more 
> > variation, more levels of parsing, disassembly, re-assembly, validation, 
> > etc. When you have multi-hop DNS forwarding, you're using up significant 
> > resources on multiple computing devices at once, in ways that don't 
> > necessarily lend themselves to optimization in hardware. It ends up being 
> > the opposite of parallelism, i.e. using the resources of multiple devices 
> > to accomplish something that could, with only configuration changes, be 
> > accomplished with the resources of only one device.
> > 
> > At the risk of sounding xenophobic, there seems to be a mindset among 
> > certain cultures that forwarding is "natural", and, in contrast, having DNS 
> > instances talk to each other directly is somehow "artificial". I've had 
> > this conversation many times with many of my European counterparts over the 
> > years, and we just seem to view things differently. One could speculate on 
> > the difference in world view -- submission to higher authority, perhaps? 
> > Hierarchical social organization? I don't know -- I don't claim any 
> > expertise whatsoever in sociology, cognitive psychology, or related fields. 
> > But for me, and I think most people in my (North American) culture -- 
> > possibly because we tend more towards individualism and/or egalitarianism? 
> > -- having DNS instances talk *directly* to each other, as "equals" or 
> > "peers", is much more natural than one DNS instance relying upon another to 
> > handle all of its resolution needs (thus making the first instance 
> > subservient, in a sense, to the second), which then relies on another, and 
> > to another, and so on, in a daisy chain.
> > 
> > Again, maybe it's just a different mindset/world-view. Or, perhaps I'm 
> > over-generalizing a cultural difference from a relatively-small sample of 
> > conversations. But, as I touched on in my second paragraph, there may be 
> > some objective reasons to eschew forwarding, particularly multi-hop 
> > forwarding.
> > 
> >- Kevin
> > 
> > 
> > -Original Message-
> > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of 
> > Willmann, Robert
> > Sent: Friday, August 12, 2016 1:33 AM
> > To: bind-users@lists.isc.org
> > Subject: RE: Delegation questions
> > 
> > Kevin Darcy wrote:
> >> 
> >> In any case, multi-hop forwarding is always the least-preferred option.
> > 
> > I wonder for which reason do you think this.
> > 
> > Of course, any forwarding adds a additional hop and therefore additional 
> > delay and an additional possible point of failure.
> > But this is true for any network-connection.
> > 
> > So, what do you think are the DNS-specific downsides of forwarding?
> > The only thing that comes to mind if I think about downsides of forwarding 
> > is that, if something goes wrong, the client only gets a generic SERVFAIL 
> > as errormessage instead of a specific explanation what exactly went wrong.
> > 
> > Do you see other downsides to forwarding?
> > 
> > 
> > Mit freundlichen Grüßen
> > Robert 

Re: resolution problem

[Sam Wilson]

In article ,
 Matus UHLAR - fantomas  wrote:

> On 18.05.16 14:10, Con Wieland wrote:
> >I am having an issue resolving www.cloudsat.cira.colostate.edu from 2 of my
> > name servers.  I have 2 others with identical configs that resolve
> > correctly.  A normal lookup shows a server fail but a +trace looks ok. 
> > Any ideas how to better troubleshoot the issue?
> 
> tried web dns checkers? Some of them use to provide useful results.
> 
> >dig www.cloudsat.cira.colostate.edu @ns1.service.uci.edu
> [...]
> >;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1057
> 
> 
> >colostate.edu.  172800  IN  NS  dns1.colostate.edu.
> >colostate.edu.  172800  IN  NS  dns3.colostate.edu.
> >;; Received 119 bytes from 192.41.162.30#53(l.edu-servers.net) in 78 ms
> >
> >www.cloudsat.cira.colostate.edu. 3600 IN CNAME  dpc.cira.colostate.edu.
> >dpc.cira.colostate.edu. 3600IN  A   129.82.109.62
> >;; Received 83 bytes from 129.82.103.121#53(dns1.colostate.edu) in 36 ms
> 
> often a problem of invalid NS delegation, or bad TTL (A record for a server
> expires before NS record).

Glue A records for the nameservers have 172800 TTL, authoritative A 
records have 1200.  

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Intermittent Issues Resolving Microsoft Hostnames

[Sam Wilson]

In article ,
 Stephane Bortzmeyer  wrote:

> On Wed, May 04, 2016 at 02:02:24PM -0400,
>  Rob Heilman  wrote 
>  a message of 305 lines which said:
> 
> > We run BIND 9.9.5-9 on Debian x86_64 to support a moderately sized
> > email hosting system.  System info listed at the end of this
> > message.  We are seeing intermittent but frequent issues resolving
> > Microsoft records.  The hostnames are usually in the form of
> > *.mail.protection.outlook.com
> 
> protection.outlook.com has a legal but unusual setup. It has only two
> name servers (not enough for an important domain) but each has several
> IP addresses. It should work because the RFC says that the resolver
> has to try every _address_ not just every name. And I'm confident BIND
> does the right thing.
> 
> However, one can note that both name servers have _exactly_ the same
> set of IP addresses. Again, it should work, but this setup is strange.

 (and its duplicate at 
) both report a) that neither/none of the 
servers supports queries over TCP and b) that there is no SOA for the 
zone mail.protection.outlook.com.  Using dig from my desktop confirms 
the TCP analysis and that when queried for the SOA they return 
NOERROR/NODATA, but with an authority section containing the SOA that's 
been queried for.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Adding CNAME for the root domain issue

[Sam Wilson]

In article ,
 "Baird, Josh"  wrote:

> Any thoughts on a service like Cloudfare's 'CNAME Flattening' [1]?
> 
> [1] 
> https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/


Does anyone else find themselves mentally yelling "apex!" whenever they 
read the word "root" in that document?


Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: frequent queries to root servers

[Sam Wilson]

In article ,
 Grant Taylor  wrote:

> I think chained CNAMEs fall into the gray area (no mans land) between 
> zealots on either side of the RFC interpretation line.
> 
> If chained CNAMEs work for you, more power to you.  But don't be 
> surprised if they fail unexpectedly at some point.

We should be warning those niche players Microsoft and Akamai.

$ dig www.microsoft.com

; <<>> DiG 9.8.5-P1 <<>> www.microsoft.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18453
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 8, ADDITIONAL: 8

;; QUESTION SECTION:
;www.microsoft.com. IN A

;; ANSWER SECTION:
www.microsoft.com.   846   IN CNAME www.microsoft.com-c.edgekey.net.
www.microsoft.com-c.edgekey.net. 1362 IN CNAME  
www.microsoft.com-c.edgekey.net.globalredir.akadns.net.
www.microsoft.com-c.edgekey.net.globalredir.akadns.net.  2897 IN  CNAME 
e10088.dspb.akamaiedge.net.
e10088.dspb.akamaiedge.net. 6 IN A  2.18.4.103

[snip]

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: A tale of two nameservers - resolution problems

[Sam Wilson]

In article ,
 Robert Moskowitz  wrote:

> I will be looking more into this.  Obvious when you get ones nose 
> dragged into time wrong on boot.  This is actually a broader problem on 
> arm SoC booting.  Your logs all have the wrong time for the boot 
> messages until there is a network to get time.  I have some ideas for a 
> process that will set time a boot to the time of the last poweroff.  at 
> least that is 'close enough' for starters.

I believe that's the solution Apple adopted for the AppleTV, which has 
no rtc and couldn't use a certificate to connect to a wireless network 
because the certificate wasn't valid in 1970.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Digging to the final IP

[Sam Wilson]

In article mailman.1128.1414072988.26362.bind-us...@lists.isc.org,
 Bob Harold rharo...@umich.edu wrote:

 Anytime you see 'grep' and 'cut' used together, they can usually be
 shortened to just 'awk', which requires starting one less process.  And if
 this case it splits fields the way a users sees them, so the same code
 works in both cases:
 
 $ dig +noall +answer home.kreme.com in a | awk '/[\t ]A[\t ]/ {print $NF}'
 23.24.150.141
 $ dig +noall +answer  dave.knig.ht in a | awk '/[\t ]A[\t ]/ {print $NF}'
 216.235.14.46

$ dig +noall +answer cancer.ucs.ed.ac.uk | perl -ne ' /\sA\s/  do { 
@_=split; print $_[$#_]\n }' 
129.215.166.13
129.215.200.7

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Change in behaviour regarding ndots and searchlist

[Sam Wilson]

In article mailman.957.1410786839.26362.bind-us...@lists.isc.org,
 Steven Carr sjc...@gmail.com wrote:

 Without the final explicit . your name is not fully qualified.

Except in an email address where a trailing . is illegal.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: A record of domain name must be name server ?

[Sam Wilson]

In article mailman.892.1410364699.26362.bind-us...@lists.isc.org,
 Alan Clegg a...@clegg.com wrote:

 On 9/10/14, 8:42 AM, Sam Wilson wrote:
 
  And you could reduce maintenance very slightly by replacing
  
  www in  A   75.100.245.133
  
  with 
  
  www in  CNAME   @
 
 And now you have an MX record, 3 NS records and a bunch of other crap
 associated with the WWW address.  Keeping track of one extra A record
 (and associated  record if you go in that direction) isn't a bad thing.

And the discussion went on from there.  Sorry, I really didn't mean to 
poke a hornets' nest.

 (Personal preferences, of course)

Personal preference and dependent on the exact needs of the users of the 
data, of course.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: A record of domain name must be name server ?

[Sam Wilson]

In article mailman.902.1410422525.26362.bind-us...@lists.isc.org,
 Antonio Querubin t...@lavanauts.org wrote:

 On Thu, 11 Sep 2014, Matus UHLAR - fantomas wrote:
 
  If you point www CNAME @, the 'www' will have both MX and NS records same as
  example.com.  Which may e.g. cause rejectd on backup MX hosts, apparently
  not designed to receive mail for www.example.com.
 
 Actually no.  All other RRs are supposed to be ignored (except for RRSIG, 
 etc) once the CNAME exists.  Ie. the MX and NS RRs exist only for 
 example.com, but not www.example.com.

I think that's a misunderstanding of what Matus wrote.  With separate A 
records then www.example.com will only have an A record.  If you alias 
www to @ then looking up MX and NS records for www will return the ones 
for example.com.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: A record of domain name must be name server ?

[Sam Wilson]

In article mailman.890.1410357943.26362.bind-us...@lists.isc.org,
 sch...@adi.com (Thomas Schulz) wrote:

  Hi,
  
  xxx.com and IP address 192.168.1.100 is just a example domain name and IP
  address. Our boss want everybody access our domain example.com through
  browser, then it will redirect to our web site www.example.com. So I want
  to get more information about unexpected impact when we changed DNS records.
  
  Thanks for your help.
  
  Best Regards,
  Pete Fong
 
 Here is how I have things set up here. Our domain is adi.com. We have
 three name servers set up. Our web site can be accessed as both
 www.adi.com and adi.com. Here is what I have on our zone file:
 
 
 @   in  ns  bluegill.adi.com.
 in  ns  a.dns.tds.net.
 in  ns  seahorse.adi.com.
 
 bluegillin  A   75.100.245.131
 seahorsein  A   75.100.245.134
 www in  A   75.100.245.133
 @   in  A   75.100.245.133
 
 @   in  mx  0   mackerel.adi.com.
 in  mx  10  seahorse.adi.com.
 in  mx  20  bluegill.adi.com.
 
 Note that address 75.100.245.133 is entered twice.
 The mx records are to get email to work correctly.

And you could reduce maintenance very slightly by replacing

www in  A   75.100.245.133

with 

www in  CNAME   @

Though in Thomas' case the PTR record for 75.100.245.133 returns 
www.adi.com, so that's a good reason for not doing the CNAME thing.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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 and listening on interfaces

[Sam Wilson]

In article mailman.722.1406907165.26362.bind-us...@lists.isc.org,
 Reindl Harald h.rei...@thelounge.net wrote:

 Am 01.08.2014 um 17:16 schrieb Barry Margolin:
  In article mailman.720.1406904401.26362.bind-us...@lists.isc.org,
   Reindl Harald h.rei...@thelounge.net wrote:
  
  the thread yesterday reminded me on my Fedora bugrpeort
  https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c3
  https://bugzilla.redhat.com/show_bug.cgi?id=1073038#c8
 
  i don't buy Note that destination IP address must be
  known and set correctly in reply, otherwise clients
  will be confused because how does it survive NAT
  
  What's meant is that the source address of the reply must match the 
  destination address of the request. This is the how TCP behaves 
  automatically, since it involves connections, but all UDP packets are 
  independent. When BIND sends a reply message, the stack doesn't know 
  that it's related to a particular incoming message whose IPs should be 
  flipped.
  
  It survives NAT because the router remembers how it translated the 
  incoming packet. When it sees an outgoing packet with the translated IP 
  and port, it undoes the translation
 
 yes and no
 
 iptables knows the concept of  -p udp -m conntrack --ctstate NEW
 so the stack somehow knows, not the same way as TCP but it knows
 
 other UDP services like OpenVPN, dhcpd, avahi or mediathomb just
 listening on UDP 0.0.0.0:port and just working

Works fine on single-homed hosts, can break on multi-homed hosts.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Default query type of dig

[Sam Wilson]

In article mailman.434.1403713820.26362.bind-us...@lists.isc.org,
 Scott Bertilson s...@umn.edu wrote:

 Don't know if you can control the default query type, but this is a RTFM
 (see man dig):
 
 It is possible to set per-user defaults for dig via ${HOME}/.digrc. This
 file is read and any options in it are applied before the command line
 arguments.

You can put '-t ' in .digrc and dig will default to  queries.  
Unfortunately in the version I have this also overrides the default PTR 
type for -x queries.  Other queries seem to work fine. (DiG 9.8.5-P1, 
supplied with Mac OS X 10.8).

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Point domain name of my zone to name in somebody else's zone?

[Sam Wilson]

In article mailman.212.1399660752.26362.bind-us...@lists.isc.org,
 Kevin Darcy k...@chrysler.com wrote:

 On 5/9/2014 6:59 AM, Tony Finch wrote:
  Dave Warren da...@hireahit.com wrote:
  I actually think that MX records were a boneheaded thing to do, had email
  started using SRV records in the first place we might be in a position now
  where using SRV records is the defacto standard if not the actual standard 
  for
  all services. (No offense to the folks that made MX records happen, I 
  realize
  that in historical context it was the correct decision and it solved the 
  very
  immediate problem -- I'm just saying that in an ideal world, SRV records
  instead of MX records would solved the same problem in a more generic 
  fashion,
  and would have pushed us to a better place for other protocols)
  It is interesting to look at the old RFCs and see how many false starts it
  took to get to the MX design. Mail was the first heavily virtualized
  application so I think their failure to generalize was forgivable,
  especially since they were also dealing with the massive problem of
  gatewaying between dozens of balkanized mail networks.
 
  http://stuff.mit.edu/afs/athena/reference/net-directory/documents/JANET-Mail
  -Gateways.ps
 
 Indeed. Hindsight is 20/20. Mail was the killer app for the early 
 Internet, and providing a way to route it over the Internet, with 
 automatic load-balancing and failover, was a major achievement. Sure, 
 the IETF could have spent a few more years coming up with a generic 
 way to do things, throwing in -- as SRV eventually did -- port 
 reassignment, weighting and namespace semantics, but how much would that 
 delay have stunted the growth of the nascent technology? Maybe it would 
 have resulted in OSI/X.400 surpassing SMTP as the predominant mail 
 transport, and we'd all be *miserable*.

Actually some of us who were already using a more sophisticated naming 
scheme[1] were disappointed that the DNS was really only a replacement 
for HOSTS.TXT.  That was one of the few downsides of joining the 
Internet.

Sam

[1] http://en.wikipedia.org/wiki/JANET_NRS 3rd paragraph

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Private separate DNS domains

[Sam Wilson]

In article mailman.2610.1396955773.20661.bind-us...@lists.isc.org,
 Joseph S D Yao j...@tux.org wrote:

 On 2014-04-08 06:08, Bryan Harris wrote:
  ...
  The current mechanism is to put the Windows AD server into the
  resolv.conf BEFORE the BIND servers, since, as has been explained to
  me a Linux server will perform a query against all three
  simultaneously (that doesn’t immediately ring true to me, it’s just
  what I was told).  ...
 ...
 
 
 You were told wrong about simultaneously from /etc/resolv.conf.  It 
 uses the first one that gives an answer.  If the first one times out, it 
 asks the next and ignores any response from the first, etc.  (If you 
 think about it, what happens if two simultaneously respond with 
 different answers?  If one never responds?) ...

Novell's LAN Workplace for DOS used to do simultaneous queries to 
however many (max 3 IIRC) servers you put in its RESOLV.CFG.  I've never 
seen it happen on a *ix/*ux box.  I can't remember if the slower servers 
received port unreachables when their answers trailed in behind the 
leader.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: High recursive client counts

[Sam Wilson]

In article mailman.2530.1395774135.20661.bind-us...@lists.isc.org,
 Jason Brandt jbra...@fsmail.bradley.edu wrote:

 For now, I've disabled DNS inspection on our firewall, as it is an ancient
 Cisco firewall services module, and that seems to have stabilized things,
 but it's only been 30 minutes or so.  Until I get a few days in, I'll keep
 researching.

We used to run DNS inspection on our FWSMs.  We didn't notice any issues 
with DNS resolution per se, but we did find that turning it off dropped 
the FWSM CPU from ~70% to less than 30%.  We're not aware of any issues 
that using DNS inspection might have caused.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: High recursive client counts

[Sam Wilson]

In article mailman.2540.1395835774.20661.bind-us...@lists.isc.org,
 Jason Brandt jbra...@fsmail.bradley.edu wrote:

 The code on our FWSMs isn't the latest release, so that could be part of
 the issue, but it's been about 16 hours now since I shut it off, and so far
 so good.  I would say though with the other load on our firewalls, it's
 highly possible that they were being overloaded.  Unfortunately our MRTG
 isn't setup to track firewall CPU, so I can't say for sure.

Logging into your FWSM and doing 'show cpu usage' when things are going 
badly might be an option, but if you've got MRTG monitoring the 6500 
that the FWSM is in you could also have a look at the traffic on the 
virtual ethernets that connect to the FWSM.  Whilst they don't show up 
on 'show int' they and a 6 Gbps portchannel are visible to SNMP and in 
'show firewall module X traffic' (or 'show firewall switch X module Y 
traffic' in a VSS setup)..

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Can we do a sub-domain delegation with godaddy?

[Sam Wilson]

In article mailman.2063.1389807192.20661.bind-us...@lists.isc.org,
 Warren Kumari war...@kumari.net wrote:

 On Tue, Jan 14, 2014 at 12:39 PM, Blason R blaso...@gmail.com wrote:
  Hi Folks,
 
  I am not sure if this is an appropriate forum to answer since more or less
  it is pertaining to Go Daddy support but since its a huge community our
  there and I am sure many of them are already using Go Daddy wondering if
  su-domain delegation is possible in Go Daddy?
 
 Yes, yes it is...
 I run my own DNS, but have a few test domains for playing with stuff
 like this, and just tested it...
 
 
  I mean I have example.com hosted with Go Daddy while I need sub-domain
  ftp.example.com to be delegated to my internal BIND server.
 
 So, your question is a little vague / incomplete. ftp.example.com is
 *probably* a host name in example.com, and not a delegation.
 ...

Unless it's a delegation to a loadbalancer - a configuration we see 
plenty of examples of on this list.

-- 
Sam Wilson
Communications Infrastructure Section, IT Infrastructure
Information Services, The University of Edinburgh
Edinburgh, Scotland, UK

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Can I have Inbound load balancing achieved with below settings

[Sam Wilson]

In article mailman.1686.1384528769.20661.bind-us...@lists.isc.org,
 Blake Hudson bl...@ispn.net wrote:

 Phil Mayers wrote the following on 11/14/2013 2:39 AM:
  I think there are better solutions than publishing an enormous list of 
  A/ records, personally, and I think it's good that browser 
  manufacturers aren't blasting out 6 SYNs every time someone types 
  www.google.com...
 On a related note, I have seen recent Comtrend DSL modems (w/ integrated 
 router and DNS cache) send out parallel DNS requests to both of the 
 configured DNS servers. The debug log on the modem indicates that the 
 modem throws away latter responses.

Novell's LAN Workplace for DOS client used to issue simultaneous DNS 
requests to all configured resolvers.  IIRC all meant a maximum of 3.  
You could add more servers to its resolv.conf equivalent (RESOLV.CFG?) 
but it ignored all but the first three.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Reverse address entries

[Sam Wilson]

In article mailman.807.1373643569.20661.bind-us...@lists.isc.org,
 Novosielski, Ryan novos...@ca.rutgers.edu wrote:

 Came across another instance where [reverse lookups] may matter: TCP Wrappers.
 Although the case there was a bit more peculiar -- rr.net does not
 appear to have FORWARD DNS for at least some of its dynamic address
 space. So you can get a PTR, and then address validation fails on the
 forward address. I guess perhaps if you had no PTR it would never go
 that far.

Yep, when you have PTRs they should agree with the A records or paranoid 
reverse lookup will fail.  That should still be fairly quick, though, 
since there should be NXDOMAIN responses to the forward lookups rather 
than timeouts.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Reverse address entries

[Sam Wilson]

In article mailman.736.1372773195.20661.bind-us...@lists.isc.org,
 Steven Carr sjc...@gmail.com wrote:

 On 2 July 2013 14:42, Sam Wilson sam.wil...@ed.ac.uk wrote:
  Can anyone here give examples of the types of various software that will
  not operate without a PTR record?
 
 There have already been numerous listings of software that require
 reverse lookups. SMTP being the main one. Other services like IRC and
 some databases (Oracle/MySQL) can also be configured to require
 properly working reverse lookups.

... can also be configured ... - see below.

  I agree that if PTR records exist then they should match an A record.
  My experience (and IIRC correctly the word of several RFCs) is that PTRs
  are not required for most things to work.
 
 RFC1912 [http://tools.ietf.org/html/rfc1912] section 2.1...
 
 Every Internet-reachable host should have a name... Make sure your PTR
 and A records match.  For every IP address, there should be a matching
 PTR record in the in-addr.arpa domain.  If a host is multi-homed,
 (more than one IP address) make sure that all IP addresses have a
 corresponding PTR record (not just the first one). Failure to have
 matching PTR and A records can cause loss of Internet services similar
 to not being registered in the DNS at all.  Also, PTR records must
 point back to a valid A record, not a alias defined by a CNAME.

Sorry for the delay in returning to this.  RFC 1912 says:

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind. ...

To make myself clear, I'm a big fan of correct PTR records and we try to 
make sure that our reverse DNS is fully populated.  I do not regard lack 
of a valid PTR record to be a reason to refuse connection except, 
perhaps, in very particular circumstances, for instance where it might 
be part of a trust stance.  That would be by agreement between 
consenting adults, not the law of Internetland in general.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Reverse address entries

[Sam Wilson]

In article mailman.737.1372773227.20661.bind-us...@lists.isc.org,
 Daniel McDonald dan.mcdon...@austinenergy.com wrote:

 On 7/2/13 8:42 AM, Sam Wilson sam.wil...@ed.ac.uk wrote:
 
  There may be a subtle language thing going on here.  I read the original
  post above as saying, literally, you need PTR records because various
  software tries to match A and PTR records.  It doesn't say you need
  PTR records because some systems require PTR records (and if you have
  them they will also need to match the A records).  PTR records are nice
  but they aren't a general requirement.
  
  Can anyone here give examples of the types of various software that will
  not operate without a PTR record?
 
 I've had trouble with OSI-Soft PI historian without reverse entries.  If
 there is no reverse, then the PI software would spend about 30 seconds
 looking in vain for a DNS answer before sending a SYN-ACK packet.  Since the
 embryonic timer on a Cisco firewall is usually 20 seconds, the sessions
 would simply not come up. I've seen similar things with openssh.

That seems fairly weird.  If there is no DNS entry then that should be 
determinable in the same time as getting a valid entry.  If there's 
broken DNS resolution that's much more likely to cause the 30s timeout, 
which is very likely due to the system trying to log the name of the 
incoming client.

 The other place reverse DNS is routinely queried is SMTP.  If you care
 enough to send mail, you should care enough to set up your reverse entries
 realistically so that spam filters will recognize that you are trying to
 actively manage your email server and this isn't mail from a BOT...

Routine query, yes; refusal of service based (solely?) on lack of a PTR 
record is not, so far as I can tell, widespread.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: configure syslog prefix

[Sam Wilson]

In article mailman.731.1372769988.20661.bind-us...@lists.isc.org,
 Tony Finch d...@dotat.at wrote:

 Klaus Darilion klaus.mailingli...@pernau.at wrote:
 
  Some software allows to configure the syslog prefix, but I couldn't find 
  that
  for bind.
 
 Rename the named executable.

Assuming a Unix-like OS would having multiple links (hard or soft) have 
the correct effect?

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Reverse address entries

[Sam Wilson]

In article mailman.727.1372684591.20661.bind-us...@lists.isc.org,
 Matus UHLAR - fantomas uh...@fantomas.sk wrote:

  In article mailman.710.1372442831.20661.bind-us...@lists.isc.org,
   Charles Swiger cswi...@mac.com wrote:
   Certainly.  Various software performs what's called a double-reverse
   lookup
   to confirm that the A and PTR records match.
 
 In article mailman.718.1372672345.20661.bind-us...@lists.isc.org,
  Matus UHLAR - fantomas uh...@fantomas.sk wrote:
  He apparently meant exactly the same. Also calles FcRDNS - forward
  confirmed or full circle reverse DNS.
 
 On 01.07.13 14:11, Sam Wilson wrote:
 OK.  So what Mr. Swiger refers to is not relevant - it's no reason to
 add PTR records.
 
 Yes, it is.
 
 Various software performs what's called a double-reverse lookup to confirm
 that the A and PTR records match.
 
 It means that various software checks your PTR and then A (or maybe
 ) records, and can fail if eny of them is not found ot rhe latter result
 doesn't match the original IP address.

There may be a subtle language thing going on here.  I read the original 
post above as saying, literally, you need PTR records because various 
software tries to match A and PTR records.  It doesn't say you need 
PTR records because some systems require PTR records (and if you have 
them they will also need to match the A records).  PTR records are nice 
but they aren't a general requirement.

Can anyone here give examples of the types of various software that will 
not operate without a PTR record?

 Now that IS a reason to add PTR for IP address, and they must point to
 hostnames that point to the same IP.

I agree that if PTR records exist then they should match an A record.  
My experience (and IIRC correctly the word of several RFCs) is that PTRs 
are not required for most things to work.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Reverse address entries

[Sam Wilson]

In article mailman.710.1372442831.20661.bind-us...@lists.isc.org,
 Charles Swiger cswi...@mac.com wrote:

 On Jun 28, 2013, at 10:54 AM, Ward, Mike S mw...@ssfcu.org wrote:
  Hello all, is there any reason to setup reverse address entries for a zone?
 
 Certainly.  Various software performs what's called a double-reverse lookup
 to confirm that the A and PTR records match.

Isn't that paranoid reverse lookup?  Since reverse lookups can be faked 
(I'll spare the details here) some uses of in-addr.arpa also require a 
subsequent forward lookup.  If there is no PTR record then the double 
lookup doesn't happen.  I don't know of anything to be gained by 
requiring a reverse lookup after a forward lookup.

  I have asked some of the admins here and the consensus from them is that 
  only A records are necessary. Is this true?
 
 I suppose that depends on how wide (or limited) one's view of necessary is.
 
 Many mail systems choose not to grant much trust towards IPs without good 
 DNS.
 Java's SSL on some platform performs a double-reverse check and declines to 
 proceed if there is a mismatch.

It's nice for humans too.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Reverse address entries

[Sam Wilson]

In article mailman.718.1372672345.20661.bind-us...@lists.isc.org,
 Matus UHLAR - fantomas uh...@fantomas.sk wrote:

  On Jun 28, 2013, at 10:54 AM, Ward, Mike S mw...@ssfcu.org wrote:
   Hello all, is there any reason to setup reverse address entries for a 
   zone?
 
 In article mailman.710.1372442831.20661.bind-us...@lists.isc.org,
  Charles Swiger cswi...@mac.com wrote:
  Certainly.  Various software performs what's called a double-reverse 
  lookup
  to confirm that the A and PTR records match.
 
 On 01.07.13 10:48, Sam Wilson wrote:
 Isn't that paranoid reverse lookup?  Since reverse lookups can be faked
 (I'll spare the details here) some uses of in-addr.arpa also require a
 subsequent forward lookup.  If there is no PTR record then the double
 lookup doesn't happen.  I don't know of anything to be gained by
 requiring a reverse lookup after a forward lookup.
 
 He apparently meant exactly the same. Also calles FcRDNS - forward
 confirmed or full circle reverse DNS.

OK.  So what Mr. Swiger refers to is not relevant - it's no reason to 
add PTR records.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.78.1365430543.20661.bind-us...@lists.isc.org,
 Phil Mayers p.may...@imperial.ac.uk wrote:

 On 08/04/13 14:46, Sam Wilson wrote:
  In article mailman.59.1365230565.20661.bind-us...@lists.isc.org,
Phil Mayers p.may...@imperial.ac.uk wrote:
 
  Sam Wilson sam.wil...@ed.ac.uk wrote:
 
  [adding an A record for ed.ac.uk.]
 
 
  If your AD realm is also called ed.ac.uk then adding an A record will
  definitely affect things.
 
  Which is exactly the opposite of what our AD guys said, but not with
  such great conviction.  :-)
 
 Off the top of my head the two most recent issues we've had.
 
 1. If you don't have a domain controller A record at your AD realm name, 
 you'll experience sporadic timeouts and slowness if you ever want to 
 roll out DFS, particularly if your domain members include non-Microsoft 
 clients such as Macs
 
 2. If you put something else at that place, you'll see SMB connection 
 attempts and if they fail but port 80 is open, you'll see Windows trying 
 to do WebDAV requests (!) to it.
 
 Both these and other issues make me wish we'd chosen a sub-domain for 
 our AD realm when we migrated from NT4. But we had no way of knowing at 
 the time :o(

Thank you (belatedly) for that information.  As I think I remarked 
elsewhere we wished to retain the existing structure of our DNS, with 
some domains delegated to others (as well as a lot that we delegate to 
ourselves) which needed to be in the same AD thingy[*].  Forcing another 
layer of DNS naming between the institution and the department seemed 
inappropriate.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.79.1365435117.20661.bind-us...@lists.isc.org,
 Barry S. Finkel bsfin...@att.net wrote:

 On 4/8/2013 9:10 AM, bind-users-requ...@lists.isc.org wrote:
  In article mailman.59.1365230565.20661.bind-us...@lists.isc.org, Phil
  Mayers p.may...@imperial.ac.uk wrote:
  Sam Wilsonsam.wil...@ed.ac.uk  wrote:
  
   [adding an A record for ed.ac.uk.]
   
  
  If your AD realm is also called ed.ac.uk then adding an A record will
  definitely affect things.
  Which is exactly the opposite of what our AD guys said, but not with
  such great conviction.:-)
 
  Sam
 
 AD clients, if they do not know about SRV records for finding the
 LDAP servers, will use the A records for the AD domain to locate
 the Domain Controllers.  ...

Can you identify any such clients?  Phil Mayers has already mentioned 
non-MS DFS clients and other things (MS?) which might try SMB and WebDAV 
to an A record at the AD domain name.  Are there others?

 ... Where I used to work we did not segregate
 AD, so internally,
 
   example.com
 
 pointed to the Domain Controllers.  Externally,
 
   example.com
 
 had no IP address because the DCs were not accessible from the
 external Internet.  When we had the DC addresses externally, then
 AD clients would see the addresses, try to authenticate to the AD,
 experience timeouts, and get frustrated.  Without an external
 address, AD clients do not try to access the DCs.  The drawback
 is that we can not have
 
   example.com
 
 externally have the same address as
 
   www.example.com
 
 to aid browser users.

Which is exactly where I came in - the people who manage our corporate 
image feel that this is unacceptable and reflects badly on the 
University.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.86.1365490964.20661.bind-us...@lists.isc.org,
 Phil Mayers p.may...@imperial.ac.uk wrote:

 On 04/08/2013 06:59 PM, Novosielski, Ryan wrote:
 
  Someone can correct me if I'm wrong, but I think they'd be right if
  and only if the webserver they're adding the A record for happens to
  also be the AD server.
 
 In principle that's correct.
 
 In practice, running a publicly accessible webserver on your AD 
 controllers is a bad move IMO. The security implications are gruesome.
 
 I think I almost dislike the idea so much that I'd suggest split DNS 
 before this. And given how much I dislike split DNS, that's saying 
 something.
 
 But hey, to each their own.

In our case it would be impossible for the University's public web 
presence and the AD domain controllers to be the same machines.  It is 
conceivable that we could do some magic in load balancers to divide 
traffic appropriately, but I'd rather not do that if I don't have to.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.84.1365479484.20661.bind-us...@lists.isc.org,
 Doug Barton do...@dougbarton.us wrote:

 On 04/08/2013 06:54 AM, Sam Wilson wrote:
  In article mailman.61.1365232319.20661.bind-us...@lists.isc.org,
Doug Barton do...@dougbarton.us wrote:
  On 04/05/2013 11:53 PM, Novosielski, Ryan wrote:
 
  | It is funny you should mention that... my questions about using views
  | to create a situation where one single record is different happens to
  | be exactly for this reason. The Active Directory administrators were
  | saying that not having umdnj.edu point to an Active Directory server
  | was bothering the AD servers in some fashion. The solution we're going
  | to test is telling the AD servers that umdnj.edu are them, but telling
  | everyone else on the planet that it's www. We think this will do it,
  | but haven't tested yet.
 
  Much better to put the AD stuff in its own subdomain, like ad.umdnj.edu.
  AD DNS is only really happy when it runs the whole show for its home
  domain. It's possible to do otherwise, but really painful and fragile.
 
  We've been running our main domain with the underscore domains delegated
  to AD for well over a decade and it's been neither painful nor fragile,
 
 You apparently missed the context of the response. :)
 
 I didn't say impossible, and I've set it up the way you describe in 
 the past. But it assumes both an initial and ongoing level of clue that 
 is not always available. Whereas, put all the AD stuff in its own 
 subdomain is both pain-less, and has other advantages.

It would not have been painless for us.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.108.1365771792.20661.bind-us...@lists.isc.org,
 Dave Sparro dspa...@gmail.com wrote:

 On 4/6/2013 12:46 AM, Lawrence K. Chen, P.Eng. wrote:
  So, up until a couple years ago...our webmail address had always been, and 
  only webmail.ksu.edu.  But, under the new directionit has to work as 
  webmail.ksu.edu, www.webmail.ksu.edu, 
  webmail.k-state.edu,www.webmail.k-state.edu. and SSL certs to work for 
  all those.
 Sounds like it is time to have some fun with recursion...
 You should mention that since www.webmail.ksu.edu exists, 
 www.www.webmail.ksu.edu should work too.  :D

We once wondered about obtaining an EDU domain, and pondered on what 
domain our Faculty of Education might want to use.  The University of 
Edmonton may have had similar thoughts.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.49.1365191296.20661.bind-us...@lists.isc.org,
 wbr...@e1b.org wrote:

  Incidentally, we have just been asked for an A record for cam.ac.uk to
  duplicate www.cam.ac.uk because, and I quote, all the publicity 
 material
  sent out by the nominator [for an award for the web site] gave the URL
  as http://cam.ac.uk/ and this has been retweeted around.
  
  Yes, sadly I've lost that technical battle with marketing several places
  now.
 
 And then there's theses folks:
 
 http://no-www.org/ 

Is co-opting high-level name space for a single protocol a modern-day 
landgrab?  Discuss.  Points will be deducted for uncritical mentions of 
SRV records.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.51.1365192701.20661.bind-us...@lists.isc.org,
 Dave Warren li...@hireahit.com wrote:

 On 2013-04-05 12:18, Sam Wilson wrote:
  We're currently prevaricating over putting in an A record for ed.ac.uk.
  Whilst my colleagues who manage active directory assure me that having
  an A record there - pointing at the content-managed web server that has
  difficulty handling arbitrary URLs - won't break anything I'm not going
  to try it except under very controlled conditions and after I've spoken
  to a lot of other people who do it already.
 
 Is ed.ac.uk your Active Directory root as well? If so, my experience is 
 that pointing it at anything but domain controllers will eventually lead 
 you to issues.

It is.  That's the sort of response I was hoping for - thank you.

 It's not to say that this totally forbidden, but there is (was?) 
 Microsoft best practices documents suggesting avoiding this 
 configuration entirely when possible, although there were ways to 
 mitigate most of the negative side effects.

If you know of a reference that would be helpful.

 Obviously if you can run a split DNS environment this is less of a factor.

We don't and we're trying not to have to.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.59.1365230565.20661.bind-us...@lists.isc.org,
 Phil Mayers p.may...@imperial.ac.uk wrote:

 Sam Wilson sam.wil...@ed.ac.uk wrote:
 
  [adding an A record for ed.ac.uk.]
  
 
 If your AD realm is also called ed.ac.uk then adding an A record will 
 definitely affect things.

Which is exactly the opposite of what our AD guys said, but not with 
such great conviction.  :-)

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.61.1365232319.20661.bind-us...@lists.isc.org,
 Doug Barton do...@dougbarton.us wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256
 
 On 04/05/2013 11:53 PM, Novosielski, Ryan wrote:
 
 | It is funny you should mention that... my questions about using views
 | to create a situation where one single record is different happens to
 | be exactly for this reason. The Active Directory administrators were
 | saying that not having umdnj.edu point to an Active Directory server
 | was bothering the AD servers in some fashion. The solution we're going
 | to test is telling the AD servers that umdnj.edu are them, but telling
 | everyone else on the planet that it's www. We think this will do it,
 | but haven't tested yet.
 
 Much better to put the AD stuff in its own subdomain, like ad.umdnj.edu.
 AD DNS is only really happy when it runs the whole show for its home
 domain. It's possible to do otherwise, but really painful and fragile.

We've been running our main domain with the underscore domains delegated 
to AD for well over a decade and it's been neither painful nor fragile, 
at least no more painful than running AD any other way as far as I can 
tell.  We already had a well partitioned and, in some cases, delegated 
DNS structure before Windows 2000/Active Directory came on the scene, 
but we needed to have a single AD thingy (forest? domain?  I can't 
remember the correct terminology).  Replicating all of that under a new 
functional domain didn't seem like a sensible option.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.70.1365423010.20661.bind-us...@lists.isc.org,
 wbr...@e1b.org wrote:

 Warren Kumari war...@kumari.net wrote on 04/05/2013 06:48:08 PM:
 
   And then there's theses folks:
   
   http://no-www.org/ 
   
  
  Oh wow!
  
  Gee, thanks for that?
 
 And it's always fun when you tell someone to go to a URL that doesn't 
 include the W's and they want to type them in anyways, ie. 
 chat.example.com.

Oh yes.  Sigh...

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Simple question about zone and CNAME

[Sam Wilson]

In article mailman.46.1365189018.20661.bind-us...@lists.isc.org,
 Chris Thompson c...@cam.ac.uk wrote:

 On Apr 5 2013, John Wobus wrote:
 
  DNAME? runs away, giggling…
 
 Or SRV records.  Surely browsers are adding support
 in the next day or two?
 
 Come on, April 1 has been over for too long for this.
 
 Incidentally, we have just been asked for an A record for cam.ac.uk to
 duplicate www.cam.ac.uk because, and I quote, all the publicity material
 sent out by the nominator [for an award for the web site] gave the URL
 as http://cam.ac.uk/ and this has been retweeted around.

We're currently prevaricating over putting in an A record for ed.ac.uk.  
Whilst my colleagues who manage active directory assure me that having 
an A record there - pointing at the content-managed web server that has 
difficulty handling arbitrary URLs - won't break anything I'm not going 
to try it except under very controlled conditions and after I've spoken 
to a lot of other people who do it already.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Delegations

[Sam Wilson]

In article mailman.564.1351726720.11945.bind-us...@lists.isc.org,
 Mark Andrews ma...@isc.org wrote:

 In message 5091adef.1040...@dougbarton.us, Doug Barton writes:
  On 10/31/2012 03:56 PM, Mark Andrews wrote:
   You are equating a practice that was techically wrong, and known
   to be wrong from the get go, with one that has never been techically
   wrong.
  
  Yes, I'm making exactly the same judgment that typical users make. It
  works, so it must be Ok.
  
  The fact that we (experts) can get away with something, whether it's
  technically right/wrong/indifferent not withstanding, doesn't mean that
  it's good advice for the average user.
  
  Doug
 
 Putting in delegations where they are not needed introduces additional
 work and more places that can go wrong.

And also (he said very quietly indeed after delurking) increases the 
granularity of management.  Being able to reload or work on a small 
(sub)zone rather than a large one can have advantages, which of course 
have to be balanced with the extra effort involved in setting such a 
system up.  YPYMAYTYP.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Delegations

[Sam Wilson]

In article mailman.571.1351768172.11945.bind-us...@lists.isc.org,
 Jan-Piet Mens jpmens@gmail.com wrote:

  YPYMAYTYP
 
 Zero results from my favorite search engine -- congratulations. ;-)

Thank you.  Try YPYMAYTYC but I was thinking pick.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Understanding cause of DNS format error (FORMERR)

[Sam Wilson]

In article mailman.1145.1340719800.63724.bind-us...@lists.isc.org,
 Barry Margolin bar...@alum.mit.edu wrote:

 In article mailman.1144.1340718471.63724.bind-us...@lists.isc.org,
  Sam Wilson sam.wil...@ed.ac.uk wrote:
 
  For a NXDOMAIN response, or NOERROR with an empty answer section, the 
  server should provide the SOA record in the authority section.  That SOA 
  is the apex of the zone which doesn't contain the answer record you 
  asked for, if you see what I mean.  The server is proving that it has 
  authority to tell you that the information doesn't exist.
 
 More important, the SOA record contains the TTL that should be used for 
 the negative cache entry.

More important for the operation of the DNS, but I'd think less 
important from the point of view of manual debugging, like we're doing 
here.

  The fact that looking for nonexistent data for 
  vlasext.partners.extranet.microsoft.com returns the 
  partners.extranet.microsoft.com SOA record shows that the vlasext 
  subdomain has not been delegated.  The servers should therefore be able 
  to offer an authoritative answer for data that does exist for 
  vlasext.etc... but they don't.
 
 This type of inconsistency often suggests a DNS-based load balancer is 
 involved.

I wondered that but it's not consistent with earlier results in the 
thread which suggested Windows DNS server for at least one of them.  An 
old version of fpdns (someone might like to try a newer one) concurs:

$ for i in 0 1 2 3 ; do fpdns dns1$i.one.microsoft.com  ; done
fingerprint (dns10.one.microsoft.com, 131.107.125.65): Microsoft \
Windows 2003 
fingerprint (dns11.one.microsoft.com, 94.245.124.49): Microsoft \
Windows 2003 
fingerprint (dns12.one.microsoft.com, 207.46.55.10): Microsoft \
Windows 2003 
fingerprint (dns13.one.microsoft.com, 65.55.31.17): Microsoft \
Windows 2003 
$ fpdns -v
fpdns.pl version 0.9.1


Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Understanding cause of DNS format error (FORMERR)

[Sam Wilson]

In article mailman.1143.1340715359.63724.bind-us...@lists.isc.org,
 Gabriele Paggi gabriele@gmail.com wrote:

 Hello Sam,
 
  There's some kind of delegation bug as well.  If I query
  dns1[0-3].one.microsoft.com for SOA and NS for
  partners.extranet.microsoft.com you get sensible answers though the
  origin host is different for each server queried and those origins are
  privately addressed.
 
 Which kind of misconfiguration could lead to SOA records for hosts on
 the internet to be privately addressed?
 Misconfigured split horizon server?

It's not difficult for private addresses to escape. It need not actually 
be a problem.  It's not necessarily a problem here but it does make it 
difficult to work out what's going on.

 [...]
  The authority for zero-answer responses such as
  vlasext.partners.extranet.microsoft.com/IN/ is the SOA for
  partners.extranet.microsoft.com
 
 What do you mean with authority for zero-answer responses?
 What is the normal authority response I should get when querying for
 non-existent records?

For a NXDOMAIN response, or NOERROR with an empty answer section, the 
server should provide the SOA record in the authority section.  That SOA 
is the apex of the zone which doesn't contain the answer record you 
asked for, if you see what I mean.  The server is proving that it has 
authority to tell you that the information doesn't exist.

The fact that looking for nonexistent data for 
vlasext.partners.extranet.microsoft.com returns the 
partners.extranet.microsoft.com SOA record shows that the vlasext 
subdomain has not been delegated.  The servers should therefore be able 
to offer an authoritative answer for data that does exist for 
vlasext.etc... but they don't.

 I'm trying a few third level domains (e.g. fabric.readthedocs.org) and
 I most of the time get as authority section the SOA for the second
 level domain (readthedocs.org).
 
 Thanks!

dig domain +trace will also (normally) show you how the tree is 
delegated, though it doesn't print out the SOA records.  Try 
www.automation.ucs.ed.ac.uk.

  It's all rather horrible.
 
 I concur!

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Understanding cause of DNS format error (FORMERR)

[Sam Wilson]

In article mailman.1121.1340625284.63724.bind-us...@lists.isc.org,
 Tony Finch d...@dotat.at wrote:

 It looks to me like this is an EDNS bug. ...

There's some kind of delegation bug as well.  If I query 
dns1[0-3].one.microsoft.com for SOA and NS for 
partners.extranet.microsoft.com you get sensible answers though the 
origin host is different for each server queried and those origins are 
privately addressed.

If I query dns1[0-3].one.microsoft.com for 
vlasext.partners.extranet.microsoft.com/IN/A I get answers with no AA 
bit set and a decreasing TTL as if the data were cached.  It does not 
appear that vlasext.partners.extranet.microsoft.com is delegated itself 
so it's not cached answers from a child zone.  The authority for 
zero-answer responses such as 
vlasext.partners.extranet.microsoft.com/IN/ is the SOA for 
partners.extranet.microsoft.com

It's all rather horrible.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Clarification on wildcard falls into glue records

[Sam Wilson]

In article mailman.797.1337090936.63724.bind-us...@lists.isc.org,
 Alexander Gurvitz a...@net-me.net wrote:

 You should NOT get A records. Wildcard works only for hostnames
 that have NO records of ANY type.

Excuse me while I delirk, but this is interesting.  Is a name on the RHS 
of an RR regarded as existing enough to prevent wildcard lookup?  In 
this I would have expected the NS lookup to be followed by an A lookup 
for abc.a.example.com which would match the wildcard, assuming no other 
records match that name on the LHS.

Sam

 From wikipedia:
 To quote RFC 1912, A common mistake is thinking that a wildcard
  MX for a zone will apply to all hosts in the zone. A wildcard MX will
  apply only to names in the zone which aren't listed in the DNS at all.
  That is, if there is a wild card MX for *.example.com, and an
 A record (but no MX record) for www.example.com, the correct
 response (as per RFC 1034) to an MX request for www.example.com
  is no error, but no data; this is in contrast to the possibly expected
  response of the MX record attached to *.example.com.
 
 Regards,
 Alexander,
 net-me.net
 
 On Tue, May 15, 2012 at 9:34 AM, rams brames...@gmail.com wrote:
  Hi,
  I have NS record points a record [A/] which is falls into wildcard . But
  when I query for NS record against bind, we are not getting these records as
  glue records.
 
  ex:
  *.a.example.com A 1.1.1.1
  example.com. NS abc.a.example.com.
 
  Querying example.com with any or ns.
  don't we get glue records for this scenario? please confirm.

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: Clarification on wildcard falls into glue records

[Sam Wilson]

In article mailman.800.1337093642.63724.bind-us...@lists.isc.org,
 Tony Finch d...@dotat.at wrote:

 Sam Wilson sam.wil...@ed.ac.uk wrote:
 
  Is a name on the RHS of an RR regarded as existing enough to prevent
  wildcard lookup?
 
 No, only RR owner names.
 
  In this I would have expected the NS lookup to be followed by an A
  lookup for abc.a.example.com which would match the wildcard, assuming no
  other records match that name on the LHS.
 
 Yes that should work. The latter answer might appear to be missing because
 additional section processing is a bit special. In your original question
 you mentioned glue, ...

Not I - another poster.

Sam

-- 
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
___
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: load-balancing in DNS using two A records

[Sam Wilson]

In article mailman.581.1324405362.68562.bind-us...@lists.isc.org,
 Matus UHLAR - fantomas uh...@fantomas.sk wrote:

 On 20.12.11 19:37, Martin T wrote:
 I have seen setups where one domain name has two address records.
 First IP address is in the ISP-A network and the other one is in the
 ISP-B network. In case I execute host www.domainname.com, I always
 get two IP addresses as a reply and they always appear by turns. Am I
 correct, that setup like this provides redundancy as well as
 load-balancing?
 
 Kind of. It's much better to have real load-balancing and vailover by 
 multiple links or L3 load balancers. 

If you're really cheapskate and have a little scripting expertise you 
can do what we did before we went to hardware load balancing.  Give your 
systems names with short TTLs in a dynamic zone.  Have a watchdog 
process monitor the systems and remove any that don't respond.  It's not 
generally fast enough to help individual clients but it can help the 
overall availability of a system.  It's victim to browsers ignoring 
TTLs, of course, though I've never been able to verify such browser 
behaviour myself.

Sam
___
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: Choosing max-journal-size

[Sam Wilson]

In article mailman.403.1322655086.68562.bind-us...@lists.isc.org,
 Matus UHLAR - fantomas uh...@fantomas.sk wrote:

 On 30/11/11 10:09, Matus UHLAR - fantomas wrote:
 Well, that's way too much. The main point of journal is imho to provide
 
 On 30.11.11 11:51, Phil Mayers wrote:
 I think this is a decision for each operator to make themselves.
 
 I was trying to explain that there are reasonable limits over which 
 journalling is useless.  However you have deleted the important p

We may also like to consider whether the journal should be limited by 
the expiry or refresh times of the zone itself.  There is unlikely to be 
huge utility in keeping changes that go back many times further than the 
expiry time.

Sam
___
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: Help with dig to check NS servers for DNSSEC setup

[Sam Wilson]

In article mailman.90.1321303169.68562.bind-us...@lists.isc.org,
 Eduardo Bonsi beart...@pacbell.net wrote:

 I am checking my DNS setup from inside using dig and I am getting 
 everything ok but I need a second opinion from outside of the server to 
 see if my ns1 and ns2 are responding ok to setup DNSSEC.

Looks like you haven't put in any glue records for nsX.bonsi.org.

Sam
---

$ dig bonsi.org +trace

;  DiG 9.3.6-APPLE-P2  bonsi.org +trace
;; global options:  printcmd
.   432891  IN  NS  g.root-servers.net.
.   432891  IN  NS  f.root-servers.net.
.   432891  IN  NS  d.root-servers.net.
.   432891  IN  NS  l.root-servers.net.
.   432891  IN  NS  c.root-servers.net.
.   432891  IN  NS  b.root-servers.net.
.   432891  IN  NS  m.root-servers.net.
.   432891  IN  NS  j.root-servers.net.
.   432891  IN  NS  e.root-servers.net.
.   432891  IN  NS  i.root-servers.net.
.   432891  IN  NS  a.root-servers.net.
.   432891  IN  NS  h.root-servers.net.
.   432891  IN  NS  k.root-servers.net.
;; Received 512 bytes from 129.215.205.191#53(129.215.205.191) in 1 ms

org.172800  IN  NS  b0.org.afilias-nst.org.
org.172800  IN  NS  c0.org.afilias-nst.info.
org.172800  IN  NS  a0.org.afilias-nst.info.
org.172800  IN  NS  b2.org.afilias-nst.org.
org.172800  IN  NS  a2.org.afilias-nst.info.
org.172800  IN  NS  d0.org.afilias-nst.org.
;; Received 429 bytes from 192.112.36.4#53(g.root-servers.net) in 52 ms

bonsi.org.  86400   IN  NS  ns2.bonsi.org.
bonsi.org.  86400   IN  NS  ns1.bonsi.org.
;; Received 95 bytes from 199.19.54.1#53(b0.org.afilias-nst.org) in 230 
ms

dig: couldn't get address for 'ns2.bonsi.org': not found
___
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: Clarification on CNAME

[Sam Wilson]

In article mailman.1454.1295874574.555.bind-us...@lists.isc.org,
 Matus UHLAR - fantomas uh...@fantomas.sk wrote:

 On 24.01.11 17:13, rams wrote:
  y resolver is returning multiple CNAMEs for same hostname. But I believe
  CNAME should not return same hostname with multiple values.
 
 correct.
 
  Is this behavior is correct. Could you please clarify me.
 
 it's not. CNAME may be the only record type for a domain, only its signature
 may appear on it...
 the server that returns multiple cnames is broken.

Even more so if the name that the original poster quoted (ramesh.com) is 
the one for which the CNAMEs are returned.  The real ramesh.com has SOA 
and  NS because it's delegated from .com (it also has A and MX records) 
and therefore can't have a CNAME anyway.

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

Re: Bind and blacklist IP file

[Sam Wilson]

In article mailman.447.1286891555.555.bind-us...@lists.isc.org,
 Alans alans...@gmail.com wrote:

 [ Norwegian Gov vs ISPs, banning domains, and inserting local host
entries to subvert such a ban ]

 Even this way, you should know all the IP of subdomains to work 
 properly. Try it for facebook, open homepage fine but once you login it 
 will fail.
 Another thing, we are talking about a technical person, for other users 
 they don't know about hosts file or they don't have access to change it 
 even it they know about it.

So there's a market opportunity for someone with half a clue to help out 
his friends.

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

Re: zone syntax question

[Sam Wilson]

In article mailman.2120.1279397548.21153.bind-us...@lists.isc.org,
 Doug Barton do...@dougbarton.us wrote:

 On Wed, 14 Jul 2010, Lyle Giese wrote:
 
  I would replace example.com in the SOA with @
 
 I generally recommend against doing this unless you are explicitly 
 planning to use the same zone file with multiple zones. There is no 
 advantage to using @ in a one-zone file, and unnecessary obfuscation is 
 not your friend when it comes to DNS administration. :)

I *would* recommend using @ everywhere possible - it's so much less 
liable to typos than using the real domain and unnecessary obfuscation 
is not your friend when it comes to DNS administration. :) :)

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

Re: problems resolving domains unser NSxx.DOMAINCONTROL.COM - this problem i have too! :(((((

[Sam Wilson]

In article mailman.1886.1277331842.21153.bind-us...@lists.isc.org,
 Mark Andrews ma...@isc.org wrote:

   If it is not a local DPI problem then the only other thing
   is that domaincontrol.com in using anycast and one or more
   of the sites is using using nameservers that don't respond
   to EDNS queries or has a firewall that blocks EDNS queries.

A few minutes poking around with traceroute.org finds the same two 
destinations that Mark does, one apparently in Washington DC or close by 
accessed via AboveNet, GBLX, Level3 and maybe others, and the other in 
or around Singapore, accessed via SingTel.

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

Re: Master server offline

[Sam Wilson]

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.

Make them 10 days - that way you can break things on a Friday, have a 
week off and then fix them again on the Monday morning you come back.

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

Re: IPv6 reverse zones advise

[Sam Wilson]

In article mailman.1455.1273495770.21153.bind-us...@lists.isc.org,
 Matthew Seaman m.sea...@infracaninophile.co.uk wrote:

 This means that the smallest chunk of IP space you can delegate is 16
 addresses, ...

Nitpick: The smallest chunk of IPv6 space you can delegate is a single 
address, as you can for IPv4.  You could also do RFC 2317 style 
delegations to delegate chunks of other sizes, though you might argue 
that that's a specially extended case of delegating single addresses 
(all those CNAME records!).

Given the standard address granularity in IPv6 (/64 is mandated for 
almost all the address space, though there is pressure to allow /126 or 
/127 for point to point links) there probably aren't many cases were 
you'd want to delegate any further than at the /64 boundary.

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

Re: Switching to TCP in BIND.

[Sam Wilson]

In article mailman.1323.1272653060.21153.bind-us...@lists.isc.org,
 Stephane Bortzmeyer bortzme...@nic.fr wrote:

 On Wed, Apr 28, 2010 at 11:59:11AM -0400,
  Kevin Darcy k...@chrysler.com wrote 
  a message of 21 lines which said:
 
  I know of no such feature. What do you mean by spoofed anyway? How
  would you expect named to detect spoofing, and is that its job?
 
 It seems (not tested by me) that Nominum CNS does that: when many
 responses arrive which do not match (src IP address, query ID, etc)
 any pending answer, it switches to TCP, assuming someone tries to
 poison it.
  
 This is supposed to be a protection against the Kaminsky attack.

Interesting.  Switches by what means?  Returns TC responses to all UDP 
queries?  Just for particular clients or particular domains?  Is this 
documented at all (yes, I'm too lazy to Google :-) ).

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

Re: Switching to TCP in BIND.

[Sam Wilson]

In article mailman.1394.1273050634.21153.bind-us...@lists.isc.org,
 sth...@nethelp.no wrote:

I know of no such feature. What do you mean by spoofed anyway? How
would you expect named to detect spoofing, and is that its job?
   
   It seems (not tested by me) that Nominum CNS does that: when many
   responses arrive which do not match (src IP address, query ID, etc)
   any pending answer, it switches to TCP, assuming someone tries to
   poison it.

   This is supposed to be a protection against the Kaminsky attack.
  
  Interesting.  Switches by what means?  Returns TC responses to all UDP 
  queries?  Just for particular clients or particular domains?  Is this 
  documented at all (yes, I'm too lazy to Google :-) ).
 
 According to the Nominum CNS manual,
 
 When a single query ID mismatch is detected in the expected DNS
 response, CNS switches the recursive query to the more reliable TCP
 protocol ...
 
 So it is definitely documented - though I'm sure there are details of
 the implementation which are *not* documented in the regular user
 manual.

Oh, I see. It's the other way round from what I had (wrongly) assumed - 
if the response to a query looks suspect then CNS will retry the query 
using TCP to try to protect against spoofed answers coming back.  Seems 
sensible.

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

Re: Switching to TCP in BIND.

[Sam Wilson]

In article mailman.1395.1273052339.21153.bind-us...@lists.isc.org,
 Stephane Bortzmeyer bortzme...@nic.fr wrote:

 On Wed, May 05, 2010 at 09:35:38AM +0100,
  Sam Wilson sam.wil...@ed.ac.uk wrote 
  a message of 22 lines which said:
 
   It seems (not tested by me) that Nominum CNS does that: when many
   responses arrive which do not match (src IP address, query ID, etc)
   any pending answer, it switches to TCP, assuming someone tries to
   poison it.

   This is supposed to be a protection against the Kaminsky attack.
  
  Interesting.  Switches by what means? 
 
 I don't understand the question. When detecting an attack, CNS decides
 to query the authoritative name servers with TCP instead of querying
 with UDP as it does by default, that's all.

Yeah - I misunderstood the original description and had in my mind CNS 
getting spoofed responses and causing the original querier to retry with 
TCP.  I understand now.

Thanks,

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

Re: logging forwarding reqs

[Sam Wilson]

In article mailman.1172.1271358692.21153.bind-us...@lists.isc.org,
 Gregory Hicks ghi...@hicks-net.net wrote:

  Date: Thu, 15 Apr 2010 14:25:35 -0400
  Subject: Re: logging forwarding reqs
  From: Jonathan Reed jreed...@gmail.com
  To: bind-users@lists.isc.org
  
  But I am still unable to determine if those reqs are asking the
  forwarders.
 
  The forwarders are all Windows boxes which I dont have rights to
  access.  Still hoping there is something within bind9 that can say
  the req went to fwd'er.
 
 Since you don't have access to the Windows boxen, it seems to me that
 this is a candidate for the old sniff the firewall trick.
 
 Sniff the DNS traffic on the internal facing connection of your
 firewall (you DO have a firewall, don't you?) and see which IP
 addresses the DNS requests are originating from.  If from your Windows
 boxen, then the forwarding is working correctly.  (You ARE getting dns
 requests resolved on the non-windows clients are you not?)
 
 If not from the Windows boxen, then there is an error in your setup.

Simpler yet, sniff the resolving server and see if it's getting its 
answers from the Windows boxes.

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

Re: Intermittent failures resolving .org domains in BIND 9.7.0 with DLV enabled

[Sam Wilson]

In article mailman.983.1269884152.21153.bind-us...@lists.isc.org,
 Roy Badami r...@gnomon.org.uk wrote:

  I have seen this happen when bind for some reason (eg mtu issues with
  vpn) cannot query for the DLV key at dlv.isc.org. I have not figured
  out the exact failure mode there. Check the logs to see errors for DNSKEY
  queries for dlv.isc.org to see if this is happening here too. However in
  that case, no queries at all make it.
 
 Hmm, I wonder whether it could be related to my tunnelled IPv6
 connectivity.  I still don't see why, though.
 
 Resolution definitely works sometimes.  When it starts failing
 'rndc flush' has fixed it for me.

... thus removing a cached and broken resolution chain and starting 
again from fresh?

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

Re: DNSSEC and child zones on same authoritative NS. Expert help needed.

[Sam Wilson]

In article mailman.814.1268703621.21153.bind-us...@lists.isc.org,
 Gary Wallis wgg1...@gmail.com wrote:

 Let's say I have this setup :
 
 BIND 9.4 named.conf includes a master.zones file with the following:
 
 ...
  zone ns1.yourdomain.com {
  type master;
  file master/external/n/ns1.yourdomain.com.signed;
  };
 
  zone ns2.yourdomain.com {
  type master;
  file master/external/n/ns2.yourdomain.com.signed;
  };
 
  zone yourdomain.com {
  type master;
  file master/external/y/yourdomain.com.signed;
  };
 ...
 
 More background for question below:
 
 The yourdomain.com is I gather the zone APEX for all featured zones 
 above. (Is this the correct use of the term APEX?)

Parent, as Mark has already pointed out.

 I am learning via trial and error about transitioning from DNS to DNSSEC 
 and we have these child zones (is ns1.yourdomain.com really a child 
 zone, as regards the setup above?) that currently have precedence over 
 the parent zone yourdomain.com for conflicting A records. For example:
 
 If
 
 ns1 A 123.123.123.123
 
 is placed in yourdomain.com zone.

Some nitpicking - I'm not a DNSSEC expert and I'm not commenting on that 
part of your question.  Including this record would normally be an 
error.  ns1.yourdomain.com is delegated into its own zone and the A 
record should be in that zone, not in the parent zone.[1]

 And a similar RR is placed in ns1.yourdomain.com zone, like:
 
 ns1 IN A 10.0.0.1

If you place ns1 in the zone ns1.yourdomain.com then the name will be 
ns1.ns1.yourdomain.com.  If you force the name to be ns1.yourdomain.com 
[2] then that A record should override the one in the parent zone (see 
[1] again).

 And named reloaded.
 
 dig @localhost ns1.yourdomain.com A +short
 
 will return 10.0.0.1, the parent A RR is ignored.

Correct - see above

Can't answer your DNSSEC queries, but I'm not sure if they're relevant 
if you correct the above.

Sam


[1] UNLESS ns1.yourdomain.com is also the name of one of the nameservers 
for a child zone in which case that record would be a glue record which 
would be valid in the parent zone.  It would normally be superseded by 
the corresponding A record in the child zone which is regarded as a more 
trustworthy source of data. There are various ways by which a server for 
the parent zone can learn the correct data from the child zone.

[2] You can do that by using the @ sign in the LHS of the A RR, or by 
using a fully qualified name (inflexible), or by using the $ORIGIN 
directive,  or by leaving the name blank at the head of the zone 
(slightly risky).  Of these @ is the one mostly recommended.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC and child zones on same authoritative NS. Expert help needed.

[Sam Wilson]

In article mailman.828.1268758483.21153.bind-us...@lists.isc.org,
 Gary Wallis wgg1...@gmail.com wrote:

 Sam Wilson wrote:
  In article mailman.814.1268703621.21153.bind-us...@lists.isc.org,
   Gary Wallis wgg1...@gmail.com wrote:
  
  Let's say I have this setup :
 
  BIND 9.4 named.conf includes a master.zones file with the following:
 
  ...
   zone ns1.yourdomain.com {
   type master;
   file master/external/n/ns1.yourdomain.com.signed;
   };
 
   zone ns2.yourdomain.com {
   type master;
   file master/external/n/ns2.yourdomain.com.signed;
   };
 
   zone yourdomain.com {
   type master;
   file master/external/y/yourdomain.com.signed;
   };
  ...
 
  More background for question below:
 
  The yourdomain.com is I gather the zone APEX for all featured zones 
  above. (Is this the correct use of the term APEX?)
  
  Parent, as Mark has already pointed out.
 
 Got that :)
 
 I would be nice to know what a zone apex is since what I have found on 
 the web so far is pretty self-referential.

The zone apex is the name of the zone.  It will always have SOA and NS 
records at that point and in DNS Classic[tm] may, but need not, have 
other records as well (MX and A are common).  DNSSEC brings other RRs to 
the party at the apex.

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

Re: dnsquery for Solaris

[Sam Wilson]

In article mailman.750.1268169970.21153.bind-us...@lists.isc.org,
 jcarrol...@cfl.rr.com wrote:

 dig was added to Solaris 9. It is not native to Solaris 8 or older.

That would explain why it's only where Chris found it on some of our 
range of Solarises (vintage or only slightly worn).

  Chris Thompson c...@cam.ac.uk wrote: 
  On Mar 9 2010, Sam Wilson wrote:
  
  ...  I don't know whether [dig is] there [/usr/local/bin] if you use the 
  Solaris-supplied BIND.
  
  Sure it is:
  
  $ ls -l /usr/sbin/dig
  -r-xr-xr-x   1 root bin75208 Jul 29  2008 /usr/sbin/dig
  $ fgrep /usr/sbin/dig /var/sadm/install/contents
  /usr/sbin/dig f none 0555 root bin 75208 48119 121715 SUNWbind
  
  (that's a 9.3.5-P1 dig, from a not very up-to-date Solaris 10 installation,
  but it's been around in Solaris distributions much longer than that).

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

Re: strange behaviour of resolving nameserver

[Sam Wilson]

In article mailman.751.1268170620.21153.bind-us...@lists.isc.org,
 Mark Andrews ma...@isc.org wrote:

 In message 20100309154017.4801c...@the-damian.de, Torsten writes:
  Am Wed, 10 Mar 2010 00:44:46 +1100
  schrieb Mark Andrews ma...@isc.org:
  
   
   In message 20100309142153.016c7...@the-damian.de, Torsten writes:
Hi,

I'm a bit clueless about what's happening here exactly.
I have a server (9.6.1-P3) that tries resolving
ws.mobilecdn.verisign.com. Queries for this host permanently fail
with SERVFAIL.

I've narrowed the problem down to answers from c2.nstld.net 


dig @c2.nstld.com mobilecdn.verisign.com 
;; Got referral reply from 192.26.92.31, trying next server
   
   Fix /etc/resolv.conf to point to recursive nameservers.  192.26.92.31
   is not a recursive nameserver.
  
  /etc/resolv.conf already points to recursive nameservers. Since these
  nameservers can't resolve ws.mobilecdn.verisign.com I tried every
  single nameserver found by dig +trace and ended up with the behaviour
  of c2.nstld.net.
 
 I mis-read.  192.26.92.31 is c2.nstld.net so someone at RedHat has
 hacked dig to return  ;; Got referral reply from 192.26.92.31,
 trying next server when it see a referral and move onto the next
 address which is a IPv6 addresss which presumably you don't have
 connectivity for.
 
 Try dig -4 @c2.nstld.com mobilecdn.verisign.com.  Then yell at
 RedHat.  Dig is not supposed to move on when it sees a referral.
 Dig is a diagnostic tool first and foremost, not a general hostname
 lookup tool.  One needs to see the answers to queries in a diagnostic
 tool not have them skipped.

There's also a lame delegation.  Here's an extract from dig 
ws.mobilecdn.verisign.com +trace:

   :
   :
mobilecdn.verisign.com. 900 IN  NS  dns2-auth.m-qube.com.
mobilecdn.verisign.com. 900 IN  NS  dns1-auth.m-qube.com.
;; Received 98 bytes from 192.5.6.31#53(a2.nstld.com) in 119 ms

ws.mobilecdn.verisign.com. 1800 IN  A   64.14.95.24
mobilecdn.verisign.com. 1800IN  NS  dns2-auth.m-qube.com.
mobilecdn.verisign.com. 1800IN  NS  dns3-auth.m-qube.com.
mobilecdn.verisign.com. 1800IN  NS  ns1.savvis.net.
mobilecdn.verisign.com. 1800IN  NS  ns2.savvis.net.
mobilecdn.verisign.com. 1800IN  NS  ns3.savvis.net.
;; Received 178 bytes from 64.14.95.64#53(dns2-auth.m-qube.com) in 90 ms

dns1-auth.m-qube.com does not respond, at least to me, and will also 
cause delays or failures because it is a CNAME for dns1.m-qube.com.


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

Re: dnsquery for Solaris

[Sam Wilson]

In article mailman.747.1268158060.21153.bind-us...@lists.isc.org,
 ic.nssip ic.ns...@northwestel.net wrote:

 I find it useful to test records cache time.

dig tells you that.  

 I'll check on BIND 8 package.
 Thank you for pointing to a Solaris compatible source.

Use dig from a recent BIND package, though you may find it's already 
there - ours is in /usr/local/bin/dig on our Solaris systems and was 
installed with BIND 9.  I don't know whether it's there if you use the 
Solaris-supplied BIND.

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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Sam Wilson]

In article mailman.633.1267090950.21153.bind-us...@lists.isc.org,
 Florian Weimer fwei...@bfk.de wrote:

 * Sam Wilson:
 
  Has anyone found any uz5* servers out there yet?
 
 node.pk, dempsky.org has such name servers.  I thought there were
 more.  Has the magic prefix changed?

OK.  I found none in 130 MB of cache from 3 servers.  Clearly the wave 
hasn't broken yet.

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

Re: Fwd: IPv6 client and negative cache - some doubts

[Sam Wilson]

In article mailman.575.1266994115.21153.bind-us...@lists.isc.org,
 Michal Wesolowski gmic...@gmail.com wrote:

 My server is caching only, I don't administer ns*.az.pl servers. I'm just
 trying to understand if binds copes well with such an external error. As you
 pointed out both servers fails in some (different) way but second one does
 this only when queried for something other than A record. For A everything
 is ok. THERE IS A record for virtual.jasnet.pl. Why bad response from
 external server for  record affects subsequent queries for A? Which
 entry of cache is responsible for this:

These:

 virtual.jasnet.pl.  3597A   85.202.208.254
 3597CNAME   jasnet.pl.

You can't have both a CNAME and an A record for the same name.  I'm not 
sure which version of BIND you're using for your cache, but I'm slightly 
surprised it retains both records.

 Is it a case that unexpected response to  query from ns10.az.pl marks
 virtual.jasnet.pl invalid even for A queries?

It looks like it.  

 Sorry for my persistence

Keep it up.  Now you need to talk to the az.pl people and persuade them 
their server is broken.

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

Re: Fwd: IPv6 client and negative cache - some doubts

[Sam Wilson]

In article mailman.564.1266963563.21153.bind-us...@lists.isc.org,
 Mark Andrews ma...@isc.org wrote:

 In message f677fefa1002230600n4694161cu315e5dd4beaaa...@mail.gmail.com, 
 Micha
 l Wesolowski writes:
  
  After some reading my present understanding is that correct response to 
  
  query when there is such record in the zone and there exists another record
  of different type for the same name - is to reply with empty answer and no
  error (this applies to authoritative NS). So what ns10.az.pl does is not
  consistent with specification.

That's correct.

  However I'm still not sure if bind shouldn't cope with this somehow. I
  understand that if it applied to final query for www.goliszew.pl than it
  would be correct for bind to cache it as negative for all types of records.
  But if it concerns bad respond for NS? - I don't know.

I don't either.

 Well one of the nameservers does not exist and the other is a CNAME.
 Both of these are fatal errors for the particular nameserver and
 as there are only two nameservers for the zone lookups fail.

I hesitate to take issue with you Mark, but the problem is also that one 
of the nameservers has either an A record or a CNAME depending on how 
you look it up (A or  query), and his caching server is keeping them 
both.

 Add A records to the sincom.pl and jasnet.pl zones for virtual.sincom.pl
 and virtual.jasnet.pl respectively.

As the OP has pointed out that's not under his control, and if the same 
misbehaving servers are responsible there's the chance that both will be 
screwed up.

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

Re: OpenDNS today announced it has adopted DNSCurve to secure DNS

[Sam Wilson]

In article mailman.608.1267031100.21153.bind-us...@lists.isc.org,
 Chris Thompson c...@cam.ac.uk wrote:

 On Feb 24 2010, Evan Hunt wrote:
 
  Thats not the case with DNScurve. Again I stress - over 20 billion
  requests per day at OpenDNS are DNScurve compatible. The traffic in
  DNSSEC is chicken feed compared to DNScurve.
 
 ORG and GOV and quite a lot of the ccTLD's are DNSSEC compatible, so I
 don't actually think it'd be much of a horserace if compatibility is all
 you're looking for.  What'll be interesting is how many queries the root
 and TLD servers start seeing for uz5*/NS.
 
 If OpenDNS really believe that DNScurve is the way of the future, why
 don't they have such NS records for opendns.com?

And what effect will 54-character names for nameservers have when the 
description recommends against using TCP or UDP with packets longer than 
512 bytes (EDNS0, anyone?).

Actually the idea of encoding your public key your name, whilst 
superficially neat, sounds like a killer to me.  How will I ever 
remember which server is which?

Has anyone found any uz5* servers out there yet?

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

Re: IPv6 client and negative cache - some doubts

[Sam Wilson]

In article mailman.529.1266923597.21153.bind-us...@lists.isc.org,
 Michal Wesolowski gmic...@gmail.com wrote:

 Hello Everyone
 
 I have a problem with Bind 9.3.6-P1 (included in Solaris 10) but honestly I
 don't even understand if it is wrong Bind behaviour or my ignorance. It does
 apply only to some specific cases when external domain delegation is also
 somewhat broken. My server is caching only. Let me show it by the example:
 
 Host www.goleszow.pl has bad NS delegation on country root servers level
 because virtual.sincom.pl is not resolvable:
 
 goleszow.pl.86400INNSvirtual.sincom.pl.
 goleszow.pl.86400INNSvirtual.jasnet.pl.
 ;; Received 91 bytes from 149.156.1.6#53(G-DNS.pl) in 19 ms

That may be part of the problem, and it needs to be fixed, but I don't 
think that's all of it.

 When dns client asks my server for A record of www.goleszow.pl -
 everything is fine. But when first query (after cache is flushed) asks for
  record - my server seems to cache negative answer and all subsequent
 queries for A record also fails. ...
 [snip]
 This is what I found in the Bind cache:
 # rndc dumpdb -all
 # cat /var/named/log/named_dump.db | grep virt
 goleszow.pl.85994   NS  virtual.jasnet.pl.
 85994   NS  virtual.sincom.pl.
 virtual.jasnet.pl.  3194A   85.202.208.254
 virtual.sincom.pl.  3194\-ANY   ;-$NXDOMAIN
 ; virtual.jasnet.pl alias jasnet.pl [v4 TTL 3194] [target TTL 3194] [v4
 success] [v6 unexpected]
 ; virtual.sincom.pl [v4 TTL 3194] [v6 TTL 3194] [v4 nxdomain] [v6 nxdomain]
 
 Which for me doesn't explain this behaviour. Please advice.

Note that line beginning virtual.jasnet.pl alias jasnet.pl.  jasnet.pl 
is delegated to ns10.az.pl and ns11.az.pl.  If you ask them for an A 
record for virtual.jasnet.pl you get an A record; if you ask for  
you get a CNAME pointing to jasnet.pl.  I can't imagine what sort of 
configuration could cause that to happen.  I'm also not sure how that 
might be screwing up your lookups, but it's certainly weird.  On the 
'fix what you know to be broken' principle I'd try to get that and the 
broken delegation sorted first before looking any further.

Sam


$ dig virtual.jasnet.pl @ns11.az.pl  

;  DiG 9.3.6-APPLE-P2  virtual.jasnet.pl @ns11.az.pl
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 47757
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;virtual.jasnet.pl. IN  A

;; ANSWER SECTION:
virtual.jasnet.pl.  3600IN  A   85.202.208.254

;; Query time: 43 msec
;; SERVER: 62.146.68.200#53(62.146.68.200)
;; WHEN: Tue Feb 23 12:24:05 2010
;; MSG SIZE  rcvd: 51

$ dig virtual.jasnet.pl @ns11.az.pl 

;  DiG 9.3.6-APPLE-P2  virtual.jasnet.pl @ns11.az.pl 
;; global options:  printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 13425
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;virtual.jasnet.pl. IN  

;; ANSWER SECTION:
virtual.jasnet.pl.  3600IN  CNAME   jasnet.pl.

;; AUTHORITY SECTION:
jasnet.pl.  3600IN  SOA ns10.az.pl. admin.az.pl. 
2009091500 10800 3600 604800 3600

;; Query time: 44 msec
;; SERVER: 62.146.68.200#53(62.146.68.200)
;; WHEN: Tue Feb 23 12:24:09 2010
;; MSG SIZE  rcvd: 99
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: no hostname become unresolvable.

[Sam Wilson]

In article mailman.538.1266936679.21153.bind-us...@lists.isc.org,
 Lightner, Jeff jlight...@water.com wrote:

 You need an A record for the domain itself:
 superease.net.   IN  A   202.68.195.36
 www  IN  A   202.68.195.36
 
 The first one (terminated by the dot) tells it lookup for the domain
 name superease.net itself.  The dot is important - without it this
 would try to lookup superease.net.superease.net.
 
 The second one www (without a dot) tells it to lookup www.superease.net
 by appending the domain to the entry.

Better yet use @, as the OP already does for NS and MX records - it 
means the current origin as set by the zone name that the file is 
loaded into from named.conf or as set by $ORIGIN (which is probably 
superfluous in this case), and is shorter and easier to type.

Sam


 -Original Message-
 From: bind-users-bounces+jlightner=water@lists.isc.org
 [mailto:bind-users-bounces+jlightner=water@lists.isc.org] On Behalf
 Of Cefull Lo
   :
   :
 $TTL86400
 $ORIGIN superease.net.
 @   IN SOA  dns1.man169.com. root.dns1.man169.com. (
 2010022307  ; serial (d.
 adams)
 10800   ; refresh
 900 ; retry
 604800  ; expiry
 86400 ) ; minimum
 
 @   IN  NS  dns1.man169.com.
 @   IN  NS  dns2.man169.com.
 @   IN  MX 10   mail.man169.com.
 ... [etc.]
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Script to delete zone from named.conf

[Sam Wilson]

In article mailman.365.1265321768.21153.bind-us...@lists.isc.org,
 Mark Andrews ma...@isc.org wrote:

 Recent version of named-checkconf have a -p (print) option which
 will emit named.conf, sans comments, in a consistent style which
 will then be easy to post process.

Shame about the sans comments - easy comprehension or easy management 
- take your pick.  (Yes, I know it's a difficult task to preserve 
commenting - BTDT.)

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

Re: zone vs domain

[Sam Wilson]

In article mailman.1146.1259697520.14796.bind-us...@lists.isc.org,
 Doug Barton do...@dougbarton.us wrote:

 gmspro wrote:
  What's the main difference between zone and domain?
 
 In what context? Unfortunately both terms get used by various
 people/vendors in different ways. A little more detail is needed to
 answer your question (although if you're talking strictly DNS terms
 Chris' answer was quite detailed).

In the context of a DNS-centred newsgroup/mailing list Chris' answer was 
excellent.  Whether the original author was asking about the DNS is, of 
course, slightly open to question.  Unfortunately, as you imply,  
computing, and network related fields in particular, are full of 
multivalued terms.  They have to be disambiguated by referring to their 
particular, errm, domain.

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

Re: Parent is a CNAME

[Sam Wilson]

In article mailman.1153.1259725836.14796.bind-us...@lists.isc.org,
 Joseph S D Yao j...@tux.org wrote:

 On Tue, Dec 01, 2009 at 04:59:16PM -0800, Hans Jacobsen wrote:
  If a.stanford.edu is a cname (say to b.stanford.edu)
  can I delegate subdomain.a.stanford.edu?  Are there documents that  
  point to this being an ok or bad practice?
  
  I know all records for a.stanford.edu are relegated to records for  
  b.stanford.edu
  What about subdomains?
 
 
 No.
 
 The domain that has a CNAME must never appear on the left-hand side of
 another record.

Not true.  CNAME chains - CNAMEs pointing to other CNAMEs - are 
inefficient and discouraged but the DNS spec is built to ensure that 
they work.  Check out www.google.com sometime (or www.google.co.uk) and 
wonder at how many people would be annoyed if they didn't.

 If you delegate, the domain appears on the left side of NS records.

If you delegate there is ambiguity because there are CNAME and other 
records.  A CNAME says all the information about this name can be found 
attached to that other name over there.

 If you include the domain in a declaration in the same zone, it still is
 on the left side of a record - just not alone.
 
 a CNAMEb
 ; Delegate a - WRONG
 a NSns1  [WRONG]

Correct.

 ; Use a on LHS - WRONG
 subdomain.a A 7.8.9.10 [WRONG]
 subdomain.a NSns1.subdomain.a   [WRONG]
 ns1.subdomain.aA 7.9.11.13   [WRONG]

As Chris Buxton points out, these will actually work though not in the 
form you've given them.  The A record for subdomain.a needs to be in the 
subdomain.a child zone and the A record for ns1 must be in the child 
zone but may also need to be in the current zone as glue.

We use the same kind of convention Chris describes for naming our 
routers - look up kb6.net.ed.ac.uk, say.  We've been doing it for years.

 Why not do this?
 
 subdomain.b A 7.8.9.10
 subdomain.b NSns1.subdomain.b
 ns1.subdomain.bA 7.9.11.13

If b was itself delegated the CNAME would be problematical again.

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

Re: Parent is a CNAME

[Sam Wilson]

In article mailman.1165.1259775639.14796.bind-us...@lists.isc.org,
 Joseph S D Yao j...@tux.org wrote:

 On Wed, Dec 02, 2009 at 12:47:08PM +, Sam Wilson wrote:
  In article mailman.1153.1259725836.14796.bind-us...@lists.isc.org,
   Joseph S D Yao j...@tux.org wrote:
 [incorrectly]
   No.
 ...
  Not true.  CNAME chains - CNAMEs pointing to other CNAMEs - are 
  inefficient and discouraged but the DNS spec is built to ensure that 
  they work.  Check out www.google.com sometime (or www.google.co.uk) and 
  wonder at how many people would be annoyed if they didn't.
 
 
 CNAME chains have nothing to do with this.  THIS is perfectly legal:
 
 a CNAME   b
 b CNAME   c
 c CNAME   d
 d CNAME   extra-ordinary
 
 although, as mentioned, inefficient.

My bad - I read your initial statement as banning names with CNAME 
records from the RHS of other RRs, not from the LHS, and I was offering 
a counterexample.

 THIS is not legal:
 
 a CNAME   b
 a CNAME   c
 a A   1.1.1.1

To be pedantic, the first alone is legal, but once that exists neither 
of the second nor third is legal.

 ...
   Why not do this?
   
   subdomain.b A 7.8.9.10
   subdomain.b NSns1.subdomain.b
   ns1.subdomain.bA 7.9.11.13
  
  If b was itself delegated the CNAME would be problematical again.
 ...
 
 
 And if all the name servers crashed, then the domain would be unserved.
 Why introduce unnecessary hypotheticals?  ;-)

Because you introduced a delegation for a and I wanted to head off the 
idea that you could delegate b and then point a to it as a CNAME.  You'd 
need to use DNAME in that situation.

 And, as pointed out in another post, the CNAME does not appear to be
 problematic in this case, even were it to exist.

Indeed.

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

Re: ** server can't find barcelonamedia.org.barcelonamedia.org: SERVFAIL

[Sam Wilson]

In article mailman.917.1257494968.14796.bind-us...@lists.isc.org,
 Marc Riera marc.ri...@barcelonamedia.org wrote:

 Now I have this on my named.conf.options to let me have underscores:
 
 check-names master ignore;
 check-names slave  ignore;

Not a good plan.  Those checks are in there for a reason, namely that 
underscores are invalid in host names.  Whilst you can make your 
nameservers accept them you can't legislate for other software which 
might take a less liberal view.  Better to eliminate the underscores. 

Note that the restriction on underscores does not apply to the entries 
in some special purpose domains such as SRV records and DKIM entries, 
just to hostnames - mostly A and PTR records.

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

Re: Nslookup not showng TTL

[Sam Wilson]

In article mailman.715.1255626934.14796.bind-us...@lists.isc.org,
 Kevin Darcy k...@chrysler.com wrote:

 (Fortunately nslookup's whole won't do a lookup because I can't 
 reverse-resolve my resolver bogosity isn't really an issue at Chrysler, 
 since we maintain proper reverse mappings, but that's another popular 
 nslookup sucks, don't use it-category posting to this mailing list)

Fortunately (or not - it would be another nail) that bogosity is gone 
from recent nslookups.

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

Re: Query Refused problem

[Sam Wilson]

In article mailman.649.1254472597.14796.bind-us...@lists.isc.org,
 Michael Monnerie michael.monne...@is.it-management.at wrote:

 On Freitag 02 Oktober 2009 Mark Andrews wrote:
  if (set(allow-query-cache))
  use allow-query-cache;
  else if (set(allow-recursion))
  use allow-recursion;
  else if (set(allow-query))
  use allow-query;
  else if (set(recursion no;))
  use { none; };
  else
  use { localnets; localhost; };
 
 Ah, it's always an elseif. That wasn't clear to me. Easier to read C 
 than english, am I a nerd? ;-)
 Maybe it's because I'm not native English, but the paragraph is very 
 confusing. A simpler wording would surely help others as well.

I second that and I'm a native English speaker.  I've also been looking 
at rearranging our DNS recently and the same logic defeated me.

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

Re: rndc command for erased zone?

[Sam Wilson]

In article mailman.574.1253708535.14796.bind-us...@lists.isc.org,
 Matus UHLAR - fantomas uh...@fantomas.sk wrote:

 On 23.09.09 14:00, Marcos Lorenzo de Santiago wrote:
  I no longer manage one of our DNS domain. As I use 'rndc reconfig' to
  load newly created zones I was wondering if exists a way to do the same
  as reconfig but inversely, I mean, reload configuration forgetting the
  just erased zones.
  
  I tried every command that rndc has, but I guess that my only choice is
  to restart bind. I even tried flushing cache, but it keeps answering to
  DNS queries to that zone even when I erased the zone file.
 
 does it return authoritative responses? Does the server allow recursion for
 you?
 
 I think rndc reconfig should forget removed zones too, but you may be
 - either seeing the same zone in other view
 - see records fetched from other servers after zone was removed

rndc reconfig does remove zones.  If logging is set appropriately you 
should see messages something like this:

02-Sep-2009 10:02:30.995 general: zone 
193.215.129.in-addr.arpa/IN/default: (slave) removed

That won't remove any files from either master or slave servers, but 
should stop your server from answering authoritatively.  If there are 
other servers and you haven't deleted the delegation then there will 
still be traces of the domain around.

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

Re: Modified a zone, so when it becomes available?

[Sam Wilson]

In article mailman.508.1253094340.14796.bind-us...@lists.isc.org,
 Marcos Lorenzo de Santiago marcos.lore...@ayto-getafe.org wrote:

 El mar, 15-09-2009 a las 13:45 +0200, Udo Zumdick escribió:
  Am Tue, 15 Sep 2009 12:28:24 +0200
  schrieb Marcos Lorenzo de Santiago marcos.lore...@ayto-getafe.org:
  
  []
   After making changes to zone, updated serial, and rndc reload, I dig my
   zone and get always the old serial. The serial and the changes only
   appear when I '/etc/init.d/bind restart' it.
   
   I use bind 9.5.1 on debian 5.0.3.
   
   Any clue?
  
  Maybe there are some .jnl files (IXFR journalfiles) which could prevent 
  bind from updating the zone ?
  Removing them and disabling incremental zone transfer might help. I had
  such problems in the past.
 
 There are no .jnl files, so I guess is turned off, but anyway, how can I
 know If this is enabled? I don't have any allow-update option...
 
 Thanks in advance.

Have you checked your log file yet?  I don't know where the debian setup 
puts the messages by default, but you should be able to see messages 
saying what named is doing when you tell it to reload the zone.

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

Re: one DNS names to multiple IP Addresses(Round Robin DNS)

[Sam Wilson]

In article mailman.459.1252545857.14796.bind-us...@lists.isc.org,
 Joseph S D Yao j...@tux.org wrote:

 On Wed, Sep 09, 2009 at 05:47:34PM +0100, Sam Wilson wrote:
  In article mailman.450.1252511223.14796.bind-us...@lists.isc.org,
   Balanagaraju Munukutla 9ba...@sg.ibm.com wrote:
   Hi
   
   Anybody can help to explain the side effect of configuring the DNS name 
   to 
   multiple IP addresses(Round Robin DNS).
  
  If you're planning to use it for load sharing, then the effect is very 
  basic - requests get shared equally among the addresses irrespective of 
  load on the target system or whether the system is offering the service 
  or not.  If one of the target systems goes down then clients which are 
  directed to that system will either get rejected or time out, depending 
  on the type of failure.  You can mitigate this by using watchdog 
  scripts, short TTLs and dynamic DNS updates.
  
  In short it's cheap and cheerful load balancing.  A large commercial 
  organisation might not want to rely on it, but depending on the 
  application it can work well enough.
 
 
 There are several problems with using this for load balancing.
 
 The first is, simply, it will not work unless the name server that is
 authoritative for this zone is also your resolving name server.  If
 there are ANY resolving name servers between the user and the
 authoritative name server - as there usually is/are - then it's the
 round robin policy - or lack thereof - of the last caching name server
 before your stub resolver that will dictate how the addresses are
 delivered.

In most of our cases the vast majority of clients are local so we do 
control the resolving servers, and observation shows that loads are 
fairly well balanced.

 Second, if one of the system goes down, then its IP address is still in
 the rotation, again, unless some clever dynamic-DNS insertion and
 deletion strategy is used.  This means that users will get frustrated
 when their Web browser sometimes gets the Web site and sometimes
 doesn't; or some automatic process that is trying to get your
 information will not fail cleanly.

We do exactly that - a watchdog script that can add and remove addresses 
by dynDNS.  It never removes the last entry, of course.

 ISTM, it's better to try and do failover some other way, such as with
 high-availability Linux, than to try to get DNS to do load balancing.

Certainly - if you need to balance load across highly stressed servers 
or if want real high availability or guaranteed response times then the 
DNS is not the way to achieve those things.  For cheap resilience and 
more or less good enough load balancing it *can* be useful.  Only the OP 
can say whether it would work for his/her situation.

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

Re: root and in-addr.arpa zone transfers

[Sam Wilson]

In article mailman.469.1252646962.14796.bind-us...@lists.isc.org,
 Michael Monnerie michael.monne...@is.it-management.at wrote:

 On Freitag 11 September 2009 Joseph S D Yao wrote:
  However, as M. Bortzmeyer has said, why do this?
 
 Faster queries after a named restart. ...

How often do you restart named?  We hit our master once a day, in the 
early hours but that's just habit and I've always thought we were a bit 
hyperactive.  The slaves only get hit for upgrades or problems.

 ... Reverse lookups faster too, good 
 for the spam filters.

Only the first few, until the relevant X.in-addr.arpa NS records are 
cached. How many X in *.X.in-addr.arpa do you get spam from?

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

Re: Double messages in comp.protocols.dns.bind

[Sam Wilson]

In article mailman.366.1250954533.14796.bind-us...@lists.isc.org,
 Barry Margolin bar...@alum.mit.edu wrote:

 It looks like there are two mail-to-news gateways running for 
 bind-users, so every message to the list is being posted twice to the 
 newsgroup.  ...

But at least messages are now being posted to the newsgroup - the 
gatewaying, at least as seen from here and from Google, went AWOL on 4 
June 09.  Postings from 15 Aug onward have now appeared.

So thank you, ISC, even if the gatewaying is now a little 
overenthusiastic.  :-)

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

bind-users - comp.protocols.dns.bind stopped?

[Sam Wilson]

I note that the last posting in comp.protocols.dns.bind seems to have 
been on 4-Jun-09, both on my local news server and on Google Groups.  I 
can't see any relevant announcements in the archive.  What's happened?

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

Re: Delegation of DHCP blocks within same server?

[Sam Wilson]

In article gv25eq$2n...@sf1.isc.org,
 Matthew Pounsett m...@conundrum.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 
 On 20-May-2009, at 19:03, John Cole wrote:
 
  For a concrete example:
 
  10.0.0.0/16 is presently handled by a single zone file.
  10.1.3.0/24 is DHCP issued
  10.1.4.0/24 is DHCP issued

Note 1: 10.1.3.0/24 and 10.1.4.0/24 are not subnets of 10.0.0.0/16.  Did 
you mean 10.1.0.0/16 or 10.0.0.0/8?

 I haven't tested this... but I'm 99% certain that you can simply load  
 them as three separate zones, exactly as you might expect.  BIND  
 should recognize that the zone{} statements for 10.1.3/24 and  
 10.1.4/24 are more-specific than what's in 10.0/16 and act  
 accordingly.  Along those same lines, if you happen to have data for  
 either 10.1.3/24 or 10.1.4/24 inside the 10.0/16 zone file, you should  
 get an error.

You should put in proper delegations for 3.1.10.in-addr.arpa and 
4.1.10.in-addr.arpa.  Typically you'd do it like this if you're using 
10.1.0.0/16:


; in zone 1.10.in-addr.arpa
$TTL ...
@  IN SOA ...

@  IN NS first server name for 1.10.in-addr.arpa
@  IN NS second server name for 1.10.in-addr.arpa

3  IN NS first server name for 3.1.10.in-addr.arpa
3  IN NS second server name for 3.1.10.in-addr.arpa

4  IN NS first server name for 4.1.10.in-addr.arpa
4  IN NS second server name for 4.1.10.in-addr.arpa

; rest of content for 1.10.in-addr.arpa


or like this if you're using 10.0.0.0/8:


; in zone 10.in-addr.arpa
$TTL ...
@  IN SOA ...

@  IN NS first server name for 10.in-addr.arpa
@  IN NS second server name for 10.in-addr.arpa

3.1  IN NS first server name for 3.1.10.in-addr.arpa
3.1  IN NS second server name for 3.1.10.in-addr.arpa

4.1  IN NS first server name for 4.1.10.in-addr.arpa
4.1  IN NS second server name for 4.1.10.in-addr.arpa

; rest of content for 10.in-addr.arpa


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

Re: two NS servers on a single host

[Sam Wilson]

In article guel1o$2ds...@sf1.isc.org,
 Bradley Giesbrecht b...@pixilla.com wrote:

 On May 13, 2009, at 6:51 AM, Stephane Bortzmeyer wrote:
 
  On Wed, May 13, 2009 at 09:02:55PM +0800,
  Tech W. tech...@yahoo.com.cn wrote
  a message of 34 lines which said:
 
  I want to give two NS records for my domain, each NS take each of
  the IP set in the host.
 
  Why? This would be completely useless. RFC 1034 and other documents
  call for at least two name servers, for redundancy reasons. If the two
  name servers are on the same host, what's the point? There would be no
  gain in reliability.
 
 If you have ever had the ip for your name server the target of a dos  
 attack you could have blocked traffic to that ip and still had dns.
 
 Two networks to same host is network redundancy and has value.

But a in that case you would include one NS record for a host with two A 
records.  Check the NS records for my own domain for an example.

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

Re: tcp versus udp

[Sam Wilson]

In article gttqkl$ot...@sf1.isc.org,
 Barry Margolin bar...@alum.mit.edu wrote:

 In article gtrqte$2in...@sf1.isc.org,
  Sam Wilson sam.wil...@ed.ac.uk wrote:
 
  In article gtrbsa$296...@sf1.isc.org, Mark Elkins m...@posix.co.za 
  wrote:
  
   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).
  
  If the registry is testing for compliant servers then a failed TCP query 
  should flag the server as non-working, as would a failed UDP query.
 
 DNS servers MUST support UDP, and only SHOULD support TCP.  So a failed 
 TCP query should not flag the server as non-working.

You're right of course - my apologies.  A failed TCP query should flag 
the server as not supporting TCP queries, with reference to RFC 1123 
sections 6.1.3.2 and 1.3.2.  The registrar may or may not wish to 
comment on the advisability of that.  

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

Re: tcp versus udp

[Sam Wilson]

In article gtr212$220...@sf1.isc.org, Danny Mayer ma...@gis.net 
wrote:

 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.

It's not quite nonsense, only very nearly.  One can imagine a corner 
case where a router has equal cost paths to more than one anycast 
instance and that same router is set up to do per-packet load balancing, 
then it might not be possible to set up a TCP connection to that anycast 
address through that router.  This is likely to be a rare occurrence.

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

Re: stop zone transfers from coming in

[Sam Wilson]

In article gt8lk3$1pe...@sf1.isc.org,
 Chris Henderson henders...@gmail.com wrote:

 My server works as a secondary for a zone. I asked the master server's
 admin to stop the zone transfer; I didn't get any reply and thus
 commented out the zone's section in my named.conf. But I'm still
 getting zone files coming in to my server.
 
 Here is what I have commented out:
 
 #  zone example.com {
 #   type slave;
 #   file extra/example.com;
 #masters {
 #   xxx.xxx.xx.xx;
 #   };
 #  };
 
 I commented out for some other zones as well and they have stopped
 coming but not this one.
 How do I stop this?

Just asking the obvious, but have you reconfig'ed or restarted named 
since you made the change?  The other point is that master servers don't 
send zones, the slave server requests it.  The master may send out 
notify messages to tell the slaves that a change has occured and they 
should schedule a transfer, but the responsibility lies with the slave.

I'd also normally suggest you provide the real name of the zone and the 
addresses of the server, thought it might not help in this case.

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

Re: Failover

[Sam Wilson]

In article gt3l6f$17m...@sf1.isc.org, philippe.simo...@swisscom.com 
wrote:

 This is not the DNS job to check at the web service availability.
 You could make an external script that is testing for the service availibil=
 ity
 and change the dns accordingly, like (...) :
 
 web1 active  ?
 yes : was it active at last test ?
 yes : do nothing
 no : set www to point to web1 in DNS
 no : was it already inactive ?
 yes : do nothing
 no : set www to point to web2 in DNS
 
 and with having www/web1/web2 having a low TTL.

We do something like this for some not-very-critical services.  A script 
(happens to run on a nameserver, but that's coincidental) watchdogs a 
number of servers and uses (suitably secured) dynamic update to remove 
non-responsive ones from a low-TTL roundrobin.  It knows not to remove 
the last entry.

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

Re: Adding records to a domain I don't control for anyone who uses my nameserver

[Sam Wilson]

In article goadgr$2au...@sf1.isc.org,
 Barry Margolin bar...@alum.mit.edu wrote:

 In article go6pea$2ru...@sf1.isc.org,
  Brandon Dimcheff bdimc...@wieldim.com wrote:
 
  Hello,
  
  I'm trying to configure BIND to add some records to a domain that I  
  don't control, so that anybody who uses my nameserver will have the  
  additional records.  Specifically, I'm trying to add xmpp SRV records  
  so our jabber infrastructure that uses our nameserver can contact a  
  handful of domains properly.  All other records for the domain should  
  work as defined by their authoritative server.
  
  Example:
  
  dig @127.0.0.1 SRV _xmpp_client._tcp.example.com. should return my SRV  
  record hosted by my server
  dig @127.0.0.1 A example.com should return example.com's A record by  
  recursive lookup
  
  Does anybody have any suggestions?  I've tried a few different things,  
  but none of them seem to have worked.
 
 I don't think you can do this with BIND.  Its database is organized by 
 names, not types.  If a server is authoritative for a name, it will 
 never recurse for that name.

He could create a local zone for the domain 
_xmpp_client._tcp.example.com containing only the SRV record (plus the 
necessary SOA and NS records).  That way any lookups for *.example.com 
and *._tcp.example.com would get directed to the real example.com 
servers.  It's a horrible thing to do, though, to claim authority for 
someone else's address space.  What happens when example.com sets up its 
own _xmpp_client._tcp.example.com with different data in it?  Who debugs 
that?

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

Re: ARPA entries for a host with multiple IPs

[Sam Wilson]

In article go4umg$1ks...@sf1.isc.org,
 Barry Margolin bar...@alum.mit.edu wrote:

 A common practice is to create unique names for each machine, in 
 addition to the round-robin entry.  This way, if you need to perform 
 maintenance on a specific machine, you can go to it by its unique name.  
 Then you should make the PTR record point to this name.  E.g. the 
 forward zone for myzone.com would contain:
 
 ws IN A 1.2.3.1
IN A 1.2.3.2
IN A 1.2.3.3
 
 ws-1 IN A 1.2.3.1
 ws-2 IN A 1.2.3.2
 ws-3 IN A 1.2.3.3
 
 and the reverse zone 3.2.1.in-addr.arpa would contain:
 
 1 IN PTR ws-1.myzone.com.
 2 IN PTR ws-2.myzone.com.
 3 IN PTR ws-3.myzone.com.

Or it might contain

1 IN PTR ws.myzone.com.
2 IN PTR ws.myzone.com.
3 IN PTR ws.myzone.com.

Either is acceptable, but you have to decide which is more useful in 
your situation - is it more important to know which interface is being 
used to make an outgoing call (the usual use of PTR records) or is it 
vital the machine be recognised as the same one no matter which 
interface it uses?

You can try doing this:

1 IN PTR ws.myzone.com.
1 IN PTR ws-1.myzone.com.
2 IN PTR ws.myzone.com.
2 IN PTR ws-2.myzone.com.
3 IN PTR ws.myzone.com.
3 IN PTR ws-3.myzone.com.

which is technically legal but (allegedly) not many systems can make 
sensible use of multiple reverse entries and it might cause more 
confusion than it's worth.

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

Re: denied NS/IN

[Sam Wilson]

In article gl61mf$9h...@sf1.isc.org,
 Mark Andrews mark_andr...@isc.org wrote:

 In message fb979b33-df83-4460-a3e4-040cd165e...@newgeo.com, Scott Haneda 
 writ
 es:
 
  Is BCP 38 really as solid and plug and play as it sounds?  In a  
  shared, or colo'd environment, can that ISP really deploy something  
  like this, without it causing trouble for those that assume unfettered  
  inbound and outbound traffic to their servers?
 
   Yes it is.  Everyone in a colo should be able to tell you which
   source address (prefixes) they should be emitting.  You filter
   everything else.
 
   The closer to the edge that you do this the easier it is to do.

Just a niggle (because we've been bitten by this): if you have 
multihomed hosts you need to be careful.

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

Re: General performance

[Sam Wilson]

In article git9no$126...@sf1.isc.org,
 Stephane Bortzmeyer bortzme...@nic.fr wrote:

 On Tue, Dec 23, 2008 at 08:36:36PM -0800,
  Scott Haneda talkli...@newgeo.com wrote 
  a message of 35 lines which said:
 
  First, if I learn it is in fact true that all 50K zones will be
  identical, is there any reason to make 50K zone files?
 
 No.
 
  Is it ok to point different domains to the same zone file?
 
 Yes. 
 
 http://www.bortzmeyer.org/identical-domains-with-bind.html

... whilst remembering that any slave server(s) will need to have 
separate files defined for each zone, though the creation is up to the 
nameserver - they don't have to be done manually.

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

Re: MIME garbage in comp.protocols.dns.bind

[Sam Wilson]

In article ghtjng$2pd...@sf1.isc.org,
 Barry Margolin bar...@alum.mit.edu wrote:

 Does anyone still read this list via the comp.protocols.dns.bind Usenet 
 gateway?  I do, and ever since the web site and mailing list revamp last 
 month, it has been a real PITA.  About 1/3 of the messages in the group 
 have all sorts of MIME garbage in the body of the messages.  The problem 
 appears to be that the Content-type: multipart/alternative header line 
 is being stripped from the header by the gateway; actually, it ends up 
 in the body of the message.  As a result, my newsreader doesn't 
 recognize that the message is multipart, and shows all the pieces 
 literally.
 
 You can see the same thing if you view the messages in Google Groups, so 
 it's not just my news provider (Motzarella) or newsreader 
 (MT-Newswatcher).  The old mail-to-news gateway either got this right or 
 extracted the plain text alternative before forwarding.
 
 I sent mail to bind-users-request a few weeks ago, but got no response.  
 Is this bugging anyone else but me?

Yes, it's bugging me.  I use MT-Newswatcher (Mac OS X) and whilst I can 
cope with the multipart/alternative hassle (just stop reading where it 
turns into HTML - see [1]) the ones that really annoy me are the base64 
encoded messages like [2].

I'm clearly less conscientious than Barry - I haven't complained before 
now.

Sam


[1] news:ghs3de$1f8...@sf1.isc.org
[2] news:ghtbae$2er...@sf1.isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNS issues with tmomail.net

[Sam Wilson]

In article [EMAIL PROTECTED],
 David Ford [EMAIL PROTECTED] wrote:

 Sam Wilson wrote:
  I hadn't noticed it but all the records in the response to a request for 
  the MX for tmomail.net have a TTL of 60 seconds, that's the MX record, 
  the NS authority record and the additional A record.  The names in the 
  delegation NS records for for tmomail.net are different from the 
  authoritative ones, though they seem to be the same servers.  There's 
  considerable opportunity there for things to go wrong, though it all 
  seems to work fine from here.

 It will work for hours, sometimes a day before bind is unable to fetch 
 records for it again.  But immediately upon restarting bind, bind is able to 
 go fetch records for it.  I understand that the records for tmomail.net are 
 problematic but what makes the difference in bind from running a while vs. a 
 fresh restart when it comes to fetching records?  Why would it be 100% 
 successful on restart?

Dunno, but when you poke around in that area there are a whole lot more 
duelling TTLs.  But as Jinmei-san points out you may be being bitten by 
a bug.

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