On Mon, 25 Jun 2012, David Ford wrote:
> it's posted 2x, slightly different.
>
> To: comp.protocols.dns.b...@googlegroups.com
> To: comp-protocols-dns-b...@isc.org
I suspect this is an artifact of people starting a thread one place and
cc'ing one reflector or the other. I'll see if I can rea
it's posted 2x, slightly different.
To: comp.protocols.dns.b...@googlegroups.com
To: comp-protocols-dns-b...@isc.org
both cc the newsgroup
-david
On 06/25/2012 06:11 PM, Barry Margolin wrote:
I read bind-users through the comp.protocols.dns.bind newsgroup. I'm
seeing lots of duplicate posts.
I read bind-users through the comp.protocols.dns.bind newsgroup. I'm
seeing lots of duplicate posts. Most of the replies in the "CNAME Rules"
thread showed up twice.
Is there a problem with the gateway?
--
Barry Margolin
Arlington, MA
___
Please visi
Chuck,
I am talking from the point of view of a DNS server not a client resolver.
Anyways note that the entire CNAME chain is from the same wordpress zone, so
the chain should be followed without requiring an additional query and there is
no need for trying to short circuit the process by addin
Mark,
Is the first parsing step over both Answer and Additional sections, I was under
the impression that "Named" parses the response into RRSets from the Answer
section and if there is a CNAME chain both within the same zone it follows the
chain as well. But no additional sections are checked
On Jun 25, 2012, at 2:34 PM, Srinivas Krishnan wrote:
> You are using a caching resolver to check the responses and you only see
> response after its been resolved by Google's DNS server.
The overwhelming majority of Internet users are using caching resolvers running
at their ISP, employer, etc.
In message
, Srinivas Krishnan writes:
> The RFC rules on CNAMEs is fairly tight but I am seeing an increasing
> amount of traffic with misconfigured CNAMEs some of which are accepted
> by BIND as valid responses. The examples capture three trends, note
> these are actual responses:
Name
I don't know about best practice in this case, but I decided to put our reverse
entries into one "super netting" file as you call it.
We had the same problem that a lot of reverse entries were missing, so I wrote
a script to parse the forward file and create the reverse. Then I incorporated
that
Chuck,
You are using a caching resolver to check the responses and you only see
response after its been resolved by Google's DNS server. Try dig
@ns1.wordpress.com after12.failblog.org. to see the actual records that you
would receive if you were a DNS server performing an authoritative query t
We've just resolved this amicably--I'd missed the
commercial.service@rcn.comaddress, but was contacted off-list by one
of RCN's engineers, who read
this thread and has removed our domain from their nameservers. He was
quite helpful. No cease-and-desist letter needed--not by a long shot!
John
On Jun 25, 2012, at 2:13 PM, Srinivas Krishnan wrote:
> The RFC rules on CNAMEs is fairly tight but I am seeing an increasing
> amount of traffic with misconfigured CNAMEs some of which are accepted
> by BIND as valid responses. The examples capture three trends, note
> these are actual responses:
I strongly recommend splitting on /8 /16 and /24 boundries. With the
number of zones you are talking about, doing anything else will get very
confusing very quickly.
If a netblock is larger than a /24, put at the top and bottom of each /24
a comment lile explaining what size it is
For examp
The RFC rules on CNAMEs is fairly tight but I am seeing an increasing
amount of traffic with misconfigured CNAMEs some of which are accepted
by BIND as valid responses. The examples capture three trends, note
these are actual responses:
1) Example-1: CNAME in the additional section necessary to fi
Hi all,
look for some info on best practices for reverse zones. I have, a pretty big IP
space and alot of reverse zones are not created.
I want to clean it up, a few people that dont really know DNS are thinking of
"super netting" eg a top level 10.0.0.0/16 sorta thing.
but we have 100s of d
In article ,
Tony Finch 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 q
Carsten Strotmann (private) wrote:
>
> The FORMERR I'm seeing is also quite odd, as it has the "AD" flag set,
> which should normally not appear in an error type of response, but
> might be caused by a mangled DNS packet:
I think it is echoing the AD bit in the query.
; <<>> DiG 9.9.1-P1 <<>> +
It looks to me like this is an EDNS bug. I am querying the authoritative
server directly, with no firewalls in the way. The FORMERR is coming from
the authoritative server not from BIND. I get the same result over IPv4
and IPv6.
They also have a bug in their NXDOMAIN logic: extranet.microsoft.com
>> My experience with changing the timing metadata or removing the key
>> files is that named issues a warning like the following: zone /IN:
>> Key // missing or inactive and has no
>> replacement: retaining signatures. In this circumstance none of the
>> RRSIGs or NSECs are removed. They sit the
Spain, Dr. Jeffry A. wrote:
>
> My experience with changing the timing metadata or removing the key
> files is that named issues a warning like the following: zone /IN:
> Key // missing or inactive and has no
> replacement: retaining signatures. In this circumstance none of the
> RRSIGs or NSECs a
19 matches
Mail list logo
