[dns-operations] question on dns setup, name-servers on adjacent IPs

Mark Andrews marka at isc.org
Fri Aug 26 03:28:31 UTC 2016


In message <CA+8FKT9J7vs0wn1MhgsdVt3Sd=_SQctww4LyXf=TMff+O7hjLQ at mail.gmail.com>, Veaceslav Revutchi writes:
> Hello, need your opinion on a dns setup.
> 
> By looking at the query below is it reasonable to assume that the two
> name-servers for that domain are collocated or on the same l2 domain?
> 
> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> @c.gtld-servers.net. trondent.com
> +norec +noall +auth +addi
> ; (1 server found)
> ;; global options: +cmd
> trondent.com. 172800 IN NS tdcns-01.trondent.com.
> trondent.com. 172800 IN NS tdcns-02.trondent.com.
> tdcns-01.trondent.com. 172800 IN A 199.3.18.24
> tdcns-02.trondent.com. 172800 IN A 199.3.18.25
> 
> I know in theory the two could be further apart and announced as /32s,
> however mtr shows almost identical hops and latency, sprint looking
> glass shows a /24 and the rest of the world sees a /14 for those IPs.
> Would you flag this as a poor setup where a network problem affecting
> that subnet could take down both servers?
> 
> This is a vendor we make api calls to and once in a while the calls
> fail with a dns resolution error. The destination server that fails to
> resolve has an A record in the domain above. By the time the problem
> gets reported and looked at the name is resolving ok and there is not
> much in our bind resolver logs. No other dns related alerts around
> that time so I'm suspecting bind did not get a response from those two
> IPs. I'm setting up a couple of probes on the net to periodically
> query those NS, hopefully I will have more data next time it happens.
> Is there a best practice document on the number of NS and their
> distribution that I can forward to the vendor?
> 
> Also, the two servers do not respond if I set the edns version to
> something other than 0. Does that mean there is a firewall in front of
> them that doesn't handle dns properly? I understand this means not
> following the RFC.

They also don't respond to unknown EDNS flags.  There is a firewall
that has this signature which the vendor is in the processes of
fixing.

Mark

EDNS Compliance Tester

Checking: 'trondent.com' as at 2016-08-26T03:23:23Z

trondent.com @199.3.18.24 (tdcns-01.trondent.com.): dns=ok edns=ok edns1=timeout edns at 512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=timeout edns at 512tcp=ok optlist=ok
trondent.com @199.3.18.25 (tdcns-02.trondent.com.): dns=ok edns=ok edns1=timeout edns at 512=ok ednsopt=ok edns1opt=timeout do=ok ednsflags=timeout edns at 512tcp=ok optlist=ok

The Following Tests Failed

EDNS - Unknown Version Handling (edns1)

dig +nocookie +norec +noad +edns=1 +noednsneg soa zone @server
expect: BADVERS
expect: OPT record with version set to 0
expect: not to see SOA
See RFC6891, 6.1.3. OPT Record TTL Field Use

EDNS - Unknown Version with Unknown Option Handling (edns1opt)

dig +nocookie +norec +noad +edns=1 +noednsneg +ednsopt=100 soa zone @server
expect: BADVERS
expect: OPT record with version set to 0
expect: not to see SOA
expect: that the option will not be present in response
See RFC6891

EDNS - Unknown Flag Handling (ednsflags)

dig +nocookie +norec +noad +ednsflags=0x80 soa zone @server
expect: SOA
expect: NOERROR
expect: OPT record with version set to 0
expect: Z bits to be clear in response
See RFC6891, 6.1.4 Flags

Codes

ok - test passed.
timeout - lookup timed out.
To retrieve this report in the future: https://ednscomp.isc.org/ednscomp/dca5ee9dca


> 
> Thank you,
> Slava
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
> dns-operations mailing list
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org



More information about the dns-operations mailing list